Balancing Business & Open Source: Permissive Licenses, Copyleft, and CLA

Open-source licensing refers to a type of license that allows the source code of a software to be freely accessed, modified, and redistributed by anyone. Unlike proprietary licenses, where the source code is kept secret and controlled by the creator, open-source licenses promote collaboration, transparency, and community-driven development. These licenses come in various forms, with different rules and obligations, but they all share the spirit of making the code openly available.

Recent shifts in the open source landscape, such as HashiCorp’s decision to switch from the MPL-2.0 to a more restrictive license , and Red Hat’s changes in attitude towards OSS , have reignited debates on balancing business needs with open source principles. The use of Contributor License Agreements (CLAs) sits at the heart of this discussion. How can a company protect its interests while nurturing an open source community?

As an early disclaimer, we value early transparency and endorse free software, and in this article, we will explore licensing from this perspective. We recognize that there are various opinions and approaches within the community, and our intention is to share our perspective on balancing commercial objectives with the ethos of open-source development.

What are CLAs and BSLs?

A CLA is a legal document that clarifies rights between the contributor and the project owner, offering benefits such as protecting Intellectual Property (IP), clarifying commercial use, and allowing the ability to re-license.

A BSL is a “source-available” license that restricts certain usages, reflecting a nuanced approach to balancing commercial objectives with the ethos of open-source development. A BSL is not considered an open-source license by the Open Source Initiative (OSI) but a “source-available” license. BSL has been a licensing approach taken by some in tech industry before, offering a balance between traditional open-source and proprietary licenses. This is the HashiCorp change from MPL-2.0 to BSL for some of their products.

Pros of using a CLA:

• Clarifying Commercial Use: Depending on how the CLA is structured, it can outline specific terms around commercial use, providing more control over how the code might be utilized in commercial contexts.
• Protecting Intellectual Property (IP): It can help ensure that contributors have the rights to the code they are contributing and that they are granting appropriate rights to the project. This helps in avoiding potential legal complications related to IP.
• Ability to Re-license: It allows to adapt to new business needs or market conditions. This can be useful if the project wants to switch to a different open-source license, a proprietary license, or a dual-licensing model later on.

Cons of using a CLA:

• Loss of True Open Source Spirit: The change often restricts certain commercial usage, which deviates from the open-source principles of free use, modification, and distribution.
• Deterrent to contributors: CLAs can be seen as a barrier to contributing to a project, as they require contributors to sign a legal document and provide a certain level of legal protection to the project owner. This can reduce the number of contributions and make it more difficult for a project to grow.
• Complexity: CLAs can be complex and difficult for contributors to understand, potentially leading to misunderstandings and disputes.
• Time-consuming: The process of collecting and tracking CLAs can be time-consuming, especially for large projects with many contributors. Any attempt must be streamlined without introducing too much friction.
• Reputation: Requiring a CLA can harm a project’s reputation, as some people may view it as a barrier to contributing and a sign that the project owner is more concerned with control than with collaboration.
• Community Distrust: The community may feel that claims of being open-source are disingenuous. There are concerns that this could affect the vibrancy and openness of the broader ecosystem that impact other products of the company.

Using a CLA can provide legal protection and help establish ownership of the code, but it can also be seen as a barrier to contributing and negatively impact a project’s reputation. Companies should weigh the pros and cons and decide if using a CLA is the right choice for their specific situation and goals.

Controversy and the Spirit of Open Source

Using BSLs/CLAs has been a source of controversy. Open source typically means that the software’s source code is freely available to view, modify, and distribute. It emphasizes collaboration, transparency, and community-driven development.

It’s challenging to retain control over the commercialization while adhering to true open-source principles. Some companies implement CLAs or choose licenses with specific restrictions, but these can create tensions within the community.

Choosing a License

The type of license a project uses can affect whether a CLA is needed. For projects that plan to commercialize their product, a CLA can be useful to ensure they have the necessary rights to use and distribute contributions in the project. In this case, a CLA can protect intellectual property and give the company greater control over the development of the product.

For projects that are libraries or tools expected to be widely used, a CLA may not be necessary or even harmful. For example, the Apache 2.0 license, which is a permissive license compatible with many other open source licenses, may be a better choice. The Apache 2.0 license also provides patent protection provisions, making it easier to integrate code from other projects.

In contrast, the GPL v3 license is a copyleft license that requires derivative works, including modified versions, to be licensed under the same GPL v3 license. The GPL v3 license is more appropriate for projects that are product-oriented and want to ensure that their code is used in a specific way. In this case, a CLA can provide additional legal protection and help establish ownership of the code.

In our approach to balancing business and open-source endeavors, we classify projects into ‘Universally Permissive’ and ‘Product Copyleft’ categories. This classification helps in better understanding the licensing options and provides a framework for making informed decisions.

‘Universally Permissive’ Type Projects

We prefer the Apache 2.0 license over the MIT, BSD, or ISC license for several reasons:

• Patent protection: The Apache 2.0 license includes patent protection provisions that can protect us and our contributors from patent infringement lawsuits. This is not typically included in the MIT, BSD, or ISC licenses.
• Compatibility with other open source licenses: The Apache 2.0 license is a permissive license that is compatible with many other open source licenses, making it easier to integrate code from other projects into our own.
• Strict compliance requirements: The Apache 2.0 license has strict compliance requirements, ensuring that contributions to our project are properly licensed and attributed.

An open source project that uses the Apache 2.0 license and does not require a CLA for contributions. They are focused on delivering a widely applicable solution to a common problem and encourage collaboration and sharing among contributors.

‘Product Copyleft’ Type Projects

The GPL v3 is a copyleft license that requires that derivative works of the software, including modified versions, be licensed under the same GPL v3 license. A CLA can further strengthen this protection, ensuring that derivative works are also licensed under the GPL v3.

This protection by requiring that contributors assign the copyright of their contributions to the company. This means that the company has full control over the codebase, including the ability to commercialize the project. This can be especially useful if the project is intended to be a commercial product, and we want to ensure that we have full control over the code and can take the project in any direction we see fit.

An open source project that uses the GPL v3 license and requires a CLA for contributions. This type of project is typically focused on delivering a specific solution to a problem, and is intended to protect the investment and interests of the company behind the project. The copyleft license ensures that derivative works and improvements are made available under the same license, while the CLA allows the company to assume ownership of contributions and maintain control over the project.

This is closely aligned with Canonical’s approach to open-source licensing , as they pursue a more traditional open-source philosophy. The GPL encourages code sharing and collaboration and does not include the time-bound commercial restrictions that characterize some BSL’s.

Are CLAs in conflict with Open Source Principles?

A company using a CLA in conjunction with a copyleft license, such as the GPL v3, may appear to be contradictory to freedom. However, using a CLA can serve as a means to protect the company’s intellectual property and maintain control over the development of a product that the company has invested resources in. By requiring contributors to sign a CLA, the company can ensure that all contributions are made under the terms of the copyleft license and that the company has the necessary rights to commercialize the software if it chooses to do so. At the same time, the company can still allow others to use, modify, and distribute the software under the terms of the copyleft license, which promotes the principles of collaboration and sharing.

Adding a CLA Process

When a CLA is desired, it is important to minimize friction for contributors to your projects. The Contributor Assistant GitHub Action for example is a tool that automates managing contributions.

Conclusion

The ongoing debate about the balance between the spirit of open-source collaboration and business considerations is complex. Controversy serves as a reminder that commercial success should not come at the expense of collaborative ethos. The core takeaway is the importance of aligning licensing choices with technological needs and business goals, doing so early and transparently helps building stronger community relationships.