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



Published 07 September 2021
News image

If a technology company is the target of a corporate transaction (for instance, a new issue of shares), a due diligence of the company may be required. Legal due diligence usually includes reviewing the company’s use of open source components and compliance with the applicable license terms. Non-compliance with open source licenses is a finding that may influence the valuation of a company, as it may for example expose the company to cease and desist orders from the originators or stewards of the open source components. Replacing or removing open source components from source code, to mitigate non-compliance with open source license terms, can be time-consuming, expensive and impractical. Open source components can be embedded in hardware that cannot be updated remotely and changing software can give rise to a lengthy certification process, for instance in the case of medical devices.

By Hugo Berg Otterlei, Anna Eide and Jenny Nondal

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.


Different categories of open source licenses

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:

  1. combining components licensed under different open source licenses in a larger work (c.f. the MIT and GPL example above);
  2. combining copyleft open source components with components licensed under a proprietary license in a larger work; and
  3. using copyleft open source components in a larger work commercially licensed to customers on the market.

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?

  • Derived work under GPL means proprietary work based upon an open source component licensed under the GPL, including but not limited to, copying the licensed or modified material into proprietary software.
  • Work that dynamically or statically links to the open source components licensed under GPL licensed constitutes derived work under the GPL.

What constitutes distribution under the GPL?

  • Distribution includes providing anyone copies of code (in any format, executable or source code).
  • It is generally assumed that access to a product solely as a software-as-a-service (i.e. SaaS) does not constitute distribution under GPL if no code is transferred to the user side. This so-called ASP-loophole is only stated explicitly in some versions of the GPL.
  • If the software is sent to the user’s machine through, for example, HTML, CSS, or JavaScript, the ASP-loophole does not apply and it will be considered as distribution.

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

  • Use strictly within the company does not trigger the copyleft, meaning, all users must be the company's own employees for such usage to be safe.
  • Software that includes derived works under GPL can be made available as SaaS (if no code is transferred to the user side), although, this relies for GPL versions 1.0 and 2.0 on interpretations that are not entirely certain.
  • Some components are subject to "exceptions" from the GPL licenses that prevent certain use from triggering the copyleft clauses.

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?

  • Work that is based upon, modifies or includes a copy of the licensed or modified open source component, constitutes a derived work.
  • If parts of a software product only link to the open source component at runtime (dynamic linking), the software product is not considered as a derived work.
  • If, on the other hand, parts of the software product are permanently linked to the open source component, when building the software product for distribution (static linking), the entire software product is considered as a derived work. When statically linking to an open source component, some of the executable file will be based partly on the open source code component.

What constitutes distribution under the LGPL?

  • As under the GPL, distribution under LGPL includes provision of copies of the software to the user.
  • As under the GPL, SaaS does not constitute distribution if no code is transferred to the user side.

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

  • Larger works (products) that include dynamic links to solely unmodified LGPL licensed components can be distributed.
  • Larger works (products) that include derived works under LGPL can be made available as a SaaS (if no code is transferred to the user side).

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?

  • The term "work based on" AGPL covered software shall be interpreted as the term "derived work" under the GPL. Thus, software that is statically or dynamically linked to AGPL licensed components constitutes work based on the AGPL covered software.

What constitutes conveying under the AGPL?

  • The term "conveying" under the AGPL comprises the same elements as the term "distribution" under the GPL, except for the ASP-loophole.
  • As the AGPL explicitly targets SaaS, making available software over a network, even without transferring a copy of code to the user's machine, triggers the AGPL copyleft clause.

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

  • As any distribution of software that is linked to or incorporates AGPL components triggers copyleft, either the entire product must be made available under the AGPL or the product must only be used strictly internally.

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?

  • Additions to, and deletion from, the licensed open source component and copying a part of the licensed component into new source code constitute modifications under the MPL.
  • Software that includes static or dynamic linking to MPL licensed components is not deemed as modifications under the MPL.

What constitutes distribution under the MPL?

  • Provision of a copy of the software to another person or entity is considered as distribution.
  • Provision of software over network, without transferring a copy to the user's machine, does not constitute distribution.

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

  • Software that includes dynamic or static links to unmodified MPL licensed components can be distributed.
  • Software that includes modifications of components licensed under MPL can be made available as a SaaS (if no code is transferred to the user side).


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.