Open source in software development: legal principles and practice

Open source software has become an integral part of modern software development – whether in the development of computer games(game development) or plugins for popular platforms such as WordPress or Shopify. Developers like to use freely available libraries, engines and code snippets for cost reasons and due to the large community support. But “freely available” does not mean “free of conditions”. Especially in IT law and media law, the legal framework conditions of such open source licenses play a central role. Copyright law and contract law in particular set certain limits on the use of open source, which developers and companies need to be aware of.

This blog post provides a comprehensive overview of the use of open source in game development and plugin development. The focus is on practical aspects: License compatibility between common licenses (such as GPL, MIT, Apache), risks and legal consequences of license violations, effects of copyleft licenses (especially the GPL) on proprietary software, as well as contractual points such as integration clauses, testing obligations and due diligence. The presentation is neutral and legally precise, but at the same time comprehensible for practitioners. Developers of games, software and plugins should recognize what they need to pay attention to in order to avoid legal pitfalls. Terms from IT law, copyright law and contract law are explained, relevant German legal norms – for example from the Copyright Act (UrhG) – as well as court decisions and practical examples are included.

Basics of open source licenses

Open source and copyright

Open source software (OSS) refers to software whose source code is publicly accessible and may be used, modified and redistributed by third parties – but under certain license conditions. In legal terms, this model is based on copyright law: under German law, software enjoys copyright protection as a so-called computer program (Section 2 (1) No. 1, Section 69a UrhG). The author (or rights holder) of software has extensive exclusive rights of use (Section 69c UrhG), including the right to reproduce, distribute, modify or make the program publicly accessible. No one may legally copy or distribute the software without the consent of the rights holder.

A software license is precisely this consent: in a license agreement, the author grants a user certain rights of use (Section 31 UrhG). Open source licenses are usually pre-formulated standard licenses in which the authors grant everyone certain rights to the software – typically free of charge and for an unlimited period of time – but linked to conditions. These conditions distinguish open source licenses from purely “free” (unconditional) public domain software. From a legal perspective, open source licenses often have the character of general terms and conditions (GTC), as they are unilaterally set by the author and accepted when the software is used. They must therefore comply with the law on general terms and conditions (§§ 305 ff. BGB).

It is important to note that even if no contract is signed, the open source license applies by implication – anyone who uses or distributes the software agrees to the terms of the license. With open source, the “conclusion of the contract” takes place to a certain extent through the use of the software. The OSI (Open Source Initiative) defines criteria for when a license is considered “open source” (free redistribution, access to the source code, permission to make changes, no discrimination against persons or areas of use, etc.). Well-known examples are the GNU General Public License (GPL), the MIT license, the Apache License 2.0, the BSD licenses and many more.

Permissive vs. copyleft licenses

Open source licenses can be roughly divided into two categories: permissive licenses and copyleft licenses. The difference lies in the strength of the conditions attached to the further use of the code.

Permissive licenses grant extensive rights and impose only minimal conditions. Examples are the MIT license, the Apache License 2.0 or the BSD licenses. They allow you to integrate the software into your own projects, even proprietary software, and redistribute it with virtually no restrictions. Typically, they only require that a copyright notice and the license text or a license note be retained in the software. For example, the MIT license stipulates that the original license text must be included with redistributed code. The Apache License 2.0 also contains an explicit grant of patent licenses to users of the software and some protection clauses (e.g. when changing names/trademarks), but also remains “permissive” in the sense that derived works may be published under any license (including proprietary) as long as the few conditions are met. Permissive licenses are popular with developers because they offer maximum freedom and hardly cause any legal conflicts – you can build your own closed software from permissively licensed code without having to disclose source code later or fulfil other usage obligations.

Copyleft licenses, on the other hand, impose stronger conditions and aim to pass on the freedom of the code. In simple terms, “copyleft” means that derived works of the licensed code must in turn be published under the same license. The idea behind this is to protect openness: no one should be able to take the free code and turn it into a proprietary offshoot that is inaccessible to others without also making their own changes available to the community. The GNU General Public License (GPL) is the best known and strictest copyleft license. Although it allows users to use, modify and redistribute the program free of charge, this is subject to conditions: When redistributing, the source code of the derived software must be disclosed, and in turn the GPL license must be applied to it. In addition, the GPL requires that a reference to the licensor (copyright notice) is retained and that a copy of the license is included with the program. A disclaimer of liability and exclusion of warranty is also part of the GPL – although a complete exclusion of liability for intent and gross negligence would be invalid in Germany for reasons of general terms and conditions law (Section 309 No. 7 BGB). The essential core of the GPL is: If I integrate a GPL-licensed program or library into my own software and then distribute it, my entire software must be under the GPL and the source code must be openly accessible.

In addition to the “strong” GPL, there are also weakened copyleft licenses. The LGPL (Lesser GPL) for example, is considered a “weak copyleft”: it allows an LGPL library to be integrated into proprietary software, as long as the library itself remains interchangeable and under LGPL. In practice, this often means dynamically linking a DLL or .so file; the proprietary software must then offer the possibility for the end user to exchange the library for another version. The proprietary software does not have to be GPL/LGPL, but changes to the LGPL component itself would have to be published. Another variant is the AGPL (Affero GPL)which closes a loophole in the GPL: In the case of AGPL-licensed software, the source code must also be disclosed if the software is not distributed in the classic way, but is used as a service via a network (keyword Software-as-a-Service). It is relevant if, for example, someone modifies an AGPL-licensed server or web service and offers it to the public – in this case there is also an obligation to provide the source code of the changes.

In summary: Permissive licenses (MIT, Apache, BSD etc.) are uncomplicated and compatible with proprietary use, as they have hardly any restrictions apart from copyright attribution. Copyleft licenses (GPL and similar) ensure openness and force developers to reciprocate: whoever takes must also give back. Both models are common in practice; which one is used depends on the author’s objectives. For game developers and plugin developers, it is important to recognize which category a component falls under, as this will later determine whether and how you are allowed to publish your own software.

Typical open source licenses at a glance

At this point, it is worth taking a brief look at the most important individual licenses that are frequently encountered in the practice of game and plug-in development:

• GNU General Public License (GPL): Currently mainly version 3 (GPLv3) as well as many projects under version 2 (GPLv2). Strict copyleft. Conditions: Redistribution of the source code of all derived software, same license type for redistribution, inclusion of the GPL license text, naming of the author. Often used for end applications and also libraries where the enforcement of openness is desired (e.g. many Linux programs, but also some game engines that have been released as open source). Example: The id Tech 3 engine (basis of Quake 3) was released under GPL – anyone publishing a game based on it would also have to release its code under GPL.

• MIT license (expat): Very short and simple license. Anyone may do anything with the code (modify, sell, license), liability is excluded, condition: the MIT license text and copyright notice must be retained in all copies or significant parts thereof. No copyleft requirements – i.e. MIT code can be used in proprietary projects. Example: The JavaScript library jQuery is MIT-licensed; it can be used in commercial web projects as long as the license notice is included somewhere in the imprint or code.

• Apache License 2.0: More comprehensive than MIT, but also permissive. In addition to the MIT obligations, it stipulates that the distribution of modified software must indicate what has been changed, and it contains a patent license: Contributing authors grant the user patent rights that are necessary to use the code. Conversely, there is a clause stating that this patent license is forfeited if a lawsuit is filed against the provider for patent infringement (avoidance of patent disputes). Despite these additions, Apache 2.0 is essentially free: Derived software may also be licensed differently (proprietary), again with the proviso that the Apache license text is included and copyright notices are preserved. Example: The TensorFlow framework from Google is licensed under Apache 2.0 – companies can use it internally or commercially without having to disclose their own code.

• BSD licenses: There are the “3-clause BSD” (or “New BSD”) and similar licenses. They are similar to the MIT license: they allow almost anything, but only require that copyright notices be retained. An older variant, the 4-clause BSD, contained an advertising clause (the author had to be named in advertising material), but this was considered too restrictive and incompatible with the GPL. Modern BSD licenses are GPL-compatible (more on this in the next section) and widely used, e.g. in the networking sector or for operating systems (FreeBSD etc.).

• Mozilla Public License 2.0 (MPL): A middle ground between copyleft and permissive. MPL is file-based copyleft: changes to MPL-licensed files must be disclosed when distributed, but you may include these files in a larger project without the entire project having to be open. Proprietary and MPL files can coexist (as long as they are separate files). This license is only mentioned here in passing, as GPL, MIT and Apache are the more common cases in our focus (game dev, plugins). However, Mozilla, for example, uses its MPL for Firefox, and some libraries in the software area are also MPL-licensed. For plugin developers MPL is rarely relevant, more often you see GPL or MIT.

Summary of the basics: The various license types determine the conditions under which code may be used. Developers should clarify at an early stage which license an open source component has and what this means in concrete terms – do I also have to freely license my own code when using it (copyleft) or is a simple note (permissive) sufficient? This question is the linchpin for further use in your own (possibly commercial) projects.

License compatibility in practice

When several components with different licenses come together in a software project, the problem of license compatibility arises. This refers to whether two (or more) license conditions are compatible with each other so that the code in question can be used and distributed together without violating one of the licenses.

What does license compatibility mean?

