Cracking the Code: Legal Issues in Open Source

In Switzerland, software is protected by the Copyright Act (CopA). Copyright protection for software is granted automatically upon its creation. No registration, publication, or other official recognition is required for this purpose. As a result, there is no central registry for copyright ownership in Switzerland.

The CopA grants developers (authors) several exclusive rights. These rights include the ability to control the reproduction, modification, and public availability of the software. Copyright protection only extends to the source code of the software and does not cover the underlying idea or functionality. Therefore, if the source code is not directly copied, it is possible to replicate the idea or function of the software without infringing copyright. To protect the idea or function of a software, it is possible to seek patent protection. Contrary to popular belief, such protection is also feasible in Europe with relatively few restrictions.

For computer programs, copyright law generally protects the specific expression of an idea, particularly the corresponding source code. By contrast, the underlying idea, a mathematical method, or the mere functionality of a program is generally not protected by copyright.

The distinction becomes more difficult when an idea can technically be implemented in only a limited number of ways. In such cases, the idea and its specific expression are closely intertwined. Under the “Merger Doctrine” developed in U.S. law, software is not protected by copyright where its form of expression “merges” with the underlying idea. In such cases, copyright protection should not result in the underlying idea or method being effectively monopolized through protection of the source code.

In Switzerland, the Merger Doctrine is not recognized as a standalone legal principle. However, Swiss copyright law may lead to a similar result: protection extends to the original expression, not to the underlying idea. The more source code is dictated by technical specifications, standards, or the intended functionality, the more limited the scope of copyright protection may be.

An algorithm may, however, be protected in other ways, for example through confidentiality, contractual provisions, or, if the relevant requirements are met, a patent.

A licence is a legal agreement between the copyright holder (licensor) and a user (licensee), that grants the user a contractual right to use the software. Software usage rights can be structured in different ways. On the one hand, a comprehensive right can be granted, covering the use, reproduction, modification, and publication of the software. On the other hand, the individual rights contained in the copyright (which is often referred to as a «bundle of sticks») can also be granted separately. Licences also allow the copyright holder to implement different licensing and business models by tailoring the rights of use and attaching specific conditions to them. For example, the use of the software may be free of charge, while commercial distribution may be subject to a license fee. 

OSS is software whose source code is publicly available source code and can be viewed, modified, and used by third parties. OSS is released under licences that define the terms of use, which can vary. There are two main open source license types: copyleft licences and permissive licences. The main difference between these license types lies in the distribution of modified OSS. With copyleft licences, any derivative works of the software must be released under the same licence (known as the «viral effect»). Permissive licences do not have such a requirement. This means that developers who integrate “permissive” OSS components into their software can license their software under any license of their choice.  

No, open source does not mean that the rights to use the source code are unrestricted. Similar to proprietary licences, the use of OSS is subject to terms and conditions set by the copyright holder (licensor). Most licenses focus on conditions directly related to redistribution. These conditions include, for example, the obligation to include the license text with the software, to attribute the author, or to maintain a change log documenting any modifications made to the source code. However, there are also open source licenses that require the user to buy the licensor a beer if they ever meet in person (Beerware License) or to perform a specific dance and share a video of the performance on social media (Chicken Dance License). 

Open source means that the source code is publicly available and can be used free of charge. However, the executable software based on an OSS source code does not necessarily have to be distributed free of charge. The process of converting the source code into executable software (compilation) requires expertise, time, and resources that not every user has or wants to invest. Developers may offer to compile the source code for a fee, even if the source code is available as OSS.

A good example of this is the Linux distribution «Red Hat Enterprise Linux» offered by the software manufacturer «Red Hat». The source code of the software is freely available as OSS and can be viewed on platforms such as GitHub. However, if a company wants to obtain the ready-to-use code of the software without having to reconstruct it from the source code itself, it must purchase a paid subscription.

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.

Yes. Publishing refers to making software publicly available, for example by uploading the source code to a repository such as GitHub. This makes the software accessible to the general public and, in particular, to the open-source community, allowing its members to review, analyse and suggest improvements to the software (known as "community audits"). This transparency fosters software quality, security, user trust and innovation in OSS.

