reader comments

167 with 78 posters participating, including story author

Most people have at least heard of open source software by now—and even have a fairly good idea of what it is. Its own luminaries argue incessantly about what to call it—with camps arguing for everything from Free to Libre to Open Source and every possible combination of the above—but the one thing every expert agrees on is that it’s not open source (or whatever) if it doesn’t have a clearly attributed license.

You can’t just publicly dump a bunch of source code without a license and say “whatever—it’s there, anybody can get it.” Due to the way copyright law works in most of the world, freely available code without an explicitly declared license is copyright by the author, all rights reserved. This means it’s just plain unsafe to use unlicensed code, published or not—there’s nothing stopping the author from coming after you and suing for royalties if you start using it.

The only way to actually make your code open source and freely available is to attach a license to it. Preferably, you want a comment with the name and version of a well-known license in the header of every file and a full copy of the license available in the root folder of your project, named LICENSE or LICENSE.TXT. This, of course, raises the question of which license to use—and why?

There are a few general types of licenses available, and we’ll cover each in its own section, along with one or more prominent examples of this license type.

Default licensing—proprietary, all rights reserved

In most jurisdictions, any code or content is automatically copyrighted by the author, with all rights reserved, unless otherwise stated. While it’s good form to declare the author and the copyright date in the header of any code or document, failing to do so doesn’t mean the author’s rights are void.

An author who makes content or code available on their own website, a Github repository, etc—either without a stated license or with an express declaration of copyright—maintains both usage and distribution rights for that code, even though it’s trivially simple to view or download. If you execute that code on your own computer or computers, you’re transgressing on the author’s usage rights, and they may bring civil suit against you for violating their copyright, since they never granted you that right.

Similarly, if you copy that code and give it to a friend, post it on another website, sell it, or otherwise make it available anywhere beyond where the author originally posted it, you’ve transgressed upon the author’s distribution rights, and they have standing to bring a civil suit against you.

Note that an author who maintains proprietary rights to a codebase may individually grant license to persons or organizations to use that code. Technically, you don’t ever “buy” software, even when it’s boxed up in a physical store. What you’re actually purchasing is a license to use the software—which may or may not include physical media containing a copy of the code.

Home-grown licenses

The short version of our comment on home-grown licensing is simple: just don’t do it.

There are enough well-understood, OSI-approved open source licenses in the world already that nearly any person or project should be able to find an appropriate one. Writing your own license instead means that potential users of your project, content, or code will have to do the same thing the author didn’t want to—read and understand a new license from scratch.

The new license will not have been previously tested in court, which many (though not all) of the OSI-approved open source licenses have been. Even more importantly, your new license will not be widely understood.

When a person or company wants to use a project licensed under—for example—GPL v3, Apache 2.0, or CC0 (more on these licenses later), it’s relatively easy to figure out whether the license in question grants enough rights, in the right ways, to be suited for that purpose. Asking a competent intellectual property lawyer for advice is cheap and easy, because that competent IP lawyer should already be familiar with these licenses, case-law involving them, and so forth.

By contrast, if your project is licensed “Joe’s Open Source License v1.01” nobody knows what that means. Legal consultation for a project under that license will be much more expensive—and dicey—because an IP lawyer would need to evaluate the text of the license as an entirely new work, unproven and untested. The new license might have unclear text, unintentional conflicts between clauses, or be otherwise unenforceable due to legal issues its author did not understand.

Failure to choose an OSI-approved license can also invalidate a project from certain rights or grants. For example, both Google and IBM offer royalty-free usage of portions of their patent portfolio to open source projects—and your project, no matter how “free” you consider it, may not qualify with a home-grown license. (IBM specifically names OSI license approval as a grant condition.)

OSI-approved licenses

The Open Source Initiative maintains a list of approved open source licenses, which comply with the OSI’s definition of “open source.” In the OSI’s own words, these licenses “allow software to be freely used, modified, and shared.” There is a lot of overlap among these licenses, many of which probably never should have existed—see “home grown licenses,” above—but at some point, each of them gained enough traction to go through the OSI license approval process.

