Open Source in Softwareentwicklung: Rechtspraxis | IT-Medienrecht

Discover legal aspects of Open Source in software development. Learn about licenses, risks, and copyright for game and plugin dev. Protect your projects…

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 often utilize freely available libraries, engines, and code snippets for cost reasons and due to extensive community support. However, "freely available" does not equate to "free of conditions."

Especially in IT law and media law, the legal framework of these open source licenses plays a crucial role. Copyright law and contract law, in particular, establish specific limits on the use of open source, which developers and companies must understand. Awareness of these regulations is vital for legal compliance.

This blog post offers a comprehensive overview of using open source in game development and plugin creation. It focuses on practical aspects, including: license compatibility between common licenses (such as GPL, MIT, Apache), risks and legal consequences of license violations, and the effects of copyleft licenses (especially the GPL) on proprietary software. Additionally, it addresses contractual elements such as integration clauses, testing obligations, and due diligence.

The information is presented neutrally and with legal precision, yet remains accessible for practitioners. Game, software, and plugin developers should recognize what they need to consider to avoid legal pitfalls. Key terms from IT law, copyright law, and contract law are explained. Relevant German legal norms, such as those from the Copyright Act (UrhG), along with court decisions and practical examples, are included to provide a clear understanding.

Basics of Open Source Licenses

Open Source and Copyright

Open source software (OSS) refers to software whose source code is publicly accessible. Third parties may use, modify, and redistribute this software, but always under specific license conditions. Legally, this model is rooted in copyright law.

Under German law, software enjoys copyright protection as a computer program (Section 2 (1) No. 1, Section 69a UrhG). The author or rights holder of the software possesses extensive exclusive rights of use (Section 69c UrhG). These include the rights to reproduce, distribute, modify, or publicly make the program available. Therefore, no one may legally copy or distribute the software without the rights holder's consent.

A software license precisely represents this consent. In a license agreement, the author grants a user certain rights of use (Section 31 UrhG). Open source licenses are typically pre-formulated standard licenses, granting everyone specific rights to the software. These rights are usually provided free of charge and for an unlimited period, but they are always linked to conditions.

These conditions differentiate open source licenses from purely "free" (unconditional) public domain software. From a legal perspective, open source licenses often function like general terms and conditions (GTC). They are unilaterally set by the author and accepted when the software is used. Consequently, they must comply with the law on general terms and conditions (§§ 305 ff. BGB).

It is important to note that even without a signed contract, 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" occurs, in essence, through the act of using the software.

The OSI (Open Source Initiative) defines criteria for what constitutes an "open source" license. These criteria include free redistribution, access to the source code, permission for changes, and no discrimination against persons or fields of use. Well-known examples of such licenses include the GNU General Public License (GPL), the MIT license, the Apache License 2.0, and the BSD licenses, among many others.

Permissive vs. Copyleft Licenses

Open source licenses can be broadly categorized into two types: permissive licenses and copyleft licenses. The primary distinction lies in the strictness of the conditions governing further use of the code.

Permissive licenses grant extensive rights and impose only minimal conditions. Examples include the MIT license, the Apache License 2.0, and the BSD licenses. They permit the integration of software into your own projects, including proprietary software, and allow redistribution with virtually no restrictions. Typically, these licenses only require that a copyright notice and the license text (or a reference to it) be retained within the software.

For instance, the MIT license mandates that the original license text must accompany any redistributed code. The Apache License 2.0 also includes an explicit grant of patent licenses to users and some protective clauses (e.g., when modifying names/trademarks). Despite these additions, Apache 2.0 remains "permissive" because derived works may be published under any license (including proprietary) as long as its few conditions are met. Permissive licenses are favored by developers for offering maximum freedom and causing minimal legal conflicts. You can build closed software from permissively licensed code without needing to disclose source code or fulfill other usage obligations.

Copyleft licenses, conversely, impose stronger conditions and aim to pass on the freedom of the code. In essence, "copyleft" means that derived works of the licensed code must, in turn, be published under the same license. The underlying principle is to safeguard openness: no one should be able to take free code and transform 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 most recognized and stringent copyleft license. While it allows users to use, modify, and redistribute the program free of charge, this is subject to certain conditions. When redistributing, the source code of the derived software must be disclosed, and the GPL license must apply to it. Additionally, the GPL requires retaining a reference to the licensor (copyright notice) and including a copy of the license with the program.

