Freeware has copyright restrictions

Open Source Software Law: Large FAQ with lots of practical tips

Use, further development and distribution of software under Open Source License (OSS) are the trend. Legal uncertainties often go hand in hand. We address the most common legal questions about open source software in this FAQ.

1. What does Open Source Software (OSS) mean and what types are there?

The term “open source software” was developed in IT specialist circles; there is no legal definition. For software to be considered open source software according to the definition of the Open Source Initiative (OSI), the license must meet the following ten criteria:

  1. Free redistribution: The license must allow anyone to redistribute or offer the software. No license fee may be charged.
  2. Access to the source code: The source code of the program must be readily available to the user.
  3. Admissibility of further developments: The license must allow the further development of the program as well as the creation of own programs as well as their distribution under the same conditions as the original software.
  4. Allowable Restrictions on Distribution of Modifications: The license must allow the distribution of modifications of the original source code, but may require that the software is then given a different name and that the changes are documented.
  5. No discrimination against people or groups of people.
  6. No usage restriction: The use of the software may not be excluded for certain purposes.
  7. License must apply to everyone: The license must apply to everyone who receives the software. No special licenses may be granted.
  8. Product neutrality of the license: The license must not only be tailored to software, but must also apply equally to software developed from it.
  9. No restriction of other software: The license may not contain any provisions about other software.
  10. Technology neutrality: The license may not restrict the distribution of the software to a specific technology.

In the same breath with open source software becomes regular Free software called. The mother of the concept of Free Software, the Free Software Foundation (FSF), attaches importance to the fact that the terms are not congruent. At the same time, she admits that both terms cover almost the same software category. The term “open source” only describes the development methodology, while “free software” describes a social movement with an underlying (liberal) ideology.

Note: In practice, both terms are used synonymously. The descriptions in this article therefore relate to programs that are referred to as open source software as well as to free software. For the sake of readability, we only use the term “open source software”.


2. What are the main differences between open source licenses?

All open source licenses have the Granting a right of reproduction and processing together, which one mostly certain conditions or restrictionssubject. The individual licenses differ primarily with regard to the terms of use and the obligations that are imposed on the licensee to exercise the right of reproduction and processing.

The most important consideration is which one Requirements for the distribution of changed versions of the software or new software which was developed on the basis of open source software.

The different license models can best be differentiated according to whether the respective license has a so-called. Copyleft effect includes or not. The copyleft effect describes the licensee's obligation to issue the software as well as any processing under the same license conditions as open source software.

a. Licenses with strict copyleft effect

Licenses with a strict copyleft effect oblige the licensee to issue the software or any processing under the same license conditions as the original software as open source software.

b. Limited copyleft licenses

In the case of licenses with a limited copyleft effect, certain forms of further processing are excluded from the copyleft effect.

c. Interoperable copyleft licenses

On its joinup platform, the European Commission takes the view that the distinction between strict and restricted copyleft effects is only rarely legally relevant because it considers the extent of the viral effect to be significantly less. Therefore, some special features apply to the European Union Public License issued by the EU Commission (EUPL). This is also a copyleft license ( - Objectives). Nevertheless, in the opinion of the Commission, the viral effect does not apply to links (not even static) from other programs if these are made for the purpose of interoperability. The Commission therefore assigns the EUPL to a new category of "Interoperable Copyleft"Licenses.

d. Licenses without copyleft effect

Licenses without copyleft effect, also "Permissive Licenses"Called, grant the licensee all the freedoms of an open source license, but do not commit to any particular license type with regard to distribution. Therefore, the licensee can easily distribute modified versions as proprietary software.

e. Licenses with options or privileges

In addition to the license types mentioned, there are mixed forms of the above licenses, which are characterized by the fact that the licensee is given certain options for distributing further developments or that they grant the licensor special privileges with regard to further developments.

A detailed overview of all important open source licenses can be found at the Institute for Legal Issues in Free and Open Source Software (ifrOSS).

  • Examples of popular open source software: Linux, WordPress, Java, Joomla, Apache OpenOffice, Ubuntu.


3. What are the best known and most common OSS licenses?

