Freie Software wird über den offenen Zugang zum Quellcode, vor allem aber über die lizenzrechtlichen Eigenschaften definiert.
Nachfolgend beschreiben wir rein informatorisch unsere Praxis; eine irgendwie geartete Empfehlung, so vorzugehen, ist damit ausdrücklich nicht verbunden.
Nutzen
Beim Einsatz von freier Software können wir alle OSI Approved Licenses nutzen.
Code Contributions
Wenn wir Open-Source-Software selber verändern und wieder veröffentlichen, ist die jeweilige Lizenz zu beachten und es sind die geforderten Bedingungen einzuhalten. In der Regel stellt das Verändern bestehender Software hinsichtlich der Lizenz kein Problem dar, da ein Fork des Repositorys gebildet wird, das auch die Lizenzdatei enthält.
Eigenentwicklungen
Die Veröffentlichung der von der LHM entwickelten Software erfolgt unter der MIT-Lizenz, um eine Wiederverwendung möglichst wenig zu behindern. Die MIT-Lizenz wird außerdem schon im Stadtratsbeschluss "Neue Software im Open Source-Kontext entwickeln!" vorgeschlagen.
Einbindung in Eigenentwicklungen
Wir achten darauf, keine Software mit Lizenzen mit starkem Copyleft-Effekt zu nutzen. Dadurch sind wir freier in der Wahl der Lizenz für unsere eigene Software und vermeiden Lizenzkonflikte. Wir nutzen bevorzugt Software mit Lizenzen, die permissiv oder mit schwachem Copyleft-Effekt sind.
In der Praxis nutzen wir vor allem Software mit folgenden permissiven, von der Open Source Initiative geprüften Lizenzen:
Als Lizenzen mit schwachem Copyleft kommen in Frage:
Wir vermeiden die Nutzung von Software unter Lizenzen mit starkem Copyleft. Typische Vertreter sind:
Ausnahme Java
Eine Ausnahme bildet Java. Java steht unter der GPL. Für OpenJDK gilt aber die GPL mit Ausnahmen für gelinkte Software. Das bedeutet, Software die OpenJDK nutzt muss nicht zwangsläufig unter der GPL lizensiert werden.
Prüfen und Dokumentieren
Um sicherzustellen, dass wir keine Lizenzverstöße begehen, müssen sämtliche Abhängigkeiten unserer Software geprüft und dokumentiert werden.
Auf Github nutzen wir dazu GitHub Dependency Review, das ist im oss-repository-en-template bereits vorgegeben.
Das zentrale it@M Policy File ist definiert in it-at-m/.github - dort sind v.a. die Lizenzen mit starken Copyleft definiert, die wir vermeiden wollen.
Da es bei der Lizenzerkennung durchaus zu "false positives" kommen kann, können diese dort auf eine Ignore-Liste gesetzt werden.
Die Kompatibilität der genutzten Lizenzen können mit dem JLA - Compatibility Checker geprüft werden.