052.2 Lesson 1
Certificate: |
Open Source Essentials |
---|---|
Version: |
1.0 |
Topic: |
052 Open Source Software Licenses |
Objective: |
052.2 Copyleft Software Licenses |
Lesson: |
1 of 1 |
Introduction
The importance of licenses for both the use and the development of software has already been described. It is therefore not surprising that free software has also been characterized by new approaches to licensing from the outset: Conditions for the unrestricted use or collaborative development of software must be legally defined in order to be protected and enforced.
Aware that copyright law, which is firmly anchored in almost all legal systems worldwide, could not be questioned or replaced, software developers took an approach as early as the 1980s that respects copyright regulations but supplements them with new regulations that emphasize the principle of “freedom”: copyleft.
Copyleft and the GNU General Public License (GPL)
Richard Stallman, then a developer at the renowned MIT, founded the GNU Project in 1983 to develop what he considered to be a “free” operating system. It soon became clear that the code developed by the project had to be legally protected so that it could not simply be taken over by commercial providers and thus become “non-free.”
Stallman therefore founded the non-profit Free Software Foundation (FSF) in 1985, which summarizes its mission on its website as follows: “The Free Software Foundation is working to secure freedom for computer users by promoting the development and use of free (as in freedom) software and documentation…”
A key instrument for this mission is a license that respects applicable law (especially copyright law) on the one hand and implements its own ideas of freedom in a legally clean manner on the other. The result was the first version of the GNU General Public License (GPLv1) in 1989. This license and numerous articles — such as “What is Free Software?”, written by Stallman in 1992 — make clear the motivations and values of free software developers, who now also see themselves as a “movement.”
The programmatic core is still formed by the “four essential freedoms” formulated by Stallman in the aforementioned article, the numbering of which begins with 0:
The freedom to run the program as you wish, for any purpose (freedom 0).
The freedom to study how the program works, and change it so it does your computing as you wish (freedom 1). Access to the source code is a precondition for this.
The freedom to redistribute copies so you can help others (freedom 2).
The freedom to distribute copies of your modified versions to others (freedom 3). By doing this you can give the whole community a chance to benefit from your changes. Access to the source code is a precondition for this.
What is Free Software?
Unlike licenses for commercial products, which place restrictions on use in the foreground, free software is about maximum freedom for users and developers.
The preamble of the GNU GPLv1 summarizes this as follows:
Specifically, the General Public License is designed to make sure that you have the freedom to give away or sell copies of free software, that you receive source code or can get it if you want it, that you can change the software or use pieces of it in new free programs; and that you know you can do these things.
version 1
This means that everyone has the right to use, distribute, and modify software under the GPL without restriction (which is possible because the source code is accessible, i.e. “open”) and in turn to distribute the modifications. It is even possible to charge money for passing on the software:
Actually, we encourage people who redistribute free software to charge as much as they wish or can. If a license does not permit users to make copies and sell them, it is a nonfree license….Free programs are sometimes distributed gratis, and sometimes for a substantial price. Often the same program is available in both ways from different places. The program is free regardless of the price, because users have freedom in using it.
Selling Free Software
But if the freedoms are so far-reaching, to what extent is software protected under this license, for example from being incorporated into proprietary products?
This is the role of the previously mentioned copyleft principle, which the GPL already applies in version 1 even if the term does not yet appear explicitly:
You may not copy, modify, sublicense, distribute or transfer the Program except as expressly provided under this General Public License.
This means that all these freedoms are linked to the condition that users preserve these freedoms in everything they do with the software.
Copyleft therefore not only guarantees freedoms, but also requires all users to grant these freedoms to others. This is achieved by stipulating that software under a copyleft license (such as the early GPLv1) may be modified and redistributed only if the modifications are published under the same conditions, i.e. under the same license.
The ideal of free software, namely the collective use and further development of software, therefore takes precedence over the personal needs that individuals might have in relation to the software. The principle of reciprocity is crucial: Those who use freedoms must also grant them. Copyleft licenses are therefore often referred to as reciprocal.
This completely new approach to a software license already proved to be legally sound and practicable in version 1 of the GPL, so the GPL has undergone only two major revisions in the almost 40 years during which the modern IT market has developed.
GPLv2 and GPLv3
In 1991, the Free Software Foundation presented version 2 of the GNU General Public License (GPLv2), which established itself as the most popular license for free software projects over many years. For example, the core of the Linux operating system is still licensed under GPLv2 today.
Compared to version 1, version 2 is primarily concerned with more precise definitions to avoid ambiguities. For example, version 2 explains in much greater detail what is meant by “source code.”
Also of interest is the new Section 7, which sets the principle of freedom and thus the validity of the license as absolute and does not allow any compromises — for example, the integration of less free parts into the software:
If you cannot distribute so as to satisfy simultaneously your obligations under this License and any other pertinent obligations, then as a consequence you may not distribute the Program at all. For example, if a patent license would not permit royalty-free redistribution of the Program by all those who receive copies directly or indirectly through you, then the only way you could satisfy both it and this License would be to refrain entirely from distribution of the Program.
It was not until 16 years later, in 2007, that the FSF published a new version of the GPL in order to take account of technical innovations — such as the provision of software services via the internet — as well as issues of compatibility with other FOSS licenses. However, the license remains stable in terms of its core statements and merely adds details for further clarification. Let’s take a closer look at some of these additions.
While the GPLv2 still generally refers to the provision of software as distribution, GPLv3 specifies this process with two new terms: propagation and conveying. The main reason for this is that the term “distribution” is defined in numerous copyright laws worldwide. To avoid ambiguity or conflict, the GPLv3 chooses these new terms and defines them as follows:
To “propagate” a work means to do anything with it that, without permission, would make you directly or secondarily liable for infringement under applicable copyright law, except executing it on a computer or modifying a private copy. Propagation includes copying, distribution (with or without modification), making available to the public, and in some countries other activities as well.
To “convey” a work means any kind of propagation that enables other parties to make or receive copies. Mere interaction with a user through a computer network, with no transfer of a copy, is not conveying.
With the significantly growing number of commercial software products whose distribution is restricted by manufacturers through technical measures such as registration codes or hardware components (so-called dongles), there were a number of international legal initiatives in the late 1990s to criminalize the circumvention of these measures. This so-called digital rights management (DRM), also derogatorily referred to by opponents as digital restrictions management, is a thorn in the side of the FSF, as the measures fundamentally contradict the demand for the free distribution of software.
In response, version 3 of the GPL contains a passage stating that software under the GPL may not be modified with reference to legal DRM requirements. This also means that software licensed under GPLv3 may use DRM, but that others are also permitted to circumvent such measures.
The term tivoization is also frequently used in this context. The word appeared explicitly in the first drafts of GPLv3 but was not included in the final version. The term goes back to the company TiVo, which used GPLv2-licensed software in its digital video recorder, but at the same time technically prevented modified software from being installed and used on the device. In the FSF’s opinion, this contradicted the principles of the GPL, and after some discussion, the GPLv3 takes this into account with a paragraph on so-called user products. It generally stipulates that products that use GPLv3-licensed software must also provide information on how this software can be modified.
A further addition concerns patents, which the FSF fundamentally rejects on software with reference to their obstruction of freedom and innovation. This is already stated in the preamble to GPLv3:
Finally, every program is threatened constantly by software patents. States should not allow patents to restrict development and use of software on general-purpose computers, but in those that do, we wish to avoid the special danger that patents applied to a free program could make it effectively proprietary. To prevent this, the GPL assures that patents cannot be used to render the program non-free.
The license text also contains several passages that allow the inclusion of code under a patent by means of a “non-exclusive, worldwide, royalty-free patent license” from the licensor in order to protect users of such code from disputes between patent holders and licensees.
The GNU Affero General Public License (AGPL)
With the increasing availability and speed of the internet, more and more services are emerging in which the software is merely installed on the servers of the vendor — the Application Service Provider (ASP) — and whose customers interact with the services via the internet. The trend has gained the name Software as a Service (SaaS).
In such cases, the GPLv2 did not provide any clarity as to whether and how the source code (possibly modified by the provider) should be made available. Version 3 of the GPL closes this loophole, known as the ASP loophole, by explicitly referring in section 13 to another license issued by the FSF in 2007: the GNU Affero General Public License version 3 (GNU AGPLv3). The name goes back to the company Affero, which developed and published the first two versions of this license.
This AGPLv3 basically corresponds to the GPLv3, but explicitly regulates the ASP problem in the section “remote network interaction.” Furthermore, both licenses explicitly state that they can be combined with each other without restriction.
In summary, the GNU AGPL is a complementary supplement to the GPL. The AGPL extends the scope of the GPL by applying copyleft to software that is no longer used in local installations, but exclusively in the form of services transmitted via networks.
Compatibility of Copyleft Licenses
The development of free software thrives on building on the work of others, i.e. integrating, modifying, and sharing the source code of others. If all parts of a modified or newly compiled software are under the same copyleft license, for example the GPLv3, this is possible without any legal problems. The license simply requires that the result is distributed under the same license.
Things become more complicated when software consists of parts that are licensed under different licenses. Several factors need to be taken into account here.
Combined and Derivative Works
Free software is sometimes created under very different conditions. Changes range from simple error corrections to complex projects with millions of lines of code. Regardless of the scope, a basic distinction is made between two types of works when it comes to licensing: derivative and combined.
Let’s assume, for example, that software project A is missing a certain functionality. Instead of developing this functionality from scratch, it makes sense to combine code from another project B, which offers exactly this functionality, with A. The software from B would not even have to be changed for this, but could simply be added to A. It is therefore a combined work. If both A and B are under the same copyleft license, there are no problems for the combined work.
If A and B are under different copyleft licenses, caution is required: Is the combination of A and B already a separate work? And, if so, under which license can or must it be licensed? Or can a conflict be avoided by ensuring that both parts A and B remain separate with their respective licenses and do not constitute a new work?
It becomes even more difficult with derivative works, i.e. when project A can make use of B’s functionality only by incorporating code from B directly into the code of A. This integration creates a new, derivative work whose parts can no longer be separated.
Copyleft comes into play for a derivative work. If, for example, A is under a copyleft license such as the GPLv3, the new, derivative work must also be under the GPLv3 in accordance with the principle of reciprocity. But what if B is under a different license? Is it a copyleft license, and is it compatible with the GPLv3? Or, if it is a different type of license, can B also be published under a different license, i.e. relicensed? Or are the licenses of A and B even categorically mutually exclusive?
The aim in this lesson is not to list the possible combinations and possible solutions. The important thing is to illustrate the complexity of the problem resulting from the combination of very different issues.
Technically, the first thing to clarify is how the different parts of the software (in our example A and B) work together: Can they be separated from each other or are there processes whose execution can no longer be clearly assigned to one part or the other?
From a legal point of view, questions arise about the relationship between the licenses of A and B. Are they compatible with each other, or only in parts or only in one direction? Is relicensing an option?
We can only hint at the complexity of these questions here, not resolve them. Such decisions call for sound legal knowledge. Thus, licensing decisions for new works, but especially for combined and derivative works, should be made early, carefully, and always after detailed legal advice.
Weaker Copyleft
The copyleft has proven to be extremely robust over the past decades, especially in the form of the GPL in versions 2 and 3. However, special technical requirements have prompted the FSF to react by adapting its licenses. The GNU Affero General Public License is one such example. We discuss other examples in the following subsections.
The GNU Lesser General Public License (LGPL)
A method frequently used in software development is the use of small modules for standard tasks, such as opening or saving files. These modules — or collections of such modules — are referred to as software libraries. They are usually not independently executable applications, but routines that the actual application integrates as required. The integration process is known as linking, whereby a distinction is made between two methods.
With static libraries, the actual application (via auxiliary programs and intermediate steps) firmly integrates the code of the modules into the executable file of the application. With dynamic libraries, on the other hand, the application integrates a module only when required at runtime and loads it into the working memory.
This raises a question with regard to copyleft and licensing: What are the licensing implications of linking? For example, does this form of taking over code require an application that uses a library under the GPL to adopt the GPL itself? And does this apply to both static and dynamic linking?
The linking process is so ubiquitous in software development, and the issues associated with reciprocal copyleft so extensive, that the FSF looked early on for a licensing solution that permitted linking through the GNU Lesser General Public License (LGPL). The LGPL is updated at the same time as each new version of the GPL. The name of the license in version 1 was the GNU Library General Public License, which revealed the original problem that led to the license’s creation. In versions 2 and 3, “Library” replaced by “Lesser” to indicate what is actually at stake, namely a pragmatic weakening of the copyleft principle.
A library licensed under the LGPL can therefore be used by software without this software itself automatically being subject to the copyleft. Software projects under so-called permissive licenses (covered in another lesson), in particular, benefit from this compromise, as it creates legal protection for the combination of approaches that are not per se compatible under licensing law.
Any changes to LGPL-licensed software are still subject to the copyleft, i.e. they must also be under the LGPL.
However, the LGPL-licensed library must be interchangeable, to allow the user of the software to replace the library with a modified version. Appropriate conditions must be created for this, i.e. information must be provided on how such a replacement can be made.
Other Copyleft Licenses
Other FOSS projects and organizations also look for the best legal framework for their needs, and hence develop their own licenses. One example is the Mozilla Foundation, founded in 1998 and today best known for the two projects it supports: the Firefox internet browser and the Thunderbird email client.
Version 1 of the Mozilla Public License (MPL) was published in 1998, and the current (as of 2024) version 2.0 in 2012.
Like the LGPL, the MPL is often referred to as a “weak copyleft” license. In fact, it seeks to strike a balance between the strict requirements of the copyleft and the possibilities for integration with commercial products. It achieves this, among other things, through a principle known as file-level copyleft: If you make a change to a file that belongs to software under the MPL, you can integrate this file into proprietary software as long as the modified file itself is remains under the MPL and is therefore accessible.
Another example of a weak copyleft license is the Eclipse Public License (EPL) from the Eclipse Foundation. The current version 2.0 from 2017 is very similar to the MPL and is often referred to as the most “business-friendly” copyleft license. However, the various copyleft licenses — and there are others besides the ones mentioned here — often arose due to historical developments rather than clear legal differences.
Guided Exercises
-
What does the abbreviation GPL stand for?
-
Why are copyleft licenses also referred to as reciprocal?
-
Which FSF copyleft license is suitable for software libraries?
-
Which English terms replace the term “distribution” in GPLv3 and why?
-
Which of the following copyleft licenses were issued by the Free Software Foundation?
GPL version 3
AGPL version 1
LGPL version 2
MPL 2.0
EPL version 2
Explorational Exercises
-
Which of the following are copyleft licenses?
GPL version 2
3-clause BSD License
LGPL version 3
CC BY-ND
EPL version 2
-
Can one typically create a derivative work combining parts of two software projects that are under different strong copyleft licenses? Give reasons!
-
Which of the following licenses have a strong copyleft and which have a weak copyleft?
Common Development and Distribution License (CDDL) 1.1
GNU AGPLv3
Microsoft Reciprocal License (MS-RL)
IBM Public License (IPL) 1.0
Sleepycat License
-
Describe some compatibility issues that could arise when combining software under a weak copyleft license with software under a non-copyleft license.
Summary
This lesson deals with the characteristics of software licenses that follow the principle of copyleft. Developed in the 1980s by the Free Software Foundation, the GNU General Public License (GPL) is currently the most popular license with a strong copyright. Despite several revisions up to the current version 3, its basic requirements have remained virtually unchanged: The freedoms granted by the license to use, redistribute, and modify the software without restriction must be preserved at all times. This means that the modified software may be distributed only under the same conditions (i.e., the same license).
Technical innovations as well as the desire for legal leeway when collaborating with other projects have prompted the FSF to develop supplementary or alternative licenses. The GNU Lesser General Public License (LGPL), for example, takes into account the static or dynamic linking of software libraries frequently used in software development. The GNU Affero General Public License (AGPL) responds to the technical trend toward using software in the form of services via the network (especially the internet), i.e. not in local installations.
In addition to the FSF, other projects such as the Mozilla Foundation and the Eclipse Foundation have developed copyleft licenses. These also seek a compromise between securing the freedoms granted by the license and a simpler relationship to software under other licenses by means of a weaker copyleft.
In principle, license compatibility is an important issue with copyleft licenses, because the principle of free, collaborative software development must be reconciled with the legal conditions determined by the respective license. In any form of combination of software under different licenses, the legal conditions must be examined carefully in each individual case.
Answers to Guided Exercises
-
What does the abbreviation GPL stand for?
General Public License
-
Why are copyleft licenses also referred to as reciprocal?
The principle of copyleft requires that freedoms granted by a license must also be granted to others without restriction. For example, if you make a change to software under the GPL, you are obliged to make these changes available to others under the same conditions, in accordance with this reciprocity.
-
Which FSF copyleft license is suitable for software libraries?
GNU Lesser General Public License (GNU LGPL)
-
Which English terms replace the term “distribution” in GPLv3 and why?
The terms “convey” and “propagate” replace “distribution.” The background to this is that the term “distribution” is firmly anchored in international copyright law. To avoid conflicts or misunderstandings, the GPL in version 3 does not use this term.
-
Which of the following copyleft licenses were issued by the Free Software Foundation?
GPL version 3
X
AGPL version 1
LGPL version 2
X
MPL 2.0
EPL version 2
Answers to Explorational Exercises
-
Which of the following are copyleft licenses?
GPL version 2
X
3-clause BSD License
LGPL version 3
X
CC BY-ND
EPL version 2
X
-
Can one typically create a derivative work combining parts of two software projects that are under different strong copyleft licenses? Give reasons!
No. Licenses with a strong copyleft generally require that modified versions are under the same license. This also excludes relicensing. The combination of licenses, when both follow these principles, therefore represents an irresolvable contradiction.
-
Which of the following licenses have a strong copyleft and which have a weak copyleft?
Common Development and Distribution License (CDDL) 1.1
weak
GNU AGPLv3
strong
Microsoft Reciprocal License (MS-RL)
weak
IBM Public License (IPL) 1.0
weak
Sleepycat License
strong
-
Describe some compatibility issues that could arise when combining software under a weak copyleft license with software under a non-copyleft license.
While a strong copyleft requires the modified software to be distributed under the same license, the conditions are “relaxed” in the case of a weak copyleft. Nevertheless, any combination with other licenses raises fundamental questions of compatibility. Important aspects need to be considered when answering these questions: Are the original parts of the two software projects clearly separate in the new work and, if necessary, can they still be licensed differently? At what level does the connection between the two original software projects actually take place? Is source code directly adopted or is it “only” dynamically linked against the other software (library)? Does one of the two licenses generally allow relicensing? All questions of this kind can be answered only after a precise analysis of the respective licenses and with specialist legal expertise.