According to a study, the MIT license is the most widely used Open source license without copyleft effect. Well-known examples under MIT license are about Ruby on Rails, Node.js and JQuery. By far the most projects on GitHub are also under MIT license. The MIT license is very permissive, it contains almost no restrictions. The MIT license conditions allow unrestricted use, processing and sub-licensing under any other license (OLG Karlsruhe, judgment of January 27, 2021, Az. 6 U 60/20). In particular, further developments of software under MIT license can be sold commercially as proprietary software without any problems without the source code having to be disclosed.

The best known and most used Open source license with copyleft effect is the current third version of the GNU General Public License (GPLv3) from the Free Software Foundation was developed as part of the GNU project. Any further development or redesign of GPL software may also only be redistributed under GPL conditions. Software that is licensed under the GPL can therefore generally not be used for profit, as the GPL only allows payment of a fee for the production of copies or special warranties and services. The FSF has the GNU Lesser General Public License (LGPL) also published a license version with a weaker copyleft effect, which in particular allows integration into proprietary software without the source code of the company's own additions having to be disclosed.


4. How do you differentiate OSS from other "free" license types?

The open source licenses presented here have certain similarities with other types of license. It is all the more important to make a careful delimitation:

  • Freeware: Just like open source software, freeware is available free of charge and may also be redistributed. Freeware is usually delivered without source code. Changes and further developments are prohibited.
  • Shareware: Shareware is ordinary proprietary software that (for marketing reasons) is offered free of charge in a test phase. In order to be able to continue using the software after the test phase has expired, the required remuneration must be paid. Shareware is also delivered without source code and must not be changed.
  • Public domain software: Public domain software describes a principle originating in the USA in which copyrights are completely renounced. Since a waiver of copyright is impossible under German law (Section 29 (1) UrhG), a public domain license in Germany is regarded as a simple right of use that allows unrestricted use of the software (see Marly, Handbuch Softwarerecht, Rn. 883 ff.).

To illustrate what has been said so far, we will use an example to show how one can deal with open source software that is offered under a) GPL V3 or b) CC BY license.


A company would like to use the software "OS", which makes it possible to clearly organize and link files on a computer. The company has several plans for how it intends to use the software:

  1. use: The software should be installed on your own PC and used there to organize your own files.
  2. To edit: The company wants to change the source code of "OS" ("Customizing") in order to adapt the functions to its own needs and then to use the software for its own purposes.
  3. Retransmission: The company wants to offer the edited and optimized version of the software on its website for third parties to download.

In the following we describe what the company has to observe legally, depending on whether "OS" is licensed under GPL V3 or CC BY:


GPL V3: The simple use of the software is in no way restricted by the GPL (No. 2 Paragraph 1 P. 2 GPL V3). Use here means loading the software into the main memory and running the source code. The company can use the program for itself and does not have to pay attention to anything else.

CC BY: The CC BY license also does not restrict the use of the software in any way.


GPL V3: The company is also not subject to any restrictions when processing the program (No. 2 Paragraph 2 GPL V3). It can modify the "OS" software as desired and then use it without restriction.

CC BY: Even after the CC BY license, the same applies as for licensing under GPL V3.


Differences become noticeable when distributing the software:

GPL V3: The conditions under which the company may offer the modified version of the software for download on its own website is regulated in No. 5 GPL V3. Thereafter, if a modified version of the software is distributed, the following conditions must be met:

  • Copyright notice: According to No. 5 in conjunction with No. 4 GPL V3, the modified software must contain a copyright notice on the author of the "OS" software.
  • Modification note: According to No. 5 letter a GPL V3, the modified software must contain a note stating that it was modified, by whom it was modified and when it was modified.
  • Note on licensing under GPL: According to No. 5 lit. b GPL V3, the modified software must contain a clear note that it is licensed under GPL V3.
  • Licensed under the GPL: Consequently, the modified software may only be licensed to third parties under GPL V3. In particular, each purchaser must therefore be given a copy of the GPL V3 license (No. 5 lit. c, No. 4 GPL V3).
  • Legal notices in the program: Not only during the purchase process, but also when using the program itself, the purchaser must be given information on the legal situation, provided that the user can interactively influence the current program. The company must therefore incorporate a menu item with legal information in its modified version.

