Open-Source License Guide

As a developer, you might be wondering about licensing options opened up before you and your software. If you consider closed-source licenses, everything is pretty much straight-forward – ultimately, you get the full right to possess and use your software, while everybody else willing to try it out needs to purchase the same right for a definite sum of money. However, what about open-source licenses?  Well, that requires more of your time and attention, as some open-source licenses allow for a complete freedom of action with the software, while some have certain restrictions that must be taken into account. This article aims at giving you an insight into the not-that-straightforward world of open-source licenses.

Why Open Source?

It all started back in the 80-s when the GNU operating system was developed. Its founder, Richard Stallman, came with an idea that for the software to be effective, it should be available to everybody, including the users, to contribute to its constant improvement. At that time, however, such an idea seemed to be absurd, as the majority of software corporations licensed their products primarily for commercial purposes. As we can see today, open-source model is gradually taking over due to the obvious productivity as well as simplicity of management; among the leaders we find familiar brands such as Linux, Apache, and Android.

So basically, open-source software is a genuine path towards a constant improvement of your product. By allowing other developers to modify your code, you create an independent collaboration team that will work on sustaining the software’s competitiveness on the global market.

What is meant by open-source software?

To be on the safe side we won’t make up a new definition of what open-source software is because there is already one provided by the Open Source Initiative (OSI), an organization aiming to promote open-source software in general. According to their official Open Source Definition, the open-source software is meant to be distributed under a definite license. It subsequently provides its developers and users with a set of rights, such as:

• The software can be used for commercial but also non-commercial redistribution, which may include either selling or free sharing of the product. The owner of the software may or may not be granted with royalties.
• The users/developers should either have a free access to the source code of the software or be able to obtain it by means of other additional tools in order to use it for further software modification.
• The users/developers can create their own software on the basis of the original under the same rights and conditions. It should be noted that these so called derived works need to somehow differ from the main software: they can take a different name or version number, or become an original-based patch.
• The software can be used by literally anyone (individuals or groups of people) regardless of their field.

However, there are some restrictions as for the realm of application of the open-source licenses. Thus, you can redistribute your software in your own country as well as in other countries unless some of them prohibit it by their state law. Moreover, you can use your software for any purposes but those that can cause moral or material harm to other individuals and organizations.

Finally, when it comes to using open-source software in other projects (including commercial ones), you should consider both the license of this software and the intended license of your future product. If they contradict each other, you might need to decide on another type of license for your project. However, there are other options.

Real-life licensing conflict and its resolution

A good example of such conflict is the licensing conflict between Linux and ZFS file system. Originally, both of them are open-source, but while Linux is distributed under the restrictive General Public License, ZFS carries the Common Development and Distribution License (CDDL) whose restrictions contradict those of GPL.

As it was said before, one of the possible solutions here could be that one party should simply change their license (in our case it would be easier for the owners of ZFS to do that). However, if the current license is considered to be for the most part appealing, it’s possible to add ZFS as an exception in Linux’s GPL. In fact, this was once done to OpenSSL library which is part of many GPL-based programs. The only requirement is that OpenSSL has to be redistributed and advertised under a specific phrase provided by the given exception.

Popular features

Regardless of their type, all open-source licenses share a set of common features that make them different from closed-source and mixed licenses.

1. The notion of copyleft

In short, copyleft is a counterpart of copyright. While the latter exists to protect intellectual property from illegal copying and distribution, the former is there specifically to provide open-source software with the ways to be freely copied and shared. In its turn, copyleft can be strong and weak. If the original open-source software is licensed under strong copyleft, all the modified software will have to be licensed under the same license as well, meaning that they will also have to include the originally stated restrictions, if any. On the other hand, if the original open-source software is licensed under weak copyleft, the derived objects can be licensed under any other types of licenses, including closed-source ones. However, there are cases when open-source software does not possess any copyleft, which means that the owners don’t care if you make the modification closed-source or open-source.

2. Level of permissiveness

