Enlarge /. Most open source projects are far more restrictive with their brands than with their code. Puffy from OpenBSD, Tux from Linux and Meditating Gnu from FSF are among the few FOSS logos that can be easily and legally remixed and reused for simple illustration purposes.
Most people have heard of open source software at least – and even have a pretty good idea of what it is. His own luminaries argue relentlessly about what you call it – with camps that fight for everything from free to libre to open source and any combination of the above arguments – but every expert agrees that it's not open source (or whatever) if there is no clearly assigned license.
You can't just publicly release a lot of source code without a license and say, "Whatever – it's there, everyone can get it." Because of how copyright works in most parts of the world, freely available code is copyrighted by the author without an explicitly declared license. All rights reserved. This means that it is simply unsafe to use unlicensed code, published or not – nothing prevents the author from coming after you and charging royalties when you use it.
The only way to actually make your code open source and freely available is to attach a license to it. You would prefer a comment with the name and version of a known license in the header of each file and a complete copy of the license in the root folder of your project called LICENSE or LICENSE.TXT. This naturally raises the question of which license should be used – and why?
There are several general types of licenses available, and we'll cover each in a separate section, along with one or more prominent examples of this license type.
Standardization – proprietary, all rights reserved
In most countries, any code or content is automatically copyrighted by the author, with all rights reserved unless otherwise noted. Although it is a good form to include the author and copyright date in the header of a code or document, it does not mean that the author's rights are invalid.
An author who makes content or code available on his own website, in a Github repository, etc. – either without a specified license or with an explicit declaration of copyright – retains both the usage and distribution rights for this code, even if it's trivially easy to view or download. If you execute this code on your own computer or on your own computers, you are violating the rights of use of the author and he can take civil action against you for infringement of his copyright, because he never granted you this right.
If you copy this code and share it with a friend, publish it on another website, sell it, or otherwise make it available elsewhere than the author originally published, you have violated the author's distribution rights and they are available to you Bring civil lawsuit against you.
Note that an author who owns a code base can individually license people or organizations to use that code. Technically, you never "buy" software, even if it's packaged in a physical store. What you are actually buying is a license to use the software, which may include physical media that contains a copy of the code.
Licenses from own cultivation
The short version of our commentary on self-licensing is simple: just don't do it.
There are enough well-understood, OSI-approved open source licenses in the world so that almost anyone or any project should be able to find one that suits them. If instead you write your own license, potential users of your project, content, or code will have to do what the author didn't want – read and understand a new license from scratch.
The new license had not previously been tested in court, which was many (if not all) of the OSI-approved open source licenses. More importantly, your new license is not widely understood.
If a person or company wants to use a project that is licensed under GPL v3, Apache 2.0 or CC0, for example (more on these licenses later), it is relatively easy to find out whether the license in question rightly grants enough rights to that right Purpose to be suitable. It is cheap and easy to get advice from a knowledgeable intellectual property lawyer because that knowledgeable IP lawyer should already be familiar with these licenses, their jurisdiction, etc.
However, if your project is licensed "Joe's Open Source License v1.01", nobody knows what that means. Legal advice for a project under this license is much more expensive – and delicate – because an IP lawyer would have to rate the text of the license as a completely new work that has not been proven and has not been tested. The new license may contain unclear text, unintentional conflicts between clauses or otherwise cannot be enforced due to legal problems that the author did not understand.
If you do not select a license approved by OSI, a project can also be excluded from certain rights or grants. For example, both Google and IBM offer free use of parts of their patent portfolio for open source projects – and your project, no matter how "free" you view it, may not qualify with a license you created. (IBM explicitly mentions OSI license approval as a licensing requirement.)
OSI approved licenses
The open source initiative maintains a list of approved open source licenses that meet the OSI definition of "open source". In OSI's own words, these licenses enable "free use, modification and sharing of software". There are many overlaps between these licenses, many of which probably should never have existed – see "Own Licenses" above – but at some point, each of them gained enough traction to go through the OSI license approval process.
We'll divide this list of licenses into three categories and list some of the more notable examples from each. Most authors do not have to read and understand the entire list of the OSI. There are usually not enough differences between common and unusual variants of a general license type, so it is worth deviating from the most commonly used and understandable versions.
Strong copyleft licenses
A Copyleft license is a license that grants permission to freely use, modify, and redistribute the intellectual property covered – but only if the original license remains intact, both for the original project and for any changes to the original project. This type of license – sometimes dismissively or fearfully called "viral" – is the one that is associated with such famous projects as the Linux kernel, the GNU C compiler and the WordPress content management system.
A copyleft license can be "strong" or "weak" – a strong copyleft license covers both the project itself and any code that is linked to a code within the covered project. A weak Copyleft license only covers the original project itself and makes it possible to link code not licensed with Copyleft – including proprietary code – with functions within the project licensed with weak Copyleft without violating its license.
Some of the most popular licenses for strong copyleft are:
- GPLv2– The public GNU license allows free use, modification and distribution of the covered code. However, the original license must remain intact and cover both the original project and any changes. No naming or patenting is required in the GPLv2, but the seventh section prohibits redistribution of GPLv2-licensed code if patents or other reasons would render the redistributed code unusable for a recipient. The GPL also requires that anyone distributing compiled versions of a project also provide the original source code, either by providing the source code along with the distributed object code or by offering it on request.
- GPLv3– Version three of the GNU Public License is similar to GPLv2 in most cases. However, patents are treated differently – the GPLv2 prohibited redistribution under the GPLv2 if this might require license fees for patents that cover the work. The GPLv3 goes one step further and explicitly grants free usage rights for patents that are then or in the future owned by a project employee. The GPLv3 explicitly grants recipients the right to break digital rights management (DRM) codes included in the covered project to prevent them from being charged with violations of the Digital Millennium Copyright Act or similar "tamper-proof" laws ,
- AGPL– The Affero GNU Public License is effectively the GPLv3 with a significant additional clause. In addition to offering GPL freedoms to those who receive copies of AGPL-licensed software, it offers users who interact with the AGPL-licensed software the same freedoms over a network. This prevents a person or company from making significant, valuable changes to a project that is intended for widespread network use and refusing to make those changes freely available.
We're going to give the AGPL a little more ink outside of our bulleted list, as it's a little more difficult to explain the impact to someone who isn't very familiar with copyleft. To better understand the implications, we will look at a real AGPL license project and a fictional scenario involving a large company that may want to take it over.
Nextcloud's web-based file sharing suite is an AGPL-licensed project. Because it's licensed under a GPL variant, anyone or any company can download, install, and use it for free, either for themselves or to offer other services, including paid services. Let us imagine a hypothetical company – we call it PB LLC and its product Plopbox – that decides to open a large commercial website that offers paid access to managed, hosted Nextcloud instances.
As Plopbox scales to millions of users, PB LLC makes significant changes to the code. The changed code consumes far less server resources and adds several features that Plopbox users consider valuable enough to significantly differentiate Plopbox from Nextcloud vanilla installations. If Nextcloud – the open source PB LLC project used to create the Plopbox service – had been licensed under the standard GPL, these changes could remain proprietary and PB LLC would not be required to make them available to anyone ,
This is because the limitations of the standard GPL only apply to redistribution and PB LLC has not redistributed the modified version of Nextcloud. Since PB LLC has installed Nextcloud only on its own servers, there is no obligation to forward copies of Nextcloud – either the original version or the modified version – to third parties automatically or on request.
However, Nextcloud is not licensed under any of the standard versions of the GPL – it is licensed under the Affero-GPL, and the Affero-GPL grants networked users of a covered project all rights associated with the GPL, not just recipients of distributed code. Therefore, PB LLC would actually be obliged to make its scalability and changes to new functions available in source code form (and possibly in object code form) to anyone who has both used the project (e.g. by opening a Plopbox account) and has requested a copy ,
Weak copyleft licenses
A weak Copyleft license is essentially similar to a strong Copyleft license, but does not extend its "viral" protection beyond link boundaries. Changes to the weak copyleft library (or any other project) itself must keep the original license, but any code outside of this project – even fully proprietary code – can be directly linked to features within the project with weak copyleft licenses.
There are relatively few weak copyleft licenses. The most common ones are:
- LGPL– the Lesser GNU Public License. Sometimes incorrectly referred to as the "Library" GNU Public License because it is most commonly used in shared libraries. Compatible for use with GPL-licensed projects.
- MPL 2.0– the Mozilla Public License. MPL 2.0 is compatible for use with GPL-licensed projects. earlier versions were not.
- CDDL v1.0—The Common Development and Distribution License, originally written by Sun Microsystems. CDDL is known to be considered incompatible with the GPL, although this incompatibility has not been tried in court.
The main difference between the LGPL and the MPL is the assignment. To link to a LGPL project from a non-GPL-compatible project, you must "clearly indicate … that the library is used in (and) by this license." The MPL has no mapping requirements; You can redistribute MPL projects and link them to functions within an MPL project without having to communicate this.
The Mozilla Public License also offers "forward migration". The Mozilla Foundation, as the license manager, may be able to create updated versions of the MPL with unique version numbers in the future. In this case, any user of a project-licensed MPL 2.0 can decide to use it under the original MPL 2.0 or a later version of the license.
The CDDL similarly enables forward migration, but defines the license manager as Sun Microsystems and not as Mozilla Foundation. Unlike LGPL and MPL 2.0, CDDL is generally considered – possibly on purpose – not to be compatible with the GPL. Some companies have already opted to dynamically link CDDL and GPL-licensed code, particularly Canonical, manufacturer of the Ubuntu Linux distribution, who announced in early 2016 that they would sell a Linux port on the ZFS file system.
At Canonical, we have a legal review of the licenses that apply to the Linux kernel and ZFS, including a discussion with the industry's leading software freedom legal advisor.
We have come to the conclusion that we are acting within the rights granted and in accordance with the terms of these two licenses. Others independently reached the same conclusion. There are different opinions, but please remember that these are opinions.
A major contradiction to Canonical's position arises from the Freedom Conservancy software, which states that linking CDDL and GPL code is necessarily a GPL violation. While the SFC undoubtedly finds this, it expresses "sympathy" for Canonical's goals, and its conclusion focuses on asking Oracle (the CDDL's license manager, who currently owns Sun Microsystems) to resolve the issue.
Should Oracle make the original ZFS code base available under a GPLv2-compatible license – including one of the compatible permitted licenses – this availability would again be a grandfather in the later OpenZFS project, without having to laboriously consult each individual contributor.
We do not recommend the modern use of the CDDL license – due to its GPL incompatibility, it is neither generally useful as a licensed license nor as a "GPL poison pill" because Canonical and others take a strong stance that there are legal challenges to linking CDDL – and GPLv2 code would fail in court.
Permitted licenses are subject to very few restrictions on the use, distribution or modification of covered projects. As a result, one licensed license is very similar to another.
The most common limitation on licensed licenses is assignment. In other words, these licenses generally require declarations that the original project is recognized in derived projects. (We cover permissible licenses for which no mapping is required in the next section on public domain equivalent licenses.)
Notable licenses include:
- BSD license with four clauses– The original Berkeley Software Distribution license from 1990 allowed free use, modification, redistribution and even re-approval of the covered software. Four clauses were the only limiting factors: each redistribution must include the copyright notice of the original project (clauses one and two), promotional materials for the project or a derived project must recognize the use of the source project (clause three), and none Rights to use the names of the authors and / or owners of the original project granted to support derivative projects (Section 4).
- BSD Three-clause license– In the BSD license with three clauses, which was first published in 1999, the advertising clause is deleted from the original BSD license with four clauses. Otherwise it is identical.
- BSD two-clause license– Also known as the "Simplified BSD License" or "FreeBSD License", the two-clause BSD license omits the endorsement clause and the advertising clause of the original BSD license.
- Apache license 2.0– The Apache license is a legal license that is similar to the BSD license with two clauses, except that it also grants patent rights similar to GPLv3. The Apache 2.0 license also requires redistribution of the original contents of a NOTICE file, if one should exist in the source project. The NOTICE file can be attached if desired, but may not omit the original content and may not change or appear to change the license terms.
- "MIT license"– We put this in frightening quotes because it is not unique and can refer to one of several license variants. When someone says "MIT license", it most often means the variant known as the expat license, which, like the BSD license with two clauses, grants the covered project rights of use, changes, redistribution and new registration rights and only the original requires copyright notices preserved and contained. In order to disguise the use of the term "MIT license", the OSI has published a word-for-word copy of the expat license.
- GNU all-permissive license– This is another extremely simple permissible license that allows the use, redistribution and modification of covered projects and only requires the inclusion of the original copyright and the only paragraph of the permissible GNU license itself. Although it is possible to license entire projects under the GNU APL, this is both unusual and not recommended – it is really intended for use in README, INSTALL, and similar, simple single files.
Although software surveys conducted by Github and Black Duck Software list the MIT license as the most common open source license, we strongly recommend not to use it due to the ambiguity. The MIT license does not grant (or limit) use significantly differently than the BSD license with two clauses.
Since the BSD license with two clauses is much clearer both in its own text and in what "BSD license with two clauses" refers to in normal use, we strongly recommend that you use it instead. We recommend the Apache 2.0 license to anyone who explicitly wants to grant patent rights – with the restriction that Apache 2.0 is compatible with the GPLv3, but not with the more widely used GPLv2.
Public domain equivalent licenses
Many of the people who publish their work without a license notification simply don't want to bother to read or understand any of the licenses or their implications, and mistakenly believe that providing the work without a license is "free".
We understand the desire not to have to think about licenses, but to ask these people to use a public domain license instead. There is only one public domain equivalent license approved by OSI, and here it is listed in its own single bullet list:
- BSD 0 clause license—This is the disclaimer from the original BSD license, without one of the limiting clauses, and with the leading statement "Permission to use, copy, modify and / or distribute this software for any purpose with or without fee, is hereby granted. "" The BSD 0 clause license does not grant royalty-free use of software patents to anyone who receives or uses licensed BSD 0 clause projects. This is the only public domain license approved by OSI.
Licenses not approved by OSI
If a license has not been approved by OSI, you should largely not consider it – and you should also be careful about using it. Regardless of whether you are looking for a strong copyleft, a weak copyleft or an approved license, there are numerous examples in the list approved by the OSI and therefore no reason to get lost.
On the other hand, there is only one OSI-approved public domain license – and the kind of people who don't allow legitimate licenses to be valid enough tend to be quite persistent and balk at doing so. With that in mind, we'll cover some of the most notable public domain equivalents not approved by OSI here.
- Don't license—The unlicense states that covered works are publicly available and then specifies exactly what that means. This is not a license approved by OSI, partly due to the use of the term "public domain" itself, which could make legal situations with works that are unlicensed difficult.
- CC0—The Creative Commons Zero license is the most revealing form of the Creative Commons family of licenses that is used more often for text and media creation than for code. The Creative Commons Foundation has submitted CC0 to the OSI for ratification as an open source license. Although the OSI never officially rejected it, they were unable to reach a conclusion to ratify it – largely due to its explicit disclaimer for the transfer of patent rights, which the OSI openly describes as "extremely rare" and "potentially dangerous" source license.
- wtfpl– In short, the WTFPL license is a very short and extremely informal confirmation that you can do anything you want with any code provided under the WTFPL. The Free Software Foundation recognizes the WTFPL as a GPL-compatible license for free software, but does not recommend its use. The OSI completely rejected the WTFPL on the dubious grounds that it "is no different than a public domain dedication", although the term "public domain" is not used and the different rights in different jurisdictions are related to the public domain.
We would like to reiterate that we do not recommend using a license that is not approved by OSI. Using any of these unapproved public domain licenses, no matter how free, is a risky undertaking. It is better to use a license that is not OSI approved than no license at all. However, there is a risk that you or your users will be excluded from patent or even cash grants.