CC BY: The CC BY license has slightly lower requirements for the redistribution of edited versions. If "OS" is licensed under CC BY, the company must comply with the following when distributing the modified version:

  • Copyright notice with attribution: The most important thing is that the licensor (= author of "OS") is identified by his name as the author of the modified "OS".
  • Note on CC BY: There must be a note that the original "OS" was licensed under CC BY, whereby the CC BY license conditions must be linked.
  • Notice of disclaimer: There must be a reference to the disclaimer according to the CC BY.
  • If possible, a link to the original software: If feasible, a URL or a hyperlink to the original software must be set, in our example to "OS".
  • Modification note: As with the GPL, the CC BY license must indicate that the company has changed the "OS" in its original form.
  • Difference to GPL: In contrast to GPL V3, CC BY has no copyleft effect Not required that the modified version is also licensed under CC BY.


5. What does the term “proprietary software” mean?

In the literature, the term of the proprietary software used. Proprietary software refers to software according to the FSF, the use, redistribution or modification of which is prohibited or severely restricted. Proprietary software is characterized, among other things, by the fact that its source code is not made accessible.

  • Examples: Microsoft Windows, McAfee, Apple iOS, Adobe Photoshop.


6. Can OSS be integrated into software without it becoming OSS?

The most important question for many companies is whether their own software, integrated into open source software or developed on the basis of open source software, can be sold as proprietary software without disclosing the source code or whether it will necessarily become open source software itself . The license conditions of the respective open source license are decisive. This depends largely on the copyleft effect, which has already been mentioned several times:

  • At Licenses without copyleft effect (so-called Permissive Licenses), the respective OSS can be integrated into your own product without it having to be sold under the OSS Open Source license. Attention: If the OSS license contains restrictions (typically the obligation to add a copyright notice and specification of the license provisions in the source text, possibly other requirements), these must be observed. Otherwise the right of use lapses with the consequence that injunctive relief and claims for damages are threatened.
  • At Licenses with strict copyleft effect Like the GPLv2, processing and duplication may only take place on the condition that the complete new source code is disclosed (see LG Hamburg, judgment of 14.06.2013, Az. 308 O 10/13 - FANTEC).
  • At Limited copyleft licenses or those with Choices and privileges the specific license terms must be checked on a case-by-case basis. The limitation of the copyleft effect is, for example, often that the source code of the own software parts does not have to be published.


7. What is the viral effect of licenses with a strict copyleft effect?

If the processed open source software is one with a strict copyleft effect, special attention must be paid to the so-called. viral effect be respected.

The viral effect denotes the risk that when open source software is integrated with a (strict) copyleft effect, even self-created software parts can only be sold as open source software and their source code has to be disclosed within the framework of the open source license (cf. LG Hamburg, judgment of 14.06.2013, Az. 308 O 10/13 - FANTEC). With the GPLv3, for example, the viral effect is anchored in § 5 lit. c of the GPLv3 license conditions. The term “viral” is based on the effect of the copyleft effect, which, like a virus, “infects” independently developed software parts. From the opposite point of view, there is sometimes also talk of an “immunizing effect” because the copyleft model protects source code from secrecy and exclusive rights.

Example of the viral effect: AVM As the manufacturer of the well-known FRITZ! Box routers, they put together various files for their firmware. Among them was the Linux kernel, which is licensed under the GPL. Because of the viral effect regulated in the GPL, the Berlin Regional Court ruled that AVM was obliged to submit its firmware to the GPL. AVM could therefore in particular not assert an injunction against a competing provider of WLAN routers who had edited the firmware of the FRITZBox manufacturer and used it himself (see LG Berlin, judgment of November 8, 2011, Az. 16 O 255/10).


8. When does the viral effect exceptionally not take effect?

The viral effect occurs only if the open source software is incorporated / integrated into your own software on. Such an integration does not exist if the programmer only has one Software development environment with an open source license for its software development.

Examples: JDeveloper; Eclipse

