Presented by J Aaron Farr, Treasurer for Apache Software Foundation
Aaron tries to unravel the mysteries of the various open source licenses for us. Starting by answering questions from the floor (only one was asked), and then moving into an explanation of open source licenses that are available, he is covering a lot of ground in fifty minutes. I really enjoyed the breakdown of licenses into three categories and the simple explanation of these categories.
The only question asked at the beginning of the session was “I have been told that as long as I am using open source code internally (setting up IT infrastructure for example), I do not have to worry much about licensing. Is this true?“. This seems to be a topic that is up for interpretation. Aaron explained that if you are modifying an open source work and distributing it within your company, it seems that you are not “publicly distributing” and the source code is available within the company, so you are probably safe. Of course, you still have to be careful not to accidentally include it in a commercial product without understanding the licensing.
Open source licensing is about giving you a certain set of rights and empowering you to do certain things with the source of a project. The license determines the rules the community lives by. We will look at the goals, philosophy, example uses, and community implications of some various licenses.
First, why not release everything in the public domain? First, there are jurisdictions in the world that do not have the concept of public domain. Secondly, this doesn’t give you the ability to explain that you do not offer a warranty, which may leave you legally liable for some things. Thirdly, most open source projects desire some sort of attribution requirements, as well as stipulating certain requirements on distribution and derivative works.
Some common goals among many licenses: Ensure that the code remains open source. Reserve some sort of control. Building a commercial coalition around an open source project. Some licenses are chosen specifically for a market strategy, or to encourage a third party marketplace built around the project.
Most licenses can be broken down into three families:
- Give me credit - i.e. Apache License, BSD, MIT - primarily concerned that attribution is given
- Give me the fixes - i.e. Mozilla (MPL), Eclipse (EPL), LGPL - I don’t care if it’s included in larger works, but I would like fixes to my software contributed back.
- Give me everything - GPL - if it ends up in your redistributable, I want it.
The “Give me credit” or “permissive” licenses such as the Apache license say that derivatives can sub-license, and may have some conditions, such as warranty, but these are not required. Credit to the original authors is required. They allow anyone to contribute to it because everyone has free access afterwards. It makes it difficult for any one entity to control, because at any time it could be taken and a separate commercial product could be made from it. This allows for competing services based on a single product. Typically, these licenses are found on a lot of lower-level projects.
The “Give me fixes” or “weak copylefts” licenses such as Mozilla, Eclipse, and LGPL. These tend to end up with a single entity in control since all fixes flow back into that first project. This ends up resulting in less forking, but is still very “business friendly”. They also encourage incorporation of code into larger works. These licenses tend to be used in a lot of libraries or platforms.
The “Give me everything” or “strong copylefts” licenses like GPL say that all derivate works must remain under the same license. Linked works may also need to remain under the license (depends on type of linking). This makes it hard to incorporate it into commercial products. The original copyright holder ends up retaining a lot of control over derivative works. For example, if you don’t want to open source your derivative work, you could go back to the original copyright holder and obtain a secondary type of licensing, similar to what MySQL offers.
The diagram above is one that he used during his presentation and is provided by the Free Software Foundation that shows how licenses work together.
The Apache license is a permissive license, but requires attribution via a NOTICE file. There is no trademark grant - you can not use the trademark of Apache - you may say it is “based on Apache FOO”, but it could not be called “Apache FOO”. The authors do grant use of any patents that are part of the software distributed under the license.
Disclaimer: These are simply my notes from his session at ApacheCon. Neither myself, as maintainer of this blog, or J Aaron Farr, are lawyers. Anything written on this page is not intended as advice, and you always bear your own responsibility for making sure that you are complying with all licensing and legal requirements of any software. For more information, see http://opensource.org/