How to Open Source your Project?

26.02.2021

Dr. Andreas Kotulla

Open Source

Dr. Andreas Kotulla

Open Source (OSS) is everywhere. Nowadays, hardly any project can be carried out economically if existing software packages are not reused. This is advantageous for software development: The usage of Open Source increases the speed of development, reduces costs, and very often is of higher quality then similar code written in-house due to extensive collaboration of many people.

Open Source usage is frequently discussed. This article deals with the important question of what has to be considered when self-created software is to be released as open source. The comments are based on best practices and are not a legal advice.

Why make your code Open Source?
There are several reasons why companies or developers publish their own code as Open Source: Open Source-Code is a good way to build the brand and awareness for the company or a developer. If a project becomes popular, a community of likeminded developers will take on a lot of work which may result in faster development progress and much better code quality. With a higher number of developers, more use cases are being explored, resulting in a more robust code being created. Experienced developers are often interested in contributing to Open Source projects for their own portfolio and many companies have now developed their own business model around Open Source.

The popularity and success of Open Source project depends on many factors. One may be a big community, however licensing can be one of the defining factors. If individuals and organizations cannot easily use and re-distribute (often commercially) Open Source code – it may become a major obstacle and prevent such project from wider adoption. In order to simplify the use of your Open Source project for third parties, some important points must be considered.

Choose the right distribution model and license
It will be easier for the end users of your Open Source project to adopt your code if it is accompanied with a well known OSS license that clearly defines obligations under which the software can be used, and modified, distributed and combined with other work.

Before choosing the license you should choose the distribution model for your software. E.g. nowadays most of the projects are distributed over network (SaaS) but other models are also applicable e.g. physical distribution on customer end (e.g. mobile apps downloaded on phones).

Once a distribution model has been defined, choosing the right license is relatively easy. Basically your choice is between permissive and restrictive licenses. A permissive license has a minimal set of obligations on the end user. E.g. BSD or MIT are attribution style licenses which essentially require end users to maintain your copyright statement (hence they are referred to as attribution).

Restrictive licenses in contrast oblige end users to perform a lot more things, and on top of this distribute derived code under the same license. The latter obligation is often is reflected in the name of the license – with the use of the words “Public License”.

You should remember that if you yourself plan to use someone elses code you should never relicense it. I.e. you cannot pick restrictively licensed code and make it permissive.

To select a suitable license for your project, you may want to find answers to the following questions (based on recommendations by the Open Source initiative OSI):

  • Should my copyright and/or license be preserved by whoever uses my code?
  • Should the end user provide details on any changes upon modification of my code?
  • Should the end user also make modifications (patches) to my code public?
  • Should there be restrictions on private or commercial use?
  • Do I want to be held liable for damages?
  • Should there be an impact on patents or other intellectual property for the end user (maybe you would like them to return something back to the community in return for using code developed by you)?

Websites such as choosealicense.com oder tldrlegal.com can offer some additional advice in choosing the right license. The selected license should be included with the project in a copying- or license file. Copyrights are best listed individually in each file.

Know your authors
The software in the first instance belongs to the author, this can be, for example, an individual, commercial or non-commercial organization. Knowing the copyright holder of a software is especially important for companies, because then the rights of use can be clarified with the copyright holder. To clearly identify the author in the software, a copyright notice is used. Copyright notices are a way to make it clear that you have to be consulted in how the code you create is used. If the notice is missing, it will be difficult for users to identify who created the software and it will be impossible to obtain permission to use it in case of doubt. A missing copyright can result in companies not allowing to use a certain Open Source product. Hence you should carefully mark all your files with appropriate copyright holders. Also, when your project is open sourced, and some community members have started contributing into your project you should establish some way to carefully attribute everyone’s contributions.

Create Bill of Materials
Finally, it is important to list all other Open Source code used in your project. This can be a difficult task to accomplish, especially if creators of OSS-packages used, have not taken care of that themselves. The creation of a BoM is a time consuming and daunting task which usually is not feasible to perform manually. It is advisable to create a BoM with a tool that automatically finds licenses and copyrights from the code and compiles them accordingly.

To re-cap before open-sourcing your project

  1. Carefully choose distribution model of your code and license that fits that model (a well known OSS license is best)
  2. Establish all Copyright holders in the code you’re Open-Sourcing making sure you do not infringe anyones copyright
  3. Create bill of materials of all third-party code in your project

Bitsea has over a decade of experience offering organisations advice, consultation and auditing services in areas of Open Source Governance, Code Quality and Application Security. If you want to open source your project or consider using open source in your organisation we are happy to provide you our help and answer your questions.

Good luck with open sourcing!

Eigene Projekte als Open-Source veröffentlichen

26.02.2021

Dr. Andreas Kotulla

Open Source

Dr. Andreas Kotulla

Warum Open Source

Open Source (OSS) ist überall. Kaum ein Projekt kommt ohne bestehende Softwarepakete aus. Die Wiederverwendung spart Zeit, senkt Kosten und verbessert die Qualität.

