Cracking the Code: Legal Issues in the Realm of Open Source (Part 2)
Articles
Compliance
Legal
Data / Technology / IP
Part 2 of this series focuses on questions that are crucial from the perspective of software developers.
Noëlle Glaus
Legal Associate
Michael Kunz
Legal Partner
Philipp Stadler
Senior Legal Associate
Part 2: The Developer's Perspective
The second part of our open-source series deals with the question of whether and why software developers should license their source codes under an open-source license, what advantages arise from this type of licensing and what developers should bear in mind in connection with open source.
What are the advantages of licensing under an open-source license?
Licensing software under an open-source license offers numerous advantages that go far beyond the mere disclosure of the source code. One of the most important advantages is legal clarity. Established open-source licenses define exactly how the software may be used, modified and distributed. This helps to avoid uncertainties and provides both developers and companies with a reliable basis for the use and further development of the software. Since open-source licenses allow access to the software without complicated license negotiations, they can be adopted more quickly by companies, authorities or developers.
Another advantage is the support provided by the community. Open-source software thrives on collaboration: other developers can report bugs, identify security vulnerabilities and actively contribute to further development of the software. This not only makes the software more stable, but also allows it to improve much more quickly. Instead of relying on a single development team or a single manufacturer, open-source projects benefit from collective review by a broad community.
In addition to the technical and legal advantages, open-source also offers economic opportunities. Developers can generate income from services such as support, consulting or customized implementations. Many successful companies rely on an open-core model in which the basic version of a software is free of charge, while extended functions or premium support are offered for a fee.
Under which open-source license should the code be licensed?
The Open Source Initiative, an organization founded in 1998 to promote OSS, has recognized more than 80 open-source licenses. These licenses usually fall into one of two categories: permissive licenses and copyleft licenses.
Permissive licenses allow other developers (third parties) to use the software as they wish, provided that they comply with certain licensing obligations (e.g. referencing of the author). Third parties are thus free to decide under which license they wish to distribute their own modifications of the software.
Copyleft licenses, on the other hand, oblige other developers (third parties) to also offer their own further development under the original open-source license when passing on modifications to the software (so-called viral effect). This has the consequence (as under GPL v3), for example, that the source code of one's own further development must be disclosed when passing on the further developed software in accordance with the license conditions, that no license fees may be charged for its use and that the recipient cannot be prohibited from redistributing the software.
The question of which license to use for your own open-source project is always a matter of the individual case. As a first step, developers should consider whether they are happy with the idea of third parties creating a proprietary version of their software and making money from it without contributing themselves. If they are, then a permissive license is suitable. Otherwise, a copyleft license should be chosen. If a copyleft license is chosen, it is particularly important to decide how strong the viral effect should be:
Strong copyleft licenses, such as the GNU General Public License (GPL), allow the modification and distribution of the original code, but only on the condition that the entire derivative work is also published under the same license. This ensures that the original source code and all further developments remain accessible to the community.
In the case of weaker copyleft licenses, such as the Mozilla Public License (MPL), the viral effect is limited to the directly modified files. If one of the original files is changed, it must be licensed under the MPL and must be published when it is shared. However, if an author develops new files independently of the original MPL code, these can be published under a different license or even kept proprietary. This principle is often referred to as ‘file-based copyleft’, since the license obligations remain limited to the file level.
Furthermore, thoughts about compatibility with other software licenses and the aim of the licensing (e.g. commercialization) can be crucial for the choice of the open-source license. In principle, it is advisable to base the selection on the established, most widely used licenses and to avoid exotic licenses or the development of your own licenses. It is also advisable to choose a license text in English to avoid unnecessary language barriers when it comes to international use.
Is it legal to charge for open-source software?
The use of the term ‘free software’ in connection with open-source software (OSS) often leads to misunderstandings about whether OSS developers can charge money for their work. The Free Software Foundation clarifies:
„Free software is a matter of liberty, not price. To understand the concept, you should think of free as in free speech, not as in free beer.”
Contrary to popular belief, it is not illegal to commercialize source code that has been published under a common copyleft license. For example, the author may charge a fee for copies of the licensed code (in source form or binary form) or collect royalties for support services and for offering a guarantee. Even if the source code is provided on a physical data storage medium, the author may charge a reasonable fee for its production and distribution.
Another example is offering paid extensions or premium features for open-source software. Many companies use open-source software as a basis and then offer additional features that are only available for a fee, as is the case with open-core models, for example. Commercial use is also possible in the area of cloud services. Providers such as Red Hat and Canonical offer open-source software such as Linux or OpenStack for free download, but make money by providing support services, customized solutions and cloud infrastructure services.
Licensing software under an open-source license does not mean that the software must be offered for free or without the possibility of making money. Rather, it is about the freedom to use, modify and redistribute the code. Developers can thus certainly build commercial business models based on open-source software, whether it be through chargeable additional functions, support services or customized service provisions.
Can the open-source licensing of software be reversed?
In principle, licensing under an open-source license is final. Software that has been released under a particular open-source license can be redistributed without restriction, even if the original licensor removes the OSS. This means that users or subsequent developers who have already obtained the software under these conditions remain bound by the rights and obligations of the concerning open-source license. Even if the original developer later wants to make changes, users or subsequent developers are still protected by the original provisions of the open-source license. Open-source licensing is therefore not reversible.
However, it is possible to publish new versions of the software under a different license and to commercialize those, for example. This is often referred to as ‘forking’, where a new version of the project is forked from the original version and developed under new license conditions. Only the previous versions can then continue to be used under the original open-source license. If an update is installed, however, a license change is mandatory. Since updates are almost unavoidable in today's world due to the rapid pace of software development, a project can, for example, initially gain market share with an open-source license and build up a community before switching to a commercial license.
Can you create your own open-source licenses?
Yes, new licenses can be created. However, to be recognized as an open-source license, they must go through the review process by the Open Source Initiative. For a license to be recognized by the Open Source Initiative, it must meet certain requirements, such as ensuring free distribution, providing the source code, allowing the source code to be modified and redistributed, not discriminating against individuals or groups, being independent of products, not restricting other software and being technology-neutral.
Is it permissible to adapt existing open-source licenses?
For a license to be recognized as an open-source license, it must comply with the open-source definition as described above and have passed the Open Source Initiative license review process. A recognized open-source license may therefore not be modified without further ado. However, if changes are made to a recognized license, it is no longer the original license, but a newly created license (which, in itself, is permissible). In this case, however, no reference may be made to the original license name.
What is the purpose of dual or multi-licensing?
In dual or multi-licensing, software projects are offered under several alternative licenses. This can be done for a variety of reasons.
On the one hand, dual or multi-licensing can be used as a commercial business model. The free version of the software is deliberately offered under a strict copyleft license with a viral effect. As long as third parties only use the licensed software internally within their company, the software is usually not passed on and the viral effect does not occur. However, if third parties pass the software on to subsequent developers as part of their software projects, the license obligations are triggered, and they too must pass on their software projects under the copyleft license. If subsequent developers want to avoid this and offer their projects without the restrictions imposed by the copyleft license (for example, the prohibition on charging a fee for the use of the software), they have to purchase the version of the software that is subject to a fee and that does not trigger the viral effect.
On the other hand, dual or multi-licensing reduces the risk of licensing conflicts. By offering the option of choosing between several licensing models, it becomes easier for developers and companies to ensure that all legal requirements are met and that there are no unwanted overlaps or restrictions between the licenses. This promotes broader acceptance of the software and makes it easier to integrate it into various projects and applications.
What are open-source contribution guidelines?
The most relevant open-source contribution guidelines are the contribution guidelines and the Contributor License Agreements (CLA):
Contribution Guidelines govern the organization of an open-source project by defining the collaboration of developers in the community and their roles and responsibilities. This is of great importance for the success of a project and for smooth collaboration. While verbal agreements or short, keyword-like rules may suffice for smaller projects, a sufficiently documented governance structure is recommended for larger projects.
For open-source projects, it makes sense to conclude Contributor License Agreements with external developers (known as contributors). Such agreements govern the conditions and rights for the adoption of external contributions and ensure that the open-source project has the necessary rights to use and distribute the external contributions. This is particularly recommended for commercial projects, but it requires a higher administrative effort. However, it should be borne in mind that the use of a CLA can also have a deterrent effect, as developers quickly realize that their contributions may be commercialized.