Every open source license requires certain obligations. If I have software A under license X and software B under license Y, and I want to combine A and B in a project (e.g. integrate a library A into program B), then the license conditions must match. Licenses are incompatible if one has conditions that contradict those of the other or make it impossible to fulfil both at the same time. They are compatible if I can satisfy both through a specific licensing path.

An example: Code under MIT license and code under GPL license can be used together in a project – but only on the condition that the entire product is then placed under the GPL as soon as it is distributed. Why? The MIT license allows redistribution under any conditions (as long as the copyright notice remains); it is therefore GPL-compatible because it does not contain any clauses that contradict the GPL. So I can incorporate MIT code into a GPL project, but then I have to license the end result under the GPL (because the GPL requires this for the entire work). The other way around, putting GPL code into an MIT-licensed project and continuing to publish it under MIT would not work, because then the obligations of the GPL would be violated (GPL requires that the entire work is GPL, MIT would not cover this). In such a case, practically everything must run under GPL.

GPL and permissive licenses

The GPL is known for being picky about its “partners”: it is compatible with many permissive licenses, but by no means with all of them. GPL-compatible are e.g:

• MIT license and 2- or 3-clause BSD licenses – these have no conditions that conflict with the GPL. The code can be adopted; the resulting software may (or even must) be under GPL. The original MIT/BSD code is in fact also distributed under GPL at that moment, but this is permitted because the original license allows it.

• Apache License 2.0 and GPL: The devil is in the details of the versions. Apache 2.0 was classified by the Free Software Foundation as incompatible with GPLv2. The reason: Apache 2.0 contains a clause about patent licenses and their termination in the event of patent lawsuits. GPLv2 has no such clause and contains the strict requirement that no additional restrictions may be imposed on redistribution. However, a patent termination clause could be seen as an additional restriction. Therefore: Apache 2.0 + GPLv2 = conflicting. Consequently, no code under Apache 2.0 may be integrated into a pure GPLv2 project without violating one of the licenses. However, Apache 2.0 is compatible with GPLv3, as GPL version 3 was designed in such a way that its own regulations on patents harmonize with the Apache licence. This means that code under Apache 2.0 and code under GPLv3 can be combined by publishing the entire work under GPLv3 (GPLv3 explicitly allows Apache code to be integrated as long as notice and Apache-specific requirements are met).

• Further examples: MPL 2.0 code can be used in GPLv3 projects because MPL 2.0 has a clause that allows compatibility with GPLv3 (the MPL code can be dual GPL’d if needed). Such special rules exist for some licenses, but play less of a role in typical game dev.

In general: permissive → copyleft is usually possible (i.e. permissive code can flow into a copyleft project, the result becomes copyleft). Copyleft → permissive is problematic because the copyleft material “brings its own conditions” that would not be fulfilled in a purely permissive (or even proprietary) publication.

Incompatible combinations

License incompatibility can occur in several ways:

• Contradictory conditions: Two licenses require incompatible things. Example: A hypothetical case would be a license that requires “no copyright notice may be mentioned in the software” combined with one that requires “copyright notice must be mentioned”. This would be directly contradictory. In real OSS licenses, this is rarely so blatant, as all reputable licenses allow attribution. But there are more subtle cases, e.g. the old GPLv2 vs Apache 2.0 issue as mentioned above.

• Copyleft vs Copyleft: Two different copyleft licenses can be incompatible. Example: Code under GPLv2 (without “or higher” clause) and code under GPLv3. These two versions of the GPL are incompatible with each other because GPLv3 has additional conditions that GPLv2 users have not accepted. Therefore, GPLv2-only projects cannot include GPLv3 code and vice versa without dual licensing. In practice, many GPLv2 projects are licensed with “GPLv2 or later” to remove this hurdle. Another example: GPL (copyleft) and LGPL (weaker copyleft) – here the coupling is usually such that LGPL code can be converted into GPL code (higher level GPL is more or less enforced), but not vice versa without violating the GPL.

• Proprietary vs Copyleft: This is the most common relevant incompatibility. Proprietary (non-open) software has per se the “license” of the manufacturer, who has usually reserved all rights. If GPL code is copied in without being asked, a derived work is created that is subject to the GPL conditions. However, if the manufacturer is not prepared to place the entire code under GPL, he is caught in a contradiction: he is in fact distributing code subject to GPL under a proprietary license – a clear license violation. This combination is not permitted as long as the conditions are not met. Unless the proprietary manufacturer obtains separate permission from the GPL code originator (e.g. through a dual license agreement). A practical example was the case of VMware vs. the GPL community: VMware incorporated parts of the Linux kernel (GPL) into a proprietary product. Without a special license, this is incompatible – which ultimately led to a legal dispute (Hellwig ./. VMware), which we will discuss later.

In short: Before installing an open source component, you should always check whether its license is compatible with the overall license of the project. License compatibility table: Many organizations provide overviews of which licenses are considered compatible with GPL. The Free Software Foundation, for example, lists that MIT, BSD, zlib etc. are all GPL-compatible, while the former Apple Public Source License, for example, was not compatible. For the daily work of a developer, the following rule of thumb is often sufficient: Use permissive licenses if possible, then you will hardly have any compatibility problems. If you already have GPL in your project, make sure that any additional code you use is at least GPL-compatible (or also GPL). If you want to remain proprietary, avoid GPL code, as this would force you to give up your proprietary status.

Accumulation of license obligations

License compatibility does not mean that you can choose which license applies – in a combination product you must comply with all applicable license obligations. Often the end product is offered under a single license (e.g. everything under GPL, if open source; or your own proprietary EULA, if closed). Nevertheless, it must be ensured at the same time that the conditions of the integrated open source components are complied with. In practice, this means e.g:

• Collect notices: Every piece of integrated OSS requires that you pass on the corresponding license text and copyright notice. Developers should therefore keep documentation of all third-party components. Files such as NOTICE.txt or OpenSourceLicenses.txt are often found in the installation directory of commercial software, in which all OSS components used are listed with a license. This is an implementation of the cumulative license requirements.

• offer source code: If even just one component in the product is GPL’d and the product is distributed, the provider must provide the licensee with the complete corresponding source code (GPLv2) or make a written offer to do so (GPLv3), regardless of how small the component is. It is not sufficient to provide only the code of this one component – since the entire work is considered to be derived, this also includes any custom code that has been linked to the component. Exception: Dynamically linked LGPL libraries – here you “only” have to enable the user to exchange the LGPL component, which practically requires you to provide your own object files or support dynamic linking.

• Attribution: Some licenses (e.g. CC0 for code, or formerly the 4-clause-BSD) require that you give the author’s name in advertising material. You should be aware of such more exotic obligations if you use such licenses so that they are not overlooked. Such requirements rarely occur in the area of classic software licenses (more so with CC licenses in the media sector).

A typical example of a cumulative obligation in a commercial product: A computer game uses 5 open source libraries – one under MIT, one under Apache, two under BSD, one under zlib. All are permissive, so the game team does not have to disclose its own code. But each of these licenses requires their license text to be present somewhere in the package. The game studio therefore inserts a LICENSES file in the game folder containing the texts of all five licenses + the copyright of the respective developers. This fulfills the license conditions and the proprietary game can be legally distributed with these components.

WordPress plugins and license compatibility

A special case that many plugin developers are familiar with is the topic of WordPress plugins and themes. WordPress itself is licensed under GPLv2, but the makers of WordPress (Automattic) take the view that every plugin and every theme that uses WordPress or is based on it is to be regarded as a derivative of WordPress. According to this view, every plugin must therefore also be licensed in a GPL-compatible manner – ideally also under GPL. In fact, the official directories (the WordPress Plugin Repository) and marketplaces require that uploaded extensions are licensed under GPLv2 (or a compatible license). Incompatible licenses (such as purely proprietary EULAs or certain restricted licenses) will result in the plugin not being included there.

Legally, the question of whether a plugin is a derivative work of the main software has not been conclusively clarified – there are arguments that the use of defined plugin interfaces (hooks, APIs) alone does not constitute an adaptation in the sense of copyright law, but rather a permitted coupling. However, the boundaries are blurred: as soon as a plugin directly copies WordPress code or loads it into memory (which in fact always happens, as it calls functions of the WordPress core libraries), it can very well be considered an adaptation or at least a dependent connection. Cautious developers therefore stick to the GPL so as not to enter into conflict with WordPress’ license. Although – as far as is known – there has not yet been a lawsuit in Germany by WordPress authors against a plugin developer for license violation, the community rules ensure de facto enforcement: those who do not license in accordance with the GPL are excluded from the important distribution channels and risk damage to their image.

An interesting practical case was a legal dispute about a WordPress theme before the Higher Regional Court of Karlsruhe (judgment of 27.01.2021, ref. 6 U 60/20). In this case, a developer had a commercial theme based on WordPress created and distributed without disclosing the source code. A third party (presumably a competitor or an open source activist) then demanded the disclosure of the theme code, citing the GPL. The Higher Regional Court of Karlsruhe clarified that although it follows from the GPL that the developer would actually have to disclose the code when distributing it , if he does not do so, this does not mean that someone else now has the right to simply publish this code. The exclusive rights holder of the theme (the developer) has not automatically lost his copyright to his own shares as a result of a GPL violation. In other words: The GPL does not create general usage rights for anyone to the derived software as long as the developer does not himself comply with the license conditions. Rather, the consequence of an infringement is that no one may lawfully distribute the work – neither the infringer himself nor third parties. Although this ruling concerned the issue of rights management (the theme developer could prohibit a third party from putting his theme on GitHub, even though it would be subject to GPL), it also indirectly shows the license compatibility issue: WordPress and a non-GPL theme are actually incompatible in the sense that the theme should not have been distributed proprietarily. However, it is primarily the WordPress rights holder who can sue for this; third parties cannot enforce this on their own authority.