This feature is pretty close to the notion of copyleft. In fact, open-source licenses can be either strict or permissive. Strict licenses are often related to strong copyleft, as they don’t allow derivative works to be anything but open-source. On the contrary, permissive licenses allow closed-source derivatives to be linked to the original open-source software.

3. Copyright notice

This feature is obviously restrictive and is used in some open-source licenses to partly limit the initial freedom of software distribution. If it’s the case, such notice should be added either in the source code or the UI.

4. Patent rights granting

We’ve mentioned earlier that not all open-source licenses automatically grant patent rights to software owners, so if you’re willing to take out a patent for your open-source software, choose wisely.

5. Extending the notion of licensee

In open-source licenses, licensees are not only those for whom your software is distributed but also all other users, as, according to OSI, they too have the right to look at and edit your source code.

The most popular open-source licenses

By now, there are more than 80 licenses registered in the OSI. A considerable part of them comprises common-type licenses that are pretty much equivalent to each other. The rest of them were created to suit specific needs of their licensees, like, for instance, Open Font License or Educational Community License.

We can conclude that while each and every license generally allows for free distribution and use of open-source software, there are several conditions that exist to suit specific needs of the owners and (sometimes) partly limit its freedom, mainly:

• Copyleft
• Permissiveness
• Patent rights granting
• Copyright notice
• Extension of licensees

Now let’s look at the top of the most popular open-source licenses approved by many leading software developers on the global market.

Apache License 2.0

The Apache License 2.0 is considered to be the most popular one, according to tl;dr Legal. The license belongs to the Apache Software Foundation (ASF), and it was originally used for the Apache HTTP Server. It is fully compatible with another licensing leader, the GNU General Public License (GPL), which means that if you license your open-source software under the GPL and later decide to link it to any of Apache’s codes, you will definitely manage to do it. Apache License 2.0 has the following features:

• Non-copyleft;
• Very permissive;
• Supports automatic patenting (both distributors and users of the software automatically receive patent licenses);
• May include copyright notice file, which means that any further modification should also contain it;
• Any unchanged parts of the original source code that have been included into a derived work should preserve the Apache License;
• Any licensed file, even when modified, should preserve its original trademark, patent or copyright;
• Every changed file should contain the actual notice stating that the changes have been made;
• Any contribution to Apache-licensed software can obtain Apache License.

MIT License

The MIT License is an official open-source license of the Massachusetts Institute of Technology and it’s widely used by software developers worldwide. The famous holders of the MIT License include jQuery, X Windows System, Node.js and Ruby on Rails. Its primary features include:

• Non-copyleft;
• Very permissive;
• Preserving copyright and permission notices is obligatory;
• Compatible with GPL.

GNU General Public License (GPL)

This is the most well-known license which was created by Stallman’s Free Software Foundation (FSF) in 1985. It was used for licensing the whole GNU operating system and later Linux as well. The second version of the GPL came out in 1991 and was intended to become less restrictive towards software developers. Throughout the next decade, v2 appeared to be rather practical although lacking compatibility with other licenses. This problem was solved in the GPL v3 which was released in 2007. Apart from that, additional changes were made, such as those concerning the definitions of source code, user, and consumer product. Currently, the GPL covers the following set of characteristics:

• Strong copyleft;
• Strict license type (binding the derived works to the GPL);
• You can license your code under the GPL and link it to another open-source code if its license is also compatible with the GPL;
• Certain hardware limitations on creating GPL-licensed software modifications;
• Patent rights granting;
• Compatibility with Apache License 2.0 and GNU Affero General Public License.

GNU Lesser General Public License (LGPL)

Originally, the first L in LGPL stood for Library stressing the need for providing a less restrictive license specifically to those software libraries that were supposed to be used with open-source and proprietary software, especially C library. The Library General Public License was first released together with the GPLv.2 in 1991 and was received as its complementary component. In 1999, FSF renamed it to the Lesser General Public License thus indicating that software owners can and should basically be able to do without this license at all.

The main features of the LGPL include:

• Weak copyleft;
• Permissive, if:
  • the derived work contains the source code of the original with the notice on every modification added;
  • it is possible to replace the original part of the code with a modified version without creating a licensing conflict. For this, you should either distribute the original part in a form of .dll or .so library, or changing the modified version of the code to the object code;
