This article is triggered by my frustrations at and by reading Bruno Lowagie’s post “FOSS and liberal licenses“. Bruno’s post was a reaction to “Open Source, Software Hygiene and STDs” (which includes a link to an old but interesting article about software hygiene).
It is my impression that only few developers are aware of the implications of licenses of the open source libraries they use. Most don”t seem to care. They think that once it is “open source” they can do whatever they want. It is often used as “free as in free beer”. As Richard Stallman pointed out long ago (what is free software), it should be about freedom, about “free as in free speech”.
Unfortunately though, the limitations imposed by many of the open source licenses can limit your freedom a lot. These limitations can be commercially viable, which may serve the users, but this is not always the case.
Before continuing, let me be clear, I am a developer, not a lawyer. This is my interpretation from reading licenses and trying to interpret them. Examples given are from the Java world because that is what I know best. I am focussing on open source libraries and frameworks, especially the commercial implications can be quite different when not embedding the project.
Most applications which use an open source library to not respect the license
Really!
Many licenses (for example BSD style licenses) require you to include a copyright notice. It is unclear to me whether emitting the copyright notice to the console is sufficient. The safe bet (sometimes required) would be to include it in something like an about box or a notices page which can be accessed from anywhere in the application. Some popular Java libraries for which this applies include jdom and xstream.
Some licenses are viral. This especially applies to GPL and AGPL licenses. By including such a library in your software, you are forced to use that license for your software. If your software uses iText (version 5+), it should be open source with AGPL license. If your software uses the MySQL JDBC drivers, it should be GPL.
Not all licenses can be combined (there goes your freedom). This is specifically relevant for the GPL family of licenses (see FSF’s “Various licenses and comments about them“). Sometimes licenses are updated to remedy such incompatibilities (for example Apache License v2 is GPL v3 compatible while earlier versions are not compatible).
A notable example in the Java world is the increasingly popular EPL license which is incompatible with GPL/LGPL.
More complications
When reading the above, it might seem that a very permissive license like MIT or BSD is best for included libraries. Think again. Patent law (especially in the United States, mush less in the European Union – for now, see here) might change that. Maybe the license should include a notice assuring that contributors cannot force you to pay them patent licenses on code they contributed. Maybe the license should try to at least make patent infringements clearer. Some licenses like Apache v2, EPL and the GPL family of licenses seem to do this – though not necessarily in a compatible way, see “Software patents and free software“.
Which license for your project?
There are way too many open source licenses, see the OSI list. Do not create another one!
Like David A. Wheeler, I would recommend using a GPL compatible license as there are many useful libraries in with a license from the GPL family (most JBoss libraries for example).
I would choose one of the following:
- MIT : very liberal, almost no restrictions (actually ISC is probably even simpler/better, but this is too obscure).
- Apache (ASLv2) : also very liberal but with some extra constraints regarding patents. These restrictions make me favor it over MIT.
- Affero GPL (AGPLv3) : a restrictive license which allows you to sell commercial licenses for inclusion in non-free (specifically non-AGPL) software. This can be an advantage if you want to build the software into a business.
I would also recommend that all contributors sign a CLA. This assures copyright is held by one organization which can greatly simplify things when license changes are being discussed or when litigation occurs.
Effect of license on commercial success
Open source software is commercial software. Most projects (especially those with a significant code base) are developed commercially, meaning that at least part of the development work is done by professional developers in their paid time.
Some projects are owned by a company (for example JBoss, iText, Activiti, Geomajas). The company will then use the project to generate sufficient revenue to pay developers to maintain and improve the product.
The license can significantly affect this ability to generate revenue.
- A more permissive license like Apache or LGPL can enhance the popularity of the product. Developers can often include such libraries in their project without needing permission (or risking blame). Once the library is important in the project, a need for paid support, service level agreements or extra features can arise.
- A more restrictive license like GPL or AGPL restricts including the library for free, giving the opportunity to sell licenses which are less restrictive.
The advantages of permissive licenses are demonstrated by projects like the JBoss application server and Activiti.
JBoss was originally (ten years ago) used by developers because it was free and faster then the for-pay options of that time. Licenses fees and migration costs opened the door to using JBoss in production, giving the backing company opportunity to sell support contracts and training.
Activiti was started (my interpretation, simplifying) because users (including Alfresco) requested the popular jBPM product to change license from LGPL to Apache. This was denied by the project owner. Alfresco stepped up to build a new BPM engine and managed to lure core jBPM developers to do this. The permissive license allowed other companies to see commercial opportunities in this project allowing a community and successful library to be built very quickly.
The iText case shows a mixture of both approaches. The permissive license from the early versions (in combination with the quality of the product) allowed a large body of users to grow. Even today developers can include the old version in new applications without asking permission growing the user base even more. At some point a more recent version may be needed which forces users (which now rely on the library) to buy a license. Mind you that this would not be a good strategy to follow, some users are alienated by the change of license as they feel they suddenly need to pay for something they were given.
End note
You are a developer. You don’t want your work to be pirated, so please don’t pirate my work either.
If you use software, check the license, see if it is compatible with your project. If you cannot change your project to be compatible (typically by including the necessary notices or changing the license on your software) then either buy a waver (“commercial license”) or don’t use that software!
