domain startup Commons: 5/5

Permissive Licensing (MIT, Apache)

Also known as:

GL040: Permissive Licensing (MIT, Apache)

1. Overview

Permissive software licensing, exemplified by the MIT and Apache licenses, represents a foundational approach to open-source software distribution that prioritizes freedom of use, modification, and distribution with minimal restrictions. The core purpose of these licenses is to grant broad permissions to users, developers, and organizations, enabling them to incorporate the licensed software into a wide range of projects, both open-source and proprietary, without imposing significant reciprocal obligations. This approach stands in contrast to copyleft licenses, such as the GNU General Public License (GPL), which mandate that derivative works also be distributed under the same or a compatible license, thereby ensuring the continued openness of the software ecosystem. Permissive licenses, on the other hand, are designed to maximize the adoption and utility of the software, fostering a collaborative environment where code can be freely shared and integrated across different licensing models.

The problem that permissive licenses solve in the startup and business context is the friction often associated with using open-source software in commercial products. Many businesses are hesitant to adopt copyleft-licensed software due to the perceived legal complexities and the requirement to open-source their own proprietary code. Permissive licenses alleviate these concerns by providing a clear and simple legal framework that allows for the creation of derivative works and the sublicensing of the software under different terms, including proprietary ones. This flexibility is particularly valuable for startups that need to rapidly prototype and iterate on their products, often by leveraging existing open-source components. The MIT License, originating from the Massachusetts Institute of Technology in the late 1980s, is one of the simplest and most popular permissive licenses, known for its brevity and clarity. The Apache License, developed by the Apache Software Foundation, is another widely used permissive license that includes an express grant of patent rights and a clause addressing contributions, making it a robust choice for larger, more complex projects.

From a commons-aligned value creation perspective, permissive licenses play a crucial role in fostering a vibrant and dynamic software commons. By allowing for the unrestricted use and modification of software, these licenses contribute to the growth of a shared pool of knowledge and resources that can be drawn upon by a diverse range of actors. While they do not explicitly mandate the sharing of derivative works, they create an environment where collaboration and voluntary contribution are encouraged. The widespread adoption of permissively licensed software has led to the development of a rich ecosystem of open-source tools and frameworks that form the backbone of the modern internet and software industry. This, in turn, enables new forms of value creation that are not solely based on the proprietary control of intellectual property, but rather on the collective intelligence and collaborative efforts of a global community of developers and users.

2. Core Principles

  1. Freedom of Use: Users are granted the right to use the software for any purpose, including commercial, private, and research purposes, without any restrictions on how the software is deployed or utilized.
  2. Freedom of Modification: Developers have the freedom to modify the source code, adapt it to their specific needs, and create derivative works based on the original software.
  3. Freedom of Distribution: The software, in its original or modified form, can be freely distributed, sold, or sublicensed without the need to pay royalties or seek permission from the original author.
  4. Minimal Restrictions: The only significant requirement is the preservation of the original copyright and license notices in the distributed copies of the software, ensuring that the original creators are acknowledged.
  5. No Reciprocal Obligation (Non-Copyleft): Unlike copyleft licenses, permissive licenses do not require that derivative works be distributed under the same license, allowing for the creation of proprietary products based on open-source code.
  6. Patent Grant (Apache License): The Apache License 2.0 includes an explicit grant of patent rights from contributors to users, which helps to protect users from patent infringement claims related to the software.

3. Key Practices

  1. Include the License Text: When distributing a project under a permissive license, a copy of the full license text must be included with the software, typically in a file named LICENSE or LICENSE.txt.
  2. Preserve Copyright Notices: The original copyright notices must be retained in the source code and any derivative works, giving credit to the original authors.
  3. State Changes (Apache License): If modifications are made to the software, the Apache License 2.0 requires that the changes be clearly stated in the modified files.
  4. Provide a Notice File (Apache License): For derivative works, a NOTICE file must be included that contains the attribution notices from the original software.
  5. Choose the Right License: Carefully consider the specific needs of the project when choosing between different permissive licenses, taking into account factors such as patent grants and community preferences.
  6. Contribute Back to the Community: While not a legal requirement, it is a common and encouraged practice to contribute improvements and bug fixes back to the original project, fostering a collaborative development environment.
  7. Combine with Other Licenses: Permissive licenses are generally compatible with a wide range of other licenses, both permissive and copyleft, allowing for the creation of complex software systems that incorporate components with different licensing terms.
  8. Develop a Clear Contribution Policy: For larger projects, it is advisable to establish a clear contribution policy that outlines the terms under which contributions are accepted, often through a Contributor License Agreement (CLA).

