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 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:
- combining components licensed under different open source licences in a larger work (c.f. the MIT and GPL example above);
- combining copyleft open source components with components licensed under a proprietary licence in a larger work; and
- using copyleft open source components in a larger work commercially licensed to customers on the market.