Conclusion on compatibility

Especially in larger game development projects, dozens of third-party components often come together – e.g. a physics engine, audio libraries, network libraries, etc. – possibly with different licenses. Before integration, it is essential to check whether all licenses are compatible with each other and with the planned end product. If in doubt, you should look for an alternative with a more compatible license for a component with a strict license. Numerous tools and overviews are available to clarify these questions. License compatibility is therefore a technical as well as a legal issue: technically, the components must harmonize, legally their licenses. Only if both are correct can the project be published without any worries.

Effects of copyleft licenses on proprietary software

A central concern of this article is the question of the effects of copyleft (especially GPL) on proprietary software. This means: What happens if a developer or company that does not actually want to disclose its own program (such as a commercial game or closed software) nevertheless uses open source code under a copyleft license? What obligations arise and how far do they extend?

“Viral” effect of the GPL

The “viral effect” is often mentioned in this context. This refers to the scenario where a component under GPL is integrated into a larger software product. According to the GPL conditions, the license “infects” the entire product to the effect that it may only be distributed under GPL. Like a virus that infects all cells, the license condition spreads to the entire work of art. Consequence: The previously proprietary project would have to disclose its source code and also place it under GPL if it is to continue to be distributed. From the company’s point of view, this means a potential disclosure of trade secrets and loss of exclusivity to the software.

In legal terminology, the GPL is said to contain a condition subsequent: The rights of use granted are subject to the condition that you comply with the license conditions when distributing the software. If a license violation occurs (e.g. because one does not disclose one’s own source code), the license expires automatically (e.g. as expressly stated in section 4 GPLv2 or section 8 GPLv3). As a result, the authorization to further distribute the work is lost – there is a copyright infringement if you do so anyway. The developer therefore finds himself in a lose-lose situation: either he fulfills the conditions (i.e. publishes his code openly – which he did not want to do), or he must forego distribution (i.e. remove the feature/code or withhold the product). This predicament is what is described as “viral”.

From the point of view of copyleft advocates, this is not an unfair trick, but a deliberate choice: Those who use free software should contribute to the community. From a company’s point of view, on the other hand, it is “contagious” and risky, which is why many companies take great care not to include any GPL or similarly licensed components in their proprietary products.

Scope of contagion: What is considered a derivative work?

A crucial question is how far the copyleft effect extends. It is not always clear whether software A that interacts with B is really considered an “adaptation” or derivative work of B. Copyright law (in particular § 23 UrhG) defines that adaptations of a work may only be published with the consent of the author. The GPL grants this consent subject to conditions. But if I can argue that my software is not an adaptation of the GPL work, then the obligation does not apply.

In practice, a number of differentiations are discussed:

• Static vs. dynamic linking: If I integrate a GPL library statically into my program (i.e. the code is merged into one unit during compilation), it is clearly a derived work. With dynamic linking (the library remains separate as a .dll or .so and is loaded at runtime), the situation is somewhat more complex. The Free Software Foundation takes the view that dynamically linked modules are also part of a derivative work because they run together in memory and communicate with each other. Some lawyers and developers, on the other hand, believe that dynamic linking is more of an interface usage, comparable to two independent programs working together – especially if the library remains unchanged and is only used via defined API calls. In EU/German copyright law, there is the concept of “free use” (§ 24 a.F. UrhG, but narrower for software in the EU) and non-protectable interfaces (ECJ decision SAS Institute vs World Programming, 2012, determined that functionality and interfaces do not enjoy copyright). These could be used as arguments to say that the user’s own program only uses the functionality of the library via a defined interface without making any unauthorized modifications. However, this is risky territory – there is no supreme court decision that generally says “dynamic linking is not covered by GPL copyleft”. Most experts therefore advise: Don’t rely on dynamic linking to save you from the copyleft obligation, especially as many GPL projects explicitly state that plugins/modules are also considered to be editing.

• Inter-process communication: If two programs run separately and exchange data via a pipeline, network or file interface, for example, they are generally regarded as independent works. Example: A proprietary program calls a GPL command line program and reads its output. There is no mixing at code level here; they are two processes. According to common opinion, this does not create a copyleft effect on the calling program – it remains independently licensed. However, the GPL program must of course be passed on in a license-compliant manner (i.e. source code etc.). Such architectures (separation into a GPL part and a proprietary part via a defined interface) are sometimes deliberately chosen in order to be able to use open source without having to open up one’s own code base. This “workaround” is legally permissible as long as the boundary of the works is maintained. But beware: it must not be an obvious artifice to circumvent copyleft where there is actually a strong connection.

• Plugins and the platform effect: As discussed with WordPress, the question always arises with plugins as to whether the plugin is a derivative work of the platform or the platform is a derivative work of the plugin – in both directions. The GPL propagates that every connection results in a joint work, unless there is a clear dividing line (e.g. via IPC). Thus, GPL platforms (such as WordPress, WooCommerce etc.) can cause plugins to have to place themselves under a GPL license. Conversely, proprietary platforms (such as Shopify or Adobe Photoshop etc.) impose their own license conditions, but there the plugin developer usually has a free hand as long as he does not violate the platform EULA – but he will be careful with GPL components in the plugin so as not to have to disclose his own plugin. More on this in the section on plugins.

Examples from game development

There are some well-known cases and best practices in dealing with copyleft in game development:

• Game engines: Some popular open source game engines are licensed under GPL. One example was the id Tech 4 engine (basis of Doom 3), which id Software released under GPL after a few years. This allowed the community and other developers to build on it, but hardly anyone used this engine commercially afterwards, as it would have meant disclosing the code of the entire game. Instead, commercial studios prefer to use engines that are permissively licensed (e.g. Godot Engine under MIT license) or commercial engines with their own licenses(Unity, Unreal Engine under proprietary/commercial licenses). Although these do not offer the source code freely (or only against NDA), they have clear commercial usage rights without copyleft. This shows: The strong copyleft effect of the GPL often deters companies in the games sector if the business strategy provides for closed source.

• Libraries in games: Many games use third-party libraries for certain functions (physics, AI, UI frameworks). Developers almost always make sure that these libraries are permissive (MIT, BSD, zlib etc.) or at least LGPL (where only changes to the lib would have to be disclosed). GPL-licensed libraries should be avoided. A historical example: The OGG Vorbis audio library for games was originally BSD-licensed (i.e. no problem), while the alternative library FAAC (for AAC audio) was GPL for a long time, which is why commercial projects did not touch it. Many audio codecs were therefore either developed in-house or licensed instead of using GPL code.

• Mods and tools: Interestingly, some games that are proprietary themselves include modding tools or scripting interfaces under GPL or LGPL because the game itself remains decoupled from them. For example, a developer might provide a level editor tool under GPL that helps the community to create new content – this has no impact on the license of the actual game as long as the tool is separate.

• Dual licensing: Some companies publish parts of their software under GPL in order to serve the open source community, but at the same time offer proprietary licenses for paying customers. This model (dual licensing) uses the copyleft as leverage: anyone who wants to use the software in closed source projects can buy off the GPL obligations. MySQL AB, for example, has handled this for a long time (GPL for community, proprietary license for customers). This is less common in game dev, but there are tools (e.g. certain middleware) that follow a similar strategy.

Strategies for dealing with copyleft

If you as a developer are faced with the decision to use a useful component that is under GPL, there are several strategies:

• Search for alternatives: There are often functionally similar libraries with a liberal license. The search may take time, but it pays off to avoid conflicts later on.

• Isolate: If a GPL component cannot be replaced (because it does something unique), you could try to integrate it in such a way that no derived work is created. For example, by running it in a separate process and communicating with the main program via defined protocols. In this way, the main software remains proprietary, while the GPL component is supplied as an independent tool (including source code to fulfill the GPL). Example: A level generator that is bundled with the game as an independent CLI program (GPL); the game only calls “LevelGenerator.exe” externally. However, this is only possible for certain use cases.

• Contribute and publish: Sometimes a project consciously decides to become open source itself, especially in the case of indie developers. Then you can also use GPL code without objection – you simply publish the entire game including the source. This may seem commercially unattractive, but there are cases where open development and possibly other revenue models (donations, services) make it work. However, this is rarely an option for companies that want to generate traditional license revenue.

• Obtain license advice: If in doubt, you should consult a legal advisor. There are specialists in IT law/copyright law who can help with the analysis: Is a certain integration path permissible, what obligations would arise exactly, are there clauses that can be used (e.g. if a licensor grants special permissions)? The consultant will also clarify whether there is perhaps no copyright protection at all – for example, if only tiny snippets of code have been adopted that do not reach the level of creativity. However, this is rarely the case with software; practically every non-trivially copied code enjoys protection.

To summarize: Copyleft licenses such as the GPL have a significant impact on proprietary software by triggering the disclosure requirement. Developers should understand this impact and take it into account when making design and technology decisions. In large companies, there are often strict guidelines for this (an internal license blacklist/whitelist system). In small development teams, it is the responsibility of the lead developer or CTO to keep an eye on the licenses of the tools used. If you underestimate the viral effect, in the worst case you may be forced to place your own software under conditions that run counter to the business strategy.

