Open source & copyleft licenses– how to ensure commercially acceptable use

In this article, we will explain measures that may be taken to reduce the risk of encountering any such issues when using components licensed under the most common open source licenses in a commercial setting. The most important measure is carefully considering the applicable open source license before incorporating open source components into your software product. It is advisable to establish an open source policy and an open source compliance procedure that must be followed before using any open source. Having such low-cost measures in place is a sign of a mature technology company with good protective measures in place for its intellectual property, which again may influence the valuation of the company.

Open source licenses can be divided into two categories; permissive licenses and copyleft licenses.

Permissive licenses

The use of permissive open source components is typically less problematic than copyleft components, as permissive licenses usually impose less intrusive requirements than copyleft licenses. Some of the most common permissive licenses are Apache 2.0, MIT, and the BSD licenses. Typically, permissive licenses give users a right to use, copy, modify and distribute copies of the licensed source code component. However, permissive open source licenses often make such rights conditional on the provision of licensing information to the company's own licensees, such as attributions of copyright owners and disclaimers. Consequently open source license grants are, or can at least be argued to be, invalid in the event of non-compliance with the requirement to provide licensing information. Thus, using open source without full compliance with the open source license could therefore constitute infringement of intellectual property rights. Note that this applies to all open source licenses, not just the permissive licenses.

Copyleft licenses

The copyleft licenses hold so-called copyleft clauses that apply in addition to the requirements described above that apply under permissive licenses. Copyleft clauses typically require that both (i) the original open source component, and (ii) any material based on the original open source component ("derived work"), are made available under the same copyleft license, or under another copyleft license with at least as onerous copyleft requirements. Thus, the copyleft clauses typically make the license grant conditional on compliance with the copyleft term. Please note that what constitutes a "derived work" must be interpreted in light of the specific open source license. Some copyleft licenses define "derived work" as the entire product in which the open source component is used, in addition to material based on the original component. This is referred to as the so-called "strong" copyleft effect. Some copyleft licenses use terms as "modifications" and "work based on" instead of the term "derived work". Further, open source licenses sometimes use the term "larger work" instead of "derived work". "Derived work" (or the term used in the copyleft license) is not necessarily as limited in scope as "derived work" would be under copyright law. Therefore, the wording of each copyleft license must be carefully interpreted. In this article, we, for simplicity, sometimes use the term "derived work", and other times "larger work", as if they were synonyms.

The purpose of copyleft clauses is to enforce the freedoms offered by the open source license on "derived work". The ideology is that everyone should contribute to a growing body of source code being open and available for anyone to use, exploit commercially and further develop. On the other hand, commercial developers normally desire to keep all their source code secret, in order to prevent plagiarism and other infringements. Additionally, commercial developers normally desire to license their products under a strict proprietary license of their choosing. Such strict licenses normally grant the licensee the right only to use the product for the licensee's own purposes and grant no right of commercialization and no right to change or further develop the product. In other words, commercial developers normally want to retain the exclusive rights they normally have under copyright law.

When copyleft clauses are triggered, developers of "derived work" cannot choose the terms and conditions under which the "derived work" shall be licensed. Thus, the copyleft effect is most often not commercially acceptable if an open source component establishes a "derived work".

Furthermore, not all open source licenses can be combined with components licensed under other open source licenses. As an example, it is generally assumed that a component licensed under the permissive MIT license may be incorporated into a larger work that is licensed out as a whole under the copyleft GPL license. On the contrary, a component licensed under the GPL license may not be incorporated into a larger work that shall be licensed out under the MIT license.

Therefore, software developers should consider whether the relevant licenses permit combined use before:

The most common copyleft licenses

The most common copyleft licenses are the licenses within the GNU family; the LGPL licenses, the GPL licenses and the AGPL licenses. Another common copyleft license is the MPL.

Under the GPL, LGPL, AGPL and MPL strictly internal use of a product does not involve any activity that triggers the copyleft clauses.

In the following, we give a general overview of how components licensed under the GPL, LGPL, AGPL and MPL licenses may be used in order to reduce the risk of triggering the copyleft clauses to the effect that own developed source code must be made available as open source. However, please keep in mind open source licenses are often unclear, and there are few public court awards providing guidance. In addition, it may be unclear which country's law is applicable in relation to interpretations of open source licenses. As such, the specific measures to be made must always be assessed on a case-by-case basis.

The GNU General Public Licenses (GPL)

The GPL licenses consist of three versions holding copyleft clauses requiring that all derived work that is distributed shall be licensed under the same GPL license. Since all distribution of derived work triggers copyleft, the GPL licenses are known as "strong" copyleft licenses.

What constitutes a derived work under the GPL?

What constitutes distribution under the GPL?

How can components licensed under GPL be used in a commercial setting without triggering the copyleft clause?

One should be aware that it is possible to use a module licensed under GPL as an independent program that runs on the command line (or equivalent) for some components and use cases. However, such use should be assessed by a qualified lawyer and avoided if possible. In a due diligence context, such use is likely to provide concerns.

The Lesser General Public License (LGPL)  

Under the three versions of the LGPL license, derived works that are distributed must be licensed under a LGPL license. The LGPL is considered a "strong" copyleft license. However, it is more lenient than the other open source license from the GNU family.

What constitutes a derived work under the LGPL?

What constitutes distribution under the LGPL?

How can components licensed under LGPL be used in a commercial setting without triggering the copyleft clause?

The Affero General Public License (AGPL)

The copyleft clause in the AGPL is triggered by "conveying" a "work based on" the AGPL covered software. A significant difference between the AGPL licenses and the other GNU licenses is that the AGPL licenses do not contain the so-called ASP-loophole. Therefore, the AGPL licenses are considered the most aggressive copyleft licenses in the GNU family.

What constitutes work based on the AGPL covered software?

What constitutes conveying under the AGPL?

How can components licensed under AGPL be used in a commercial setting without triggering the copyleft clause?

The Mozilla Public Licenses (MPL)

The copyleft clauses of the two versions of the MPL license cover distribution of "modifications" of the licensed open source components. The MPL is considered a "weak" copyleft license and is one of the most lenient copyleft open source licenses.

What constitutes modifications under the MPL?

What constitutes distribution under the MPL?

How can components licensed under MPL be used in a commercial setting without triggering the copyleft clause?

Conclusion

As this article illustrates, the terms of the applicable open source license should be considered before using open source components in proprietary software. This can be ensured by establishing an open source policy and an open source compliance procedure that must be followed before using any open source. We can provide advice on the content of such policies and procedures for your company.

If in doubt of the content of an open source license or the consequence of specific use of an open source component, we recommend seeking legal advice before using the open source component in proprietary software.