Understanding Open Source Licensing

To make your code free and open, you should assign it a license that grants specific permissions to potential users. In practice, each code file should have a comment line that details the identity of the author and the selected distribution license. You also need to place a complete copy of the license in the root folder of your project, in a file with an explicit name (for example, “licence.txt”).

But before getting to this point, you must first choose a license. This is not as complicated as it may seem. However, a couple of case exceptions come to mind: when you don’t have a clear idea of the permissions you want to grant, or when complex projects involve patented parts.

No License = Protected Code

Most countries’ legislation includes laws to protect the production of intellectual works. Whether this protection is called copyright (in common law) or author’s rights (in civil law), it is harmonized under international agreements such as the Berne Convention and through the work of institutions such as the World Intellectual Property Organization (WIPO).

The provisions of the Berne Convention were adapted to the digital world in 1996, extending protection to computer programs and databases. As a result, the code you create is an intellectual work and is covered by copyright/author’s rights protection.

Even without a copyright notice featuring the author’s name at the beginning of your code, it remains fully protected. You retain the rights to use and distribute this code, even if it is downloadable by third parties. You retain the right to sue anyone using your code. You may grant discrete licenses to individuals or organizations to use this code.

Home-Made License

Don’t bother with home-made licensing. It’s a waste of time. As you’re probably not a lawyer specialized in the field, the terms of your license might betray you by opening the door to uses you couldn’t foresee. There are enough types of licenses out there, including those approved by the Open Source Initiative (OSI), that you don’t need to write your own. OSI-approved licenses have been written or reviewed by experts and lawyers, and many have even passed the test in court.

Furthermore, you can’t expect users to read and understand an untried license. When a person or company wants to use a project licensed under the GPL-3.0, Apache-2.0, or MIT licenses, they are in familiar territory. It’s quick and easy for them to determine whether the license in question grants sufficient rights for the use they want to make of your code.

Strong Copyleft Licenses

A copyleft license gives permission to use, modify and redistribute the code freely, but only if the original license remains intact, both in the original project and in any modification made to the original project. The first instance of this type of license was the GPL (General Public License) written by Richard Stallman for the GNU project. When you use code from a copyleft-licensed project in your own work that you then distribute, it must adopt exactly the same license as the source project.

The philosophy underpinning copyleft is to assure the contributing authors that their work will benefit the world and always remain free while preventing exploitation by companies that would give nothing back to the community. For example, if you write a fork of WordPress that is licensed under the GPL, you can only distribute it under the GPL. WordPress is distributed under the GPL because it is itself a fork of a GPL software, b2/cafelog, created by Michel Valdrighi in 2001. To put it more simply, all derivative projects inherit the license, even if the project has evolved considerably since the initial fork.

Among the most popular copyleft licenses are GPL-3.0 and AGPL-3.0, a version of the GPL that is better adapted to the use of programs running on servers.

Weak Copyleft Licenses

Essentially similar to those with strong copyleft, they are more permissive in terms of the “virality” of the protection they grant, the capacity for “forced inheritance.” In particular, weak copyleft licenses are attributed when creating libraries that may be reused without requiring a copyleft license for the entire project. Only modifications made to the library itself always remain under the copyleft license.

The best known are LGPL, an “attenuated” version of the GPL, Mozilla MPL 2.0 and CDDL v1.0, originally developed by Sun Microsystems. 

Permissive Licenses

Permissive licenses impose minimal constraints on the use, distribution, or modification of projects. As a result, they all look very similar. Among the most commonly used are Apache-2.0, BSD-2-Clause, BSD-3-Clause and MIT. Extremely permissive, they often require little more than mentioning the developers and the original license for portions of reused code in the comments of your code and/or in the documentation.

Public Domain License

The only license of this type approved by the OSI is the Zero-BSD Clause (0BSD). This license does not require anything, not even an attribution. It boils down to the sentence “Permission to use, copy, modify, and/or distribute this software for any purpose with or without fee is hereby granted,” followed by a paragraph disclaiming any responsibility on the part of the author for any possible damage resulting from the use of the provided program.

Go Further

• List of licenses approved by the Open Source Initiative.
• The very interesting OSI Frequently Asked Questions.
• Jim Salter, from Ars Technica, offers a detailed review of the most common OSI-approved licenses: “Open source licenses: What, which, and why.”
• GitHub offers a very simple (but perhaps too simple) tool to guide you in your choice: “Choose an open source license.”