Risks and legal consequences of license violations

What are the consequences of not complying with the terms of an open source license? This section examines the legal risks – from warnings and legal proceedings to possible claims for damages – and is based in particular on German law (UrhG) and some well-known cases.

License infringement = copyright infringement

First of all, you have to be clear: An open source license violation is not a trivial offense, but legally a copyright violation. This is because the right to use third-party code is derived solely from the license. If you do not comply with the license, there is no effective grant of rights of use (Section 31 UrhG) – you are then using the code without the permission of the rights holder. This violates the exclusive rights of the copyright holder (e.g. reproduction and distribution rights pursuant to Section 69c UrhG for software).

In Germany, a clear line of case law has emerged in this regard: The GPL license(as an exemplary open source license) is understood as a right of use granted on a conditional basis (cf. LG Frankfurt a.M., judgment of 06.09.2006 – Ref. 2-6 O 224/06). This means that the right of use and distribution only exists as long as the conditions (source code disclosure, notice, etc.) are met. In the event of a breach, the right automatically lapses. This is permissible under general terms and conditions law (not surprising or unreasonable according to § 307 BGB, as courts have found) and does not circumvent § 31 UrhG, but uses its framework.

So what is the threat of such an infringement? In civil law, typically:

• Injunctive relief (Section 97 (1) UrhG): The rights holder can demand that the infringer refrains from using or distributing the software in an unauthorized manner in the future. This injunctive relief can be enforced quickly in summary proceedings (temporary injunction) if urgency is required, or in normal legal proceedings. In practice, a warning letter is usually issued first in Germany: This is a formal request to stop the infringement and to submit a cease-and-desist declaration with a penalty clause. For the person being warned, this means that they must undertake not to repeat the license infringement, otherwise they will pay a contractual penalty. This can often avoid lawsuits. In the past, groups such as gpl-violations.org (initiated by Harald Welte) have issued warnings to numerous companies who, for example, used Linux components in their devices without providing the source code. Many of these cases ended with an out-of-court settlement after a warning: the infringer provided the source code and paid the warning costs in order to avoid a lawsuit.

• Removal / recall / destruction: In addition to injunctive relief, the rights holder can demand that existing illegal copies be removed (Section 98 UrhG). In the case of software, this would mean stopping further distribution, withdrawing products from circulation or at least removing the component in question from the product. In practice: If a device has been delivered with infringing software, it could be demanded that it is not sold any further until the defect has been remedied. This can have extreme consequences – e.g. stopping the sale of a product or recalling it.

• Right to information (Section 101 UrhG): In order to be able to quantify damages, the rights holder may demand information on the extent to which the infringement took place (e.g. number of units of the distributed software, sales with it, etc.). In the open source context, this is relevant if damages are later claimed.

• Compensation for damages (Section 97 (2) UrhG): If the infringement was intentional or negligent, the infringer owes damages. In reality, however, the question arises as to how to calculate damages in the case of open source infringements. There are three basic methods under copyright law: (a) concrete financial loss of the rights holder; (b) surrender of the infringer’s profit; (c) license analogy (fictitious license fee). Option (a) is often ruled out because open source developers do not sell their software commercially – their “loss” due to an infringement is more of a non-material nature or affects the community. Option (b), profit skimming, could be considered in extreme cases: If a company has saved or earned a lot of money because it used OSS unlawfully, it could be argued that this benefit should be handed over. However, this is complex and rarely practiced, as causality and calculation are difficult. This leaves variant (c), license analogy: One asks what fee reasonable parties would have agreed for the use. However, OSS is licensed free of charge – no license fee at all. Nevertheless, some courts have initially set a kind of “fictitious license fee”, as a kind of penalty estimate. In 2016, for example, the Bochum Regional Court awarded damages to a plaintiff by estimating an amount X as a reasonable license fee, even though the license was actually free. On appeal, however, the Higher Regional Court of Hamm (judgment of 13.06.2017 – Ref. 4 U 72/16) corrected this view: If the software is under GPL and is therefore normally licensed free of charge, you cannot suddenly pretend in the event of infringement that the infringer had to pay an expensive license. The judges rejected damages in the form of a fictitious license fee. In practice, this means that in the case of OSS infringements, the rights holder usually comes away empty-handed in terms of money unless he can prove that he has suffered real damage. This may be frustrating for developers, but it also underlines the fact that the main lever of open source licenses is not the financial damage, but the power of disposal (stopping use). Important: OLG Hamm did not say that all damages are excluded – theoretically, a competitor who uses GPL code lawfully could lose competitive advantages or demonstrate similar damages. But this is difficult to quantify.

• Reimbursement of warning costs: If the rights holder issues a justified warning, he can demand reimbursement of the necessary legal costs (Section 97a (3) UrhG). This includes legal fees for the warning letter, typically calculated according to the amount in dispute. In practice, the amount in dispute for GPL infringements has been set in the range of €50,000 – €100,000 (see, for example, Munich Regional Court I in 2004 set €100,000), which can mean legal fees in the mid four-figure range. These costs must then be borne by the infringer, which has a very noticeable financial effect, even if no compensation is paid.

• Contractual penalty: If the infringer has issued a declaration to cease and desist with a penalty clause, they must pay an agreed contractual penalty in the event of a repeat infringement. This can also be high (often “to be determined by the rights holder at his reasonable discretion, reviewable by the court” – which can quickly result in five-figure sums). This is to ensure that the infringer does not simply continue.

In addition to civil law consequences, criminal law is also theoretically relevant: The unauthorized use of copyrighted works can be punishable under Section 106 UrhG, and even more severely in the case of commercial use (Section 108a UrhG). In practice, however, criminal charges for open source license infringements are almost never filed – the matter is usually settled between the parties under civil law, especially since the infringers are usually companies and the injured parties are developers or foundations that are more interested in compliance with the license than in criminal prosecution.

Relevant case law in Germany

The enforcement of open source licenses in the courts has set a number of precedents in Germany. Here are some of the most important decisions and cases:

• Regional Court Munich I, decision of May 19, 2004 (Ref. 21 O 6123/04): This was one of the first court confirmations of the GPL in Germany. The developer Harald Welte (Netfilter/IPTables project in the Linux kernel) obtained a preliminary injunction against a company (Sitecom) that used his software in router firmware without complying with the GPL conditions. The court prohibited the company from further distributing the software as long as the GPL license text is not enclosed and the source code is not offered. Also important: The Munich I Regional Court clarified that the automatic expiry of the license in the event of infringement does not violate German law. In particular, Section 31 (1) sentence 2 UrhG (according to which exclusive licenses require the written form) was not circumvented, as a simple right of use was granted here subject to a condition subsequent, which is permissible. This was a milestone – the effectiveness of the GPL was thus recognized.

• Regional Court Frankfurt a.M., judgment of 06.09.2006 (Ref. 2-6 O 224/06): Another important judgment in which the same thing was essentially confirmed: GPL violations lead to the expiry of the rights of use (here expressly with reference to § 158 para. 2 BGB, i.e. the provision on terminating conditions), and this construction is not contrary to the GTC.

• Regional Court of Cologne, judgment of 16.05.2012 (Ref. 33 O 353/11): This case concerned the distribution of GPL-licensed firmware in internet routers. The court also affirmed the right to injunctive relief in the event of a GPL infringement. What was interesting about the case was that it concerned a so-called “downloader” – i.e. a chain of companies that distributed software. The ruling made it clear that everyone in the distribution chain who passes on the software must comply with the license obligations. The router manufacturer had offered source code, but an online portal that distributed firmware updates to end users had failed to do so – this was also eligible for a warning.

• LG Bochum, judgment of 03.03.2016 (case no. I-8 O 294/15) and OLG Hamm, judgment of 13.06.2017 (case no. 4 U 72/16): This complex concerned a university that offered software (originally GPLv2, later licensed proprietarily) for download without source code. In addition to injunctive relief, the Regional Court of Bochum also awarded damages in the form of a fictitious license fee. However, the Higher Regional Court of Hamm overturned the damages award. As mentioned above, it denied such a claim as no license fee would normally be due. Nevertheless, it confirmed that there had been an infringement of copyright and that the rights of use had lapsed. Thus, the injunction and costs were upheld, but no separate damages were awarded. This OLG ruling is often cited as an indication that you do not automatically have to expect high fines for OSS infringements – but this should not mean that it is without consequences.

• Karlsruhe Higher Regional Court, judgment of 27.01.2021 (Ref. 6 U 60/20): The aforementioned WordPress theme case. The focus here was less on the infringement as such (which was implicit), but on the consequences: Does the developer lose his own rights to the work? The OLG clearly stated: No, the “viral effect” of the GPL does not mean that anyone can use the adaptation without the consent of the developer. The GPL “only” causes the loss of rights to the original OSS (i.e. you may no longer use the third-party code), but does not automatically release the newly created parts to the general public. In other words, copyleft does not force the source code to become public against the developer’s will – it only withdraws permission to distribute the product as long as the developer refuses to disclose it. This ruling brought a little more legal certainty to the effect that an infringer of the GPL can still invoke his copyright, at least vis-à-vis third parties. In practice, this means that the penalty of the GPL is the blocking of distribution, not the expropriation of the programmer. However, there is still the risk that the original rights holder (e.g. WordPress authors) could in turn demand an injunction, as a result of which the theme may ultimately also not be distributed.