Licensing, on the other hand, refers to the legal terms and conditions governing the use, modification and distribution of the software. It defines the rights and obligations granted to software users. Simply publishing the source code does not automatically grant permission to incorporate it into an existing codebase, modify it or distribute it. However, the easy accessibility of published software makes it difficult to prevent such unauthorised use. As a result, publishing source code always carries the risk that third parties may infringe the author's copyright or violate the applicable licence terms.

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. 

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. 

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. 

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.

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. 

If a public repository is changed to “private”, the source code is no longer freely accessible to new users. However, rights already granted under a valid OSS license are generally not retroactively revoked as a result.

Anyone who previously lawfully obtained the source code under an OSS license may continue to use, modify, and, to the extent permitted, distribute it in accordance with the terms of that license. Existing forks also do not automatically become unlawful when the status of the original repository changes. In principle, simply removing the repository or the license text does not alter this.

In practice, however, evidence may be crucial: Which version was obtained, when was it obtained, and under which license? Developers and companies should therefore carefully document the relevant versions and associated license information.

It is also important to note that merely publishing source code in a public repository does not automatically make it open source. For this to occur, the rights holder must grant the relevant rights of use, typically through an explicitly specified OSS license.

If the copyright in software is transferred, for example as part of an asset deal, OSS licenses that have already been validly granted remain in effect according to the view taken here. Although the doctrinal basis is not conclusively settled, practical considerations in particular support this position. The open-source model depends on users and developers being able to rely on rights already granted. If those rights could cease to exist as a result of a transfer of copyright, this would jeopardize collaborative development and contradict the fundamental principles of open source.

According to this view, the new rights holder acquires the software together with its existing licensing history. The change in rights holder leaves previously granted OSS rights to the published versions unaffected, subject to mandatory provisions of the applicable law. The new rights holder may nevertheless release future versions under a different license, provided that it holds the necessary rights to the entire source code concerned. If external contributors hold rights in portions of the source code or third-party components have been integrated into it, a change of license may require the consent of the respective rights holders, unless the necessary permissions have already been granted under the applicable licenses or a Contributor License Agreement (CLA).

In corporate transactions, it is therefore important to verify who actually holds the rights to the source code and which OSS obligations apply. License information, CLAs, employment and development agreements, and the origin of the source code are particularly relevant. An unclear rights or licensing position can significantly affect the value of the software and the ability to sell it.

A question that arises time and again is that of liability for software defects or security vulnerabilities. Since the source code of OSS is provided free of charge (see question 5), it is understandable that the licensors want to protect themselves against third-party claims. For this reason, most open source licenses contain liability and warranty disclaimers.

These disclaimers are usually so broad that they violate mandatory law in Switzerland and many other countries (e.g., exclusion of liability for gross negligence and unlawful intent). As a result, the clause is ineffective and liability is governed by statutory law. If OSS is provided free of charge, it is treated like a gift (even though the IP rights are not actually given away). In this case, the licensor is only liable to the licensee for damages caused intentionally or through gross negligence. However, if OSS is sold in compiled form, limitations of liability should be contractually stipulated in a separate agreement.

If developers want to disclaim all liability, they can do so by releasing the source code into the public domain (see below). In this case, the developer makes the source code available under no license and thereby waives all rights and obligations. As a result, there is no contractual relationship between the developer and the user regarding the use of the source code that would be subject to statutory law.

In general, an open source licence agreement only becomes applicable when the user distributes the software. As long as users do not distribute the OSS, the terms of the open source licence are not relevant to them. Internal use without distribution is therefore unproblematic for both individuals and companies. However, if distribution does take place, it is necessary to comply with the relevant licence terms.

The definition of what constitutes a distribution may vary depending on the open source licence. Generally, distribution occurs when the software is made publicly available or placed on the market (for example, by uploading it to a website, making it available in a repository such as GitHub, engaging in peer-to-peer file sharing, or installing it on a server). It is important to remember that when software is distributed, the open source licence agreement is always established between the original author of the software (licensor) and the user of the software. When users redistribute the software, the recipients do not enter into a sublicense agreement with the distributing user but into a license agreement with the original licensor.

“Distribution” refers to the transfer of a copy of a copyrighted work, such as software, from one legal entity to another. The principle of distribution is particularly important for companies and developers who use open source software (OSS) and integrate it into their own products, as many obligations under OSS licenses only take effect when the software is distributed to third parties.

