2008-10-30

An open source license primer

Licensing is a tricky issue, especially when it comes to software, and even experienced developers have a hard time knowing what you can and can't do with open source software. I am not a lawyer, but I've been interested in free and open source for a long time and a while ago a colleague and I held a presentation on licenses (Slides in Swedish here) at the company we work for.

To explain what this license thing is all about you need to start with Copyright, which is as old as the printing press. The whole point of copyright is to give the authors of “original works of authorship” the rights for their works so that they have control over how it will be distributed. If someone else want to distribute that piece of work, they need to obtain a license from the copyright holder, usually in exchange for a one time payment or a royalty agreement.

But what if the copyright owner doesn't want the distribution of his or her work to be limited in any way. The first thought might be to put the work into the public domain, meaning that you abandon any claim of ownership of the work. But is this really making it as “free” as possible? What if the piece of work is source code that someone will download, modify in some way and then compile to a binary program to be sold. Is the original piece of code still free?

This leads us to the use of Copyleft licenses where the idea is to use copyright law to prevent any restrictions that would limit the distribution of a piece of work, or modified versions of it.


Open source licenses are usually grouped into permissive, weak copyleft and strong copyleft. In the picture above the BSD license is a permissive one, LGPL a weak copyleft and GPL and AGPL are strong copyleft, meaning they include the “Liberty or Death” clause that was introduced in version 2 of the GNU GPL. Of course there are other common open source licenses, and OSI has a nice list of them here, but for simplicity I'll only discuss the ones mentioned above.

There are several versions of the licenses mentioned above and some are not compatible with earlier versions. Since GNU GPL is probably the most common open source license FSF have a chart showing compatibility with the latest version compared to the previous version.



Permissive licenses

It's important to note the word Modified before BSD in the image above. The original BSD license, sometimes called "BSD-old" or "4-clause BSD", had an advertising clause that required authors of derivatives of a BSD-licensed work to include an acknowledgment of the original source. This made it incompatible with GPL, and also unmanageable because so many acknowledgments were required. Code licensed under BSD can be used in closed source projects, as long as a copy of the license is included in the distribution. Other permissive licenses have similar demands.

If you release code for a new protocol or media codec, it might be a good choice to put it under a permissive license because it makes it more likely that companies that are not yet open source friendly will still implement it.

Weak copyleft

If you are using code covered by a weak copyleft license like LGPL, it gets a bit more complex. The GNU Lesser General Public License allows users to link to the LGPL program without having to put their own program under the same license. There are still restrictions, like that you have to make it possible to upgrade the LGPL program to a more recent version and if you modify any LGPL licensed code you have to release the changes.

This type of license is often used in toolkits like GTK+ and media libraries like gstreamer so that they can also be used to build proprietary products and get wider adoption.

Strong copyleft

Strong copyleft licenses like GPL or AGPL are a lot more restrictive when it comes to what you can do to the code. They are called strong because they include the “Liberty or Death” clause, meaning that all the code have to be open. This includes linking into libraries and running the code within the same process. It is precisely because of this strictness that LGPL was created and there is also several exceptions to the GPL covering for example GCC, fonts or the GNU Classpath.

There are two major versions of the GPL, 2.1 and 3. The big differences have been explained succinctly by the FSF and basically concerns these points:
  • Tivoization - Using crypto hardware to control what code is allowed to run on the device.
  • DRM - Restrictions on what code you write and distribute.
  • Patents - Using GPL code gives you right to use the patents in it.
  • Digital distribution - Physical distribution of the source code is no longer an explicit demand.
In addition to these changes, the text have become a bit easier to read and clarifies certain details concerning for example out-sourcing. It is also compatible with more licenses and gives you a chance to rectify your mistakes in case you violate the license unintentionally.

The difference between GPL and AGPL is that AGPL has an extension that covers online services like forums, blogs or online stores. This covers the “legal hole” in the GPL where you are not distributing a program but still provide a service for users over the net using GPL licensed code.

Remember

The important thing to remember is that these copyleft licenses are all distribution licenses and not user licenses. This means you are allowed to modify and use them internally within your company or home without releasing the changes to the code, as long as you do not distribute it in any form. Even if the company doesn't want to release all their code, hopefully they will still contribute to the upstream development of the copyleft code they use.

But if you do distribute code, be sure that it does not violate any of the licenses. It has been proven in court several times by GPL-Violations that a copyleft license has the same legal status as a proprietary license. If you think no one will find out that you are using copyleft licensed code because it's built into the firmware of your product you are probably wrong. There is even a manual written by Armijn Hemel describing how to detect license violations in consumer devices.

To be clear, building an application that runs on top of Linux or an open source application server like JBoss does not mean you have to open the source of your application.

If you plan to use GPL code in any way, do it right and follow the Software Freedom Law Center's excellent Guide to GPL Compliance!