Briefly explained: Legal aspects of FOSS
Free software is a great thing – Different license types can be a hindrance, however, if the conditions do not match the application. An overview.
(Image: Midjourney, Collage: iX)
- Manuela Astrid Weixlbaumer
The advantages of free and open source software (FOSS) are quickly explained: it makes high-quality software components available that have been tested by many parties – and, ideally, can be quickly integrated into your own projects. Underlying this is an idealistic foundation that declares information to be a common good that should be freely available to all. Richard M. Stallmann, founder of the Free Software Foundation (FSF) and initiator of the GNU project, can be regarded as the spiritual father of the movement, which is now forty years old.
For developers, this is initially a practical matter – but in a corporate context, the use of FOSS can cause offense and raise questions. The licensing landscape for free software is changing, and there are nuances and consequences. The copyleft effect has repeatedly been in the spotlight: open software that is used together with proprietary software "infects" the closed parts of a hybrid product with its license – which requires the disclosure of source code –. Many companies are therefore now looking for safelists. They indicate which licenses are to be used, how they differ and in which areas increased care is required.
A brief definition
FOSS is the neutral collective term for Free and Open Source Software – and combines the liberal-idealistic approach of Richard M. Stallman with the more pragmatic approach of Linus Torvalds. FOSS means that software can be used freely and without paying license fees. And the source code is freely accessible; users are allowed to modify and redistribute the software.
Closely related to FOSS are freeware, shareware and public domain. However, some of them differ significantly from FOSS, especially freeware and shareware, which are often classified as commercial software. Commercial software, proprietary software and closed source are therefore opposed to FOSS. FOSS has three main categories of licenses: strict copyleft licenses, limited copyleft licenses and permissive licenses.
Strict copyleft
Copyleft is something like the little brother of copyright, whereby, in contrast to copyright, it regulates the freedom to copy, modify and distribute. Copyleft appears not only in the software sector, but also in the area of copyright licenses in general. In relation to FOSS, copyleft means that software that is licensed under a copyleft license or is derived from it (derivative work) may only be redistributed under the license conditions of the FOSS license. The term "derivative work" is the decisive criterion for determining whether copyleft applies or not.
In practice, this means that the software must be redistributed under the same copyleft license. Depending on the license text, this must be the same license or can also reference a later version – This is the case, for example, with the GPL (GNU General Public License), which is available with "only" or "or-later" conditions.
It is therefore not possible to place copyleft software under a permissive or proprietary license. The software remains available to the community – and the latter is also authorized to modify and redistribute it under the license conditions.
In companies, this can have a considerable impact, as copyleft licenses are also accompanied by obligations such as the disclosure of the source code – the infamous "viral effect". Depending on the scope and quality of the associated proprietary components, this can be irresponsible for companies because it could potentially expose security vulnerabilities or trade secrets to the public. A prime example of a copyleft license is the GPL-2.0, its revised version GPL-3.0, as well as the AGPL-3.0, the CPL-1.0 and the EPL-1.0.
The GPL-2.0 as standard
The classic – and particularly relevant in practice – is the GPL-2.0, under which the Linux kernel is also licensed. It has now developed into a standard thanks to numerous examples of case law. The first groundbreaking decision in this regard in Germany was that of the Regional Court of Munich I (case no. 21 O 6123/04 of 19.5.2004), which granted the GPL-2.0 the status of general terms and conditions and confirmed its validity in Germany. The GPL-3.0 introduced in 2007 then supplemented existing loopholes in the GPL-2.0, for example with regard to tivoization, which is made considerably more difficult with the GPL-3.0. This involves the installation of proprietary software on devices that originally ran with free software.
The requirements of GPL-2.0 and GPL-3.0 apply to all versions of the programs distributed under the licenses. This means that any redistribution of a program, whether unmodified or modified, must comply with the license terms. The central obligations include
- The delivery of the license text with each copy of the program. This is possible in paper form or as a text file, but a link to the license text on the Internet is not sufficient.
- Attaching a copyright notice to each copy of the program. The example text of the GPL should be used as a guide here.
- Creating accessibility to the source code. If a program is delivered compiled in object code or as an executable, the corresponding source code must also be accessible here. This can be done by supplying the complete source code on a data carrier, by a written offer for delivery or by making the code available on the website on which the program is distributed.
Licenses with restricted copyleft
Licenses with restricted copyleft include in particular the GPL with its exceptions such as the linking exception or the classpath exception. A prime example of this is the LGPL (Lesser General Public License), which also exists in several versions. It provides for exceptions to the strict copyleft for dynamic linking of program components, in particular libraries. In contrast to static linking, dynamic linking – – therefore prevents a derived work from being created, so the clause is crucial for triggering the copyleft.
In this case, only a loose link is created between two software components, which remain independent. Such exceptions can turn a strong copyleft into a weak copyleft. They also clearly show how decisive the technical implementation, for example in the form of a link, can be for the validity of license terms.
Videos by heise
Permissive licenses
The most prominent representatives of permissive licenses include the MIT license, the BSD clauses and the Apache licenses. These are licenses without a copyleft clause and with lower licensing requirements. The Apache license is available in several versions. It does not stipulate a copyleft for derived works, but still requires compliance with certain license requirements such as the inclusion of copyright notices, the inclusion of the license text and a disclaimer.
The MIT license is extremely liberal; its only condition is the provision of the license text and the copyright notice. Developers can therefore also publish the modified software under a new license as long as the conditions of the permissive license are met – such as the retention of the copyright notice and license text. This can be another open source license or a proprietary license.
As a rule, permissive licenses can also be combined with each other. The compatibility of licenses has considerable practical relevance: For example, if license A allows something that license B excludes, they are not compatible with each other – again, this is often the case in the copyleft area in particular.
Practical tips
If a company is now considering how and which licenses it will use, precise documentation (Bill of Materials, BOM) is essential in advance. After all, it provides information about the FOSS components used in a product. As a minimum requirement, it specifies a separate component name with its FOSS licenses in the respective version. A safelist can help, but should only be used as a guide.
Of course, it is also important to instruct the staff: Ideally, people with legal responsibility in the company should have a basic interest in programming, while at least one person in the respective development team should also keep an eye on the licensing of the components used by the team. The market also offers scanning tools that help to analyze FOSS – In case of doubt, such tools help to establish legal certainty, but they are not suitable as the sole decision-making instrument. The final check must therefore always be carried out by a responsible person.
It will always come down to the question: "How can we incorporate the FOSS component into the project in such a way that we act in compliance with the license?" And if this is not possible, then the options split into two paths: Is there an alternative involving a commercial or permissive license? Or should we program the required component ourselves?
(dahe)