The decisive factor here is not how the software is used, but whether a third party actually receives a copy. As long as an application is only used or further developed internally and no external third parties receive a copy, there is no distribution. In this case, the obligations arising from OSS licenses are not yet triggered. Transfer typically occurs when (i) software is delivered to customers, (ii) source code or binary files are provided, or (iii) software is made publicly available for download.

If open source software is not only used internally but also distributed to third parties – for example, by delivering or making available an application with corresponding OSS components – certain license obligations apply. These vary depending on the type of license and include transparency requirements, the obligation to indicate changes, and the obligation typical of copyleft licenses to distribute the software under the same license terms (see below, section 6).

In order to be aware of these obligations, developers must know exactly which components are included in the application and under which licenses they are covered by the time the product is released at the latest. It is advisable to create a software “bill of materials” (BoM) that documents all components used, including license information (see also below, section 8). If this information is missing or incomplete, this can quickly lead to license violations and entail legal risks. Only if problematic components are identified in good time can they be replaced before release or included in the application under a suitable license. 

Numerous open source licenses require that the OSS components used be indicated when software is distributed. The so-called “notice” requirement means that recipients must be informed about which parts of the software are covered by which license. In practice, this usually involves including the complete license texts, naming the authors and contributors, and, if necessary, providing the associated source code.

It has proven useful to provide the source code covered by the license before distribution, as the license texts are usually included as text files in the source code package.
However, it is controversial whether simply embedding the license text files in the source code package is sufficient to meet the (sometimes) strict transparency requirements of open source licenses. For this reason, it is advisable to include an additional text file with the source code package or the corresponding repository that clearly describes under which license the entire application is published or distributed and under which license the individual components are licensed. 

The so-called “viral effect” is often discussed in connection with copyleft licenses, especially the GPL. It describes the widespread notion that the integration of copyleft code into proprietary software could automatically result in one's own code falling under the copyleft license and, as a consequence, the entire code having to be disclosed – including one's own. From a legal perspective, however, this notion is incorrect.

Copyleft licenses such as the GPL stipulate that when a combined work containing GPL-licensed code is redistributed and forms a uniform “derivative work,” the entire distributed code must be subject to the terms of the GPL. Anyone who violates this condition by distributing the combined work without disclosing the complete source code under the GPL loses the license rights to the GPL code. Further distribution then constitutes a copyright infringement, which may result in injunctive relief and, if applicable, claims for damages.

However, copyright law does not provide any legal remedies that could force developers to actively place their proprietary code under the GPL or transfer it to the public domain. The integration of GPL code does not automatically “infect” proprietary code and does not convert it into GPL code by operation of law. The viral effect acts exclusively as a condition for lawful redistribution: Anyone who wishes to distribute a combined or derivative work must decide either to comply with the GPL conditions or to refrain from distribution. 

Software is often linked to external libraries. With static linking, the library’s code is incorporated into the executable file during compilation. With dynamic linking, the library remains separate and is loaded only at runtime.

This distinction can be relevant from a licensing perspective, particularly in the case of copyleft licenses. It raises the question of whether the library and the main program are so closely linked that the licensing obligations also extend to the main program. However, the type of linking alone is not decisive.

This is illustrated by a comparison of the GNU General Public License (GPL) and the GNU Lesser General Public License (LGPL). According to the Free Software Foundation, both static and dynamic linking under the GPL result in the linked program being subject to the GPL’s copyleft obligations. By contrast, the LGPL generally also permits linking with proprietary software. Dynamic linking is usually simpler in this context, whereas static linking may entail additional obligations, particularly the obligation to enable relinking with a modified version of the LGPL library.

Accordingly, the specific license, its version, and the manner in which the library is technically integrated are always decisive.

The Classpath Exception supplements the GPL. It limits the GPL’s copyleft effect when a GPL-licensed library is linked with independent software modules. Without this exception, the linking could result in the GPL applying to the combined work. The Classpath Exception prevents this copyleft effect with respect to independent modules.

Specifically, it allows a library licensed under the GPL with the Classpath Exception to be linked with an independent module, such as a proprietary application, without requiring that module to be licensed under the GPL solely because of the linking. The resulting program may generally be distributed under terms chosen by the distributor. The license terms applicable to the linked components must nevertheless be complied with.

It generally does not matter whether the library is linked statically or dynamically. What matters is that the linked module is genuinely independent, meaning that it is not derived from or based on the GPL-licensed library.