There is also no integration into your own software if an open source software component is only available as a independent subsystem is carried out, since their source code is not required for this (cf. Hoppen / Thalhofer in CR 2010, 275 ff.).

Example: JasperReports

But as soon as the The source code of the open source software is linked in some way to the own software the Free Software Foundation believes that the viral effect should take effect (see also: Intveen / Gennen / Karger, Software Law Handbook, § 16 Rn. 30). Nonetheless, in the legal literature it is often referred to Workarounds searched.

The European Commission is of the opinion that the viral effect does not work even if a link to an open source program is used Purposes of interoperability he follows. She justifies this with the fact that, according to recitals 10 and 15 of EU Directive 2009/24 / EC, the copyright to software is not infringed if it is only integrated for the purpose of creating interoperability with other programs. Therefore put the Linking software does not represent an act relevant to copyright, which is why the license conditions did not apply. Under this premise, the viral effect would also play no role in such cases. In support of its view, the Commission refers in particular to a judgment of the European Court of Justice of May 2nd, 2012 (Az. C-406/10), in which the European Court of Justice did not see any violation of copyright in the investigation of a third-party interoperability program.


9. Can you avoid the copyleft effect?

The viral effect is an undesirable consequence of integrating open source software into your own software. It is therefore not surprising that, in the absence of well-established case law, the legal literature is intensively looking for ways to use open source software with a copyleft effect without one's own software being “infected”.

These efforts have so far not been particularly successful. The most promising way to circumvent the copyleft effect should consist in not evaluating one's own software and the open source software as part of a whole. This must be ensured from two points of view (according to Intveen / Gennen / Karger / Völkel / Kremer, Handbook of Software Law, § 16 Rn. 31 et seq.):

  • Formal separation of open source software and own software: Open source software and your own software are allowed on the one hand not connected on the other hand they must spread separately , for example by separate download. Linking must be dynamic (and not static).
  • Content-functional independence: Both your own software and open source software must be able to be viewed as independent programs according to their function.

As a result, this approach would produce the effect of two independent programs that are brought together and complement each other in terms of their effects; but not as if a new unified “whole” was created. The extent to which the open source software can then still be profited is, of course, a different topic.

Danger: Whether the above approach produces the desired separation effect has not yet been judged. Because of this, there are uncertainties, especially since the Berlin Regional Court had indicated that it assumes a wide scope of the viral effect (LG Berlin, judgment of November 8, 2011, Az. 16 O 255/10 - Surf sitter)


10. Can the copyleft effect be avoided through software as a service (SaaS)?

Since software is increasingly no longer sold, but is offered in the form of Software as a Service (SaaS), it could be interesting to offer open source software (or your own software that was combined with open source software) as SaaS.

If the license conditions of the open source software used contain a (strict) copyleft effect, the question arises as to whether the viral effect occurs and the SaaS must be provided in accordance with the license conditions of the open source software, in particular whether the source code must be disclosed Has.

According to the prevailing view in the legal literature, the viral effect of the copyleft effect in SaaS is supposed to be Not to grab. In the performance of a software as a service, no distribution of the open source software according to the current license conditions can be seen, since the user does not receive a private copy of the software at the moment.

Danger: The viral effect only does not work if the SaaS provider has developed the software with the integrated open source software components itself. If the provider had commissioned the software from a third party, this already constitutes a distribution act in accordance with the license conditions, so that the copyleft effect and in particular the disclosure obligation apply (according to Intveen / Gennen / Karger / Völkel / Kremer, Handbuch des Softwareausrechts, § 16 Rn. 12; Hilber / Reintzsch in CR 2014, 697 ff.).

Hilber / Reintzsch emphasize that, in their opinion, the copyleft effect does not work, but there are doubts as to whether the license conditions of the GPL even allow the use of software as SaaS. The GPL does not expressly say anything about this. It is possible that this lack of theming could be fatal, since according to German copyright law the Transfer of purpose doctrine is to be observed (§ 31 Abs. 5 UrhG).

