Open-source software licenses exhibit significant diversity, with some mandating patent license grants to users and developers, while others require developers using the licensed product to release their source code under identical terms. Conversely, some licenses simply provide the code without any warranties or obligations. This article aims to illuminate the key distinctions between the most prevalent open-source licenses from the dual perspectives of software users and developers.

In 1984, Richard Stallman’s initiation of the GNU project, aimed at creating a free operating system, revived the concept of software sharing among developers, engineers, and users, fostering collaborative improvement akin to the scientific process.

This approach diverged from the conventional model of licensed software employed by most software companies and developers for distribution and sales. Over three decades later, open-source software steadily gains traction across various industry sectors, with Linux, Android, Apache, and Git exemplifying dominant open-source products within their respective domains.

Open-Source or Free Software?

Throughout this article, the terms “open-source” and “free” will be used interchangeably when referring to software or licenses. Both terms convey the same fundamental idea: “open-source” from a pragmatic and technical standpoint, and “free” emphasizing the philosophical and political dimensions of the concept.

However, the ambiguity of the word “free” in English, denoting both “without cost” and “associated with freedom,” often necessitates a preference for the term “open-source.”

Common Characteristics of Open-Source Software

Assuming a rudimentary understanding of open-source software, a detailed exploration of specific license properties is essential.

It’s crucial to clarify that this article does not constitute legal advice, and in case of uncertainty, consulting the actual license texts and seeking legal counsel is recommended.

The Open Source Initiative stipulates that all open-source software is distributed under a license granting users and developers (licensees) certain rights. While a comprehensive list is available in the Open Source Definition, here’s a concise summary:

1. Unrestricted software redistribution: selling, gifting, or bundling the software within a package without royalty payments.
2. Source code availability: either included in the distribution or accessible through well-publicized means, enabling modified software versions.
3. Permitted derivative works: allowed and distributable under the original software’s terms and license, with potential requirements for name changes, version number updates, or distribution as source-code patches.
4. Unrestricted usage: by any individual or group across all fields of endeavor.

However, it’s vital to acknowledge that software licenses primarily address usage and distribution permissions granted by copyright holders. Open-source licenses may permit free redistribution of software and derivative works, but such allowances might be restricted in countries prohibiting cryptographic software exports. Similarly, while open-source licenses generally allow unrestricted software use, this doesn’t condone illegal activities like hacking using open-source software. Software patents provide another illustration: certain open-source licenses grant free patent usage permissions, while others don’t.

Therefore, the feasibility of using open-source software in product or project development hinges on the specific software license and the intended license for the final product. Choosing an appropriate license when publishing self-developed open-source code is equally critical.

Copyleft

A fascinating aspect of open-source licenses is the concept of “copyleft,” the antithesis of “copyright.” While copyright safeguards intellectual property (including software) against unauthorized copying or distribution, copyleft ensures the continued open-source status of intellectual property and software during copying or distribution.

Copyleft manifests in two forms based on its strength:

• Strong copyleft: mandates that derivative works or those linked to strong-copyleft licensed works must retain strong copyleft licenses, potentially even the same license, preventing future closure of these open-source works.
• Weak copyleft: permits works utilizing or linked to weak-copyleft licensed works to be licensed under different licenses, even closed-source ones, limiting copyleft’s effect to the original weak-copyleft licensed work.

Some open-source licenses lack copyleft provisions, expressing indifference towards the future openness of derivative software.

Permissiveness

Licenses can also be categorized based on their permissiveness:

• Strict licenses: prohibit combining strongly licensed software with closed-source software or even more permissively licensed software.
• Permissive licenses: generally allow mixing products with closed-source software or software under a completely open-source license.

While strong copyleft licenses tend to be strict and weak copyleft licenses more permissive, exceptions exist.

Differences Among Open-Source Licenses

With the Open Source Initiative approving over 80 licenses, many open-source licenses exist, some redundant or equivalent. Others cater to specific publisher interests (e.g., NASA license) or environments/purposes (e.g., Educational Community License, Open Font License).

This license proliferation stems from specific terms that, in addition to fundamental open-source properties, permit or restrict certain uses. Examples include:

• Copyleft type: weak, strong, or absent.
• Permissiveness level: permissive or strict.
• Obligatory copyright notices: in source code or user interface.
• Automatic patent grants to licensees.
• Licensee definition: encompassing not only direct recipients of software but also users (e.g., cloud service users potentially gaining access to software source code).

Challenges of Mixing Code with Different Licenses

Permissive licenses, like the MIT License, allow combining code with differently licensed source code (potentially with additional conditions), including mixing with closed-source software.

Conversely, more restrictive licenses, such as the General Public License (GPL), only permit combining source code with similarly licensed code, requiring the final product to adopt the original license.

Combining code licensed under two restrictive open-source licenses poses challenges. While permissible under the open-source principle of unrestricted use, redistribution becomes impossible due to incompatible license requirements.

