The advantages of Free and Open Source Software (FOSS) are quickly explained: it makes available high-quality software components that have been tested by multiple parties – which, ideally, can be quickly integrated into your own projects. Could. Behind this lies an idealistic basis which declares information as a public good which should be freely available to everyone. Richard M. Stallman, founder of the Free Software Foundation (FSF) and initiator of the GNU project, can be considered the spiritual father of this movement, which is now forty years old.
Advertisement
Manuela Astrid Wexelbaumer is a lawyer and works as an IP expert and compliance officer for automation specialist KEBA in Linz/Austria. She runs the vlog ‘The Cherry Compiler’ which covers intellectual property, digitalization and women empowerment.
For developers, this is initially a practical matter – but in a corporate context, the use of FOSS can be invasive and raise questions. The licensing landscape for free software is changing; There are changes and consequences. The copyleft effect has repeatedly been in the headlines: open software that is used together with proprietary software “infects” even the closed parts of the hybrid product with its license – which requires disclosure of the source code. Is. Many companies now want safelist. They explain which licenses to use, how they differ and which areas require more care.
a brief definition
FOSS serves as a neutral collective term for free and open source software – it combines the liberal-idealistic approach of Richard M. Stallman with the more pragmatic approach of Linus Torvalds. FOSS means that the software can be used freely and without paying license fees. And the source code is freely accessible; Users are allowed to modify and distribute the software.
Freeware, shareware, and public domain are closely related to FOSS. However, some of them differ significantly from FOSS, particularly freeware and shareware, which are often classified as commercial software. Therefore commercial software, proprietary software and closed source are opposed to FOSS. FOSS recognizes three main categories of licenses: strict copyleft licenses, limited copyleft licenses, and permissive licenses.
hard copy left
Copyleft is somewhat like copyright’s younger brother, although it is the opposite of copyright. Freedom Controls copying, modification, and distribution. Copyleft appears not only in the software field, but also in the field of copyright licensing in general. In relation to FOSS, copyleft means that software that is licensed under or derived from a copyleft license (derivative works) may only be redistributed under the license terms of the FOSS license. The concept of a derivative work is the decisive criterion as to whether copyleft occurs 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 may even refer to a later version – this is the case, for example, with the GPL (GNU General Public License), which states “only” or “or-later.” Available” ” 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 terms.
This can have a significant impact on companies, as copyleft licenses also come with obligations such as disclosing source code – the infamous “viral effect”. Depending on the scope and quality of the proprietary components involved, this may be irresponsible for companies as security gaps or trade secrets could potentially become public. A prime example of a copyleft license is GPL-2.0, its modified version GPL-3.0, as well as AGPL-3.0, CPL-1.0, and EPL-1.0.
GPL 2.0 as standard
The classic – and particularly relevant in practice – is GPL 2.0, under which the Linux kernel is also licensed. Thanks to numerous case law examples, this has now developed into a standard. The first unprecedented decision in this regard in Germany was that of the Munich I Regional Court (Az. 21 O 6123/04 dated May 19, 2004), which granted the status of General Terms and Conditions to GPL-2.0 and confirmed its effectiveness. Germany. GPL 3.0, introduced in 2007, addressed existing shortcomings in GPL 2.0, for example with respect to tivization, which has been made more difficult with GPL 3.0. This involves installing 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 programs distributed under the license. This means that any distribution of a program, whether unchanged or modified, must comply with the license terms. Major commitments include:
- Distribution of 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 when distributing any copy of the Program. Here you should use the example text of the GPL as a guide.
- Accessing the source code. If a program is compiled into object code or distributed as an executable, the corresponding source code must also be accessible here. This can be done by providing the complete source code on the data medium, by making a written proposal for delivery, or by making the code available on the website on which the program is distributed.
Restricted Copyleft License
Licenses with restrictive copyleft specifically include the GPL and 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 comes in several versions. It provides exceptions to strict copyleft when dynamically linking program components, especially libraries. A dynamic link – unlike a static link – prevents a derivative work from being created, so the clause is important for triggering copylefting.
Here there is only a loose relationship between two software components which remain independent. Such exceptions can turn a strong copyleft into a weak copyleft. They also clearly show how important technical implementation, for example in the form of links, can be for the validity of license terms.
permissive license
The most prominent representatives of permissive licenses include the MIT License, the BSD Clause, and the Apache License. These are licenses with no copyleft clauses and low licensing requirements. The Apache license is available in several versions. It does not mandate copyleft for derivative works, but still requires compliance with certain licensing requirements such as attaching a copyright notice, license text, and a disclaimer.
The MIT license is extremely generous, its only requirements being the provision of license text and a copyright notice. Developers may also publish modified software under the new license, as long as permissive license terms are met – such as maintaining copyright notices and license text. This may be another open source license or a proprietary license.
As a rule, permitted licenses can also be combined with each other. Compatibility of licenses has considerable practical relevance: if, for example, license A enables something that license B does not cover, then they are not compatible with each other – this is particularly frequent in the copyleft area. Is.
practical tips
If a company is concerned about how and which licenses it uses, accurate documentation (bill of materials, BOM) in advance is essential. Ultimately, it provides information about the FOSS components used in a product. As a minimum requirement, it provides its own component name with its FOSS license in the corresponding version. A safe list can help, but should only be used as a guide.
Of course, the direction of the staff is also important: legally assigned people in the company ideally have a fundamental interest in programming, while at least one person in the respective development team also keeps an eye on the licensing of the components used by the team. Keeps. , The market also offers scanning tools that help analyze FOSS – in case of doubt, such tools help create legal certainty, but they are not suitable as a sole decision-making tool. Therefore the final check should always be done by a responsible person.
The question will always come up: “How can we incorporate the FOSS component into the project in such a way that we work in compliance with the license?” And if that’s not possible, the options split into two paths: Are there any options that include a commercial or permissive license? Or should we program the required component ourselves?
(KKI)