The Transfer of purpose doctrine denotes a principle of interpretation according to which the author grants his contractual partner rights of use in case of doubt only to the extent that the purpose of the contract absolutely requires. Conversely, in case of doubt, rights not mentioned and not absolutely necessary for the contract remain with the licensor.

This could mean here that the use of software for SaaS is not a permissible use and therefore a violation of the license conditions of the open source license (see Hilber / Reintzsch in CR 2014, 697 ff).

What at first seems like a promising variant has a high risk potential due to a lack of case law. The use of open source software with a copyleft effect in the context of SaaS is therefore currently not possible without risk.


11. What are the legal consequences of violating the terms of use?

- What are the rights holder's rights?

A violation of the license terms of the open source software constitutes a Copyright infringement The reason is that the rights to use open source software under the resolving condition (Section 158 (2) BGB) that the license provisions are not violated (cf. OLG Hamm, judgment of 13.06.2017, Az. 4 U 72/16). In this case the right of use of the user does not apply and the rights holder can assert claims for omission, information, damages and, if necessary, reimbursement of warning costs in accordance with §§ 97 ff. UrhG (see LG Hamburg, judgment of 14.06.2013, Az. 308 O 10/13).

Whether in the case of unlicensed use of open source products actually claims damages exist is controversial. The crux of the matter is the question of what damage can be seen, since open source software is offered free of charge. Here it is often objected that an exemption from the obligations of open source licenses - especially the strict copyleft - has an economic value that needs to be compensated.

In earlier years courts had Compensation for damages according to the principles of license analogy awarded (LG Bochum, judgment of 03.03.2016, Az. I-8 O 294/15; LG Hamburg, judgment of 14.06.2013, Az. 308 O 10/13).

In recent decisions Claims for damages, however, were rejected. That's how it went OLG Hammin the above decision assumes that a breach of the OS license conditions would trigger a claim for injunctive relief under Section 97 (1) UrhG, but that no compensation could be claimed.

