Jusletter IT

Many, but not all, OSS licenses have a copyleft effect. For example, the GNU General Public License version 3 (GPL-3.0)¹ has a strong copyleft effect. This means that any derivative work of the original work (licensed under GPL-3.0) is bound by the same OSS license terms. As long as the derivative work is not distributed, there is no obligation to provide the modified source code (i.e. derivative work) to any third party.² However, if and once the derivative work of the original OSS licensed under GPL-3.0 is distributed (conveyed), the receiver of the derivative work, i.e. the downstream user, is entitled to receive a copy of the modified software (derivative work) in source code. If the modified software was not distributed as source code, but rather in compiled form, then it must be accompanied either by a copy of the source code or indirectly with information on how/where the source code can be obtained.³

A possible fear associated with open source software (OSS) is that its use in conjunction with other (possibly) proprietary software could result in a derivative work. In such case, the source code of the proprietary software in the derivative work might also need to be made available to the downstream users of it.⁴ The derivative work might become affected, or – for the lack of a better word – «contaminated» by the OSS licensing terms.

To know whether or not the copyleft effect applies to modified software, i.e. whether or not one must «fear» the derivative work, it is vital to know what a derivative work is. The challenge is not only that software, which is a work protected under copyright, is defined by national law (e.g. copyright law, possibly labour law, and/or case law); but also that certain OSS licenses either define derivative works or at least attempt to do so; and that OSS is (can be) deployed cross-border.

According to Swiss law, derivative works are intellectual creations with individual character that are based upon pre-existing works, whereby the individual character of the latter remains identifiable (art. 3 para. 1 CopA⁵). As one might imagine, the transition from free use of the original work to creation of a derivative work is gradual, with a (shifting) tipping point. Examples of derivative works of an original work are, e.g., translation of a book, remake of a motion picture, or update / new release of software.

However, minor modifications of an original work without qualitative changes do not qualify as derivative works, but rather (only) as use of the original work. Examples are mere copies of the original work, or quantitatively minor extractions (not being the core of the original work) from an original work, or shortening / summarizing of it.⁶

On the one hand, in its definition of software (program), (i) GPL-2.0⁷ refers specifically to «derivative work under copyright law» (cf. section 0), and (ii) GPL-3.0 refers to modified version of software (program) by defining the term «modify» as «to copy from or adapt all or part of the work in a fashion requiring copyright permission, other than the making of an exact copy» (cf. section 0 (Definitions)). Hence, both refer to copyright law.

On the other hand, the Mozilla Public License 2.0 (MPL-2.0)⁸ defines the term «Modification» as «(a) any file in Source Code Form that results from an addition to, deletion from, or modification of the contents of Covered Software; or (b) any new file in Source Code Form that contains any Covered Software.» There is no reference to copyright law.

It has been suggested that, where there is no link to copyright law in an OSS license (e.g. MPL-2.0), the definitions provided tend to encompass any new file that contains any part of the licensed OSS. Hence, either making a minor modification or copying even a very small part (e.g. a snippet) of OSS code into a file with proprietary code might arguably result in a derivative work. But apparently, besides rather clear cut examples such as (i) where two software components are compiled into a single program (e.g. executable) resulting in a derivative work or (ii) mere aggregation of separate software components on the same medium (e.g. SSD) not resulting in a derivative work many questions remain unanswered.⁹

The consequence seem to be that where an OSS license refers to copyright law (e.g. GPL-2.0/3.0), a derivative work must qualify as new copyrighted work under such national law in order trigger the copyleft effect. Contrary, where an OSS license does not refer to copyright law but rather stipulates its own terms for derivative works (e.g. MPL-2.0), no new copyrighted work (pursuant to copyright law) must have created to trigger the copyleft effect.

The advantage of one OSS license seems to be the disadvantage of the other: Under GPL-2.0/3.0 there seems to be some margin for not triggering the copyleft effect but also uncertainty regarding qualification of a derivative work due to potentially different applicable national copyright laws. Under MPL-2.0 there seems to be more certainty regarding the definition of derivative work but less margin to avoid the copyleft for a derivative work (as defined by the OSS license). This trade-off might be relevant when selecting the OSS license.