Open source powers the technology world, and 90% of modern software stacks are formed through frameworks. library; database; operating system. and countless standalone applications.
The benefits of open source software are well understood and promise greater control and transparency. However, there is a constant battle between open source and proprietary realms, with many companies retreating from open source to protect their commercial interests. At the heart of all this is the thorny issue of licensing.
There are two main types of licenses that meet the formal definition of open source as established by the Open Source Initiative (OSI). “Permissive” licenses have few restrictions on how users can modify and distribute the software, making them popular with companies that want to use the software commercially. Additionally, there are “copyleft” licenses that offer similar freedoms, but with one caveat. Modified versions of the software must also be distributed under the same original copyleft license. This is less attractive to companies that want to protect their proprietary work.
But there's more to it than that, there are different licenses within each bucket. Additionally, there are countless licenses that aren't technically open source but are worth knowing about.
tolerance
Massachusetts Institute of Technology
Born at the Massachusetts Institute of Technology in the 1980s, the aptly named MIT License is by most standards the most popular open source license and has held the top spot within the GitHub development community for many years.
The MIT license, used by projects like React (a front-end JavaScript library) and Ruby (a general-purpose programming language), allows developers to use the software in any way they like. Like most such licenses, this License is provided without warranty. This means that the author is exempted from any liability arising from damage (such as data loss) caused by the software. All developers need to worry about is including the original copyright notice and MIT License in their derivative works.
However, the MIT license has one drawback. That is, patent rights are not explicitly granted. This means that if certain software relies on patented technology, this can create legal uncertainty for developers who deploy software without securing separate permissions for that patented technology. means.
However, this highlights one of the key selling points of the MIT license. This means that the language is simple and concise with just 200 words. Clouding things up with vaguely worded patent rights adds unnecessary complexity to projects that are unlikely to involve patents, such as high-level programming languages or web frameworks.
However, many open source projects intersect with proprietary technologies, such as hardware-centric software like Android.
Apache License 2.0
The Apache Software Foundation published Apache License 2.0 in 2004. This is an updated version of the previous license with an explicit patent grant to protect users from lawsuits. So, for example, if a developer contributes their own image processing algorithm to a project licensed under Apache 2.0, any patents the developer holds on that algorithm are automatically licensed to all users of the software. will be done.
Most people are probably familiar with Google's Android brand, which has a rich app store and suite of homegrown tools and services. However, the underlying Android Open Source Project (AOSP) is effectively available under the Apache 2.0 license. This was a deliberate move by Google in 2008 to compete with Apple and encourage phone manufacturers to use Android over other proprietary incumbents at the time (such as Symbian). And it worked. Samsung, HTC, LG, and other companies have all jumped on Android.
However, as a byproduct of this, Apache License 2.0 contains approximately five times as many words as MIT, thanks to the patent grant text and other additions and clarifications. However, this is a trade-off and represents an important difference between the two most common permissive open source licenses.
Other permissible licenses
The BSD 2-Clause License is similar to the MIT license, but there are significant differences in the language used. For example, it specifies that a copy of the license must be included in both source code and compiled binary form. And then there's the BSD 3-clause license. It has an additional “no acknowledgment” clause that restricts the use of copyright holders' and contributors' names for promotional purposes in derivative projects.
There is also an MIT No Attribution License (MIT-0). It is simpler than MIT in that there is no attribution requirement for derived software. Using this is close to putting the software in the public domain, except the creator retains the copyright and the ability to change it in the future.
copyleft
GNU General Public License (GPL) v. 2.0 and 3.0
The Free Software Foundation (FSF) published the GNU General Public License (GPL) in 1989. This was one of the first copyleft licenses for general use.
Copyleft licenses are often better suited for projects that require input from the community than those supported by a single corporate entity. By requiring that all changes remain available under the same open source license, contributors can ensure that their efforts benefit the broader community rather than being used in proprietary software. Guaranteed not to. In case of violation, the license terms will apply.
GPL 3.0, launched in 2007, is the third most popular license, according to GitHub data. This license made notable updates to GPL 2.0, including improved patent grant provisions and compatibility with other open source licenses. It also prohibits so-called “tivoization,” in which hardware manufacturers that benefit from GPL-licensed software use digital rights management (DRM) mechanisms to prevent users from installing modified versions of that software. .
A notable GPL adopter is WordPress. WordPress is available under the GPL 2.0 “or later” license, leaving it up to developers to decide under which license their changes will be distributed.
Linux is one of the most successful open source projects in history, used in servers, cloud infrastructure, embedded systems, and even Android. However, the underlying Linux kernel is licensed under the GPL 2.0 license, given that Linux creator Linus Torvalds violated some of the terms added in version 3.0 of the license, including the Tivoization clause. Only available.
GNU Aferro General Public License (AGPL) 3.0
The Affero General Public License (AGPL) is similar to GPL 3.0 in that it is a “strong” copyleft license that promotes software freedom and ensures that modified versions remain open source. . However, the main difference with AGPL is that the software is focused on web-based services and applications that run from servers rather than being distributed as executable files.
The GPL 3.0 license does not require developers to release the source code of modified software when it runs on a network, such as a SaaS application. The AGPL license closes this loophole and requires the source code to be made available to third parties even if the modified software is only being run from a server.
The AGPL 3.0 license, issued by the Free Software Foundation in 2007, has grown in popularity largely due to the rise of cloud computing and SaaS, and is now the fifth most popular open source license.
GNU Lesser General Public License (LGPL)
The GNU Lesser General Public License (LGPL), also a product of the Free Software Foundation, is a “weak” copyleft license in that it has looser rules about what can be shared and is more business-friendly. The LGPL is typically used for software libraries where project authors want to encourage contributions from the community, allowing them to link their own software to the library without having to open source their entire code. If someone changes the open source library itself, they can simply release those changes under the LGPL license.
Mozilla Public License 2.0
The Mozilla Public License (MPL) 2.0, published by the Mozilla Foundation in 2012, is currently the 10th most popular open source license, according to GitHub's license metrics. MPL is also a weak copyleft license intended to protect proprietary code while allowing developers to benefit from open source software.
However, whereas the LGPL focuses on the library level and the GPL on the project level, the MPL operates at the individual file level and requires users to share a narrower set of code.
Public domain and creative commons
An “open source license” grants certain rights, but always with provisions attached. However, if you want to put your software completely in the public domain without any warnings, there are other ways to do that.
Publishing software without a license is not enough. Copyright law applies by default to most creative works, including software. This is where “dedication to the public domain” comes in handy.
Designed specifically for software, Unlicense is the 9th most popular license on GitHub (though whether it can actually be called a “license” is debatable). Although OSI approved it as a license in 2020, it called the document “poorly drafted” and questioned its legal validity in jurisdictions where works cannot be released into the public domain (such as Germany). presented.
Like Unlicense, Creative Commons CC0-1.0 is also a public domain dedication tool, but with a broader focus on creative works. Clearer and more specialized legal terminology is used that is more in line with international law. Notably, Creative Commons applied to have CC0-1.0 approved as an open source compliant license in 2012, after OSI raised concerns that it explicitly excluded patent granting. The application was withdrawn.
There are other publicly available specialized tools, such as Zero-Clause BSD, which may be attractive because they have a simpler language. However, there is no consensus on the best mechanism for transferring all rights to a particular software.
“Fake pen” source
There are countless other licensing paradigms within the software spectrum.
In some cases, companies release software with a dual license model, allowing users to choose between a recognized open source license and a commercial license, depending on their intent. Next is “Open Core,” which provides software under an open source license, but for which key features are paid. In other examples, companies may add a Commons Clause addendum to an otherwise permissive open source license to create commercial restrictions.
There are also many licenses that look and smell like open source, but are ultimately incompatible with the definition of open source.
In 2018, database giant MongoDB transitioned from a copyleft AGPL license to a server-side public license (SSPL), a license MongoDB created itself. SSPL is still fairly “open”, so-called “source available” in that although the code is accessible, there are significant commercial restrictions and as far as OSI is concerned, this is a big no-no. .
The folks at MariaDB blazed a similar path with the Business Source License (BUSL), imposing commercial restrictions before transitioning to a true open source license after a certain number of years. Another similar movement is underway to achieve “fair source” licensing. This includes the Functional Source License, which is touted as an easier alternative to BUSL.
You may also come across so-called “ethical source” licenses, such as the Hippocratic License, which prohibits the use of software that violates internationally recognized human rights. Similarly, the open standard JSON file format comes with a very permissive license, except for one interesting clause at the end: “The Software shall be used for good and not for evil.” I am.