• The third version of LGPL is compatible with GPL v.3.

GNU Affero General Public License (AGPL)

Unlike LGPL or even GPL, the Affero General Public License is considered to be pretty much restrictive, requiring its licensees to provide the source code of their software not only to the owners of the actual software but also to those accessing it online. FSF aimed this license to the developers concerned with network or cloud vulnerabilities that could break the access to the Internet based source code.

AGPL’s differential characteristics are:

• Strong copyleft;
• Strict license;
• The version 3 of AGPL is compatible with GPL v.3 but because its more restrictive, the modified code will be licensed under AGPL v.3 as well.

BSD License

BSD License is represented by the actual family of non-restrictive open-source licenses which became the basis for many other licenses they came out later, including MIT License and PHP License. This family consists of three different licenses possessing various levels of permissiveness and compatibility.

The 2-clause BSD License (also known as Simplified BSD License) has exactly the same characteristics as the MIT License thus being completely non-copyleft, very permissive and compatible with GPL.

The 3-clause BSD License (also known as New BSD License) contains an additional clause in the copyright notice stating that derived works of the licensed software may not be promoted or endorsed by the names of the licensees without their permission. This license is also compatible with GPL.

The 4-clause BSD License (also known as Original BSD License) is specified by another clause. It adds that any kind of advertising that mentions the software must contain an acknowledging line stating that the given product contains the software belonging to copyright holders. Furthermore, due to the licensing conflict, the software licensed under the 4-clause BSD License cannot be linked to GPL-licensed program.

Artistic License (v. 2.0)

This is another non-restrictive licensing option if, for some reason, you find the MIT License or the BSD License unsuitable for your open-source software. The Artistic License is known for being primarily used for distribution of the Perl-based software in combination with GPL. The license’s features include:

• Non-copyleft;
• Very permissive;
• Compatible with GPL;
• Any modification of the licensed software should be acknowledged in the form of a separate notice.

Microsoft Public License (MS-PL)

The Microsoft Public License is considered to be the least restrictive one among those established by Microsoft. After having been approved by OSI in 2007, it gave the green light to the developers seeking to make their contribution to the Microsoft-owned software.

MS-PL’s characteristics:

• Weak copyleft;
• Strict license;
• All the derived works have to be licensed under MS-PL as well.
• Incompatible with GPL.

Mozilla Public License (MPL)

The Mozilla Public License was developed by Mozilla Foundation specifically for implementing their official software. Its primary aim is to eliminate the conflicts frequently occurring between proprietary software and open-source software developers. It is also:

• Weak copyleft;
• Permissive;
• The current version of the license (v. 2.0) is compatible with GPL;
• Only those modifications are subject to MPL that lead to changes in the original code.

Microsoft Reciprocal License (MS-RL)

The second open-source license introduces by Microsft’s Shared Source Initiative in 2007. Features:

• Strong copyleft;
• Permissive, under the condition that the original source code of the modified software retains the MS-RL;
• Not compatible with GPL.

Eclipse Public License (EPL)

This license is an official license created by the Eclipse Foundation for its official products.

Features:

• Weak copyleft;
• Permissive if (in some cases) the changes in the modified programs are acknowledged;
• Incompatible with GPL.

Common Development and Distribution License (CDDL)

The license is originally based on the Mozilla Public License (v. 1.1) and in most cases shares the same differential characteristics. The CDDL was created by Sun Microsystems (later acquired by Oracle) and used for distribution of the company’s major products, such as OpenSolaris and NetBeans.

Features:

• Weak copyleft;
• Permissive license;
• Not compatible with GPL (due to the fact that it was based on MPL 1.1 which didn’t have GPL compatibility either).

ISC License

The authors of the license are the Internet Software Consortium (ISC) that used it for distributing their own software. The ISC License used to have a set of additional restrictions but was later simplified due having some expired clauses. Since 2003, it’s also used in OpenBSD operating system.

• Non-copyleft;
• Permissive;
• Compatible with GPL

Common Public License (CPL)

