Open Source Licenses: A Comprehensive Guide

The Pervasive Influence of Open Source Technology

Open source software is fundamental to the current technological landscape. It constitutes approximately 90% of the contemporary software infrastructure, encompassing frameworks, libraries, databases, operating systems, and a vast array of independent applications.

The advantages of utilizing open source software are widely recognized, notably increased control and enhanced transparency. Despite these benefits, a continuous tension exists between open source and proprietary software models.

The Open Source vs. Proprietary Debate

This tension often results in companies choosing to move away from open source contributions to safeguard their commercial endeavors. The central point of contention in this debate revolves around the complexities of software licensing.

Understanding Open Source Licenses

The Open Source Initiative (OSI) formally defines two primary categories of licenses. “Permissive” licenses impose minimal restrictions on modification and distribution, making them favored by businesses intending commercial application.

Conversely, “copyleft” licenses grant comparable freedoms but include a significant condition. Any derivative work created from the software must also be released under the same original copyleft license.

This requirement can be less attractive to organizations seeking to maintain the exclusivity of their proprietary developments.

A Spectrum of Licensing Options

The landscape of software licensing is more nuanced than a simple dichotomy. Numerous licenses exist within both the permissive and copyleft categories.

Furthermore, a considerable number of licenses, while not strictly adhering to the open source definition, are still important for developers and businesses to understand.

Here's a quick overview:

• Permissive Licenses: Offer maximum flexibility for use and modification.
• Copyleft Licenses: Ensure that derivative works remain open source.
• Non-Open Source Licenses: Provide varying degrees of restriction and control.

Permissive

MIT

The MIT License, originating from the Massachusetts Institute of Technology in the 1980s, is widely recognized as the most prevalent open source license based on numerous metrics. It consistently ranks as a top choice within the GitHub developer community.

Notable projects like React, a front-end JavaScript library, and Ruby, a versatile programming language, utilize the MIT license. This license grants developers broad freedom in software usage. Like most open source licenses, it disclaims warranties, shielding authors from liability for damages resulting from their software, such as potential data loss. Developers are only obligated to retain the original copyright notice and the MIT license text within any modified versions of the software.

However, a limitation of the MIT license is its lack of explicit patent rights. Consequently, if software incorporates patented technology, legal ambiguities may arise for developers deploying it without securing separate permissions for that technology.

This highlights a core advantage of the MIT license: its simplicity and conciseness, comprising only approximately 200 words. Introducing complex patent-related clauses would unnecessarily complicate matters for projects where patents are unlikely to be a concern, like high-level programming languages or web development frameworks.

Conversely, many open source projects do interact with patented technologies, particularly those focused on hardware, such as Android.

Apache License 2.0

Published by the Apache Software Foundation in 2004, the Apache License 2.0 represents an update to a previous version, incorporating an explicit patent grant to safeguard users against legal challenges. For example, if a developer contributes a novel image processing algorithm to a project under the Apache 2.0 license, any patents held by that developer on the algorithm are automatically licensed to all software users.

While Google’s Android is well-known for its app store and integrated services, the foundational Android Open Source Project (AOSP) is distributed under the Apache 2.0 license. This strategic decision by Google in 2008 aimed to challenge Apple and encourage phone manufacturers to adopt Android over competing proprietary systems like Symbian. This strategy proved successful, with manufacturers like Samsung, HTC, and LG embracing the Android platform.

As a result, the Apache License 2.0 contains roughly five times the word count of the MIT license, due to the inclusion of patent grant provisions and other clarifications. This represents a trade-off, illustrating the fundamental differences between these two commonly used permissive open source licenses.

Other permissive licenses

The 2-Clause BSD License shares similarities with the MIT license, but differs in its specific wording. It mandates the inclusion of a license copy with both the source code and the compiled binary distribution. Additionally, the 3-Clause BSD License includes a “no endorsement” clause, preventing the use of copyright holder or contributor names for promotional purposes in derivative projects.

The MIT No Attribution License (MIT-0) offers a simplified version of the MIT license, removing the requirement for attribution in derivative software. This approach closely resembles placing software in the public domain, although the author retains copyright and the ability to make future modifications.

Copyleft

GNU General Public License (GPL) v2.0 and 3.0

The GNU General Public License (GPL) was initially released by the Free Software Foundation (FSF) in 1989. It quickly became a foundational copyleft license for widespread application.

Copyleft licenses are frequently a more suitable choice for projects that rely on community contributions, rather than those backed by a single company. They ensure that any alterations remain under the same open source license, protecting contributors’ efforts from being incorporated into proprietary software without benefiting the broader community. Enforcement of these terms can, however, prove challenging.

GPL 3.0, launched in 2007, currently ranks as the third most prevalent open source license, according to GitHub statistics. This version introduced significant improvements over GPL 2.0, including patent grant provisions and enhanced compatibility with other open source licenses.

Furthermore, GPL 3.0 aimed to address a practice known as “Tivoization.” This involves hardware manufacturers permitting users to reinstall modified GPL-licensed software on a device, while simultaneously disabling other proprietary software essential to the device’s functionality. More details on this can be found in a blog post by Bradley M. Kuhn of the Software Freedom Conservancy.