Die Frage der Nutzung von Open Source wird vielfältig diskutiert. Heute soll hier hingegen dargelegt werden was zu beachten ist, wenn selbsterstellte Software als Open Source herausgegeben werden soll. Die Ausführungen beruhen auf bewährten Praktiken und sind nicht als Rechtsberatung zu verstehen.

Es gibt eine ganze Reihe von Gründen, warum Unternehmen oder Entwickler ihren eigenen Code als Open Source veröffentlichen wollen: Open-Source-Code kann beispielsweise gute Werbung für das Unternehmen oder den Entwickler sein. Wird das Projekt populärer, können externe Open-Source-Entwickler viel Arbeit abnehmen. Das spart Kosten und eigene Entwicklungsarbeit. Bei erhöhter Entwickler-Anzahl werden meist mehr Anwendungsfälle untersucht, was zu einem robusteren Code führt. Erfahrene Entwickler haben oft Interesse, für ihr Portfolio an Open-Source-Projekten mitzuwirken. Deswegen haben viele Firmen mittlerweile ein eigenes Geschäftsmodel um Open Source entwickelt.

Erfolgsfaktoren für Open Source Projekte

Damit ein Open-Source-Projekt erfolgreich wird, muss es auch genutz werden. Dazu sollte das System natürlich einerseits etwas Sinnvolles bewerkstelligen. Um andererseits die Nutzung für Dritte aber auch rechtlich sicher zu gestalten, gilt es einige wichtige Punkte zu beachten.

1. Urheberrecht klären

Software gehört dem Urheber – einer Person, einem Unternehmen oder einer Organisation. Nur mit klaren Nutzungsrechten bleibt die Kontrolle erhalten. Um den Urheber in der Software eindeutig zu kennzeichnen, dient ein Copyright-Vermerk. Copyright-Vermerke sind ein Weg, um deutlich zu machen, dass Sie ein Mitspracherecht bei der Verwendung des von Ihnen erstellten Codes haben möchten. Fehlt der Vermerk, wird es für Nutzer schwierig festzustellen, wer die Software erstellt hat und es ist im Zweifelsfall unmöglich, eine Nutzungserlaubnis einzuholen. Ein fehlendes Copyright kann in Unternehmen dazu führen, dass ein bestimmtes Open-Source-Produkt nicht genutzt werden darf.

2. Die richtige Lizenz wählen

Einfacher wird es für die Nutzer, wenn dem OSS-Projekt weiterhin eine Lizenz beiliegt, welche klar regelt, wie und unter welchen Bedingungen die Software genutzt und geändert werden darf, wie sie weitergegeben werden darf, und wie die Software mit anderen Werken kombiniert werden darf. Die Open Source Initiative (OSI) hat hierzu eine Reihe von Kriterien erstellt, was in einer Lizenz geregelt werden sollte. Es gibt eine Vielzahl von Lizenzvorlagen, aus welchen eine passende ausgewählt werden kann.

Grundsätzlich gibt es zwei Lizenz-Typen:

  • Permissive Lizenzen (BSD, MIT, Apache): Erlauben fast uneingeschränkte Nutzung.
  • Copyleft-Lizenzen (GPL, LGPL, AGPL): Verpflichten zur Weitergabe unter derselben Lizenz.

Die richtige Lizenz hängt von den eigenen Zielen ab. Hilfreiche Fragen:

  • Sollen Copyright und Lizenz bei der Nutzung erhalten bleiben?
  • Muss der Nutzer Änderungen dokumentieren?
  • Soll der Nutzer die Anpassungen wieder als FOSS herausgeben müssen?
  • Soll es Einschränkungen bezüglich privater oder kommerzieller Nutzung geben?
  • Möchte man für Schäden haftbar gemacht werden können?
  • Soll es Auswirkung auf Patente des Nutzers geben?

Basierend auf den Antworten lässt sich dann leicht eine passende Lizenz finden. Hier hilft zum Beispiel auch die Webseite choosealicense.com oder tldrlegal.com. Die ausgewählte Lizenz sollte dem Projekt in einer COPYING- oder LICENSE-Datei beigelegt werden. Urheber werden am besten in jeder Datei einzeln aufgeführt.

Genutzte Open Source Komponente dokumentieren

Viele Projekte nutzen bestehende Open-Source-Komponenten. Diese müssen mit Lizenz und Urheber aufgelistet werden. Dies ist oftmals aufwändig zu bestimmen, vor allem wenn die Ersteller der genutzten OSS-Pakete nicht selbst auf oben aufgeführte Hinweise geachtet haben. Die Erstellung der genutzten Komponentenliste wird schnell umfangreich und übersteigt die Fähigkeit manueller Arbeit, wenn Abhängigkeiten berücksichtig werden müssen, die beispielsweise über einen Repository-Manager eingebunden werden. Automatische Tools erleichtern die Erstellung einer vollständigen Liste, welche Lizenzen und Copyrights automatisch aus dem Code auslesen und passend zusammenstellen.