4. Implementation

Implementing a permissive licensing model for a software project is a relatively straightforward process. The first step is to choose the specific license that best suits the project’s goals. The MIT License is an excellent choice for its simplicity and broad compatibility, while the Apache License 2.0 offers a more comprehensive legal framework, including an express patent grant. Once a license has been selected, the full text of the license should be included in the project’s root directory in a file named LICENSE. It is also a good practice to add a license header to each source file, which includes the copyright notice and a reference to the license.

When incorporating permissively licensed software into a proprietary product, it is crucial to comply with the minimal requirements of the license. This typically involves including a copy of the license text and the original copyright notices in the product’s documentation or about section. For example, the Android operating system, which is based on the Linux kernel (GPL) and a large amount of Apache-licensed code, provides a clear example of how permissively licensed software can be integrated into a commercial product. Google, the developer of Android, complies with the Apache License by providing the necessary notices and making the source code of the Apache-licensed components available.

Real-world examples of permissive licensing abound in the software industry. The popular front-end web framework, Bootstrap, is released under the MIT License, which has contributed to its widespread adoption and the growth of a large and active community of developers. Similarly, the Apache HTTP Server, one of the most widely used web servers in the world, is licensed under the Apache License 2.0. These examples demonstrate the power of permissive licenses to foster innovation and collaboration, enabling the creation of complex and powerful software systems that are used by millions of people worldwide.

5. 7 Pillars Assessment

Pillar Score (1-5) Rationale
Purpose 4 Permissive licenses strongly support the purpose of creating a shared software commons, but they do not explicitly require the sharing of improvements, which can limit the growth of the commons in some cases.
Governance 3 The governance of permissively licensed projects is often centralized in the hands of the original developers or a sponsoring organization. While community contributions are welcome, the decision-making power is not always distributed.
Culture 5 Permissive licenses foster a culture of openness, collaboration, and sharing, which are core values of the commons. They encourage a positive-sum approach to software development, where everyone can benefit from the collective effort.
Incentives 4 The primary incentive for using and contributing to permissively licensed projects is the ability to freely use and modify the software. However, the lack of a strong copyleft provision can reduce the incentive for commercial users to contribute back to the commons.
Knowledge 5 Permissive licenses promote the free and open sharing of knowledge in the form of source code, documentation, and best practices. They are a key enabler of the global knowledge commons.
Technology 5 The use of permissive licenses has a direct and positive impact on the development of open and interoperable technologies. They form the legal backbone of a vast and growing ecosystem of open-source software.
Resilience 4 Permissively licensed projects are generally resilient due to their distributed nature and the ability of anyone to fork the code and continue development. However, the lack of a strong copyleft provision can make them vulnerable to proprietary capture.
Overall 4.5 Permissive licenses are a powerful tool for building a software commons, but their effectiveness depends on the willingness of users to contribute back to the community. They represent a pragmatic and flexible approach to open-source software development that has proven to be highly successful in practice.

6. When to Use

  • When you want to maximize the adoption and use of your software.
  • When you want to encourage the use of your software in both open-source and proprietary products.
  • When you want to build a large and diverse community of users and developers.
  • When you are creating a library or framework that is intended to be used as a building block for other projects.
  • When you want to minimize the legal friction for commercial users.
  • When you are not concerned about the possibility of your code being used in proprietary products without the derivative works being shared.

7. Anti-Patterns and Gotchas

  • License Proliferation: Using a non-standard or modified version of a permissive license can create confusion and legal uncertainty for users.
  • Not Including the License: Failing to include the full text of the license with your software can make it difficult for users to understand their rights and obligations.
  • Ignoring the NOTICE File (Apache License): If you are using Apache-licensed software, you must comply with the requirement to include a NOTICE file with any derivative works.
  • Patent Trolling: While the Apache License 2.0 includes a patent grant, other permissive licenses do not. This can create a risk of patent infringement claims, particularly in patent-heavy industries.
  • Proprietary Capture: The lack of a strong copyleft provision can lead to a situation where a company creates a proprietary version of an open-source project and does not contribute its improvements back to the community.
  • Assuming No Obligations: While permissive licenses are very liberal, they are not a complete absence of any obligations. It is important to read and understand the terms of the license before using the software.

8. References

  1. The MIT License
  2. The Apache License 2.0
  3. Choose an open source license
  4. Open Source Initiative
  5. The Cathedral and the Bazaar by Eric S. Raymond