• Hellwig ./. VMware (LG Hamburg 2015, OLG Hamburg 2019): This prominent case shows the difficulty in complex scenarios. Christoph Hellwig, a Linux kernel developer, accused VMware of using parts of his (GPLv2-licensed) code in the proprietary VMware ESXi hypervisor without GPL conformity. The lawsuit in Hamburg was ultimately dismissed, not because the GPL was invalid, but for reasons of proof: Hellwig could not clearly prove which parts of VMware were based exactly on his contribution, as VMware openly acknowledged using Linux code but also claimed to have written stand-alone modules. The court ultimately shied away from the fundamental question of whether the combination constituted a derivative work and ruled in favor of VMware due to a lack of substantiated evidence for the specific code. Hellwig subsequently waived further appeal. This case shows: In large projects with many authors, enforcement can sometimes fail – but this is not a license for infringements, but often only means that the pressure is then exerted differently (community pressure, press). In fact, VMware has taken several parallel steps to open up or restructure parts of its code in order to defuse GPL conflicts.

• Harald Welte and gpl-violations.org: There is no single decision on this, but a series of successful warnings and interim injunctions (in addition to 2004, for example, Munich Regional Court 2005, Berlin Regional Court 2010, etc.). Welte, as a committed developer, has virtually proven that GPL infringements can be consistently prosecuted. Many manufacturers of embedded devices (routers, DVD players with Linux, etc.) were caught not complying with the license and had to make improvements. These cases are notorious in the community; legally, they have established the enforceability of open source licenses in Germany.

In summary: The courts in this country support open source licenses. Anyone who believes that no one would seriously sue for such “free” licenses is mistaken. The courts recognize the license terms as contractual terms and treat violations as copyright infringements with the aforementioned claims. At the same time, they are aware that we are talking about free software – so extreme fines are rare. The main instrument is injunctive relief (and thus ensuring the open availability of the code or discontinuing its use).

Practical consequences for developers and companies

What do these legal risks mean in concrete terms in the day-to-day work of a development team or a company?

• Product delay or stop: In the worst case, a license violation can lead to an entire project having to be stopped. Let’s think of a video game that is about to be released and suddenly someone discovers that a developer has incorporated a GPL library without the publisher’s knowledge. If this becomes public or is reported to the licensor, there is the threat of an injunction prohibiting distribution. The game could not be released until the problem is solved – either by removing the component (which may be technically impossible shortly before release) or by disclosing the code (which the publisher may not like). Both options can significantly delay the market launch or ruin it economically. Therefore, license compliance is part of quality management.

• Contractual risk with clients: If a studio develops a game on behalf of a publisher and produces license violations, the publisher can consider this a breach of contract. This can result in claims for damages (such as costs for subsequent code refactoring or contractual penalties). In a B2B relationship, the supplier can be held liable if it does not ensure delivery free of rights in accordance with the contract. (More on this in the next section “Contractual aspects”).

• Exclusion from distribution platforms: In the plugin world – such as WordPress, but also browser add-on stores etc. – a violation can mean being kicked out of the ecosystem. If, for example, it becomes known that a WordPress plugin uses code under GPL but does not offer its own source code, WordPress could remove the plugin from the official directory and publicly point this out. In addition to the loss of sales, there is also reputational damage: Developers are then seen as working shoddily or being legally unreliable.

• Damage to developers’ reputations: Open source is a particularly sensitive topic in the developer community. Companies that disregard OSS licenses could be publicly criticized (e.g. in forums, blogs, Heise news, etc.). There have been several examples: when it became known that certain products contained GPL violations, there was media attention. In times of social media, such negative publicity should not be underestimated.

• Costs of rectification: If a warning letter is issued after all, the infringer must generally not only bear the costs of the warning letter but also act quickly to remedy the infringement. This can mean Investing developer time to add missing license texts, or making the source code available to all customers, or even replacing components. This rework ties up resources and costs money, but is necessary to avoid major damage. In the worst case, an update has to be distributed to all customers, which can be a challenge, especially for embedded devices or games without automatic patching.

Overall, it can be said that the risks of non-compliance with open source licenses are real and, above all, business-critical. They can paralyze projects and put a strain on contractual relationships. The good news is that all of this can be avoided if the licenses are handled correctly from the outset. Using open source is not dangerous per se – you just have to know the “rules of the game” and stick to them. Then the risk becomes a great benefit.

Contractual aspects when using open source

In addition to direct copyright issues, contractual regulations also play a major role when it comes to the use of open source in software projects. Here we look at how open source aspects should be taken into account in contracts – for example between client and contractor, between employer and employee developer or between software provider and customer. Keywords are integration clauses, testing obligations and due diligence clauses, but also topics such as warranty, liability and internal guidelines.

Provisions in software development contracts

When a company commissions software (e.g. a game or a plugin) from an agency or a freelancer, a contract for work and services or a similar development contract is usually concluded. This specifies what is to be delivered (functionalities, performance features) and often also the quality standards that apply. In recent years, it has become common practice to explicitly state in such contracts whether and in what form open source components may be used.

Typical clauses in this context are, for example:

• Open source permission or prohibition: Some clients prohibit the contractor from using open source code, especially code under copyleft licenses. The background to this is the concern that the software supplied would otherwise not be freely usable or could trigger third-party claims. However, a total ban is often impractical, as almost all software today uses a library of some kind. For this reason, many contracts are formulated in a more differentiated way: “The contractor may use open source software components, provided that these are under a license compatible with licensing law (e.g. MIT, BSD, Apache, LGPL) and the use of such components does not restrict the contractual use of the delivered software by the client. In particular, the use of copyleft licenses that would oblige the source code of the entire software to be disclosed (in particular GPL, AGPL) is only permitted with the express written consent of the client.” – Such a clause makes it clear that, for example, a small MIT library is okay, but a GPL library must be approved beforehand (which would usually be refused unless the client has reasons to allow it).

• Integration clause / third-party software clause: This is about disclosing all third-party components used (not only OSS, also commercial libraries). For example: “Upon delivery, the contractor shall provide the client with a complete list of all third-party software components used, including version number and license, as well as copies of the respective license terms.” This ensures transparency. The client can then check or have checked whether these licenses are acceptable. Such clauses are part of the documentation obligation. They protect the client from unpleasant surprises and enable him to point out problematic components if necessary.

• Entire Agreement / Entirety: Sometimes contracts contain a so-called integration clause in the sense of “This contract represents the entire agreement of the parties; there are no oral ancillary agreements.” What does this mean in the open source context? It could become relevant if a contractor incorporates OSS because, strictly speaking, third-party license terms “come into play” – the OSS license is a separate agreement between the rights holder and the user. An integration clause is intended to prevent third party conditions from suddenly influencing the contract. Of course, the obligations towards the OSS author cannot be overridden by means of a two-party contract – they apply independently. But this discrepancy can create tensions: In the internal relationship between client and contractor, what is written in the contract applies (e.g. “no obligation to publish”), while in the external relationship with the OSS author, the GPL applies (which the client may not even be aware of). It is therefore advisable to explicitly regulate in the contract how to deal with open source licenses instead of keeping them silent. This avoids an integration clause coming into conflict with OSS terms and conditions. In case of doubt, the contractor should point out: “Attention, this software contains OSS with the following conditions – the contract does not change this, we must comply with these conditions.”

• Transfer of rights and OSS: Clients often want to have all rights to the development result transferred (exclusive rights of use, Section 31 UrhG). However, if open source is involved, the contractor cannot transfer more rights than he himself has. He cannot therefore give the client the exclusive right to a component that is under GPL – because this component remains available to third parties under GPL. Contracts should therefore make it clear that no exclusive rights (have to) be transferred for open source components, but that the client may use them within the scope of the respective license. Sometimes the following is formulated: “If the delivery item contains open source software, the conditions of the respective open source license apply to these components. Within this framework, the customer receives the rights of use as granted by the open source license; no further granting of rights is necessary or possible.” This ensures that no one violates the logic of the OSS license.

Audit obligations and compliance processes

Verification obligations can be set out in contracts or internal guidelines. They serve to ensure that open source licenses are handled correctly.

• Contractual assurance of testing: A contractor could assure: “We have tested all components used for license compatibility.” Or a software supply contract can state that the supplier guarantees that the software is free of open source components that are subject to a publication obligation or other restriction. Such guarantees give the client a promise of security. If it turns out afterwards that it was not tested after all, this can lead to claims (e.g. compensation, price reduction).

• Audits and tests: In some contracts, especially for larger projects, the client reserves the right to audit. For example, the client may have the code checked by its own experts or tools (e.g. with a software composition analysis) before declaring acceptance. If he then finds an unauthorized GPL component, for example, he can refuse acceptance until this has been rectified. This motivates the supplier to pre-deliver what he uses.

• Internal company policies: Irrespective of contracts with third parties, companies should have their own open source compliance guidelines. These define internally how developers should proceed if they want to use open source. For example, an approval process can be defined: a developer must register every new open source package in a list, with details of the license, purpose, alternatives, and a responsible person (such as an open source compliance officer or the legal team) gives the green light or rejects it. Many larger IT companies do this. In addition, a list of permitted licenses is often provided (whitelist) and possibly a blacklist of particularly problematic licenses (e.g. AGPL, or some with tricky clauses). All of this falls under “review obligations” in the broader sense – it is the care that must be taken before using code that belongs to others.

