Open source tools like Apache and Python come with licensing terms that can be hard to understand, which can make it difficult to know whether you can legally use the tools in your commercial application. For example: If you write a program in Python, are you required to release your program’s source code into the public domain? (Answer: No.) Here’s a brief introduction to open source software licensing.
The first thing to understand is that all software licenses are based on copyright law. Whoever holds copyright on a particular piece of software gets to dictate the terms of that software’s use. If a copyright holder releases code into the public domain, he is essentially “un-copyrighting it” and waiving all rights to the code.
So rule #1 is: If a piece of code is in the public domain, you can incorporate it into your commercial application, email it to all your friends, or wallpaper your apartment with it. There are no restrictions whatsoever.
If a piece of code is not in the public domain, the copyright holder owns the code and can dictate the terms of its use. He may require that you pay license fees, use the software only in non-commercial applications, or use the software only on the second Tuesday of each month. The copyright holder can require anything at all, limited only by his imagination. If you don’t like the terms, you are free not to use the software.
Most open source software is copyrighted under terms that allow you to use the software freely (e.g. incorporate it into your application, resell it, etc.) However there are sometimes strings attached – for example you may have to display a banner mentioning the open source software, or include its copyright notice along with your own.
So rule #2 is: If you include non-public-domain components in your application (whether open source or not), you must review their licensing terms and make sure that you comply with all of them. You can’t assume that open source software is simply “free”.
Some (but not all) open source licenses contain a concept called copyleft. This is the requirement that if you create a derived work from the open-source software, the derived work must carry the same license. This makes the license infectious. For example if you download a copylefted application whose licensing terms allow source code to be freely distributed, then make some changes, you are free to sell the result as a commercial product – but the source code for your product must also be freely available and redistributable.
The notion of copyleft was invented by Richard Stallman, who many years ago released several applications into the public domain and became frustrated when he saw companies create products out of them. He didn’t mind that the companies were profiting commercially from his work – but he found it intolerable that the companies would copyright the modified sources and refuse to grant him access. He created the notion of the copyleft license – backed by copyright law – to enable him to release his code to the public without enabling others to create derived closed-source products.
Some people share Stallman’s feelings – they don’t want commercial enterprises creating proprietary works from their free code, and include the copyleft notion in their licensing terms. Others don’t care, and license their works more permissively.
The most well known copyleft license is the General Public License (GPL). If you create a derived work from GPL software, you can still sell it commercially, but your derived work must also be covered under the GPL – and therefore you must make your source code available.
Rule #3 is therefore: If you include copylefted components in your application (i.e. components whose licensing terms include the copyleft concept), then be careful – your entire application may have to be covered under the same licensing terms or you will be in violation of copyright.
Here is a list of common open-source licenses and a summary of their terms (including whether each one is a copyleft license or not):
It’s important to understand the precise conditions under which including a copylefted component makes your application a derived work (and hence “infects” your licensing terms). For example if you publish a CD containing several applications, one of which is covered by the GPL, that does not make the CD a derived work that must also be covered by the GPL. Your program must be intimately coupled to the copylefted component in order for it to be considered a derived work. The rules are spelled out clearly in the GPL Frequently Asked Questions list:
For example, if you write a program in a language whose implementation is licensed under the GPL, your program is not infected – unless your program actually links dynamically with GPL libraries. (The FAQ goes into great detail, including a discussion of plugin architectures and their licensing implications.)
Let’s work through an example. Say you are working with Microsoft’s CAB (Composite UI Application Block). It contains the following clause in its licensing terms:
[You agree] that you have no right to combine or distribute the Software or modifications with other software or content that is licensed under terms that seek to require that the Software or modifications (or any intellectual property in it) be provided in source code form, licensed to others to allow the creation or distribution of derivative works, or distributed without charge.
Would it be okay to incorporate log4net or not? Let’s work through the rules. If log4net was in the public domain, you would be free and clear. But it’s not – it’s licensed under the Apache Software License. However that license is a non-copyleft, permissive license that enables free use of log4net in commercial applications. Therefore it does not “seek to require” anything at all, so it is not in violation of Microsoft’s terms. So you are out of the woods.