Saturday, July 22, 2006

3rd party software proviso

As you build out the next killer app, (perhaps we should bring that description up to date. How about "killer service") it is extremely likely that you will use off the shelf (ots) software. It is in fact unthinkable in this day and age of mash ups, social networks, and open source that you would build everything from scratch, any more than Toyota would build all the parts it needs for its cars.

Given the possibility of the sale of your company here are three major things to consider when licensing 3rd party software whether open source or no.

Distribution
If you plan to redistribute your application, i.e. sell it to a customer and have it reside in their place of business you must have the right to distribute the third party software. If the software library you are using is not open source your contract with them must give you the right to distribute their library along with your software. Depending on the nature of the business this may range from an OEM agreement in which you pay royalties to the third party software manufacturer to a royalty free arrangement where you just pay for development licenses. In either case (and those in between) it must be handled in the agreement. If the library is open source then your obligation is dependent upon the particular open source license the software was created under. The most popular open source licenses today are GPL, LPGL, BSD, and MIT. GPL is by far the most prevalent accounting for nearly 68% of the projects listed on Source Forge (according to Wikipedia). In GPL and LPGL you must distribute the source code with your software as well as placing the GPL copyleft notice at the top. GPL is the least permissive of open source licenses and claims that software that uses GPL software is also GPL. The LPGL (lesser GPL) is more permissive and is commonly found in libraries whereas GPL is commonly found in applications. LPGL allows distribution of the library as a linkable (harkening back to the world of linked languages, such as C) component. I believe you still must distribute the library source code with the product, but do not need to distribute the source for your proprietary part of the product. The most permissive of all are the BSD and MIT licenses which allow you free and unrestricted use to the software, although I think they require the author headers be maintained in any distributed source. BSD and MIT are starting to become more prevalent as I see more and more new libraries and tools pop up that were created under these licenses.

If you are running your software as a service with a thin client interface (html or flash, also the newer Yahoo Widgets would fall into this category as well) and the core of your software resides on your own servers you will still need to have some agreement in place with software vendors. They may only charge you for dev licenses but could also charge on a use model (number of users, number of servers, etc.). The open source arena is easier to deal with here because you're not actually distributing your software, instead only using it internally and exposing outward some set of functionality. No mess.

Transferability
If you are a startup and you believe there is a good chance that you might be bought someday then the software that you license as part of your overall product or service must be transferable or assignable to the purchasing entity. Open source transferability follows the same conventions as distribution, so there are no additional considerations here (unless of course, you've open sourced your software as a result of embedding GPL and your buyer wants to make this software proprietary. In this case you will need to swap out the GPL code for your own or more permissive open source code). For non open source libraries and applications you will often see something like the following in a software vendor's license agreement:

Subject to the terms and conditions of this Agreement, Software_Company_X grants to Licensee a personal, nonexclusive, non-transferable, non-assignable and non-sublicenseable, limited license to use the software identified in the product schedules attached to this Agreement
This will not work for you. The provision you will want to carve out will say something like:
Licensee may assign this Agreement in its entirety in the event of a merger, acquisition or sale of all or substantially all of its assets, without Software_Company_X’s prior written consent; provided, however that for any proposed assignment Licensee may not assign or transfer this Agreement to any competitor of Software_Company_X that develops and/or sells similar technology and is listed on Exhibit A.
Companies will want the competitive carve out. Just lock it down to a limited set listed in an exhibit, otherwise the word competitive is open to interpretation.

Intellectual Property Ownership
If the intellectual property you create is built upon 3rd party software this is considered a derivative work. Again, GPL will not work for you. This is somewhat tricky overall depending on how important the role of the 3rd party software is in the creation of the IP. The best you can do here is to carve out a provision in the software license agreement that clearly defines your rights as follows.
Subject to Software_Company_X’s IP Rights in the Product and any derivatives thereto, title and ownership of all proprietary rights, including any copyright, patent, trade secret, trademark or other intellectual property rights, in and to any software created by Licensee will at all times remain the property of Licensee.
After this, pricing negotiation is easy ;)

2 comments:

Anonymous said...

Interesting Post!

A few notes: Based on my (limited -- I'm no lawyer) understanding of these licenses, LGPL does not require you to distribute library source code with the compiled product.

However, you do need to ensure your product is dynamically linked against the LGPL library, allowing others to substitute updated/patched versions of the library with your application. Source code for the LGPL library must also be available , but not necessarily bundled.

Staticly linked (against LGPL code) executables may also be distributed, but only if a dynamically linked executable is also available for download or included with the product distribution. I've seen several commercial Linux software vendors do just this (release a static linked version of their software, but also make a dynamically linked version available for LGPL compliance), as earlier Linux distributions weren't as forgiving with dynamic library issues.

Jinbon H Wrong aka Sloop John B said...

This is fastinating, really fastinating. Do the killer app actually kill the other app?

pull your banner ads until google does a better job