• Documentation obligation: Already mentioned – but it must also be fully documented internally which OSS components are included in a product. In the chaos of a project, it can otherwise happen that you forget what you installed months ago and then components are missing at release (such as the correct license text). A bill of materials should therefore be kept. In contracts, the delivery item can also include the documentation, for example: “The delivery item is the source code of the software including documentation of all open source elements and their license conditions.” It is then clear that the delivery is incomplete without this list.

Warranty and liability for open source use

Let’s assume that a developer delivers software to a customer and it later turns out that an OSS license has been violated. What contractual claims could the customer have? This is where warranty (material defects and defects of title) and liability rules come into play:

• Defect of title: According to Section 435 BGB, a defect of title exists if third parties can assert rights in relation to the delivered item that prevent the buyer from using it. Applied to software: If the delivered software contains code that may not be used lawfully (e.g. because the license has been violated), then a third party – the original author – has claims (injunction, etc.) that affect the contractual use of the software. This is a classic defect of title. In the case of a defect of title, the buyer/counterparty is entitled to the warranty rights: subsequent performance, in the event of failure, withdrawal or reduction, plus compensation for damages in the event of fault.

  Example: A plugin manufacturer sells a company a plugin for its website. The company later receives a warning from an OSS developer that the plugin violates the GPL. The company had to deactivate the plugin and now demands remedy from the manufacturer – either to establish license conformity or compensation for the loss of use. In such a case, one would argue: The plugin manufacturer has delivered deficiently (legal deficiency), should provide subsequent performance (deliver plugin without license violation, e.g. by update that replaces the code) and, if applicable, compensate the customer for damages incurred.

• Material defect: You could also consider a material defect if it was contractually guaranteed that no open source was included, for example. If it does contain open source, the software does not correspond to the agreed quality – this would be a material defect (§ 434 BGB). However, the legal exemption is often qualified as a legal defect. In any case: The supplier must rectify the defect or the customer has rights.

• Liability clauses: Contracts usually limit the liability of the parties, especially for slight negligence. However, core obligations cannot be excluded, and in the case of intent/gross negligence or warranted characteristics, any exclusion does not apply. So if a developer deliberately or grossly negligently disregards a license, he can hardly invoke exclusions of liability. Conversely, if a company uses open source software from an OSS project and it has a bug, for example, the exclusion of liability contained in the OSS license usually applies. However, as mentioned, a total exclusion of liability is limited under German law on general terms and conditions. In extreme cases, a user of an OSS tool could therefore hold the author liable if, for example, intent could be proven (which is extremely unlikely). In practice, these considerations rarely play a role because OSS is generally not expected to provide a warranty (it is delivered “as is”). However, in B2B contracts where OSS components are included, it is important that the supplier cannot simply refuse any responsibility by stating “there was OSS in it, the warranty is excluded”. The supplier remains liable to the end customer unless the contract expressly stipulates otherwise.

• Indemnification: Indemnity clauses are often found in international contracts (especially with US companies): the supplier indemnifies the customer against all third-party claims resulting from the infringement of IP rights and covers the costs of legal proceedings, etc. If this is transferred to OSS, it means that if an open source copyright holder sues the customer for a license infringement, the supplier must step in and protect/compensate the customer. Such a clause naturally increases the pressure on the supplier to ensure compliance from the outset, as otherwise it will be liable for high costs. In German contracts, the term “Freistellung” or “Haftungsfreistellung” is also commonly used. A client could demand: “The contractor indemnifies the client against all third-party claims arising from infringements of copyright or license rights by the software supplied.” In this way, the risk is completely shifted to the client.

To summarize: When using open source, clear contractual provisions should be made to protect all parties. The developer/supplier wants to know what he is allowed to do and that he will not be accused afterwards of having done something illegal when it was permitted. The client wants to be sure that the product does not contain a “license bomb” that will blow up later. Good contracts and open communication about the OSS used create trust and avoid disputes.

Due diligence for M&A and transactions

Another important field: due diligence in company takeovers and investments. If an investor wants to buy a software company, he naturally checks its technology. It is now standard practice to also scrutinize open source compliance. Why is that?

Imagine investor X wants to buy a game studio that has a successful proprietary game. If it turns out after the purchase that this game contains unobserved GPL code, the new owner may have to publish the source code or stop distribution until it is fixed – this could massively reduce the value of the entire investment. For this reason, various checks (due diligence) are carried out before a purchase agreement is concluded:

• Code scan: There are specialized service providers who scan the entire code of the target company (using tools such as Black Duck, FOSSID etc.) and create a report showing which open source components have been identified, with license information. Undeclared components can also often be detected in this way.

• Policy check: The buyer checks whether the company has guidelines for dealing with OSS, how compliance management is set up and whether there have been any violations or warnings in the past. A mature OSS compliance process is a good sign that there are few dormant risks.

• Contracts: Look at the contracts to see whether there are any clauses with suppliers or partners that could possibly be violated due to OSS (such as the prohibitions mentioned above). If, for example, the company has supplied software to major customers with the assurance “no copyleft software included”, the auditor should ensure that this is true, otherwise there is a risk of subsequent liability.

• Open source balance sheet: Some create a list of all OSS with a traffic light rating – green (okay), yellow (caution, e.g. LGPL or MPL, but manageable), red (GPL, AGPL, incompatible licenses). If there are red entries, the purchase price may be renegotiated or the seller may have to replace these components before closing (refactoring).

In Germany, for example, there have been cases where the sale of a company was postponed until it had a clean open source balance sheet. No buyer wants to experience a nasty surprise shortly after the deal. This applies not only to the purchase of an entire company, but also to the acquisition of individual software products or the entry of an investor.

Even if you’re not thinking about sales: partnerships and distribution licenses can trigger similar tests. For example, a large publisher wants to sign an indie studio. The publishing agreement could have a clause: “The developer warrants that the game does not contain any open source software that impairs the exercise of the publisher’s exploitation rights. The developer shall disclose all open source components to the publisher.” Again, basically due diligence on the part of the publisher before investing millions of marketing dollars in the game.

Documentation and dissemination of license information

A rather practical but contract-related topic: passing on license information to end users. Many open source licenses not only require the developer to comply, but also that end users are informed about certain things. For example, the GPL requires that each recipient of the software also receives the license terms and is informed about their rights (e.g. source code request). Or Apache/MIT require that the license text is included in the documentation, which must ultimately reach the end user.

Therefore, the following should be ensured (and contractually required) when the software is delivered:

• Including the licenses: The supplier should include all relevant license texts. It is often agreed that the documentation or help file must contain an “Open Source Licenses” section. For games in particular, this can also be done in the “Credits” or “Legal Notices” menu. It is important that it can be found in the final product. Physical products (e.g. a device with software) often come with a booklet or CD in which the open source licenses are printed.

• Source code provision obligation: If a component under GPLv2 is in the product, the provider must physically or electronically enclose the source code or at least send it on request. For GPLv3, a written offer or a suitable link must be provided that is valid for at least 3 years. These logistical obligations should be considered in the project planning. For example, if you produce an IoT device that contains Linux (GPLv2), you must either provide the end customer with the source directly on CD or at least write in the instructions “You can find the source code at [URL] or you can request it from us”. If you fail to do this, you are already in breach. Good practice: set up a web portal right away where all OSS components and source are available for download – then you can refer to this page in all products.

• Contractual penalties in reselling: If a company gives software to a reseller or distributor, it should also contractually oblige them to pass on the OSS notices. Not that the manufacturer ends up saying “I gave the distributor everything”, but the distributor forgets to give the licenses to the end customer, and then the manufacturer is still held responsible. This is why clauses are sometimes included in distribution partner agreements that oblige the partner not to remove any license texts and to pass on all necessary documents. A prohibition on providing information could also be counterproductive: Of course you can’t contractually prohibit the partner from referring to OSS, because that has to happen. So such subtleties should be taken into account.

Dealing with copyleft in contracts

It should be explicitly mentioned again: Copyleft components such as GPL in a contract should be handled very consciously and transparently. If the client agrees, e.g. because there is no alternative and he is prepared to distribute the code openly, then the contract should state exactly how this disclosure will be made and that the client knows this. It may be necessary to regulate who processes the source code requests later (the contractor on behalf of the client or the client itself).

If the client does not agree to this, the contractor should never use such a component without authorization. If he does (perhaps in the hope that it will not be noticed), he is treading on very thin ice – in addition to legal action from the OSS author, he also risks a breach of contract with the customer.

In quotations, it can be helpful to say “We use the following open source tools…” so that the customer knows. Transparency creates trust and reduces later disputes.

Example from practice

Let’s assume an agency is developing a web-based game for a client. It wants to use a specific JavaScript framework that is under GPL. However, the client wants to keep the game exclusive and the code secret. The agency cannot find a comparable alternative and proposes to use the framework anyway, but to operate it separately as a backend service. In the contract, they agree that the framework will run on a separate server and the code for it will be handed over to the customer along with the GPL license, while the actual game is decoupled from it. It is also stated that the customer consciously agrees to this GPL use and will release the source code of the framework part to third parties on request. – This constructed example shows how it is possible to work with copyleft if necessary, provided it is set up properly in the contract. Ideally, however, a different framework would simply have been used.