We’re going to break this list of licenses down into three categories and list some of the more notable examples of each. Most authors don’t need to read and understand the OSI’s entire list—there usually aren’t enough differences between common and uncommon variants of a general license type to make it worth straying from the most commonly used and well-understood versions.

Strong copyleft licenses

A copyleft license is a license that grants the permission to freely use, modify, and redistribute the covered intellectual property—but only if the original license remains intact, both for the original project and for any modifications to the original project anyone might make. This type of license—sometimes dismissively or fearfully referred to as “viral”—is the one attached to such famous projects as the Linux kernel, the GNU C Compiler, and the WordPress content management system.

A copyleft license may be “strong” or “weak”—a strong copyleft license covers both the project itself and any code that links to any code within the covered project. A weak copyleft license only covers the original project itself and allows non-copyleft-licensed code—even proprietary code—to link to functions within the weak-copyleft-licensed project without violating its license.

Some of the more popular strong copyleft licenses include:

• GPLv2—the GNU General Public License allows for free usage, modification, and distribution of covered code, but the original license must remain intact and covers both the original project and any modifications. No attribution or patent grants are required in the GPLv2, but the seventh section does prohibit redistribution of GPLv2 licensed code if patents or any other reason would render the redistributed code unusable to a recipient. The GPL also requires that anyone distributing compiled versions of a project make original source code available as well, either by providing the source along with the distributed object code, or by offering it upon request.
• GPLv3—Version three of the GNU General Public License is for most intents and purposes similar to GPLv2. It handles patents differently, however—the GPLv2 forbade redistribution under the GPLv2 if doing so would potentially require royalty payments for patents covering the work. The GPLv3 goes a step further and explicitly grants free usage rights to any such patents owned, then or in the future, by any contributor to the project. The GPLv3 also expressly grants recipients the right to break any DRM (Digital Rights Management) code contained within the covered project, preventing them from being charged with violations of the Digital Millennium Copyright Act or similar “tamper-proofing” laws.
• AGPL—the Affero GNU General Public License is, effectively, the GPLv3 with one significant additional clause—in addition to offering GPL freedoms to those who receive copies of AGPL-licensed software, it offers those same freedoms to users who interact with the AGPL-licensed software over a network. This prevents an individual or company from making significant valuable modifications to a project intended for widespread network use and refusing to make those modifications freely available.

We’re going to give a little more ink to the AGPL outside of our bulleted list above, because it’s a little harder to explain its impact to someone who isn’t already very familiar with copyleft. In order to better understand its impact, we’ll look at one real AGPL licensed project and a fictitious scenario involving a large company that might wish to adopt it.

The Nextcloud Web-based file-sharing suite is an AGPL-licensed project. Because it’s licensed under a GPL variant, any person or company can freely download, install, and use it, either for themselves or to offer services—including paid services—to others. Let’s imagine a hypothetical company—we’ll call the company PB LLC, and their product Plopbox—that decides to spin up a large commercial site offering paid access to managed, hosted Nextcloud instances.

In the course of making Plopbox scale to millions of users, PB LLC makes substantial modifications to the code. The modified code consumes far fewer server resources and also adds several features that Plopbox’s users find valuable enough to distinguish Plopbox substantially from vanilla installations of Nextcloud. If Nextcloud—the open source project PB LLC consumed in order to create the Plopbox service—had been licensed under the standard GPL, those modifications could remain proprietary, and PB LLC would not be required to provide them to anyone.

This is because the standard GPL’s restrictions only kick in on redistribution, and PB LLC did not redistribute its modified version of Nextcloud. Since PB LLC only installed Nextcloud on its own servers, it’s not obligated to provide copies of Nextcloud—either the original or the modified versions—to anyone, either automatically or upon request.

However, Nextcloud is not licensed under either standard version of the GPL—it’s licensed under the Affero GPL, and the Affero GPL grants all of the rights associated with the GPL to networked users of a covered project, not merely to recipients of distributed code. So PB LLC actually would be required to make their scalability and new-feature modifications available, in source code form (and object code form, if applicable) to anyone who had both used the project (eg, by opening a Plopbox account) and requested a copy.

