Voice of Developer (VoD): Developer’s Guide to Open Source Licenses

www.toptal.com

BY DAVID MARÍN - FREELANCE SOFTWARE ENGINEER @ TOPTAL

Not all open-source licenses are the same. Some of them obligate the software supplier to grant patent licenses to users and developers of the software. Other licenses oblige the developer that uses the licensed product or library to offer the source code of this product or library under the same terms. Others simply give away the code, with no warranty of any kind or any concerns. In this article I’ll try to highlight the main differences between the most used open-source licenses from the perspective of a software user and of a software developer.

Demystifying the abstruse - open source licenses

When in 1984 Richard Stallman begun the GNU project for creating a free operating system, he recovered the idea that software should be shared between developers, engineers and users; and they should be able to improve it in a collaborative way in the same way that science is usually done.

This option contrasted with the usual concept of licensed software chosen by most of the software corporations and developers for distributing and selling their programs. Today, more than thirty years later, open-source software slowly continues conquering wide sectors of our industry: Linux, Android, Apache and Git are examples of leading open-source products in their categories.

Open-Source or Free Software?

In this article, I’ll use the terms “open-source” and “free” as synonyms while referring to software or licenses. In my opinion, both terms express the same idea. “Open-source” expresses it in a practical and technical way, and using “Free” put the focus in a philosophical and political meaning of the concept.

Unfortunately the word “free” in English, in addition to being the adjective associated with “freedom”, also means “without cost”. This is the reason that I usually prefer to say “open-source”.

Common Properties of Open-Source Software

I suppose that you already have an approximate idea of what open-source software is. But as we are going to talk about the details of the different licenses, first we need to speak about the specific properties that define open-source software.

First of all: I am not a lawyer, and this is not legal advice. In case of doubt, please refer to the actual text of the licenses I am talking about, and to your legal counselor.

All open-source software, according to the Open Source Initiative, is distributed under a license that gives its users and developers (the licensees) some rights. The full list can be consulted in the Open Source Definition, but here is a basic summary:

1. Free redistribution of the software: the software can be sold or given away as a product or included in a software package. This can be done without paying any royalties.
2. The source code of the licensed software is either included in the distribution, or at least there are well-publicized means of obtaining the source code. This source code is usable for developing modified versions of the software.
3. Creation of derived works are allowed, and the license allows them to be distributed under the same terms and license as the original software. Depending on the original software’s license, in some cases these derived works must be differentiated from original software by changing their name or version number, or can be only distributed in the form of source-code patches.
4. The software can be used by any person or group of people, and in any fields of endeavor, with no limitations.

But you must keep in mind that software licenses speak only about using or distributing permissions granted by the copyright holders. Open-source licenses may allow you to redistribute the software or derived works freely, but that allowance may also be restricted in some countries where exporting cryptographic software is banned. In a similar way, open-source licenses allow you to use the software for any purpose, but that doesn’t mean that they allow you to hack into a bank using open-source licensed software. Software patents are another example of this: some open-source licenses grant permissions to use patents freely, but not all of them.

So, can we use an open-source software in the development of a product or project? Basically, it depends on the license of the used software and the intended license for the final product. The different licenses also matter when you want to publish your own code as open-source and you are deciding which license you should use.

Copyleft

One pretty interesting concept about open-source licenses is what is usually called copyleft, the opposite of copyright. Where copyright is used to protect intellectual property (including software) from being copied or distributed, copyleft is used to ensure that open-sourced intellectual property and software can be copied or distributed as open source.

According to its strength, there are two kinds of copyleft:

• Strong copyleft: when works derived from other strong-copyleft licensed works, or linked to these works, must continue having strong copyleft licenses, or even exactly the same license. That is, those open-source works cannot be closed in the future.
• Weak copyleft: when works using weak copyleft licensed works, or linked to it, can be licensed under other licenses, even closed-source licenses. In this case, the copyleft only affects the original weak copyleft licensed work.

There are also open-source licenses without copyleft: they simply don’t care about future openness of derived software.

Permissiveness

According to their permissiveness, the licenses can also be classified in:

• Strict licenses: when you cannot mix strong licensed software with closed-source, or even with more permissively licensed software.
• Permissive licenses: when products usually can be mixed with closed-source software, or software with a totally open-source license.

Usually, strong copyleft licenses are also strict, and weak copyleft licenses are more permissive, but it doesn’t have to be that way.

Open-Source Licenses Differences

