Open Source Licenses - Part 2

In my last post, I wrote an overview of what is open source, and common concepts for open source licenses. In this post, I would focus on a few popular licenses in open source software.

GNU General Public License (GPL)

The GNU General Public License is the license under which the GNU operating system is licensed out. The license has been authored by Richard Stallman’s Free Software Foundation, and is a copyleft license. The current version of the license is version 3.0, however the previous version 2.0 is also quite popular. Since I personally have not dealt with version 3.0, I would stick to version 2.0 in this post.
The GPL v2.0 starts with a preamble, which summarizes the philosophy behind the license. In other words, the belief that software should be free to run, modify, and distribute (while noting that "free" means freedom, and not free of cost). It also points out that there are certain restrictions which are necessary to ensure that a user of the software does not limit the freedom of other users. Paragraph-4 in the preamble section states...

This is a good summary of what the license is trying to achieve. The authors believe that the software should be available to all to use and modify freely, however, such modifications should not result in the restriction of the freedoms of other users. The preamble goes on to mention that in order to enforce this, the authors assert their copyright over the software, and are licensing it out to users under the terms and conditions of the next section. The preamble ends with an explicit patent grant.

The preamble is followed by the main "Terms & Conditions for Copying, Distribution and Modification" section. Paragraph-0 states that the license applies to both the original software work, and any derivative works. The term "derivative works" is defined as "...a work containing the Program or a portion of it, either verbatim or with modifications and/or translated into another language". This is a bit generic definition, and is one reason why GPL is not very popular for use in commercial software products. Companies that want to use open source along with their proprietary software architecture are deterred by this wide definition of derivative works. The concern is that under such a definition, all of their software stack would become a "derivate work" if they link with the open source library, and/or use the functions of the open source library. This would cause proprietary software to become "contaminated" - a term used to define the situation where proprietary code has to be licensed out in source code form, because it comes under the copyleft clause of an open source license. However, in certain cases - notably in the Linux kernel license - the authors clearly state what they consider as derivative works, and what are unrelated code. Here is a snippet of the explicit notice put in the Linux license (rest of the license is GPL v2.0)

I believe that this explicit exclusion of user space programs from the definition of derived work has been a key factor in the popularity of Linux in commercial products.
Paragraph-1 & 2 of the terms & conditions lay out the rights to redistribute the software, either as-is, or modified, provided the terms of the GPL remain unchanged, and prominent notices are displayed informing users of the terms of the license. Paragraph-3 deals with cases where one may wish to distribute the software in object code (i.e. not in source code) form. This section allows the user to do this, provided the corresponding source code is made available when requested. 

Paragraph-4 & 5 point out that the software can be copied and modified only under the terms of the license, and if a user start modifying or distributing, it implies that he or she accepts the terms and conditions. Paragraph-6 states that when a user is redistributing the software, he cannot add any further restrictions in the license (i.e. a reiteration that the redistributed work must adhere to the original terms and conditions of the GPL).

Paragraph-7 advises that if a there has been a legal restriction on a certain user distributing the software, for e.g. an injunction, which contradicts the terms of the GPL, then this does not excuse the user from adhering to the GPL. This paragraph is interesting, as it covers patent licenses. For example, if Company-A owns a software library that is patented, and it feels the same has been infringed by an open source library (under GPL). Company-B has a patent license agreement with Company-A which prohibits B from redistributing, royalty-free. Then B cannot use the open source GPL library (since such use would mean redistribution). I’m not sure why this clause is in place, but the fact that it is so specific seems to point out that is has been placed in the license as a result of some past practical problem. Feel free to add comments below, if you know the specific reason for this clause.

Paragraph-8 deals with cases where geographical laws may differ, for example, the US restricts export of cryptology software. This paragraph allows a user to add additional restrictions for certain geographies. Paragraph-9 & 10 explain that there may be different versions of the GPL, and that in some cases the Free Software Foundation may allow certain parts of the software to be licensed under different terms. Paragraph-11 & 12 wind up the "Terms & Conditions" section with a no warranty and no liability notice.

GNU Lesser General Public License