Special features of plugin development (WordPress, Shopify & Co.)

To conclude the content sections, we would like to talk specifically about plugins and development for platforms, as this target group was mentioned in particular. Plugin developers often operate in an ecosystem that has its own licensing rules and must take into account both the platform policy and the OSS licenses.

WordPress and GPL – an unavoidable connection

WordPress as a content management system is one of the best-known examples where the platform license influences the plugins. WordPress is licensed under GPLv2 (with the additional clause “or higher”, which in case of doubt means GPLv2, as WP has not yet officially switched to GPLv3). The WordPress Foundation has made it clear that it considers plugins and themes to be derivatives. In practical terms, this means

• Plugins that are listed in the official directory must be GPL-compatible. The most common choice is simply GPLv2 (or v3) as well. Many developers adopt exactly the same license as WordPress to be on the safe side.

• Even if a developer sells a plugin commercially (e.g. premium plugins outside the official site), most of them are still under GPL. And that is permissible: The GPL allows sales as long as the license and code remain open. Many plugin providers finance themselves through support, updates or additional services, not through restrictive licenses. The end customer buys an annual license for updates, for example, but the code he receives is GPL – theoretically he could pass it on. In practice, very few end customers do this because they appreciate the support value.

• Attempts to license WordPress plugins/themes differently have led to conflicts. There was the case of theme developers (e.g. some on ThemeForest) who put the PHP code under GPL – to comply with WordPress rules – but put CSS/JS/design under a proprietary license to “protect” at least part of it. The legality of this is controversial: Strictly speaking, layout and JS could also be considered part of the derivative work, because together with the PHP code they make up the theme. WordPress has tolerated marketplaces making this split, but continues to promote pure GPL licensing. From a developer and user perspective, a fully GPL-licensed theme/plugin is the most straightforward because you know exactly where you stand.

• A word about forks: If a plugin is GPL, anyone can fork it and distribute it themselves. This actually happens – there are sites that offer “GPL plugins”, i.e. redistribute purchased premium plugins there at a lower price or free of charge. This is legal according to GPL, as long as they do not claim to have written it themselves (attribution must remain). This is of course annoying for the original developers, but they fight it primarily through better service (official updates, support only for paying customers, etc.). There is nothing they can do about it under license law, as GPL allows this. Plugin developers must therefore be aware of this: If I develop for the WordPress ecosystem, I basically accept GPL and the openness that comes with it.

• Case study: OLG Karlsruhe 2021 (again briefly): Here, the commercial theme developer successfully prevented someone else from publishing his code. However, this should not be interpreted to mean that his proprietary approach has been approved. He has effectively retreated to a formal property right. If the WordPress authors had sued him, the outcome would have been different (in which case he would probably have had to lose and release his theme or accept a distribution ban).

• WordPress plugin developers must also be careful about which third-party OSS libraries they integrate into their plugin. Because in addition to the WP→Plugin license flow, there is also plugin→third-party code. A WP plugin can, for example, integrate an MIT JavaScript library – that’s okay (MIT is GPL-compatible). What if a plugin uses an LGPL library? Probably okay, since GPL>=LGPL in compatibility, but strictly speaking you would also have to fulfill the LGPL conditions (e.g. references to changes to the lib). What if a plugin uses a PL library that is not GPL-compatible? Then the plugin developer himself has a combination problem: he cannot publish his plugin in accordance with the rules because he combines WP (GPL) and this incompatible component at the same time. So here again: all components in the plugin must fit together. Good news: There are huge amounts of GPL-compatible OSS, so you would rarely be forced to use something that doesn’t fit.

Shopify and proprietary platforms

Shopify is a different beast: A closed SaaS platform for e-commerce whose code is not open. However, developers can create apps or themes for Shopify. The legal conditions here come from two directions: On the one hand, Shopify’s own contracts (partner program, API license terms, etc.), and on the other hand, the possible use of OSS in the app.

• Platform license: Shopify provides APIs, which generally stipulate that developers do not violate Shopify’s rights. Shopify itself is not open source, so there is no copyleft obligation from Platform→App. Theoretically, Shopify could even prohibit the use of open source components, but as far as I know they don’t do that directly. They are more interested in ensuring that the apps are secure and legal.

• Use of OSS in Shopify apps: A Shopify app often consists of two parts: the backend (on the developer’s server or a cloud function that receives and processes requests from the Shopify store) and the frontend part (e.g. embedded admin UI or scripts that are loaded into the store).

  • The backend part runs remotely. If a GPL component is used there, it is not “distributed” to Shopify or the merchant – it only runs on the app developer’s server. This would be comparable to a web service: GPL has no control here (unless it is AGPL). Strictly speaking, the developer does not have to publish the source as long as he only runs it as a service. That was one reason why AGPL was invented: GPL could not “catch” SaaS usage. However, if the developer later wanted to install the app on-premise at the customer’s premises (less common with Shopify), then distribution would occur and GPL would apply.

  • However, if the developer uses AGPL components in his app backend, he must also disclose the source code to the users of the service according to the license. In this case, the users would be the store operators or end customers who interact. This is usually not compatible with a commercial app model, which is why AGPL is quite feared in SaaS start-ups. Shopify apps will typically not include AGPL because it does not benefit the developer – it would only trigger obligations.

  • The front-end part of the app: This could be JavaScript, CSS, Liquid templates that are integrated into the customer’s store. These are actually delivered to the customer (e.g. as part of the theme or in the browser). If OSS code is included here, distribution applies again. A developer could, for example, use a JS widget under MIT; this would then have to be left in the code with the MIT reference. If, for example, he wanted to use a UI component under GPL (unlikely, but assumed), then he would give the retailer a GPL component, which in turn would mean that the retailer has the right to the source code, etc. The retailer would be surprised what would happen to the GPL component. The merchant would wonder what to do with it, and Shopify itself would probably not allow it because it would be confusing.

  • Shopify itself states in the Partner Program T&Cs that the developer must ensure that they have all the necessary rights to their app and that they are not doing anything illegal. A blatant OSS violation could theoretically be considered a violation of these terms and conditions, which could lead to the suspension of the developer account. In practice, however, this is only likely to happen if it comes to public attention or Shopify receives complaints.

  • Unlike WordPress, Shopify does not enforce a specific license for apps. The app developers can make their app open source, but they don’t have to. Many keep their code proprietary (even if customers could ultimately view the code that is executed, at least the front-end part). Here, the app developer has to weigh up carefully what open source to include so as not to unintentionally reveal anything.

• Themes on Shopify: Shopify also allows customized themes that can be sold. Themes are ultimately code (Liquid Templates, CSS, JS). The license of these themes is determined by the creators; Shopify does not write anything like “must be open source”. Consequently, we often find commercial licenses here. However, if a theme developer integrates a slider under GPL into his theme, for example, then he has the same problem as with WordPress: either he has to place the slider code (and therefore the theme that depends on it) under GPL, or he is in breach. But since Shopify is not GPL by itself, and the slider creator probably doesn’t realize it, it could slip through – but it’s not legally clean. However, there are tons of permissive slider libraries etc., so you can easily avoid GPL parts in Shopify themes.

In short for Shopify developers: there is more freedom on the platform to remain proprietary, but the responsibility for open source building blocks used lies entirely with the app developer. They should check just as carefully: What license does each library I include have? Do I meet their requirements (e.g. do I include copyright notices in Minified JS etc.)? What happens if I give the app to a customer for self-hosting? And of course: Do I have something that is not compatible with my closed source app (e.g. GPL)? If so, replace it urgently.

Other platforms and plugins

• Browser extensions: They are often open source or contain OSS (e.g. UI libraries). Browsers do not have a mandatory plugin license, but the Chrome Web Store, for example, has copyright compliance guidelines. If someone copies in third-party code without a license, this can become a problem. In this respect, the general rules also apply here: use OSS, but stick to the license.

• Game modding and SDKs: Some games allow mods or plugins via SDKs. The main game is usually proprietary, but the mods can carry licenses. EULAs often state that mods may only be non-commercial and that rights fall to the publisher, etc. This in turn collides with OSS licenses, which do not allow any restrictions on use (GPL, for example, says anyone may use for any purpose, a “non-commercial” ban would be contrary to GPL). You have to be careful here: If a modder puts GPL code in a mod, but the game EULA says “no commercial use”, you have conflicting terms. This is a broad field – but it is worth mentioning that there are tensions in practice. Modders should rather choose permissive licenses or public domain to avoid stress.

• App stores in general: Whether Apple App Store, Google Play, Shopify App Store or WordPress repository – platform operators generally do not want to be liable for license violations by their developers. This is why the Developer Terms almost always stipulate that the developer is responsible. It is therefore up to each developer to ensure that they do not infringe any third-party rights. Open licenses are third party rights! So yes, it is relevant.

Practical recommendations for developers and companies

After all the theory and pitfalls, here are some practical tips on how software developers – whether in game development, plugin projects or in general – can use open source in a legally compliant way without having to miss out on the creative and productive benefits:

1. Knowledge and awareness: Familiarize yourself with the basics of the important licenses. Every developer does not need to be a lawyer, but should have a basic understanding of what GPL vs. MIT means. Many companies briefly train their developers on this. It helps if terms such as “copyleft” or “GPL-compatible” are not Bohemian villages. Newly hired developers or freelancers in particular should be briefed so that they do not unknowingly contribute problematic code.

2. License selection before use: Before you incorporate an open source library into your project, check the license. Read the license text (at least skim it) or look at summaries. Pay attention to keywords: “GNU GPL” – alert, take a closer look to see if this fits in the project. “MIT / BSD / Apache” – usually not critical, but make a note of it. If you are unsure whether the license is compatible, ask colleagues or, in case of doubt, legal experts. There are also forums on the Internet (e.g. StackExchange “Open Source”) where such questions are often discussed.

3. Document all third-party components: Keep a list (e.g. in the README of the project or a special document) of all external libraries, snippets, etc. that are not your own development. Note the version and license. This makes it easier to create the “third license” file at the end and ensures that nothing is forgotten. It also prevents someone from accidentally updating a component later, the license has changed and nobody notices – you have documented it and will notice it.

4. Comply with license conditions immediately: It is best to ensure that the obligations are implemented during development. For example, if you know you are using MIT licenses, then integrate an “Open Source Credits” section in the about window or in the help menu, where you list the names and license texts. Don’t just frantically gather them the day before release. For GPL components – plan from the beginning where you will offer the source code for download or how you will provide it to the user. This should not be an afterthought, but part of the release process. Modern build pipelines often have steps that can automatically generate an OSS license overview; use such automations.

5. Choose proven OSS with community: This is more of a strategic tip. Frequently used open source projects usually also have well-documented license information and known practices. An exotic project with a self-made license brings more uncertainty. So it’s better to use popular libraries with known licenses. You are less likely to stumble across a strange clause. In addition, popular projects are usually aimed at the widest possible usability, i.e. rather permissive or at least LGPL.

6. Be careful when copy-pasting code: Many developers use Stack Overflow or GitHub-Gist for small code snippets. Note: Stack Overflow contributions are licensed under CC-BY-SA (Creative Commons Attribution-ShareAlike License). This is not a typical software license and can be problematic because it requires redistribution under the same conditions (similar to copyleft) and attribution of the author. Small pieces of code from it – some argue that this is de minimis (minor) and not protectable, but you should not rely on this. Better: If you take over something significant, ask the author or at least mention it in the code comments. For GitHub Gists or projects without a license, All Rights Reserved applies in case of doubt – in other words, keep your hands off or ask for a license, because without an explicit license you have no right of use! In short: Don’t mindlessly copy code from the internet just because it’s “there”. Always clarify which license it is under.

7. Set a good example: If you publish code yourself (be it a small plugin on GitHub or a contribution to a library), choose a clear license and include a LICENSE file. This way you contribute to the general culture that code is only available with a license. And you make it easier for others to use your code in their projects if necessary. Plugin developers on GitHub in particular should not forget to license their repo – otherwise no one else would actually be allowed to use it.

8. Use open source compliance tools: For larger projects or companies, it is worth using tools such as FOSSID, Black Duck, FOSSA, ORT, etc. These scan the code and create reports on licenses. They also recognize parts of code that could originate from OSS (by pattern matching), even if there is no indication in the code. This can reveal, for example, that someone copied a block of code from GPL software years ago. Such tools are not 100% error-free, but they are a great help. There are also open source tools such as OSS Review Toolkit or simple scripts that are integrated with npm or pip or maven to list dependent libraries and their licenses.

9. Maintain a license blacklist/whitelist: Internally, you can define which licenses can be used without any problems and which can only be used with permission or not at all. Example: “Whitelist: MIT, BSD, Apache, MPL, LGPL” (free to use); “only after approval: GPLv2/v3, AGPL, EPL…”; “blacklist: no unknown licenses, no ‘Commons Clause’, no DIY licenses”. This helps developers to find their way around. But make sure you keep these lists up to date and give reasons so that developers understand why, for example, GPL is in red (precisely because of the obligations).

10. Upstream and community: If you use open source components, don’t just minimally adhere to the obligations, but ideally be a “good citizen” of the open source community. This means: If possible, give improvements that you make to the library upstream (back to the maintainers) instead of leaving them closed-source in your project (if this is possible – with GPL you would have to give it anyway, but even with MIT it’s a nice touch). Why? For one thing, it saves you maintenance work if your changes are incorporated into the main version. Secondly, it strengthens the relationship between the company/developers and the open source community. In the event of an accidental breach, you’re likely to be treated more cooperatively if you’ve previously been seen as a fair open source user rather than a taker.

11. Seek legal advice in case of uncertainty: The subject matter can be complicated – especially in special cases (e.g. combination issues, dealing with stricter licenses or if you want to change licenses yourself). There is no shame in consulting an IT lawyer. Many law firms (especially in IT and media law) have experience with open source. The costs are manageable compared to the potential damage caused by a mistake. Especially in the case of company takeovers, large software rollouts or when a dispute is imminent, you should call in the professionals.

12. Stay informed: Licenses continue to evolve, new rulings may come, and new types of licenses emerge as well (e.g. most recently MongoDB’s server-side public license, which was rejected in some cases as “too aggressive”). For a developer, it is enough to occasionally read blogs such as heise Developer, Kanzlei-News or itmedialaw (😉) to find out whether relevant things are happening.

These measures can drastically reduce the risk. Many companies, from small start-ups to large corporations, have successfully implemented it: they use hundreds of open source components without falling into legal traps. It requires some discipline and knowledge, but the benefits of using open source – cost savings, fast development, no reinventing the wheel – justify the effort.

Conclusion

Open source is omnipresent and essential in the IT industry and especially in software development. For game developers, plug-in developers and software companies, the use of open source components offers enormous opportunities – from accelerated development to community-driven innovation. At the same time, the legal framework must not be ignored. In terms of copyright, open source code also remains protected intellectual property, the use of which is subject to conditions. In IT law and media law, a separate field of compliance has developed around open source, which is now part and parcel of professional work.

The most important findings from a practical perspective are:

• License compatibility is the be-all and end-all: developers must ensure that the open source licenses used are compatible with each other and with the license model of the overall project. Keywords such as GPL compatibility or the copyleft effect are not theoretical constructs, but can decide whether a product can be brought to market in a legally secure manner. The GPL in particular, as a strong copyleft, demands attention – its “viral” effect can “infect” proprietary software. In contrast, permissive licenses usually allow problem-free integration. Awareness of license types is therefore essential.

• The legal consequences of infringements are manageable but serious: anyone who disregards the rules risks injunctive relief and thus potentially a ban on the distribution of their software. German courts have repeatedly confirmed that open source licenses are effective and consistently treat infringements as copyright violations. Although there is generally no threat of high compensation payments (as open source is free of charge), the claims for injunctive relief and information are sufficient to significantly jeopardize projects. License violations can also lead to contractual problems, reputational damage and loss of distribution channels. Practical cases (from router firmware to university software to WordPress themes) make it clear: prevention is better than cure after the fact.

• Copyleft and proprietary development can coexist – with planning: Copyleft licenses such as the GPL do not exclude commercial use, but they require an appropriate business model (e.g. service instead of license sales) or an architecture that maintains clear separations. For most classic proprietary products, it is advisable to avoid copyleft components. If their use is necessary, developers and decision-makers must carefully weigh up the consequences. The “horror” of the GPL is mainly due to ignorance – if you know the exact scope (as also highlighted by the Karlsruhe Higher Regional Court), you can make informed decisions. In case of doubt, there are usually more license-friendly alternatives for almost every library.

• Contracts and policies create security within the team and with customers: It is not enough to know the license texts; you also need to regulate usage internally and contractually. A company in IT law should make clear contractual agreements when developing or purchasing software. Integration clauses ensure that clients know where they stand, and inspection obligations force suppliers to exercise due diligence. Due diligence during takeovers prevents “hidden obligations” from being included in the purchase. These are all best practices today. Start-ups or indie developers in particular who want to make it big should develop this professionalism at an early stage – this also increases the value of their products in the eyes of investors and partners.

• Acting in line with the target group: Developers of WordPress plugins now usually know that they cannot avoid GPL – and come to terms with it. Shopify app developers enjoy more freedom, but have to ensure license compliance on their own responsibility. Every ecosystem has its own rules; those who know them can operate within them without any problems. It is important that legal aspects also become part of the project planning – just as you consider performance or security, license compliance should be on the checklist.

• Use open source as an advantage, don’t shy away from it as a risk: in the end, the impression should not remain that open source is a minefield. On the contrary, it is a powerful tool when used correctly. In terms of IT law, much has now been clarified and is manageable – there are clearly defined licenses and tried and tested procedures. Developers and companies that observe these can benefit safely and legally from thousands of free components. Especially in the area of software development, game development and plugin development, open source can save time and money and share innovations. This only requires that you accept the responsibility that comes with freedom: i.e. complying with license terms and making your own use transparent.

To conclude: open source and proprietary software are not contradictory as long as the boundaries are respected. With the knowledge provided in this article – from copyright basics to specific license obligations and contractual safeguards – developers and companies are well equipped to use open source successfully and in compliance with the law in their projects. In this way, the advantages of the open source world can be used without unpleasant legal surprises. In the intersection of IT law and technology, open source remains an exciting field, but with the right preparation it loses its fright and unfolds its full potential for the benefit of all involved.