Understanding Open Source Licensing

In works licensed under an open source license, anyone is permitted to modify and redistribute, as long as a given set of criterion are met. But, that's the simple definition. Life in the open source licensing world is much more complex than that. Before going any further, let us catch a glimpse of what an open source license means and what are its associated caveats. Strictly speaking, an open source license must comply with the definition specified by Open Source Initiative, as laid out at http://opensource.org/ docs/definition.php:

To quote from the definition itself, “The license shall not restrict any party from selling or giving away the software as a component of an aggregate software distribution containing programs from several different sources. The license shall not require a royalty or other fee for such sale.”

Thus, if you license your work under an open source license, you do not have a commanding influence over who gets to use your work and in what manner the said person decides to use it. Surely, you can restrict commercial/derivative usage of your work, but in all likelihood, you cannot essentially make an income (or, at least a GOOD income) using open source licenses.

Further more, another important aspect of open source licenses is the permission 'to fork'. Forks of an open source project are derivatives of the project which evolve from it, but take a different line of growth and establish an altogether separate identity.

Arguably, the prime reason why developers tend to opt for open source licenses is that it lets their software roll on as a group or community exercise, and this in turn enhances productivity manifolds. For instance, Acquia Network, the parent organization behind Drupal, currently consists of 160 employees. Obviously, a company of that size cannot sustain a mammoth project such as Drupal. However, Drupal itself being open source, is helped by the numerous volunteers from the community. Similarly, WordPress rides the wagon of a super-active community while its parent organization, Automattic, concentrates on select issues.

Open source licenses nowadays come in multiple versions. Wikipedia has a rather incomplete list of some of the major free licenses at http://en.wikipedia.org/wiki/Free_software_license While all such licenses cater to diverse purposes with the same goal ('freedom'), we shall restrict ourselves to only the major ones for the sake of simplicity. From a small/medium enterprise's point of view, the noteworthy licenses include GPL/LGPL, MPL, Apache License and BSD License.

Before going any further, let us spend some time getting an overview of each major license named above. The technical and tactical details of these licenses can be adjudged after reading each, and the links for the same can be found at the website of OSI.

For an SME, GNU General Public License, or GPL as it is popularly called, is a well known license. It prohibits proprietary forking of the software, is easily understandable, and universally respected. It is also one of the most restrictive Open Source licenses, and the term 'restrictive' here applies more to enterprise usage, as well shall see later on. Also, GPL is the license behind Linux kernel.

MPL, or Mozilla Public License, as the name suggests, is Mozilla's version of GPL, though in a slightly less restrictive manner. For an enterprise, software licensed under MPL mean that the code can be used, re-used and distributed – all in a commercial environment. However, just like the GPL, MPL does not blend well with proprietary licenses.

If your enterprise comes across a software licensed under the BSD license, breathe a sigh of relief! You're in safe hands – you can happily use the BSD licensed-work in any commercial/non-commercial project, or even blend it with a proprietary fork. BSD license is known for its less restrictive nature. Your work is still copyrighted, and the project remains open source, but you do not even need to make the entire source code public in the first instance.

The Apache License, on the other hand, strikes a compromise between BSD license and GPL. You can still use such software in an enterprise environment, but unlike a BSD license, Apache does provide an explicit license clause for patents (though such clauses do not generally matter much for a small enterprise).

Another point worth noting here is the recent trend to 'dual-license' or 'multi-license' software. This happens when someone creates a fork of an existing project, but the said project's license may not be compatible with the newly created software's purpose or targeted usage.

In such a case, it becomes imperative to create a dual-licensed or even multi-licensed work. For example, MySQL is licensed under GPL. By its very definition, GPL does not allow commercial and/or proprietary forks. Thus, if one wishes to create a commercial yet non-proprietary software that incorporates usage of or even embeds MySQL, he will need to create a dual license for the software.

   Now that we have discussed the major licenses and the crux of their nature, we shall take a closer look at the info an enterprise needs to possess about the most popular open source license – GPL.

Before we proceed, let us understand the way software licensing works. A software is comparable to a book. Now, the authors (programmers) write the book (software), and get it copyrighted (proprietary). The book then comes out in the market and the readers (end-users) obtain it. If it is a proprietary book, they can read it, and stop at that. There may also be certain restrictions, that they can only keep one copy of the book, and cannot offer it to their friends or get it photocopied (piracy). Further more, super-closed licensed books may also come with regulations that forbid readers from reading the book at public places – they must read the book only at their office/home (use the software only on personal machines).

However, if the book comes with a GPL license, and belongs to the copyleft community, they can read it, and even pass it on, but they cannot create a fan-fiction replica of the book and attempt to sell it, without acknowledging the original book and GPL itself. Similarly, as the additional chapters (updates/fixes/patches) are released, they get appended to the book, and the responsibility lies with the reader to obtain the newer chapters.

Very clearly, GPL adds an altogether new dimension to the concept of copyleft and open source. In today's software world, GPL is one of the standard mechanisms to ensure that programmers are credited for their hard work and at the same time the entire community benefits from their innovations.

For a small/medium enterprise, an open source license matters in the sense that the programmer's intellectual property is not violated and, at the same time, productivity is not sacrificed due to an otherwise restricting proprietary 'legal talk'. All in all, open source licenses are a boon for organizations. However, unlike other open source licenses which are pretty straight-forward, GPL deserves slightly closer scrutiny to avoid unwanted hassles. Perhaps the sole irritant is the concept of 'derivatives' in GPL.

Generally, SMEs tend to pick up GPL licensed works assuming them to be as open source as any works under any other license. According to GPL v3, a derivative of a software is “one that is linked, statically or dynamically, to the original work”. However, this definition itself is considered vague, especially in an enterprise environment. For instance, your enterprise is using a derivative of an original GPL licensed work, with the difference being that the original software catered to a general audience while this derivative software caters especially to SMEs. Now, the two software are indeed linked, but only for the name sake. The original software does not target SMEs, while the newer one does. And as it goes without saying, you are employing this software in a commercial environment. However, philosophically, the newer software is still bound by GPL and there are limits to what you can do with it in a commercial usage scenario.

A good example of this situation is Joomla! The CMS is licensed under GPL, and by its definition, the associated themes and extensions must also be under GPL. However, a theme provider catering especially to enterprise/corporate websites once released a few themes (copyrighted, non-GPL) without paying heed to this catch. The outcome? Enterprises using the said themes were forced to change the look of their websites (consider it in terms of enterprise web identity, expenditure, etc). Ever since then, Joomla! community takes care to specify that any themes/extensions created for Joomla! must have code licensed under GPL (additional media such as animations, images and graphics can be non-GPL).

The cure to the above problem is as simple as the problem itself – keeping the eyes open! The concept behind GPL is simple – once the parent software is GPL, the offspring must at least acknowledge GPL. If it does so, it is safe for enterprise usage.