The GNU Lesser General Public License (L-GPL) is similar to the GPL, in that it is also a copyleft license. However the key distinction is that it clearly states what constitutes a derived work. The preamble here states that this is done in order to make it easier for use with commercial, proprietary software. The word "Lesser" in the name probably means that there are less restrictions here than in the GPL.

To achieve this, L-GPL defines two kinds of derived work

• Work Which Uses The Library -No modification of open source library, but just uses it’s functions. Could be either static or dynamic linking.
• Work Based On The Library - Involves modification of the open source library.

While all constraints of the L-GPL applies to "work based on the library", only certain restrictions apply to "work which uses the library". A block diagram representation of the two is as below. The green boxes labeled "new code" represent the changes done by a user, while the blue blocks labeled "LGPL licensed library" represent the original open source library.



For “work that uses the library”, the “new code” part can be excluded from copyleft clause by doing one of the following

• Provide either source code or object code so that the user can modify the Library and then relink to produce a modified executable.
• Use a suitable shared library mechanism (i.e. dynamic linking DLL’s).

A common misconception is that the LGPL instructs users to use dynamic linking if they would not like to license their modifications under the same terms as the L-GPL. But the reality is that L-GPL just states that using DLL’s or dynamic linking is just one way to comply with the clauses for "work that uses the library". The basic reasoning is that other users should be able to upgrade/modify the L-GPL licensed library, and still the derived work would compile and run.
For example, say v1.0 of a LGPL licensed library is being used as part of a "work that uses the library". The "new code" part may be proprietary.

 

If another user wishes to upgrade the v1.0 of the LGPL licensed library, he should be allowed to do so, without breaking the functionality.

 


Now, if the linking between the "new code" and "LGPL licensed library" is dynamic, then there’s nothing further to be done to ensure works. The dynamic (shared library) loading would ensure that new versions of the LGPL licensed library works (assuming no incompatible changes, like removal/change of APIs in the new version). If however, a static linkage exists, the LGPL states that the object code of the "new code" part should be made available so that another user can still upgrade the LGPL licensed library by re-linking the object code using compilation tools.
Since dynamic linking means that the "new code" (which could be proprietary software) need not be redistributed in any form, it makes this license very popular for use with proprietary software products. The L-GPL tries to maintain the freedom of open source, while still making it palatable for use with commercial software. The rest of the license is quite similar in spirit to the GPL.

Permissible Licenses

Certain open source licenses are very permissible, and do not have any copyleft clause. While this makes it even simpler for companies to use open source libraries with their proprietary systems, it also means that there would be lesser innovations in these, as contributions/redistributions are not mandatory. One of the most popular permissible open source license is the Berkely Software Distribution (BSD) license, which is used for BSD-Unix. The license is very simple, and short. It simply states...

"Redistribution and use in source and binary forms, with or without modification, are permitted provided that the following conditions are met:

• Redistributions of source code must retain the above copyright notice, this list of conditions and the following disclaimer.
• Redistributions in binary form must reproduce the above copyright notice, this list of conditions and the following disclaimer in the documentation and/or other materials provided with the distribution.
• Neither the name of the nor the names of its contributors may be used to endorse or promote products derived from this software without specific prior written permission."

This is followed by a "no warranty" and "no liability" notice, as is common in all open source licenses.
While the original BSD license was used for licensing the BSD Unix OS, there are many similar licenses which are collectively termed as "BSD-like" licenses. All of these "BSD-like" licenses allow reuse, and modification of code without contribution (i.e. not copyleft). As a consequence, software libraries licensed under such terms have found wide use in commercial products. A good example is the independent JPEG group’s JPEG codec implementation, which is widely used in smartphones, including Apple’s iPhone.

Dual Licenses
Lastly, I should mention that in some cases the same software package or library is licensed under different licenses. A user of the software has options to choose which license to use. Usually the case is that a large technology firm licenses out a popular software component under GPL, with the option for other companies to buy a commercial license if they do not wish to comply with the terms of the GPL. Qt is a good example here, where it’s available under LGPL, but there’s an option for a commercial license as well. Another example is Java, where Oracle (earlier Sun) licensed it under GPL, as well as commercial licenses, allowing licensees to choose what they are comfortable with.