A disclaimer of liability and exclusion of warranty is also part of the GPL. However, in Germany, a complete exclusion of liability for intent and gross negligence would be invalid under general terms and conditions law (Section 309 No. 7 BGB). The essential core of the GPL is that if you integrate a GPL-licensed program or library into your own software and then distribute it, your entire software must also be under the GPL, and its source code must be openly accessible.

Beyond the "strong" GPL, there are also weakened copyleft licenses. The LGPL (Lesser GPL), for example, is considered a "weak copyleft." It permits an LGPL library to be integrated into proprietary software, as long as the library itself remains interchangeable and under LGPL. In practice, this often involves dynamically linking a DLL or .so file. The proprietary software must then allow the end-user to exchange the library for another version. The proprietary software itself does not have to be GPL/LGPL, but any changes to the LGPL component would need to be published.

Another variant is the AGPL (Affero GPL), which addresses a loophole in the GPL. For AGPL-licensed software, the source code must also be disclosed if the software is not distributed conventionally but used as a service over a network (Software-as-a-Service). This is relevant if, for instance, someone modifies an AGPL-licensed server or web service and offers it publicly. In such a case, there is an obligation to provide the source code of the changes.

In summary: Permissive licenses (MIT, Apache, BSD, etc.) are straightforward and compatible with proprietary use, imposing few restrictions beyond copyright attribution. Copyleft licenses (GPL and similar) ensure openness and force developers to reciprocate: what is taken must be given back. Both models are common in practice, with their use depending on the author's objectives. For game developers and plugin developers, it is crucial to identify the category of a component. This determination dictates how and if you are permitted to publish your own software.

Typical Open Source Licenses at a Glance

It is beneficial to briefly review the most important individual licenses commonly encountered in game and plugin development practice:

Summary of the basics: The various license types define the conditions under which code may be used. Developers should clarify early on which license an open source component has and what this concretely implies. This includes determining whether using it necessitates freely licensing their own code (copyleft) or if a simple notice (permissive) suffices. This question is central to further use in proprietary or commercial projects.

License Compatibility in Practice

When multiple components with differing licenses are combined in a software project, the issue of license compatibility arises. This refers to whether two (or more) sets of license conditions are compatible with each other. Compatibility allows the code to be used and distributed together without violating any of the licenses involved.

What Does License Compatibility Mean?

Every open source license mandates certain obligations. If you have software A under license X and software B under license Y, and you wish to combine A and B in a project (e.g., integrating library A into program B), their license conditions must match. Licenses are incompatible if one contains conditions that contradict those of another, or make it impossible to fulfill both simultaneously. They are compatible if both sets of obligations can be satisfied through a specific licensing path.

For example, code under an MIT license and code under a GPL license can be used together in a project. However, this is only possible if the entire resulting product is then placed under the GPL upon distribution. Why? The MIT license permits redistribution under any conditions (provided the copyright notice remains). It is therefore GPL-compatible because it lacks clauses that contradict the GPL. Thus, you can incorporate MIT code into a GPL project, but the final result must be licensed under the GPL, as the GPL mandates this for the entire work.

Conversely, integrating GPL code into an MIT-licensed project and continuing to publish it under MIT would not be permissible. This action would violate the obligations of the GPL, which requires the entire work to be under GPL, a condition MIT does not enforce. In such a scenario, practically everything must operate under the GPL.

GPL and Permissive Licenses

The GPL is known for its strictness regarding its "partners." It is compatible with many permissive licenses, but certainly not all. Licenses that are GPL-compatible include, for example:

In general: combining permissive → copyleft is usually possible. This means permissive code can be incorporated into a copyleft project, and the result becomes copyleft. Conversely, 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 manifest in several ways:

In short: Before integrating an open source component, always check its license for compatibility with the overall project license. Many organizations provide a license compatibility table; for example, the Free Software Foundation lists MIT, BSD, zlib, etc., as GPL-compatible. However, the former Apple Public Source License was not.