There exist many open-source licenses. The Open Source Initiative has already approved more than 80 of them. Some are redundant and could be considered as equivalent to other ones. Others are specific to the interests of the software publisher (such as the NASA license), or for a given environment or purpose (such as the Educational Community License, or the Open Font License).

This proliferation of licenses is based in specific terms in the license that, added to the basic open-source properties, allow or disallow other uses. Examples of these additional conditions can include:

• Type of copyleft: weak or strong or inexistent.
• Type of permissiveness: permissive or strict.
• The obligation of adding a copyright notice in the source code, or in the user interface.
• Automatic patent granting to the licensees.
• Considering as licensees not only the parties to whom the software is distributed, but also the users of the software (so that people using a service in the cloud that uses this kind of open-source software should have the choice of downloading the source code of the software)

Problem of Mixing Code with Different Licenses

According to what we have already said before, some licenses are permissive, allowing the users to combine the code with differently-licensed source code (perhaps with additional conditions). This case would allow to mix this kind of open-source licensed software with closed-source software. An example of this kind of license is MIT License.

Others are more restrictive, so the source code can only be combined with code that is licensed in a similar way, and the final result must be licensed with the same original license. An example of this kind of license is General Public License (GPL).

Maybe you want to combine code licensed with two different restrictive open-source licenses. Using the open-source freedom to use the software as you want, you can do this. But the final program cannot be redistributed, as it should be distributed under two licenses that are not compatible with each other.

One example of this situation was ZFS. ZFS is a very advanced and innovative filesystem that was included in OpenSolaris in 2005. It is an open-source software licensed under the terms of the Common Development and Distribution License (CDDL). Although it is open-source code, it can’t be integrated into the Linux kernel because the source code of Linux is distributed under the terms of the General Public License, another restrictive open-source license. Binaries of Linux kernel compiled with ZFS support cannot be distributed due to the license conflict.

These kinds of conflict can only be solved if all the owners of one of the open-source programs agree on changing the license, or on adding exception terms in the software license. For example: a lot of GPL licensed programs are linked with OpenSSL library. OpenSSL library distribution is licensed requiring a phrase to appear in advertising material and any redistributions. These extra conditions are not compatible with the GPL, and because of this developers of GPL products that use OpenSSL have included an exception in their license specifically allowing the linking with OpenSSL.

Differential Features of Open-Source Licenses

Now I’ll try to analyze the most popular open-source licenses, remarking their differential features, with a little guide about when to use them or not. I have sorted them from the more to less used, according to the Black Duck Knowledgebase.

GNU General Public License (GPL)

The GPL is the most popular open-source license. It was created by the FSF as the license for the GNU project, and it’s also the license of the Linux kernel.

Its differential characteristics:

• Strong copyleft.
• Very strict license.
• It’s usually called a ‘viral’ license: if you link your code to another piece of code licensed under the GPL and want to distribute the results, the whole product must be GPL-licensed.
• It’s also an ‘embracing’ license: if you are developing a software and want to license it under the GPL, you can link it or include other open-source software as long as this software has a license compatible with GPL. It doesn’t require any obligation not required by the GPL.

Usually, the used license text includes the text saying that the software is distributed under the terms of the GPL version N (or any later version).

Currently there exist two versions of GPL license in use: v2 and v3. The version 3 was released in 2007 for addressing some problems that had appeared since the release of version 2 in 1991.

The GPL v3 includes some extra clauses and terms, addressing compatibility regulations with other open-source licenses, obliging patent licensing, defining the conditions for using GPL-licensed software as firmware in appliances, and taking into account concepts as digital rights management.

MIT License

The open-source license usually known as MIT License, a.k.a. X11 license, is a very permissive non-copyleft license that allows everyone to basically use the so-licensed code for whatever you want as long as you keep the copyright message, and know that the software comes without warranty of any kind.

This license is very popular, and is used by several projects as the X Window System, Ruby on Rails, jQuery or Node.js.

It’s compatible with the GPL, so you can mix MIT-licensed code into GPL software.

Apache License 2.0

The Apache License was created by the Apache Software Foundation (ASF) as the license for its Apache HTTP Server.

Just as MIT License, it’s a very permissive non-copyleft license that allows using the software for any purpose, distributing it, modifying it, and distributing derived works of it without concern for royalties. Its main difference compared to the MIT License are:

• Using the Apache License, the authors of the software grant patent licenses to any user or distributor of the code. This patent licenses apply to any patent that, being licenseable by any of the software author, would be infringed by the piece of code they have created.
• Apache License required that unmodified parts in derived works keep the License.
• In every licensed file, any original copyright, patent, trademark or attribution notices must be preserved.
• In every licensed file change, there must be a notification stating that changes have been made in the file.
• If the Apache-licensed software includes a NOTICE file, this file and its contents must be preserved in all the derived works.
• If anyone intentionally sends a contribution for an Apache-licensed software to its authors, this contribution can automatically be used under the Apache License.

This license is interesting because of the automatic patent license, and the clause about contribution submission.

It’s compatible with the GPL, so you can mix Apache licensed-code into GPL software.

BSD License

There are 3 different BSD licenses. All of them are very permissive licenses without copyleft.

The 2-clause BSD License (or Simplified BSD License) is totally equivalent of the MIT License that was explained before.

The 3-clause BSD License (or New BSD License) adds one clause, specifying that neither the name of the copyright holder nor the names of its contributors may be used to endorse or promote products derived from the software without specific prior written permission. This version is compatible with the GPL allowing you to mix 3-clause-BSD licensed code into GPL software.

The 4-clause BSD License (or Original BSD License) adds another clause, specifying that all advertising materials mentioning features or use of the software must display an acknowledgement saying that the product includes software developed by the copyright holder. This 4-clause BSD License is not compatible with the GPL. Code with this license cannot be relicensed according to the GPL terms, as the fourth clause adds a requirement that is not required in the GPL.

GNU Lesser General Public License (LGPL)

The LGPL was created by the FSF as a modification of the GPL with a weaker copyleft, allowing the linking of LGPL-licensed software with any other software. In its origins LGPL stood for “Library General Public License”, but afterwards it took its current name “Lesser General Public License” standing for the FSF’s opinion that says that all software should be free, and because of that the LGPL shouldn’t be generally used.

You can link closed-source code against an LGPL library or software and distribute the final results as long as:

• You provide the source code of the LGPLed part, with all the modifications you have made to it.
• Any user with enough knowledge is able to replace the LGPLed part of the program with a modified version. This can be done distributing the LGPLed part of the program as a dynamic library (DLL in Windows, .so in Linux/Unix), or providing the object code of the non-LGPLed part of the program.

The LGPL v3 is compatible with GPLv3, so you can enter LGPLv3 code into GPL software.

Artistic License

The Artistic License, in its current version 2.0, is a permissive open-source license with no copyleft similar to the MIT license.

The main difference between the MIT license and the Artistic License is that the latter requires that any modification made to the code must be clearly stated.

This license is almost exclusively used in the Perl community.

The current Artistic License 2.0 is compatible with GPL: you can mix Artistic-Licensed code into GPL software.

Microsoft Public License (MS-PL)

The Microsoft Public License was created in 2008 by this company as one of the open-source licenses created by their Shared Source Initiative.

It’s a strict, weak copyleft license: it allows the creation and distribution of closed-source programs with MS-PLed code, but it obliges to use the MS-PL as the license of derived works if these are distributed in source code.

I personally think that this license is a bit perverse and contrary to the spirit of the open-source, allowing the closure of code so that in a way the copyright holder doesn’t care about what you can do with the software, but you cannot share the code for being mixed with other copyleft source code. So in another way, the copyright holder really does care about what you can do, and he doesn’t want you to use the code for reasons such as improving Linux.

The MS-PL is incompatible with the GPL.

Eclipse Public License (EPL)

The Eclipse Public License is the license created by the Eclipse Foundation for their Integrated Development Environment. It’s a restrictive and weak-copyleft license, similar in many ways to LGPL. It also includes clauses for automatic patent license granting.

The EPL is incompatible with the GPL.

Mozilla Public License (MPL)

The Mozilla Public License version 2.0 is a weak-copyleft, permissive license created by the Mozilla Foundation for its products.

We could consider this license as similar to LGPL, but with the main difference that MPL also allows the static-linking of the MPLed pieces of code into closed-source software.

The MPL, in its current version 2.0 is compatible with the GPL. This isn’t true for previous versions of the MPL.

Common Development and Distribution License (CDDL)

The CDDL is a weak-copyleft, permissive license created by Sun (now Oracle) based on MPL version 1.1. Basically, it has the same properties as the MPL. Its terms were clarified, but not substantially changed.