Linux stands as a prominent example of GPL adoption, being one of the most successful open source projects ever created. It powers servers, cloud infrastructure, embedded systems, and even Android. However, the Linux kernel itself is distributed under GPL 2.0, reflecting Linux creator Linus Torvalds’ reservations about certain provisions in version 3.0.

WordPress, conversely, is licensed under GPL 2.0 “or later,” granting developers the flexibility to choose the license under which they distribute any modifications.

GNU Affero General Public License (AGPL) 3.0

The Affero General Public License (AGPL) shares similarities with GPL 3.0, functioning as a “strong” copyleft license that champions software freedoms and mandates that modified versions remain open source. A key difference lies in AGPL’s focus on web-based services and applications, where software operates from servers rather than being distributed as executable files.

A GPL 3.0 license doesn’t necessitate the release of source code for modified software when it’s run over a network, as is common with SaaS applications. The AGPL license eliminates this exception, requiring third parties to make the source code available even if the software is solely running on a server.

The Free Software Foundation published the AGPL 3.0 license in 2007. Its popularity has increased alongside the growth of cloud computing and SaaS, and it is now the fifth most popular open source license.

GNU Lesser General Public License (LGPL)

Developed by the Free Software Foundation, the GNU Lesser General Public License (LGPL) is a “weak” copyleft license. It offers more business-friendly terms and less restrictive requirements regarding code sharing.

LGPL is typically used for software libraries, encouraging community contributions while allowing proprietary software to link to the libraries without mandating the open sourcing of their entire codebase. Modifications to the library itself, however, must be released under the LGPL license.

Mozilla Public License 2.0

The Mozilla Public License (MPL) 2.0 was published by the Mozilla Foundation in 2012. According to GitHub’s license metrics, it is currently the tenth most popular open source license.

Like LGPL, MPL is a weak copyleft license designed to safeguard proprietary code while allowing developers to leverage open source software. However, MPL operates at the level of individual files, requiring the sharing of a more limited scope of code compared to LGPL, which focuses on libraries, or GPL, which focuses on entire projects.

Public Domain and Creative Commons Licensing

Although an open source license provides defined permissions, conditions invariably apply. Individuals aiming to release their software completely into the public domain, devoid of any restrictions, can achieve this through alternative methods.

Merely publishing software without a license isn't sufficient; copyright legislation automatically governs most original creations, encompassing software as well. A public domain dedication serves as a solution in these instances.

The Unlicense, specifically crafted for software, currently ranks as the ninth most utilized designation on GitHub, although its classification as a true “license” remains a point of discussion. The Open Source Initiative (OSI) officially recognized it as a license in 2020, but simultaneously acknowledged its “poor drafting” and questioned its legal validity in certain regions, like Germany, where relinquishing copyright is not permissible.

Similar to the Unlicense, Creative Commons’ CC0 1.0 functions as a public domain dedication instrument, but with a wider scope encompassing various creative works. It employs more precise and legally sound wording, potentially aligning better with international legal frameworks.

It’s important to remember that Creative Commons initially sought OSI approval for CC0 1.0 as an open source-compatible license in 2012. However, the application was withdrawn following OSI reservations regarding the explicit exclusion of patent grants.

Other public dedication options exist, such as the Zero-Clause BSD license, which may be attractive due to its simplified language. Nevertheless, no universally accepted method has emerged for completely surrendering all rights to a software project.

Understanding Public Domain Dedication

• Copyright law automatically protects most creative works.
• A public domain dedication explicitly relinquishes these rights.
• Tools like the Unlicense and CC0 1.0 facilitate this process.

Comparing Dedication Tools

The Unlicense is popular on GitHub but has legal concerns. CC0 1.0 offers clearer legal language and broader applicability. Zero-Clause BSD provides simplicity, but lacks widespread consensus.

Choosing the right method depends on specific legal considerations and desired clarity.

Alternative Software Licensing Approaches

Beyond established models, a diverse range of licensing paradigms exists within the software industry.

Some organizations employ a dual-licensing strategy, allowing users to select either a standard open source license or a commercial license based on their specific needs.

The "open core" approach provides the software under an open source license, but reserves certain crucial functionalities for paying customers.

Additionally, companies may incorporate a Commons Clause into an otherwise permissive open source license, thereby introducing commercial limitations.

Licenses Mimicking Open Source

Numerous licenses present themselves as open source, yet ultimately fail to align with the established open source definition.

In 2018, MongoDB, a prominent database provider, shifted from the copyleft AGPL license to the Server Side Public License (SSPL), a license uniquely developed by MongoDB itself.

Although the SSPL maintains a degree of openness, it is categorized as "source available," meaning the code is accessible but subject to substantial commercial restrictions – a point of contention for the Open Source Initiative (OSI).

Business Source and Fair Source Licensing

MariaDB followed a comparable trajectory with the Business Source License (BUSL), which initially imposes commercial constraints before transitioning to a genuine open source license after a predetermined period.

A related initiative is currently exploring the concept of "fair source" licensing, exemplified by the Functional Source License, positioned as a streamlined alternative to the BUSL.

Ethical and Humorous Licensing Terms

“Ethical source” licenses, like the Hippocratic License, occasionally appear, prohibiting software usage that contravenes internationally acknowledged human rights.

Even the widely adopted JSON file format, with its highly permissive license, includes a notable clause: “The Software shall be used for Good, not Evil.”