Certain open-source licenses, particularly the GNU Lesser General Public License (LGPL), are intended to ensure that users can modify an integrated OSS library or replace it with a modified version. If such a library is linked, whether dynamically or statically, to proprietary software, neither the technical arrangements nor the contractual terms may impermissibly restrict this possibility.

For software providers, this also raises the question of who bears responsibility if an end user makes such a modification independently. If the user independently modifies or replaces an OSS library and this results in malfunctions, incompatibilities, or other problems, the provider should generally not bear the same level of responsibility as it does for the software it supplies.

Precisely because certain open-source licenses grant end users such modification or replacement rights, the associated risk should be appropriately addressed in the contractual terms. In particular, the warranty and liability provisions should clarify that, to the extent permitted by law, the provider is generally not liable for the consequences of the end user’s independent modification or replacement of the relevant OSS components. At the same time, these provisions must not impermissibly restrict the rights granted to the end user under the applicable open-source license.

License conflicts arise when code bases under different licenses are merged into a new project and the terms of the licenses are incompatible with each other. For example, combining a strict copyleft license with a permissive license is fundamentally problematic if the intention is to distribute the combined (or derivative) work under a permissive license. License conflicts can also arise when certain terms of use of one license contradict the terms of another license, for example with regard to permitted use, distribution, or patent rights.

The latest Open Source Security and Risk Analysis (OSSRA 2025) study by Black Duck shows that license conflicts are still widespread: license conflicts were found in 56% of the applications examined, and in 33% of cases, components without a clear license or with an adapted license are included, which exacerbates legal uncertainties. Those responsible for open source projects, users of such software, and developers should therefore carefully review the license terms of all components used and ensure that they are compatible with each other before combining or redistributing code. 

Modern software projects often combine different open-source components, each of which is subject to its own license terms. The compatibility of these licenses is particularly relevant with regard to copyleft mechanisms such as the GPL, which stipulate that derivative works must be distributed under the same license. Compatibility issues can restrict the use or distribution of software and, in practice, can usually only be resolved through alternative licensing or the replacement of individual components.

A proven method of minimizing risk is to create a software “bill of materials” (BoM) that documents all components used, including license information. The BoM serves as the basis for internal compliance audits and is increasingly required by customers, investors, or buyers in order to understand the legal status of the software. The economic valuation and saleability of a software solution depend largely on whether its licensing situation is transparent and legally sound. A lack of transparency or unresolved license conflicts can reduce the value of the software or the company, or delay transactions, especially if the relevant risks only become apparent during due diligence reviews. 

When dealing with open source software, a distinction must be made between use without a valid license and a violation of existing license terms.

If there is no valid license or other permission to use the software, for example because third-party code has been adopted without license information and no other consent has been obtained from the copyright holder, this constitutes a copyright infringement. In this case, use is not permitted; the only options are to obtain a license from the copyright holder retrospectively or to remove the code in question completely.

If, on the other hand, there is a valid license but its terms have not been complied with or have not been complied with in full (e.g., missing copyright notices or failure to disclose information), this constitutes a license violation. Depending on the license, such a violation may result in the automatic loss of the right of use, meaning that any further use constitutes a copyright infringement. If the respective license and applicable law so provide, the infringement can be remedied by subsequent fulfillment of the license obligations and the license can be restored for the future. Otherwise, termination of use by removing or replacing the affected code is necessary. 

Docker is a widely used platform that enables software to be deployed and run in so-called containers. Containers create a largely uniform and isolated environment, allowing an application to run reliably regardless of the underlying system.

A Docker image forms the basis for this. It contains the components required to run the software, such as the application itself, libraries, runtime environments, and configuration files. A container is a running instance of such an image. Multiple separate containers can be launched from the same image.

A Dockerfile, in turn, is a text file containing instructions for creating a Docker image. Put simply, the Dockerfile is the “recipe”, the image is the software package created from it, and the container is the running instance of that package.

In addition to the application itself, Docker images often contain numerous other software components, such as operating system components, libraries, and other dependencies. If a Docker image is shared with customers or other third parties, these components are generally included as well, even if they are not actually required for the application. Their license terms must therefore also be observed.

It is important to distinguish between a Dockerfile and a Docker image. The license applicable to the Dockerfile generally says nothing about the licenses applicable to the software contained in the Docker image. For example, a Dockerfile licensed under the MIT License may include GPL-licensed software in the Docker image. Depending on the licenses of the included components, license texts and copyright notices may have to be provided, or source code made available, when the image is distributed.