For a developer's daily work, the following rule of thumb often suffices: use permissive licenses if possible to avoid compatibility issues. If GPL is already in your project, ensure any additional code is at least GPL-compatible (or also GPL). If you aim to remain proprietary, avoid GPL code, as it would compel you to relinquish your proprietary status.

Accumulation of License Obligations

License compatibility does not imply that you can choose which license applies. In a combined product, you must comply with all applicable license obligations. The final product is often offered under a single license (e.g., entirely GPL if open source, or your own proprietary EULA if closed). Nevertheless, the conditions of all integrated open source components must be simultaneously observed. In practice, this means:

A typical example of a cumulative obligation in a commercial product involves a computer game. This game might use five open source libraries: one under MIT, one under Apache, two under BSD, and one under zlib. All are permissive, so the game development team does not need to disclose its own code. However, each license requires its text to be present somewhere in the package.

Consequently, the game studio inserts a LICENSES file in the game folder containing the texts of all five licenses and the copyright of the respective developers. This fulfills the license conditions, allowing the proprietary game to be legally distributed with these components.

WordPress Plugins and License Compatibility

A specific situation familiar to many plugin developers concerns WordPress plugins and themes. WordPress itself is licensed under GPLv2. However, WordPress's creators (Automattic) consider every plugin and theme that uses or is based on WordPress to be a derivative of WordPress. This view implies that every plugin must therefore be licensed in a GPL-compatible manner—ideally, also under GPL.

Indeed, the official directories, such as the WordPress Plugin Repository, and marketplaces require that uploaded extensions be licensed under GPLv2 (or a compatible license). Incompatible licenses, such as purely proprietary EULAs or certain restricted licenses, will prevent the plugin from being included in these platforms.

Legally, whether a plugin constitutes a derivative work of the main software remains a complex issue without conclusive clarification. Arguments suggest that merely using defined plugin interfaces (hooks, APIs) does not amount to an adaptation under copyright law, but rather a permitted coupling. However, the boundaries are blurred: if a plugin directly copies WordPress code or loads it into memory (which consistently occurs when calling functions of WordPress core libraries), it can readily be seen as an adaptation or at least a dependent connection.

Prudent developers therefore adhere to the GPL to avoid conflicts with WordPress's license. While, to our knowledge, no lawsuit has yet occurred in Germany by WordPress authors against a plugin developer for license violation, community rules effectively enforce compliance. Those who do not license in accordance with the GPL are excluded from important distribution channels and risk damage to their image.

An interesting practical case involved a legal dispute concerning a WordPress theme before the Higher Regional Court of Karlsruhe (judgment of 27.01.2021, ref. 6 U 60/20). In this instance, a developer had a commercial theme based on WordPress created and distributed without disclosing its source code. A third party (presumably a competitor or open source activist) then demanded the theme's code disclosure, citing the GPL.

The Higher Regional Court of Karlsruhe clarified that, while the GPL mandates the developer to disclose the code upon distribution, failure to do so does not grant anyone else the right to simply publish this code. The theme's exclusive rights holder (the developer) does not automatically forfeit copyright to their own contributions due to a GPL violation. In other words, the GPL does not create general usage rights for anyone to derived software if the developer does not comply with the license conditions.

Rather, the consequence of an infringement is that no one may lawfully distribute the work—neither the infringer nor third parties. Although this ruling addressed rights management (the theme developer could prevent a third party from putting his theme on GitHub, even if it would be subject to GPL), it also implicitly highlights the license compatibility issue: WordPress and a non-GPL theme are effectively 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 it on their own authority.

Conclusion on Compatibility

Especially in larger game development projects, dozens of third-party components often converge. These might include a physics engine, audio libraries, network libraries, etc., potentially with different licenses. Before integration, it is crucial to verify that all licenses are compatible with each other and with the planned end product.

If in doubt, consider finding an alternative with a more compatible license for a component with strict licensing. Numerous tools and overviews are available to help clarify these questions. License compatibility is therefore both a technical and a legal issue: technically, components must harmonize; legally, their licenses must. Only when both aspects are correct can the project be published without concern.