Fazit

Zusammengefasst bietet Open Source viele Vorteile, erfordert aber klare Regeln. Mit einer passenden Lizenz und sauberer Dokumentation wird das eigene Projekt erfolgreich.

Viel Erfolg beim Open-Sourcen!

How to Open Source your Project?

26.02.2021

Dr. Andreas Kotulla

Open Source

Dr. Andreas Kotulla

Open Source (OSS) is everywhere. Nowadays, hardly any project can be carried out economically if existing software packages are not reused. This is advantageous for software development: The usage of Open Source increases the speed of development, reduces costs, and very often is of higher quality then similar code written in-house due to extensive collaboration of many people.

Open Source usage is frequently discussed. This article deals with the important question of what has to be considered when self-created software is to be released as open source. The comments are based on best practices and are not a legal advice.

Why make your code Open Source?
There are several reasons why companies or developers publish their own code as Open Source: Open Source-Code is a good way to build the brand and awareness for the company or a developer. If a project becomes popular, a community of likeminded developers will take on a lot of work which may result in faster development progress and much better code quality. With a higher number of developers, more use cases are being explored, resulting in a more robust code being created. Experienced developers are often interested in contributing to Open Source projects for their own portfolio and many companies have now developed their own business model around Open Source.

The popularity and success of Open Source project depends on many factors. One may be a big community, however licensing can be one of the defining factors. If individuals and organizations cannot easily use and re-distribute (often commercially) Open Source code – it may become a major obstacle and prevent such project from wider adoption. In order to simplify the use of your Open Source project for third parties, some important points must be considered.

Choose the right distribution model and license
It will be easier for the end users of your Open Source project to adopt your code if it is accompanied with a well known OSS license that clearly defines obligations under which the software can be used, and modified, distributed and combined with other work.

Before choosing the license you should choose the distribution model for your software. E.g. nowadays most of the projects are distributed over network (SaaS) but other models are also applicable e.g. physical distribution on customer end (e.g. mobile apps downloaded on phones).

Once a distribution model has been defined, choosing the right license is relatively easy. Basically your choice is between permissive and restrictive licenses. A permissive license has a minimal set of obligations on the end user. E.g. BSD or MIT are attribution style licenses which essentially require end users to maintain your copyright statement (hence they are referred to as attribution).

Restrictive licenses in contrast oblige end users to perform a lot more things, and on top of this distribute derived code under the same license. The latter obligation is often is reflected in the name of the license – with the use of the words “Public License”.

You should remember that if you yourself plan to use someone elses code you should never relicense it. I.e. you cannot pick restrictively licensed code and make it permissive.

To select a suitable license for your project, you may want to find answers to the following questions (based on recommendations by the Open Source initiative OSI):

  • Should my copyright and/or license be preserved by whoever uses my code?
  • Should the end user provide details on any changes upon modification of my code?
  • Should the end user also make modifications (patches) to my code public?
  • Should there be restrictions on private or commercial use?
  • Do I want to be held liable for damages?
  • Should there be an impact on patents or other intellectual property for the end user (maybe you would like them to return something back to the community in return for using code developed by you)?

Websites such as choosealicense.com oder tldrlegal.com can offer some additional advice in choosing the right license. The selected license should be included with the project in a copying- or license file. Copyrights are best listed individually in each file.

Know your authors
The software in the first instance belongs to the author, this can be, for example, an individual, commercial or non-commercial organization. Knowing the copyright holder of a software is especially important for companies, because then the rights of use can be clarified with the copyright holder. To clearly identify the author in the software, a copyright notice is used. Copyright notices are a way to make it clear that you have to be consulted in how the code you create is used. If the notice is missing, it will be difficult for users to identify who created the software and it will be impossible to obtain permission to use it in case of doubt. A missing copyright can result in companies not allowing to use a certain Open Source product. Hence you should carefully mark all your files with appropriate copyright holders. Also, when your project is open sourced, and some community members have started contributing into your project you should establish some way to carefully attribute everyone’s contributions.

Create Bill of Materials
Finally, it is important to list all other Open Source code used in your project. This can be a difficult task to accomplish, especially if creators of OSS-packages used, have not taken care of that themselves. The creation of a BoM is a time consuming and daunting task which usually is not feasible to perform manually. It is advisable to create a BoM with a tool that automatically finds licenses and copyrights from the code and compiles them accordingly.

To re-cap before open-sourcing your project

  1. Carefully choose distribution model of your code and license that fits that model (a well known OSS license is best)
  2. Establish all Copyright holders in the code you’re Open-Sourcing making sure you do not infringe anyones copyright
  3. Create bill of materials of all third-party code in your project

Bitsea has over a decade of experience offering organisations advice, consultation and auditing services in areas of Open Source Governance, Code Quality and Application Security. If you want to open source your project or consider using open source in your organisation we are happy to provide you our help and answer your questions.

Good luck with open sourcing!