ZFS, an advanced filesystem incorporated into OpenSolaris in 2005, exemplifies this situation. Licensed under the Common Development and Distribution License (CDDL), its integration into the Linux kernel, distributed under the GPL, is prohibited due to license conflicts, preventing the distribution of Linux kernel binaries with ZFS support.

Resolving such conflicts requires all owners of one open-source program to agree on a license change or the inclusion of exceptions. For instance, numerous GPL-licensed programs link with the OpenSSL library, which requires specific phrasing in advertising and redistributions. This incompatibility led GPL product developers using OpenSSL to incorporate an exception for OpenSSL linking in their licenses.

Distinctive Features of Open-Source Licenses

This section delves into the most prevalent open-source licenses, highlighting their unique features and offering guidance on their appropriate usage. Licenses are ranked by popularity based on the Black Duck Knowledgebase.

GNU General Public License (GPL)

The GPL reigns as the most popular open-source license. Developed by the FSF for the GNU project, it also governs the Linux kernel.

Distinctive characteristics:

• Strong copyleft.
• Highly restrictive.
• “Viral” nature: linking code to GPL-licensed code necessitates a GPL license for the entire product.
• “Embracing” nature: developers can link or include other open-source software within GPL-licensed software as long as the licenses are compatible with GPL, without imposing additional obligations beyond GPL requirements.

The license text typically specifies distribution under GPL version N (or any later version).

Currently, GPL versions 2 and 3 are in use. Released in 2007, version 3 addressed issues arising since version 2’s release in 1991.

GPL v3 incorporates additional clauses and terms covering compatibility with other open-source licenses, mandatory patent licensing, GPL-licensed software usage as firmware in appliances, and considerations for digital rights management.

MIT License

Also known as the X11 license, the MIT License is a highly permissive, non-copyleft license granting unrestricted code usage with minimal restrictions, requiring copyright message retention and acknowledging the software’s lack of warranty.

Widely adopted by projects like the X Window System, Ruby on Rails, jQuery, and Node.js, it’s compatible with GPL, allowing MIT-licensed code integration into GPL software.

Apache License 2.0

Developed by the Apache Software Foundation (ASF) for its Apache HTTP Server, the Apache License, similar to the MIT License, is a highly permissive, non-copyleft license permitting unrestricted software use, distribution, modification, and derivative work distribution without royalty concerns. Key distinctions from the MIT License include:

• Automatic patent license grants to all code users and distributors, covering any potentially infringed patents licensable by the software authors.
• Mandatory Apache License retention for unmodified portions in derivative works.
• Preservation of original copyright, patent, trademark, and attribution notices in all licensed files.
• Mandatory notification of changes made to each licensed file.
• Preservation of the NOTICE file and its contents in all derived works if present in the Apache-licensed software.
• Automatic licensing of intentional contributions to Apache-licensed software under the Apache License.

The automatic patent license and contribution submission clause make this license particularly appealing. It’s compatible with GPL, enabling Apache-licensed code integration into GPL software.

BSD License

Three distinct BSD licenses exist, all highly permissive and lacking copyleft provisions.

The 2-clause BSD License (or Simplified BSD License) is functionally identical to the MIT License.

The 3-clause BSD License (or New BSD License) adds a clause prohibiting the use of the copyright holder’s name or contributor names for endorsing or promoting derivative works without written permission. Compatible with GPL, it allows integrating 3-clause BSD-licensed code into GPL software.

The 4-clause BSD License (or Original BSD License) includes an additional clause mandating that advertising materials referencing the software’s features or use acknowledge the inclusion of software developed by the copyright holder. This 4-clause BSD License, incompatible with GPL, prevents relicensing code under GPL terms due to the fourth clause’s additional requirement.

GNU Lesser General Public License (LGPL)

The FSF created the LGPL as a GPL variant with weaker copyleft, allowing linking LGPL-licensed software with any other software. Initially standing for “Library General Public License,” its current name, “Lesser General Public License,” reflects the FSF’s stance that all software should ideally be free and therefore LGPL shouldn’t be widely used.

Linking closed-source code against an LGPL library or software and distributing the final product is permissible under the following conditions:

• Providing the LGPLed part’s source code, including modifications.
• Enabling users with sufficient knowledge to replace the LGPLed program portion with a modified version, either by distributing the LGPLed part as a dynamic library (DLL in Windows, .so in Linux/Unix) or providing the object code of the non-LGPLed program portion.

LGPL v3’s compatibility with GPLv3 permits incorporating LGPLv3 code into GPL software.

Artistic License

The current version, Artistic License 2.0, is a permissive, non-copyleft open-source license similar to the MIT license.

The primary distinction between the MIT license and the Artistic License lies in the latter’s requirement for clearly stating any code modifications.

Primarily used within the Perl community, Artistic License 2.0 is compatible with GPL, allowing the integration of Artistic-Licensed code into GPL software.

Microsoft Public License (MS-PL)

Created in 2008 by Microsoft as part of their Shared Source Initiative, the Microsoft Public License is a strict, weak copyleft license. It allows creating and distributing closed-source programs containing MS-PLed code but mandates the MS-PL license for distributing derivative works in source code form.