The main considerations of the Düsseldorf Higher Regional Court from a judgment on the free licensing of several brands ("ÖKO-TEST") should also be transferable to open source cases. According to this, a claim for damages, regardless of the different calculation options (specific damage, license analogy, disclosure of the infringer's profit) always presupposes a loss of assets on the part of the injured party. However, if the injured party waives any commercial use of his exclusive right, the objective value of a license fee can only be set at zero. A calculation from the point of view of the surrender of the infringer's profit is also out of the question. This calculation method is based on the idea that if the respective injury had not occurred, the injured person would have realized a profit. This cannot be assumed for a rights holder who has renounced commercial exploitation. If the owner of a property right waives its monetary exploitation, the illegal use of the property right will not cause him any damage (see OLG Düsseldorf, judgment of November 19, 2020, Az.


- What requirements do users have?

If a software provider uses open source software in its products and gives it to users without informing them, there is a risk of problems in this relationship as well. The user has no idea that he is dealing with open source software. If the user violates the license conditions, the rights holder can also assert claims for omission, information, compensation and, if necessary, reimbursement of warning costs against the user in accordance with §§ 97 ff. UrhG. The user will then in turn stick to the provider and demand compensation from them.

Unauthorized use of open source elements (especially those with a copyleft effect) in software for a user can result in a Legal deficiency represent in the sense of § 435 BGB and Warranty claims of the user justify.

tip: As a provider of software with open source components, make sure to inform your customers about the use of the open source components. We recommend documenting the use of open source software when programming. If you have software developed externally, we advise you to regulate documentation obligations in the contract with regard to the use of open source software.


12. What do you have to consider if you want to license your own software as OSS?

Anyone who wants to make self-developed software available under an open source license must above all think about the desired license. In the first step, it is helpful to get a rough legal overview of the offer of your own software as an open source solution.

The copyright situation is always determined by the law of the country in which the copyright is asserted (so-called. Principle of territoriality). Therefore, the copyright to software in Germany is to be judged solely according to the German Copyright Act (UrhG), even if the software was programmed in another country. Conversely, software programmed in Germany is protected in France under French copyright law.

In Germany, software enjoys copyright protection according to §§ 2 Paragraph 1 No. 1, 69a UrhG, both the source program and the object program. What exactly this protection includes is regulated in §§ 69c, 69d UrhG: The rights holder has the exclusive right to duplicate, edit, distribute and publicly reproduce the software.

The copyright cannot simply be "filed" because this is not permitted according to § 29 sentence 2 UrhG (so-called. Indispensability of copyright; see Marly, Handbuch Softwarerechts, margin no. 883). However, an author can grant a simple right of use free of charge (Section 31 (2) UrhG) for everyone. This is even expressly stated in the so-called. Linux clause regulated in § 32 Abs. 3 S. 3 UrhG. This right does not have to be granted in full, but can be limited in terms of space, time or content in accordance with Section 31 (1) sentence 2 UrhG.

Based on this, the provision of one's own software is legally classified as follows: Basically, each user of the software made available free of charge creates a Donation Agreement (§ 516 BGB). Each user receives a simple right of use granted within the meaning of Section 31 (2) UrhG, although this is usually the case limited by certain terms of use is. The exact conditions of use (= the license conditions) become part of the contract as general terms and conditions, provided they are effectively included. The license conditions are then binding. With open source licenses, it is common to use a resolving condition (§ 158 Abs. 2 BGB) to be included in the contract. Violations then result in the contract becoming void and that The right of use does not apply retroactively.

It becomes difficult when it comes to choosing the right license for your own software. Here you have to weigh up the reason for making your own software available in order to then choose the license that best supports the achievement of the goal. The various options are varied and depend on the individual case. offers good assistance in finding the right open source license for your own product.


13. Can English license terms be used in Germany?

The license conditions are general terms and conditions. Their effectiveness is based on §§ 305 ff. BGB. Most of the licenses are in English language composed. True, for some licenses are online too German translations available (for example the open source license "General Public License", which has already been mentioned several times). However, it is expressly noted at the beginning of the translation that the English language versions are legally binding and the translations are only for better understanding.

This raises the question of whether English-language license conditions can even become part of a contract with German entrepreneurs or even consumers. Because of the legal technical vocabulary, there is concern in the legal literature that there is at least one in contracts with consumers (i.e. private individuals who do not act commercially) reasonable opportunity to take note could be missing (§ 305 Abs. 2 BGB).

Furthermore, in the legal literature also Doubts about the effectiveness of the content of the open source licenses voiced. The full disclaimer of liability under German law in accordance with Section 276, Paragraph 3 of the German Civil Code (BGB) is inadmissible, even if the license conditions only stipulate this “as far as permissible” (cf. Marly, Manual Software Law, Rn. 964 et seq.). In addition, the GPL in particular is viewed as not sufficiently clear and understandable, which would also lead to its ineffectiveness according to Section 307, Paragraph 1, Sentence 2 of the German Civil Code (cf. Marly, Handbuch Softwarerecht, Rn. 942).

Contrary to the concerns expressed in the literature, the German courts however, unanimously believed that the most famous Open source license "GPL" is effective for entrepreneurs in any case (in English!) can be included in the contract as general terms and conditions. This was first decided by the Munich Regional Court in 2004 (Munich Regional Court I, judgment of May 19, 2004, Az. 21 O 6123/04), later followed by other courts (expressly after examination: LG Halle, judgment of July 27, 2015, Az. 4 O 133/15; LG Frankfurt, judgment of September 6, 2006, Az. 2. 6 O 224/06; accepted without examination: LG Bochum, judgment of 03.03.2016, Az. I-8 O 294/15; LG Hannover, judgment of 21.07.2015, Az. 18 O 159/15). It remains to be seen whether this also applies to consumers.


14. What are the rights of an OSS developer?

Anyone who adds their own source code to open source software creates one own processingthat is protected like an independent work (§ 69c No. 2 S. 2 UrhG in conjunction with § 3 UrhG). Basically, the person working on a software can decide on the product of the processing like on a completely independently created work.

Note: The original software remains independently protected. The editor does not acquire any rights to the original software through editing.

If, on the other hand, open source software is combined with other components, a Compilation within the meaning of Section 4 (1) UrhG (see LG Berlin, judgment of November 8, 2011, Az. 16 O 255/10, where the FRITZBox manufacturer AVM the router's firmware was composed of numerous individual files; including the Linux kernel licensed under GPL).Like adaptations, collective works are also protected as independent works (cf. § 4 Paragraph 1 UrhG).

If, as is usual with open source projects, several programmers Working on the software often results in the result Co-authorship on the processed software (§ 8 UrhG). This is the case if every developer makes a (even if only small) creative contribution to the software (see BGH, judgment of 02.26.2009, Az. I ZR 142/06 - Crane houses) and the respective shares in the software cannot be used separately (Section 8 (1) UrhG).

It is not necessary that the contributions are made together or even at the same time, as long as they are in the common overall idea of ​​the software classify (see BGH, judgment of 03.03.2005, Az. I ZR 111/02 - Fash 2000). If, as an exception, individual software parts can be used independently of the rest of the software, there is no co-authorship. With regard to the software part, the programmer has sole copyright and can therefore generally deal with him as he likes. The entire software, however, is a work connection within the meaning of § 9 UrhG. The developers are through it Partner in a civil law company in the sense of §§ 705 ff. BGB (cf. Marly, Handbuch Softwarerechts, Rn. 925).

In principle, an author has every freedom to deal with his work as he wants. He is entitled to the entire range of rights of §§ 11 ff. UrhG. In fact, this freedom does not exist with open source software, at least not with open source licenses with a strict copyleft effect. Here the license conditions of the original open source software regulate how the editor may exercise his copyright. So it is not completely free in this regard. If he violates the terms of use, he faces disadvantageous legal consequences.


15. Can one enforce rights from an OSS alone?

If you are the sole developer of the open source software, you can also enforce rights from the OSS alone. However, sole authorship of a single person is rare with OSS.

If several people have contributed to the development of the software, it is crucial whether the various developers are in Co-authorship created a joint work (§ 8 UrhG) or own works to a Works connection (§ 9 UrhG) have merged.

- What do you have to consider with co-authorship?

If several developers have worked on an open source software, there is usually co-authorship within the meaning of § 8 UrhG. In the case of co-authorship, according to § 8 Paragraph 2 No. 3 UrhGbasically every co-author is entitled to take action against violations of the common copyright. However, a service can only be requested from all co-authors.

With this in mind, a individual authors only injunctive relief assert. In contrast, claims for information and damages can only be asserted jointly by all co-authors or by a single co-author if he can prove that the remaining co-authors have assigned their exploitation rights to him. This is the naming of all those involved in the project required, which is often almost impossible in practice (cf. OLG Düsseldorf, judgment of November 25, 2008, Az. I-20 U 72/06).

- What is to be considered with a factory connection?

If there is no co-authorship, but a work connection according to § 9 UrhG, a BGB society among the developers justified. According to §§ 709, 714 BGB you can only assert any claims jointly.


16. What should be observed when asserting a claim for injunctive relief due to a violation of the terms of use for a processed software?

For the assertion of a right to cease and desist, the general information on violations of the terms of use of open source software as well as the general rules for the assertion of cease and desist claims apply. In addition, please note:

The assertion of a claim for injunctive relief is basically already possible with the first breach of the license conditions, because this indicates a risk of repetition (see LG Halle, judgment of 07/27/2015, Az. 4 O 133/15).

Anyone who asserts a claim for injunctive relief and relies on his processor's copyright must explain in a sufficiently substantiated manner which parts of the software he has reworked and that precisely these parts are affected by the action (LG Hamburg, judgment of 08.07.2016, AZ. 310 O 89 / 15).


18. Tabular overview of legal obligations for popular OSS licenses

May the source code (unchanged) be reproduced, edited and distributed?YesYesYesYes
Does the OSS license have a viral effect?YesLimitedNoNo
Can the source code be distributed with proprietary software (e.g. as a program library)?NoYesYesYes
Do modifications to the software have to be disclosed?YesYesNoNo
Is a copyright notice required?YesYesYesYes
Do the OSS license conditions have to be attached or linked to them?YesYesYesYes


Note: This article was created with the assistance of our legal colleague Felix Wichert.