The CDDL is the open-source license chosen by Sun (now Oracle) for many of its products, as OpenSolaris or NetBeans, among others.

As this license was based on the MPLv1.1, this license is not compatible with GPL, so you cannot mix CDDL-licensed source into a GPL licensed software. Many people say that this was intentional, so OpenSolaris source code cannot be introduced into the Linux kernel.

GNU Affero General Public License (AGPL)

The AGPL is a version of the GPL with even stronger and more restrictive copyleft. It obliges to provide the source code of the application not only to the people receiving a copy of the software, but also to the people who use this software through a computer network.

This license was created by the FSF for giving the developers the means for avoiding the practical closure of open-source software when it is executed in network servers or in the cloud, as the GPL cannot force the service providers to give source code to the users. In this case the software is not distributed.

The AGPLv3 is compatible with the GPL3. You can put AGPLv3 code into GPLv3 code, as long as the final result is licensed under the AGPLv3.

ISC License

The ISC License is a permissive free software license written by the Internet Software Consortium (ISC). It is functionally equivalent to the 2-clause BSD and MIT licenses, after removing some language that was deemed unnecessary.

Initially used for ISC’s own software releases, it has since become the preferred license of OpenBSD (starting June 2003), among other projects.

It’s compatible with the GPL: you can mix ISC-licensed code into GPL software.

Microsoft Reciprocal License (MS-RL)

The Microsoft Reciprocal License was created in 2008 by this company as one of the open-source licenses created by their Shared Source Initiative.

It’s similar to the MS-PL explained before, but it has a bit stronger copyleft, resembling the conditions of the LGPL, CDDL, and EPL. It requires that if you mix your code with MS-RL-licensed source code and want to distribute the final results, at least the original MS-RL-licensed part must continue to be licensed with this license.

It isn’t compatible with the GPL.

Public Domain (CC0)

According to Wikipedia, “works in the public domain are those whose intellectual property rights have expired, have been forfeited, or are inapplicable”. Dedicating a work to the public domain, the author waives all his rights over it under copyright law.

There are several software projects under Public Domain, for example SQLite, the library that implements an embeddable and simple SQL database engine that is included in several other projects, such as Mozilla projects, Android, etc.

There are many ways for dedicating a piece of software to the public domain. Creative Commons has created the CC0 Public Domain Dedication, a universal way for giving away a work into the public domain. The FSF recommends using this text for dedicating software to the public domain.

Works under public domain are compatible with any open or closed source licenses, and can be mixed into any other software.

Multiple Licensing

There’s some open-source software that is double or even triple licensed. This means that a person who receives this multiple-licensed software can choose under which license he or she wants to distribute it. As every license grants different permissions and imposes different obligations, a selection must be made for choosing the license that best meets the needs.

This is a usual case for some libraries. For example, NSS is a library made by Mozilla that implements SSL/TLS support, among other security-related features. It’s triply-licensed under MPL, GPL, and LGPL licenses.

Please, Choose a License

A lot of people publish code in platforms as GitHub without any written license. Nobody should use that code. We don’t have any idea what permissions we have for using it. If you use it, you could be sued for that. It’s like if these people were teasing us, saying “Hey, look what I’ve made! Cool, isn’t it? But you can’t use it, I only wanted to show you!”.

Please don’t be one of them. If you upload your code to GitHub or similar public sites, allow others to use it and enhance it. If you don’t want to think a lot, these are my recommendations:

• If you want to keep it simple and permissive, allowing everyone to do what they want with your code as long as they provide attribution back to you and don’t hold you liable, use the MIT License.
• If you want to keep it permissive, allowing everyone to do what they want with your code but wisely enumerating the rights under copyright law and granting those rights, along with providing an explicit grant of patent rights from contributors to users, use the Apache 2.0 License.
• If you care about sharing modifications and you don’t want your code to be used in closed developments (neither in closed software products nor in closed hardware appliances), use GPL v3.
  • If you don’t care about the possibility that your software gets used in a closed appliance, use GPL v2. But please with the “or any later version” sentence, so your code can also be used in GPLv3 projects.
  • If you don’t care about the possibility that your software gets used in closed software, as long as your software or the part that uses it continues being open-source under the same terms, use the LGPL v3.
  • If you want everybody using your software through a network to have the right of getting its source code, use AGPL v3.

After all this, you may be exhausted of all these almost-nonsense quasi-legal gibberish. But do you know what? It’s needed. Because without a license, you don’t have the rights for using or distributing any code.