Open source software (OSS) has long been the backbone of modern software development and digital infrastructure. Companies, start-ups and public authorities naturally build on frameworks, libraries and system components whose source code is publicly accessible. However, this technical freedom is accompanied by a legal responsibility that is often underestimated. Anyone who uses open source – whether for internal development or in commercial products – enters a complex field of copyright, licensing law and contract design.
The following is an overview of the most important legal aspects of open source software in Germany – with the aim of giving decision-makers and developers guidance and avoiding typical risks. I have been writing on this topic myself for decades.
The legal framework: Copyright as a foundation
Under German law – and in the EU – software is protected by copyright. This applies not only to “large” applications, but also to individual code snippets if they constitute a personal intellectual creation within the meaning of Section 2 UrhG. Protection arises automatically with the creation – no entry in a register is required. Anyone who writes software is the author and therefore has comprehensive rights: they alone decide on reproduction, distribution, editing and making available to the public.
In practice, however, the author is often not a single person, but a team, sometimes for years. In companies, employment law also comes into play, as the rights of use regularly fall to the employer in accordance with Section 69b UrhG. Nevertheless, the moral rights remain with the developer, which can have a significant influence on licensing – for example under open source conditions.
What is “open source” from a legal perspective?
Open source is not a legal vacuum. Here, too, the software remains protected by copyright – it is merely released for use under special license conditions. These licenses differ considerably in terms of rights and obligations. The decisive factor is that open source does not mean that everything is allowed. Rather, these are legally binding contracts that regulate exactly what the user may do with the code.
The best-known family are the so-called copyleft licenses, such as the GNU General Public License (GPL). These require modified versions to be made available as open source. In contrast, there are permissive licenses such as the MIT or BSD license, which grant significantly more freedom – such as integration into proprietary products.
In the legal sense, open source licenses are a special case of license agreements under the law of obligations. The major challenge is that many of these licenses originate from US law but are used worldwide. In Germany, for example, certain clauses collide with mandatory copyright law – such as the ban on the complete waiver of rights. Nevertheless, a recognized practice has emerged through judicial and academic reception that makes the core of the licenses legally viable.
Risks associated with use and disclosure
An often underestimated problem is license compliance when redistributing open source components. For example, anyone who integrates a GPL-licensed library into their own software product and distributes it must themselves license it under the GPL – including disclosure of the source code. The so-called “copyleft” thus acts like a viral license obligation.
With permissive licenses, there is no disclosure obligation, but there are nevertheless clear requirements – for example, regarding the naming of the author. Even seemingly harmless infringements, such as the removal of copyright notices, can constitute a license violation. In Germany, there is then a threat of injunctive relief or – in the case of commercial use – even compensation for damages.
It becomes particularly critical when it is unclear who is actually the author of the code. Forks or libraries are often circulating whose license situation is difficult to understand. Even automated tools for license analysis (e.g. in CI/CD pipelines) are no substitute for a legal assessment, but at best serve as an early warning system.
Special questions at a glance
Companies that develop or use open source software are faced with the task of establishing clear internal processes. This includes, for example, regulating whether employees are allowed to publish open source code as part of their employment relationship – and if so, under what conditions. A release practice (“open source governance”) helps to both protect intellectual property and act in a legally compliant manner.
Contracts with customers or suppliers should also clearly regulate whether and which open source components are used – and which obligations result from this. Avoiding unwanted “copyleft contamination” thus becomes a business necessity. Open source compliance is playing an increasingly important role, particularly in the public sector, in software-as-a-service or in product certification (for example in the medical or automotive sectors). Certification bodies and customers are paying close attention to whether and how companies are fulfilling their license obligations.
Legal pitfalls with open source software
Open source software offers freedom – but not unlimited freedom. The practical use in companies repeatedly raises complex legal issues, which are no longer just about the correct understanding of licenses, but about strategic decisions within the company. Copyleft licenses such as the GPL, the legal classification of third-party contributions and the internal processes for dealing with open source in particular require more than just technical know-how.
Copyleft und Open Source Compliance
A particularly sensitive area is the distribution of software that is subject to so-called copyleft licenses – above all the GNU General Public License (GPL) and its variants. The basic mechanism is well known: Anyone who uses, modifies and redistributes software undertakes to also make the derived works accessible under the same license – and thus together with the source code.
This obligation applies not only to traditional distributors of software packages, but also to providers of embedded systems that use Linux components or SaaS providers, such as AGPL.
Just how sharp the sword of the copyleft can be can be seen in case law, for example in the cases you have dealt with regarding the enforcement of the GPL: If the license is violated, for example because the source code was not included or references to the license are missing, there is not only the threat of a warning, but also the complete loss of the license. The consequence is serious: a previously legally used component becomes a copyright-infringing use – with injunctive relief and compensation for damages.
For companies, this means that reliable internal processes are needed that start with the selection of OSS components, document the obligations and are consistently implemented during delivery or provision. Open source compliance is not a legal fig leaf, but a question of operational excellence – especially for customer projects, in the supply chain or as part of audits.
Editing, co-authorship and rights clearance
A further area of conflict arises where software is modified or further developed. The question of whether a mere modification constitutes a “derived work” or an independent creation is by no means trivial in legal terms. The decisive factor is whether a personal intellectual creation of the original author continues to exist or is superimposed – an aspect that your blog addresses succinctly based on decisions by the ECJ and the Düsseldorf Regional Court, among others.
It becomes particularly tricky when several people work together on a project – for example as part of a fork or in internal teams. In such cases, co-authorship within the meaning of Section 8 UrhG can arise. This leads to a joint and several obligation: no party may dispose of the work without the consent of the others. This can become a blockade for companies – for example if a former developer asserts claims retroactively.
Co-authorship can be contained by clear contractual regulations. However, in the open source world, where work is often informal or community-based, there is often a gray area. Anyone who adopts contributions from the community without clarifying the copyright status of the contributor runs the risk of distributing legally vulnerable software. A Contributor License Agreement (CLA) that clearly regulates the transfer of rights is therefore recommended, especially for larger projects.
Dual licensing
A special legal case is dual licensing, i.e. the licensing of the same software under two different license models. Classically known from MySQL, for example, it allows free use under an open source license on the one hand and commercial licensing under other conditions on the other.
This is generally possible under German law, as can be seen in the specialist literature and in your blog post. The author remains the master of his rights and can grant them to different licensees in different ways. But be careful: as soon as other co-authors are involved, things get complicated. Each of them would have to agree to the commercial license. Even in the case of joint development by employees, the question arises as to whether and to what extent the corresponding rights have been granted to the employer.
There is also the risk of confusion on the part of users. If, for example, an open source version is circulating and a paid version with extended features is offered in parallel, this can lead to misunderstandings if communication is unclear – in the worst case even to ineffective licensing. Companies should therefore make it particularly clear under which conditions which license applies and which obligations arise in each case.
Open source in the employment relationship
Many developers are involved in open source projects not only on a professional basis, but also privately. This is where labor law and copyright issues come together.
As a general rule, if software is created as part of the employment relationship, the employer regularly acquires the rights to use it. However, the decisive factor is whether the work was created as part of the contractual obligations – or for private reasons, for example at the weekend or on the employee’s own initiative. The boundaries here are fluid, and even a “private” project can have legal relevance with regard to possible non-competition clauses or loyalty obligations.
If, for example, internal company components – whether knowingly or inadvertently – are included in an open source project, this can give rise to a disclosure obligation that conflicts with the protection of trade secrets. Conversely, an employee who brings open source code under GPL into the company can unintentionally activate copyleft obligations without the management knowing about it. A clear set of rules in the employment contract, flanked by internal policies, creates security here. This includes both the relationship to your own OSS use as well as collaboration on external projects. Open source is teamwork – also legally.
What often appears to be a minor legal matter can have massive legal and economic consequences if not handled with care. Especially when combined with operational reality – from the division of labor in agile development teams to contractual relationships and the integration of external modules – a complex field arises in which misunderstandings can quickly take on a life of their own.
Seize opportunities, know the risks
Open source software has become an integral part of modern software development – and rightly so. The legal issues are manageable if you take them seriously. It is crucial to be aware of the legal implications of licenses, the origin of the code and the obligations when passing it on. Companies that act proactively here and establish clear processes not only benefit from greater legal certainty – but also from trust among customers, partners and the community.
In the end, it’s simple: open source software can only develop its potential in a legally compliant manner if legal issues are considered from the outset. It is precisely at the interfaces between technology, law and organization – such as copyleft, co-authorship or the employment relationship – that pitfalls lurk that can be avoided with a sound strategy. Companies that take open source seriously should not see compliance as a form of control, but as a prerequisite for being able to use software sustainably, cooperatively and innovatively.
Our law firm specialises in criminal defence, white-collar crime and IT law / technology law. Note our activity in digital evidence in IT security and software law.
- Criminal liability for importing narcotics into Germany – what foreign actors need to know - 6. April 2025
- Informal Banking Under Legal Scrutiny: Hawala Systems and the Complex Landscape of Criminal Liability and Asset Forfeiture in Germany - 23. March 2025
- Open source software in German law - 23. March 2025