Effects of Copyleft Licenses on Proprietary Software

A central focus of this article is the impact of copyleft (especially GPL) on proprietary software. This raises the question: What happens if a developer or company, which does not intend to disclose its own program (like 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 frequently mentioned in this context. This refers to the scenario where a component under GPL is integrated into a larger software product. According to GPL conditions, the license "infects" the entire product, requiring it to be distributed only under GPL. Like a virus that infects all cells, the license condition spreads to the entire work.

The consequence: The previously proprietary project would have to disclose its source code and place it under GPL if it is to be distributed. From a company's perspective, this means potential disclosure of trade secrets and loss of exclusivity over the software.

In legal terms, the GPL is said to contain a condition subsequent. The granted rights of use are subject to the condition that you comply with the license terms when distributing the software. If a license violation occurs (e.g., by not disclosing your source code), the license automatically expires (as explicitly stated in section 4 GPLv2 or section 8 GPLv3). Consequently, the authorization to further distribute the work is lost. Distributing it anyway constitutes a copyright infringement.

The developer thus finds themselves in a lose-lose situation: either they fulfill the conditions (i.e., publish their code openly, which they did not want to do), or they must forgo distribution (i.e., remove the feature/code or withhold the product). This predicament is precisely what is described as "viral."

From the perspective 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 perspective, however, it is "contagious" and risky. Therefore, many companies take great care to avoid including GPL or similarly licensed components in their proprietary products.

Scope of Contagion: What is Considered a Derivative Work?

A crucial question is the extent of the copyleft effect. It is not always clear whether software A, which interacts with B, is truly considered an "adaptation" or derivative work of B. Copyright law (in particular § 23 UrhG) stipulates that adaptations of a work may only be published with the author's consent. The GPL grants this consent subject to conditions. However, if you can argue that your software is not an adaptation of the GPL work, then the obligation does not apply.

In practice, several differentiations are discussed:

Examples from Game Development

There are several well-known cases and best practices for managing copyleft in game development:

Strategies for Dealing with Copyleft

If you, as a developer, are considering using a valuable GPL-licensed component, several strategies are available:

  1. Search for alternatives: Often, functionally similar libraries with a more liberal license exist. While the search may take time, it is worthwhile to avoid future conflicts.
  2. Isolate: If a GPL component is irreplaceable (due to unique functionality), you might try integrating it in a way that avoids creating a derived work. For example, run it in a separate process and communicate with the main program via defined protocols. This allows the main software to remain proprietary, while the GPL component is supplied as an independent tool, including its source code to fulfill GPL requirements. An example would be a level generator bundled with the game as an independent CLI program (GPL); the game only calls "LevelGenerator.exe" externally. However, this is only feasible for specific use cases. It also relies on the distinction between separate programs rather than a single derived work.
  3. Contribute and publish: Sometimes a project consciously decides to become open source itself, particularly among indie developers. In such cases, GPL code can be used without objection; the entire game, including its source, is simply published. While this might seem commercially unattractive, open development models, potentially supplemented by other revenue streams like donations or services, can be successful. However, this is rarely an option for companies aiming for traditional license revenue.
  4. Obtain license advice: When in doubt, consult a legal advisor. Specialists in IT law/copyright law can help analyze whether a particular integration method is permissible, what obligations would arise, and if any clauses allow special permissions from the licensor. The consultant will also clarify whether copyright protection even applies, for instance, if only tiny code snippets lacking creative originality have been adopted. However, for software, this is rarely the case; virtually any non-trivial copied code enjoys protection.

To summarize: Copyleft licenses like the GPL significantly impact proprietary software by triggering source code disclosure requirements. Developers must understand this impact and factor it into design and technology decisions. Large companies often have strict guidelines, such as an internal license blacklist/whitelist system. In small development teams, the lead developer or CTO is responsible for monitoring the licenses of all tools used. Underestimating the viral effect could, in the worst case, force your own software to operate under conditions contrary to its business strategy.

Risks and Legal Consequences of License Violations

What are the repercussions of failing to comply with the terms of an open source license? This section examines the legal risks, ranging from warnings and legal proceedings to potential claims for damages. It focuses specifically on German law (UrhG) and highlights some well-known cases.

License Infringement = Copyright Infringement

First and foremost, it must be clear: an open source license violation is not a trivial offense. Legally, it constitutes a copyright violation. This is because the right to use third-party code derives solely from the license. If you do not adhere to 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 infringes upon the exclusive rights of the copyright holder, such as reproduction and distribution rights under Section 69c UrhG for software.

In Germany, a clear line of case law has emerged on this matter. 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 the right to use and distribute exists only 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 (courts have found it not surprising or unreasonable according to § 307 BGB). It does not circumvent § 31 UrhG but rather utilizes its framework. So, what are the potential threats of such an infringement? In civil law, typically:

Beyond civil law consequences, criminal law is also theoretically relevant. Unauthorized use of copyrighted works can be punishable under Section 106 UrhG, and even more severely for commercial use (Section 108a UrhG). In practice, however, criminal charges for open source license infringements are rarely filed. The matter is usually resolved between the parties under civil law, especially since infringers are typically companies and the injured parties are developers or foundations primarily interested in license compliance rather than criminal prosecution.

Relevant Case Law in Germany

The enforcement of open source licenses in German courts has established several important precedents. Here are some of the most significant decisions and cases:

In summary: German courts support open source licenses. Anyone who believes that no one would seriously sue for such "free" licenses is mistaken. The courts recognize license terms as contractual conditions and treat violations as copyright infringements, resulting in the aforementioned claims. At the same time, they acknowledge that this involves free software, so extreme fines are rare. The main instrument is injunctive relief, ensuring the open availability of the code or discontinuing its use.

Practical Consequences for Developers and Companies

What do these legal risks mean concretely for the daily operations of a development team or a company?

Overall, the risks of non-compliance with open source licenses are real and, crucially, business-critical. They can paralyze projects and strain contractual relationships. The good news is that all of this is avoidable if licenses are handled correctly from the outset. Using open source is not inherently dangerous; you merely need to understand and adhere to the "rules of the game." Then, risk transforms into significant benefit.

Contractual Aspects When Using Open Source

In addition to direct copyright issues, contractual regulations also play a significant role in the use of open source in software development contracts. This section examines how open source aspects should be incorporated into contracts, for example, between client and contractor, employer and employee developer, or software provider and customer. Key terms include integration clauses, testing obligations, and due diligence clauses, as well as topics such as warranty, liability, and internal guidelines.

Provisions in Software Development Contracts

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

Typical clauses in this context include:

Audit Obligations and Compliance Processes

Verification obligations can be stipulated in contracts or internal guidelines. Their purpose is to ensure the correct handling of open source licenses.

Warranty and Liability for Open Source Use

Let's assume a developer delivers software to a customer, and it later emerges 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:

To summarize: when using open source, clear contractual provisions should be established to protect all parties. The developer/supplier wants to know what they are permitted to do, and to avoid accusations of illegal actions when their conduct was permissible. The client, conversely, seeks assurance that the product does not contain a "license bomb" that could explode later. Well-drafted contracts and transparent communication about the OSS used foster trust and prevent disputes.

Due Diligence for M&A and Transactions

Another important area is due diligence in company takeovers and investments. When an investor plans to acquire a software development company, they naturally scrutinize its technology. It is now standard practice to also examine open source compliance. Why?

Imagine investor X intends to buy a game studio with a successful proprietary game. If, after the acquisition, it turns out that this game contains unobserved GPL code, the new owner might be compelled to publish the source code or halt distribution until the issue is resolved. This could drastically reduce the value of the entire investment. For this reason, various checks (due diligence) are performed before a purchase agreement is finalized:

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

Even if a sale isn't contemplated, partnerships and distribution licenses can trigger similar assessments. For instance, a large publisher wanting to sign an indie studio might include a clause in the publishing agreement: "The developer warrants that the game does not contain any open source software that impairs the publisher's exploitation rights. The developer shall disclose all open source components to the publisher." This is essentially due diligence by the publisher before investing millions in marketing the game.

Documentation and Dissemination of License Information

A practical yet contract-related topic is passing on license information to end-users. Many open source licenses not only require developers to comply but also stipulate that end users be informed about certain aspects. For example, the GPL mandates that every recipient of the software also receives the license terms and is informed of their rights (e.g., the right to request source code). Similarly, Apache/MIT require the license text to be included in documentation, which must ultimately reach the end-user.

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

Dealing with Copyleft in Contracts

It bears repeating: Copyleft components, such as GPL-licensed elements, must be handled very consciously and transparently within a contract. If the client agrees—perhaps because no alternative exists and they are prepared to distribute the code openly—then the contract should precisely state how this disclosure will be made and that the client is aware of this. It may be necessary to regulate who processes source code requests later, whether 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 they do, perhaps hoping it goes unnoticed, they are treading on very thin ice. In addition to potential legal action from the OSS author, they also risk a breach of contract with the customer.

In quotations, it can be helpful to state, "We use the following open source tools..." so the customer is informed. Transparency fosters trust and reduces future disputes.

Example from Practice

Consider an agency developing a web-based game for a client. The agency wishes to use a specific JavaScript framework that is under GPL. However, the client wants to keep the game exclusive and its code confidential. Unable to find a comparable alternative, the agency proposes using the framework but operating it separately as a backend service. They agree in the contract that the framework will run on a separate server, and its code, along with the GPL license, will be handed over to the customer, while the actual game remains decoupled. It is also stipulated that the customer consciously agrees to this GPL use and will release the source code of the framework component to third parties upon request. This constructed example illustrates how it is possible to work with copyleft when necessary, provided it is properly structured 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 will specifically discuss plugins and development for platforms, as this target group was particularly mentioned. Plugin developers often operate within an ecosystem that has its own licensing rules. They must account for both platform policies and OSS licenses.

WordPress and GPL – An Unavoidable Connection

WordPress, as a content management system, is a prime example where the platform's license influences its plugins. WordPress is licensed under GPLv2 (with the additional clause "or higher," which in case of doubt refers to GPLv2, as WP has not yet officially transitioned to GPLv3). The WordPress Foundation has explicitly stated that it considers plugins and themes to be derivatives. In practical terms, this means:

Shopify and Proprietary Platforms

Shopify presents a different scenario. It is a closed SaaS platform for e-commerce with proprietary code. However, developers can create apps or themes for Shopify. The legal conditions here stem from two sources: Shopify's own contracts (partner program, API license terms, etc.) and the potential use of OSS within the app.

In short for Shopify developers: While there is more platform freedom to remain proprietary, the responsibility for used open source building blocks rests entirely with the app developer. They must check just as meticulously: What license does each integrated library have? Do I fulfill its requirements (e.g., including copyright notices in minified JS)? What happens if I provide the app to a customer for self-hosting? And crucially: Is anything incompatible with my closed-source app (e.g., GPL)? If so, replace it urgently.

Other Platforms and Plugins

Practical Recommendations for Developers and Companies

After reviewing the theory and potential pitfalls, here are some practical tips for software developers—whether in game development, plugin projects, or general software development—to use open source in a legally compliant way without sacrificing its creative and productive benefits:

  1. Knowledge and awareness: Familiarize yourself with the basics of important licenses. Not every developer needs to be a lawyer, but a fundamental understanding of what GPL versus MIT means is essential. Many companies provide brief training for their developers on this. It helps if terms like "copyleft" or "GPL-compatible" are not foreign concepts. Newly hired developers or freelancers, in particular, should be briefed to prevent inadvertently contributing problematic code.
  2. License selection before use: Before incorporating an open source library into your project, check the license. Read the license text (at least skim it) or review summaries. Pay attention to keywords: "GNU GPL" should trigger an alert, prompting a closer look to see if it fits the project. "MIT / BSD / Apache" licenses are usually less critical, but still make a note. If uncertain about license compatibility, consult colleagues or, if necessary, legal experts. Online forums (e.g., StackExchange "Open Source") often discuss such questions.
  3. Document all third-party components: Maintain a list (e.g., in the project's README or a dedicated document) of all external libraries, snippets, etc., that are not proprietary. Record the version and license. This simplifies the creation of the "third-party license" file at the end and ensures nothing is overlooked. It also helps prevent issues if a component is accidentally updated later, its license has changed, and no one notices—having it documented will make you aware.
  4. Comply with license conditions immediately: It is best to ensure that obligations are implemented during development. For example, if you know you are using MIT licenses, integrate an "Open Source Credits" section into the "About" window or help menu, listing names and license texts. Do not scramble to 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 include steps to automatically generate an OSS license overview; utilize such automation.
  5. Choose proven OSS with community support: This is more of a strategic tip. Frequently used open source projects typically have well-documented license information and established practices. An exotic project with a self-made license introduces more uncertainty. Therefore, it is preferable to use popular libraries with known licenses, which reduces the likelihood of encountering unexpected clauses. Moreover, popular projects generally aim for broad usability, tending towards permissive or at least LGPL licenses.
  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 author attribution. Small code pieces from it—some argue this is de minimis (minor) and not protectable, but this should not be relied upon. Better practice: if you adopt something significant, ask the author or at least mention it in code comments. For GitHub Gists or projects without a license, All Rights Reserved applies by default. In other words, refrain from using it or request a license, because without explicit permission, you have no right of use! In short: do not mindlessly copy code from the internet simply because it's "there." Always clarify its license.
  7. Set a good example: If you publish your own code, whether a small plugin on GitHub or a contribution to a library, choose a clear license and include a LICENSE file. This contributes to the general culture where code is only available with a license. It also makes it easier for others to use your code in their projects if needed. Plugin developers on GitHub, in particular, should not forget to license their repository; otherwise, no one else would actually be permitted to use it.
  8. Use open source compliance tools: For larger projects or companies, it is beneficial to use tools such as FOSSID, Black Duck, FOSSA, ORT, etc. These tools scan code and generate license reports. They also identify code parts that might originate from OSS (via pattern matching), even if there is no explicit indication. This can reveal, for example, that a block of code was copied from GPL software years ago. While such tools are not 100% error-free, they are immensely helpful. There are also open source tools like the OSS Review Toolkit or simple scripts integrated with npm, pip, or maven to list dependent libraries and their licenses.
  9. Maintain a license blacklist/whitelist: Internally, define which licenses can be used without issues and which require permission or are prohibited. 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 guides developers. Ensure these lists are up-to-date and provide reasons, so developers understand why, for instance, GPL is on the red list (due to its obligations).
  10. Seek legal advice in case of uncertainty: The subject matter can be complex, especially in special cases like combination issues, stricter licenses, or self-license changes. There is no shame in consulting an IT lawyer. Many law firms, particularly in IT and media law, have experience with open source. The costs are manageable compared to the potential damage caused by a mistake. Especially during company takeovers, large software rollouts, or when a dispute is imminent, engaging professionals is advisable.
  11. Stay informed: Licenses continuously evolve, new rulings emerge, and new types of licenses appear (e.g., MongoDB's Server-Side Public License, sometimes rejected as "too aggressive"). For a developer, occasionally reading blogs like Heise Developer, Kanzlei-News, or itmedialaw is sufficient to stay abreast of relevant developments.

These measures can significantly reduce risk. Many companies, from small startups to large corporations, have successfully implemented these practices. They use hundreds of open source components without encountering legal traps. It requires discipline and knowledge, but the benefits of using open source—cost savings, rapid development, avoiding reinvention of the wheel—justify the effort.

Conclusion

Open source is ubiquitous and essential in the IT industry, particularly in software development. For game developers, plugin developers, and software companies, the use of open source components offers immense opportunities, ranging from accelerated development to community-driven innovation. Simultaneously, the legal framework must not be overlooked.

From a copyright perspective, open source code remains protected intellectual property, and its use is subject to conditions. In IT law and media law, a distinct field of compliance has evolved around open source, now an integral part of professional practice.

The most important findings from a practical perspective are:

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. This way, the advantages of the open source world can be harnessed without unpleasant legal surprises. At 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.