A Docker image also consists of multiple layers. For compliance purposes, the software distributed within these layers is generally relevant, not merely what is visible in the final Docker image. Companies should therefore identify the included components and their licenses and review them before distributing the image. This also applies to Docker images obtained from public repositories.

Modern software often relies on numerous external software packages and libraries integrated through package managers such as npm, Maven, or pip. These packages and libraries may, in turn, depend on other components. Such transitive dependencies are often installed automatically, without developers consciously selecting each individual component.

From a licensing perspective, these dependencies must not be overlooked. The various components may be subject to different open-source licenses and, depending on how they are integrated and used, may trigger obligations such as requirements to include license texts and copyright notices or, particularly in the case of copyleft licenses, more extensive obligations. Problems may arise, in particular, if individual licenses are incompatible with the intended use or with other applicable licenses.

Companies should therefore identify and document not only the OSS components they have directly selected, but also the entire dependency tree. Software Composition Analysis (SCA) tools and an up-to-date Software Bill of Materials (SBOM) can help automatically identify direct and transitive dependencies and the corresponding license information. Before any release or distribution of the software, companies should verify that all resulting license obligations are being met.

With modern forms of delivery such as Software-as-a-Service (SaaS) or web-based applications, the concept of transfer is not always clear. The key question is: Does a transfer already occur when users interact with the software via the Internet without downloading a copy? According to prevailing doctrine and case law, the answer for most open source licenses is no. Users only receive access to the software, but not a copy, so the license obligations are not usually triggered. For example, the strict GPLv3 license defines the term “convey” as follows:

“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.”

The Affero GPL (AGPL) is a special exception. It was developed to ensure that license obligations also apply when software is provided via a network without copies being transferred. Simply providing the software via a network is considered distribution in this case. In this case, the license terms of the AGPL must be complied with, such as the obligation to make the source code available to all users under the same conditions.

 In addition to copyright, open source software can also raise questions about patents. Some licenses, such as Apache 2.0 or GPLv3, explicitly include a patent license that allows the use of protected technologies within the software and prevents rights holders from asserting patent claims against users after the code has been distributed. Other licenses, such as BSD, MIT, or GPLv2, do not make any clear statements on this issue. Some courts take the view that the use of OSS source code grants an implicit patent license, but this has not been clarified uniformly in law. In principle, therefore, licenses without an explicit patent clause leave a certain degree of uncertainty regarding possible patent claims by the rights holder against users. 

While OSS remains one of the most popular forms of licensing alongside proprietary licences, an increasing number of developers are choosing to move away from the (pure) open source model. The reasons for this shift are plentiful, often stemming from the perception that open source licenses can be overly rigid. Below, we present the most common alternatives:

• Public domain: Public domain refers to software for which the author has waived their copyright, making it freely available to the public. This means that anyone can use, modify, distribute, and commercially exploit the software without needing permission in the form of a licence. Examples of software programmes whose source code has been released into the public domain include the «Secure Hash Algorithm 3» (SHA-3) and online games such as «One Hour One Life» and «The Castle Doctrine».
• Open core («freemium»): In the Open Core model, the core of the software is available to all users as OSS. However, certain additional features and add-ons are sold for a fee under a commercial licence. The Open Core model is used by the software management provider «GitLab». While the «Community Edition» is freely available as OSS, the «Enterprise Edition» that includes additional features is offered under a commercial licence.
• Source available: Source available means that the source code of the software is made publicly available, similar to OSS. The difference with source available software is that certain usage rights are restricted. Source available licences may, for example, include restrictions on commercial projects or certain categories of applications (such as deep learning or search engines). Examples of software that is no longer available as OSS but offered under a source available licence include the visualisation tool «Kibana», the NoSQL database management system «MongoDB», the data platform «Redis», the log management solution «Graylog» and the DeFi protocol «Uniswap v4».
• Dual licensing: Dual licensing (or multi licensing) involves offering software under a choice of licences. On the one hand, the software is offered under a strict copyleft licence in order to trigger the «viral effect». On the other hand, the same software is offered under a commercial licence without the «viral effect». The ability to modify the source code without restrictions, incorporate it into proprietary source code and/or distribute it is therefore subject to a fee. One of the best known examples of the dual licensing model is the database management system «MySQL» from Oracle.

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. 

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.