Weak copyleft licenses

A weak copyleft license is essentially similar to a strong copyleft license, but it does not extend its “viral” protection across linkage boundaries. Modifications to the weak-copyleft library (or other project) itself must retain the original license, but any code outside that project—even fully proprietary code—may link directly to functions inside the weak copyleft-licensed project.

There are relatively few weak copyleft licenses. The most commonly encountered are:

• LGPL—the Lesser GNU General Public License. Sometimes still referred to by its original name, GNU “Library” General Public License, since it’s 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; prior versions were not.
• CDDL v1.0—The Common Development and Distribution License, originally authored by Sun Microsystems. CDDL is famously considered incompatible with the GPL, although this incompatibility has not been tested in court.

The major difference between the LGPL and the MPL is attribution—in order to link to an LGPL project from a non-GPL-compliant project, you must “give prominent notice… that the Library is used in it (and) covered by this license.” The MPL does not have any attribution requirements; you may redistribute MPL projects, and link to functions within an MPL project, without any need to announce that you’re doing so.

The Mozilla Public License is also notable for offering “forward migration.” The Mozilla Foundation, as license steward, may create updated versions of the MPL in the future, with unique version numbers. Should it do so, any user of a project licensed MPL 2.0 may choose to use it under the original MPL 2.0 or any later version of the license.

The CDDL similarly allows forward migration but defines the license steward as Sun Microsystems rather than the Mozilla Foundation. Unlike the LGPL and MPL 2.0, CDDL is generally considered incompatible—possibly deliberately—with the GPL. Some organizations have chosen to dynamically link CDDL and GPL licensed code anyway—most notably Canonical, makers of the Ubuntu Linux distribution, who announced their decision to do so by distributing a Linux port of the ZFS filesystem in early 2016.

We at Canonical have conducted a legal review, including discussion with the industry’s leading software freedom legal counsel, of the licenses that apply to the Linux kernel and to ZFS.

And in doing so, we have concluded that we are acting within the rights granted and in compliance with their terms of both of those licenses. Others have independently achieved the same conclusion. Differing opinions exist, but please bear in mind that these are opinions.

One significant dissent to Canonical’s position comes from the Software Freedom Conservancy, which states that linking CDDL and GPL code is necessarily a GPL violation. Although the SFC states this in no uncertain terms, it expresses “sympathy” to Canonical’s goals, and its conclusion focuses on asking Oracle (the CDDL’s license steward, as the current owners of Sun Microsystems) to resolve the issue.

Should Oracle make the original ZFS codebase available under a GPLv2 compatible license—including any of the compatible permissive licenses—this availability would, in turn, grandfather in the later OpenZFS project without need for laborious consultation of every individual contributor.

We do not recommend modern use of the CDDL license—it is neither generally useful as a permissive license due to its GPL incompatibility, nor is it likely to be useful as a “GPL poison pill” given the strong stance Canonical and others have taken in belief that legal challenges to the linkage of CDDL and GPLv2 code would fail in court.

Permissive licenses

Permissive licenses make very few restrictions in the usage, distribution, or modification of covered projects. As a result, one permissive license tends to be very similar to another.

The most common restriction in permissive licenses is attribution—in other words, these licenses generally require statements giving credit to the original project in any projects derived from them. (We cover permissive licenses that do not require attribution in the next section on public domain equivalent licenses.)

Notable permissive licenses include:

• BSD four-clause license—the original 1990 Berkeley Software Distribution license allowed for free usage, modification, redistribution, and even relicensing of covered software. Four clauses provided the only limiting factors: any redistribution must include the copyright notice of the original project (clauses one and two), any advertising materials for the project or any derivative project must acknowledge the use of the source project (clause three), and no rights to use the name of the authors and/or owners of the original project are granted to endorse any derivative projects (clause four).
• BSD three-clause license—The BSD three-clause license, first published in 1999, omits the advertising clause from the original four-clause BSD license. It is otherwise identical.
• BSD two-clause license—Also known as the “Simplified BSD license” or “FreeBSD license,” the two-clause BSD license omits the endorsement clause as well as the advertising clause of the original BSD license.
• Apache license 2.0—the Apache license is a permissive license similar to the BSD two-clause license, except that it additionally grants patent rights similarly to the GPLv3. The Apache 2.0 license also requires redistribution of the original contents of a NOTICE file, should one be present in the source project. The NOTICE file may be appended to if desired but must not omit the original contents and must not alter—or seem to alter—the license terms.
• “MIT license”—we placed this one in scare quotes because it’s ambiguous and could refer to any of several license variants. When someone says “MIT license” they most commonly mean the variant known as the Expat license—which, similarly to the BSD two-clause license, grants usage, modification, redistribution, and relicensing rights to the covered project, requiring only that the original copyright notice be retained and included. In an attempt to de-obfuscate usage 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 permissive license, allowing usage, redistribution, and modification of covered projects, requiring only inclusion of the original copyright and the single paragraph of the GNU all-permissive license itself. Although it’s possible to license entire projects under the GNU APL, this is both uncommon and discouraged—it’s really intended for use in README, INSTALL, and similar, simple single files.

Although software surveys performed by Github and Black Duck Software both list the MIT License as the most commonly encountered open source license, we strongly recommend against its usage due to the ambiguity involved. The MIT license does not grant (or restrict) usage significantly differently from the BSD two-clause license.

Since the BSD two-clause license is considerably more clear, both in its own text and in what “BSD two-clause license” refers to in normal use, we strongly recommend its use instead. We recommend the Apache 2.0 license to those who wish to explicitly grant patent rights—with the caveat that this makes Apache 2.0 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 any license notice at all just don’t want to bother reading or understanding any of the licenses or their implications and mistakenly believe that providing the work without providing a license makes it “free.”

We understand the desire not to have to think about licensing, but implore those people to use a public domain equivalent license instead. There is only one OSI-approved public domain equivalent license, and here it is, in its own single-bullet list:

• BSD 0-clause license—this is the warranty disclaimer from the original BSD license, with none of the restrictive 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 specifically grant royalty-free usage of software patents to anyone receiving or using BSD 0-clause licensed projects. This is the only OSI-approved public domain equivalent license.

Non-OSI-approved licenses

For the most part, if a license is not OSI approved, you shouldn’t consider using it—and you should be wary of using it, as well. Whether you’re looking for strong copyleft, weak copyleft, or permissive licensing, there are plenty of examples in the OSI-approved list and, therefore, no reason to stray.

On the other hand, there’s only one OSI-approved public domain equivalent license—and the kind of folks who don’t find permissive licenses permissive enough tend to be pretty stubborn and may balk even at that. With that in mind, we’ll cover a few of the most notable non-OSI-approved public domain equivalents here.

• Unlicense—the Unlicense states that covered works are released into the public domain and goes on to specify exactly what that means. This is not an OSI-approved license, due in part to its use of the term “public domain” itself, which could complicate any legal situations involving works placed under the Unlicense.
• CC0—The Creative Commons Zero license is the most permissive form of the Creative Commons family of licenses, which are more commonly used to cover text and media creations than code. The Creative Commons Foundation submitted CC0 to the OSI for ratification as an open source license; although the OSI never formally rejected it, they were unable to reach a conclusion to ratify it—due mostly to its explicit disclaimer of conveyance of patent rights, which the OSI refers to as both “exceedingly rare” and “potentially dangerous” in an open source license.
• WTFPL—short for, well, WTF Public License, the WTFPL is a very short and exceedingly informal affirmation that you can do whatever you’d like to do with any code made available under the WTFPL. The Free Software Foundation recognizes the WTFPL as a GPL-compatible Free Software License but does not recommend its use; the OSI rejected the WTFPL entirely on the dubious grounds that it is “no different to a public domain dedication,” despite its lack of use of the term “public domain” and the different rights associated with public domain in different jurisdictions.

We want to note—again—that we do not recommend the use of any non-OSI-approved license. Using any of these unapproved public domain-equivalent licenses—no matter how apparently free—is a risky proposition. It’s better to use a non-OSI-approved license than no license at all, but doing so runs the risk of disqualifying yourself or your users from patent or even monetary grants.