This license’s approach can be perceived as contradictory to the open-source ethos, as it allows code closure while simultaneously restricting code sharing for integration with other copyleft source code.

Incompatible with GPL, the MS-PL reflects a degree of control exerted by the copyright holder, potentially limiting the code’s use for purposes like Linux improvement.

Eclipse Public License (EPL)

The Eclipse Public License, created by the Eclipse Foundation for their Integrated Development Environment, is a restrictive, weak-copyleft license akin to LGPL, also featuring clauses for automatic patent license grants.

The EPL is incompatible with GPL.

Mozilla Public License (MPL)

Developed by the Mozilla Foundation for its products, the Mozilla Public License version 2.0 is a weak-copyleft, permissive license.

Comparable to LGPL, a key distinction is that MPL permits statically linking MPLed code portions into closed-source software.

MPL 2.0 is compatible with GPL, unlike earlier versions.

Common Development and Distribution License (CDDL)

Based on MPL version 1.1, the CDDL is a weak-copyleft, permissive license created by Sun (now Oracle). Essentially sharing similar properties with MPL, its terms were clarified without substantial modifications.

Sun (now Oracle) chose the CDDL for many of its products, including OpenSolaris and NetBeans.

Based on MPLv1.1, the CDDL is incompatible with GPL, preventing the integration of CDDL-licensed source code into GPL-licensed software. This incompatibility is often perceived as intentional, preventing OpenSolaris source code integration into the Linux kernel.

GNU Affero General Public License (AGPL)

The AGPL, an even stronger and more restrictive copyleft version of GPL, mandates providing the application’s source code not only to software recipients but also to those using it over a network.

The FSF created this license to address the practical closure of open-source software when executed on network servers or in the cloud, as GPL couldn’t compel service providers to disclose source code to users in the absence of software distribution.

AGPLv3 is compatible with GPL3, allowing the inclusion of AGPLv3 code within GPLv3 code as long as the final product is licensed under AGPLv3.

ISC License

The ISC License, a permissive free software license authored by the Internet Software Consortium (ISC), is functionally equivalent to the 2-clause BSD and MIT licenses after removing redundant language.

Initially used for ISC’s software releases, it gained popularity among projects like OpenBSD (since June 2003).

Compatible with GPL, the ISC license allows integrating ISC-licensed code into GPL software.

Microsoft Reciprocal License (MS-RL)

Created in 2008 by Microsoft under their Shared Source Initiative, the Microsoft Reciprocal License resembles the MS-PL but with slightly stronger copyleft, akin to LGPL, CDDL, and EPL. It requires that when combining code with MS-RL-licensed source code and distributing the final product, at least the original MS-RL-licensed portion retains its license.

Incompatible with GPL, the MS-RL presents a more restrictive approach compared to the MS-PL.

Public Domain (CC0)

According to Wikipedia, public domain works encompass those with expired, forfeited, or inapplicable intellectual property rights. By dedicating a work to the public domain, the author relinquishes all copyright claims.

Several software projects, like SQLite, a library implementing an embeddable SQL database engine used in projects like Mozilla and Android, operate under Public Domain.

Numerous ways exist to dedicate software to the public domain. Creative Commons created the CC0 Public Domain Dedication, a standardized method for releasing works into the public domain, recommended by the FSF for software dedication.

Public domain works exhibit compatibility with all open and closed source licenses, allowing seamless integration into any software.

Multiple Licensing

Some open-source software employs double or even triple licensing, allowing recipients to choose the license under which they distribute it. This flexibility caters to diverse needs as each license offers distinct permissions and obligations.

This practice is common for libraries like NSS, a Mozilla-developed library implementing SSL/TLS support and other security features, triply licensed under MPL, GPL, and LGPL.

Choosing a License: A Call to Action

Publishing code on platforms like GitHub without a written license is strongly discouraged. Using such code carries significant risks, including potential lawsuits, as the permitted usage remains unclear. It’s akin to teasing potential users with unusable code.

Embrace responsible code sharing by granting others permission to use and enhance your code when uploading it to public platforms. Here are some recommendations for license selection:

• For simplicity and permissiveness, allowing unrestricted code use with attribution and no liability, opt for the MIT License.

• For permissiveness with clearly enumerated copyright rights, explicit patent right grants from contributors to users, and comprehensive legal clarity, choose the Apache 2.0 License.

• To encourage sharing modifications and prevent use in closed developments (software or hardware), utilize GPL v3.

  • If closed appliance usage is acceptable, consider GPL v2 with the “or any later version” clause for compatibility with GPLv3 projects.
  • If closed software usage is acceptable as long as the software or the portion using the code remains open-source under the same terms, select LGPL v3.
  • If all network users should have access to the source code, opt for AGPL v3.

While navigating these legal intricacies might seem daunting, it’s essential to remember that licenses are crucial for establishing clear usage and distribution rights, ultimately fostering a responsible and thriving open-source ecosystem.