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 does not 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.
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 did want to — read and understand a new license from scratch.
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 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 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 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 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 would actually 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
link age 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 Public License. Sometimes referred to incorrectly as the “Library” GNU 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.
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.
(BSD three-clause license) – The BSD three-clause license, first published in 2015, 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 use, 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.
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.
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.
GIPHY App Key not set. Please check settings