Not too long ago, acquiring software was pretty easy: gather requirements, meet with vendors to evaluate products, select the winner. Legal review took place late in the process, and the final terms that both customer and vendor could live with were generally agreed to quickly.
That was then. This is now.
Open source software has gone from quirky and free to mainstream for the enterprise. Rather than handling objections about "free software," I now find myself having to justify a non-open-source solution I may recommend to my prospects and customers. Customers are not interested just because it’s “free” -- mergers and acquisitions in the commercial space have obsoleted so many products that open source is often the "safe" solution now.
The catch with open source software -- the dark side if you will -- is the potential for license mismatch. Let me explain.
Know Your License
Open source software can be distributed under several different licenses. The most popular varieties are GNU, Apache, MIT and BSD. Each has its own unique requirements, often with subtle differences.
Three are quite similar in their licensing terms: BSD, Apache and MIT are all relatively user friendly, known as “permissive” in license-speak. Basically, if you use a tool licensed to you in a product, you generally need only provide attribution to the original developer project in your code and documentation.
GPL, the GNU Project, is the giant in open source community because it is essentially "pure" open source. GNU has two different licenses: GPL v3.0 and the more liberal “Lesser GPL” license, which is a bit less restrictive. For example, under GPL, all of the code you write that uses GPL v3.0 code must be distributed under the GPL license.
The "lesser" LGPL license is a bit less restrictive -- for example, you can link in other LGPL projects with your product without the requirement to LGPL your code. What happens if you also use an Apache licensed library in your code? Developer beware!
The MIT license, like GNU, requires attribution in your code and documentation. Unlike all of the others mentioned here, it features a very simple and brief license.
Apache, which covers all of the "Apache Zoo" projects including Lucene/Solr, Zookeeper, Hadoop and more, allows derivative works without the requirement to contribute changes back to the project. It also allows commercial products to use Apache licensed open source tools. Attribution is required, as with all of the other projects mentioned here. It is these license terms that make Apache the choice of so many of the big data and search companies today.
Finally, BSD provides a license that is pretty much wide open as long as you provide attribution in code and documentation. With BSD licensed products, if you can build it, you can do pretty much whatever you please.
Time for the Lawyer?
While many of the license terms seem to have the largest impact on products written for sale or for public distribution, don’t think you’re off the hook. Some of the license terms require that, if you modify any of the open source code, you have to submit the changes back for inclusion into the public code. If you’ve created a proprietary algorithm to spot stock market moves, you want to be darn sure you don’t develop under such a license, or your proprietary algorithm goes public.
Some other potential risks for legal review:
- Some licenses make it difficult or impossible to mix code provided under a different style license
- GPL requires that any software you use in conjunction with the GPL code be released under GPL
- There may be intellectual property rights issues related to rights and ownership
If you license software from a company that includes open source libraries in its distribution, there’s a good chance that the vendor will limit your liability. On the other hand, a few bucks spent for a lawyer now may save many more under duress later on. Measure twice, cut once.
In fact, open source is now so prevalent that it’s worth asking every vendor you buy software from 1. if they use open source in the creation of their code; 2. what license that software uses; and 3. have they had legal review of the product, specifically with respect to the software licenses in use.
While I'd stress speaking with a lawyer as the way to go, there are some good sources of background information. New Media Rights Open Source Licensing Guide offers side by side comparison of the licenses mentioned above and includes a handy chart that breaks down the differences. Black Duck provides a list of the 20 most popular open source licenses with links for further information for many.
What's the Answer?
As is often the case, “it depends.” If you are going to use open source in your application, spend some time with a lawyer who knows and understands software and open source software licenses.