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

Permissive licences

The use of permissive open source components is typically less problematic than copyleft components, as permissive licences usually impose less intrusive requirements than copyleft licences. Some of the most common permissive licences are Apache 2.0, MIT, and the BSD licences. Typically, permissive licences give users a right to use, copy, modify and distribute copies of the licensed source code component. However, permissive open source licences 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 licence 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 licence could constitute an infringement of intellectual property rights. Note that this applies to all open source licences, not just the permissive licences.

Copyleft licences

Copyleft licences hold so-called copyleft clauses that apply in addition to the requirements described above that apply under permissive licences. 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 licence, or under another copyleft licence with at least as onerous copyleft requirements. Thus, the copyleft clauses typically make the licence grant conditional on compliance with the copyleft term.

What constitutes a "derived work" must be interpreted in light of the specific open source licence. Some copyleft licences 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 "strong" copyleft effect. Some copyleft licences use terms as "modifications" and "work based on" instead of the term "derived work". Further, open source licences sometimes use the term "larger work" instead of "derived work". "Derived work" (or the term used in the copyleft licence) is not necessarily as limited in scope as "derived work" would be under copyright law. Therefore, the wording of each copyleft licence 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 licence 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 licence their products under a strict proprietary licence of their choosing. Such strict licences 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 licences can be combined with components licensed under other open source licences. As an example, it is generally assumed that a component licensed under the permissive MIT licence may be incorporated into a larger work that is licensed out as a whole under the copyleft GPL licence. On the contrary, a component licensed under the GPL licence may not be incorporated into a larger work that shall be licensed out under the MIT licence.

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

1. combining components licensed under different open source licences in a larger work (c.f. the MIT and GPL example above);
2. combining copyleft open source components with components licensed under a proprietary licence 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 licences are the licences within the GNU family; the LGPL licences, the GPL licences and the AGPL licences. Another common copyleft licence 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 paragraph, we give a general overview of how components licensed under the GPL, LGPL, AGPL and MPL licences 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 be aware that open source licences 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 licences. As such, the specific measures to be made must always be assessed on a case-by-case basis.

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

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 licences that prevent certain use from triggering the copyleft clauses.

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.

Under the three versions of the LGPL licence, derived works that are distributed must be licensed under a LGPL licence. The LGPL is considered a "strong" copyleft licence. However, it is more lenient than the other open source licences 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 copyleft clause in the AGPL is triggered by "conveying" a "work based on" the AGPL covered software. A significant difference between the AGPL licences and the other GNU licences is that the AGPL licences do not contain the so-called ASP-loophole. Therefore, the AGPL licences are considered the most aggressive copyleft licences 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 copyleft clauses of the two versions of the MPL licence cover distribution of "modifications" of the licensed open source components. The MPL is considered a "weak" copyleft licence and is one of the most lenient copyleft open source licences.

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 licences 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 licence 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.