The Common Public License was introduced by IBM that used it for licensing their products. It was later chosen by Microsoft for licensing their Windows Installer Xml. In most cases, CPL can be superseded by the Eclipse Public License.

Features:

• Weak copyleft;
• Strict license.

European Union Public License (EUPL)

The license was created and approved by the European Commission in 2007. It’s translated to 22 languages spoken in the member states and it’s mainly directed for the EU governments to provide their software developers with a free distribution opportunity that will at the same time comply with the EU Law.

Features:

• Strong copyleft;
• Strict license;
• Compatible with GPL v.2. Compatibility with GPL v.3 is possible through licensing under CeCILL v. 2 and then relicensing under GPL v.3.

Creative Commons Zero License (CC-0)

Basically, not only software but any type of intellectual property can be put on the public domain if, at some point, its rights become expired, deprived or unusable. In case with open-source software, the author himself can release his work to the public domain by waiving his rights over it in favor of other authors and users. The easiest way to do that is by using the Creative Commons Zero License (CC-0) created by Creative Commons in early 2009. CC-0 allows software to be used by and shared among other people under legally approved terms and conditions.

The license is actively used among software developers aiming to share their works under public domain. Among the well-known projects there is SQLite library which is extensively used in major projects, such as Mozilla and Android.

CC-0 is the most democratic license that is:

• Non-copyleft;
• Permissive;
• Compatible with any other licenses, including closed-source ones.

Double- and triple-licensing

Sometimes, owners of open-source software license their works under several licenses to allow its recipients for larger scope of distribution. This is especially the case with libraries that are often used in the development of other open-source or closed-source projects. For instance, NSS library, providing SSL/TLS support, is distributed under three licenses: MPL, GPL, and LGPL.

For now, you should’ve caught the idea that some licenses can be mixed with one another, while some contradict each other. So, before you choose the right licenses, make sure that they are not involved into the licensing conflict and meet your personal needs.

Tips on the license choice

Such online public platforms as GitHub allow software developers to share their codes with others in such a way that hardly anyone will care whether these codes are licensed or not. However, you really SHOULD care about that, because if you decide to use one of those codes for your own profit, it is likely that one day you will be caught and sued for illegal actions. To be on the safe side, try to protect your own code from being used by somebody in the way which you wouldn’t like. So when uploading any software online with an intention to make it freely accessible, used, and improved by others, take time to make this possible in a legal way – to protect you or anybody else from undesirable consequences.

Now, depending on your actual intentions, you might want to choose one of the open-source licenses discussed above. To make it easier for you to choose, we offer you the following tips:

1. Choose the MIT license if you don’t care about the future of your code but need the derived works to attribute to you as the author of the original source code.

2. Choose the Apache 2.0 License if you don’t care about the future of your code but want your contributors to grant patent rights to those who will use the final product. This license will also require other developers modifying your software to keep the rights reserved under copyright law in the code.

3. Choose GPL v.3 license if you CARE about your code and its future modifications and don’t want it to be used in closed-source projects.

4. Choose GPL v.2 license if you don’t care if your code is used in closed-source projects.

5. Choose LGPL v.3 license if you don’t care if your code is used in closed-source projects but you want it to remain open-source whatever the case.

6. Choose AGPL v.3 license if your code is meant to be used through a network and you want the users to also have an access to its source code.

Open-source licensing trends

To help you make your choice even more weighed, we offer you to take a look at some figures representing the latest licensing trends that have taken place during the last decade.

According to Blackduck’s recent stats, the MIT License takes the leading position (25% of the general license use) as the most commonly used license in open-source projects. The GPL v.2 goes second (22%), Apache 2.0 – third (16%), and GPL v.3 – fourth (9%). In fact, the tendency was completely different back in 2008. At that time, GPL v.2 was considered to be more reliable from the owner’s point of view, which resulted in the license having the highest percentage in use. Since then, however, the rates dropped sharply – it lost more than 21%; MIT and Apache 2.0 licenses, on the other hand, significantly increased in use during the same time period. The main reason for such abrupt changes lies in the global shift from strict to permissive licensing.