Webstart Lizenz des entwickelten Java-Programms

[java_in_medical_sector]

Hallo liebe Community,

ich habe im Rahmen meiner Master-Thesis ein Programm im klinisch-biologischen Bereich geschrieben, das bald auf der Bioinformatik-Seite meiner Universität zur Ausführung bereit stehen wird. Genauer gesagt steht der Client zur Verfügung, der über SSL mit dem Server kommuniziert, der die Hauptlast der Berechnungen übernimmt. Der Client stellt die Ergebnisse dar. Der Source Code für den Client, den Server und die Datenaufbereitung sind auf GitHub. Zur Nachvollziehung wird auch der Quellcode veröffentlicht. Der Vollständigkeit halber muss eine Lizenz vergeben werden.

Ich kenne mich mit der Lizenzierung leider nicht nicht aus.
Ich verwende folgende Drittanbieter-Komponenten, eine von mir nachfolgend vergebene Lizenz wird die Lizenz der Packages berücksichtigen müssen:
1x Apache License 2.0 oder Eclipse Public License 1.0
2x LGPL 2.1
3x Apache License 2.0
1x BSD
1x CeCILL-C oder LGPL 3.0

Die Verantwortung der Ausführung sollte beim Anwender liegen.

Welche Lizenz kann ich vergeben?

 

[mrBrown]

Afaik kannst du jede beliebige Lizenz nutzen. Wenn das sowieso Open Source wird, musst du auch wegen LGPL besonderes nichts beachten.

Je nachdem wie du dazu stehst würde ich entweder GPL v3 oder Apache/MIT/BSD nutzen

 

[mihe7]

Die Frage wäre in einem Jura-Forum oder noch besser bei einem Fachanwalt sicher besser aufgehoben.

Meine absolut laienhaften Meinung zum Thema: es kommt sehr genau darauf an, was Du wie verwendest und auslieferst.

Nehmen wir mal an, Du hast eine Anwendung, die sich via JDBC mit einer Datenbank verbindet. Wir nehmen weiter an, die JDBC-URL ist frei konfigurierbar und Du lieferst keinen JDBC-Treiber aus. Dann ist die Sache klar: Die Anwendung besteht nur aus Deinem Code und liefert nichts anderes aus - Lizenz wie Du willst. Die Tatsache, dass irgendjemand einen unter der LGPL lizenzierten JDBC-Treiber verwendet, ist nicht Dein Problem.

Gehen wir einen Schritt weiter und fügen der Anwendung ein Class.forName("package.des.jdbc.treibers"); fest kodiert hinzu. Dann könnte man argumentieren, dass Deine Anwendung eine Bibliothek nutzt, wobei man hierüber trefflich streiten kann, denn noch steht hier nur ein Name und keine konkrete Bibliothek oder gar Version/Lizenz einer Bibliothek.

Also klären wir das und sagen ganz klar, dass die Anwendung den Treiber X Version Y unter der LGPL benötigt, sprich die Anwendung die Bibliothek nutzt. In dem Moment muss aufgrund den Bestimmungen der LGPL die Lizenz Deiner Anwendung es dem Anwender erlauben, die Bibliothek zu verändern (z. B. den Treiber patchen) und ein Reverse Engineering Deiner Anwendung zulassen, so dass die Veränderung an Deine Anwendung angepasst werden kann. Das ist selbst für proprietäre Software nicht dramatisch, denn das gilt in der EU sowieso ganz ähnlich.

Das ist die Nutzung der Bibliothek - nicht das Verteilen. Wenn Du den Treiber zusätzlich auslieferst, musst Du z. B. auch den Quellcode zum Treiber ausliefern.

Jetzt machen wir mal ein wenig weiter: Du passt den LGPL-lizenzierten JDBC Treiber an. Dann hast Du ein abgeleitetes Werk bzw. ein Werk basierend auf dem LGPL-Treiber. Dem entsprechend bist Du verpflichtet, dieses Werk unter die LGPL zu stellen.

Kommen wir zur Kompatibilität: nehmen wir an, bei der Anpassung hast Du Teile aus einer Apache Bibliothek verwendet. Dann hast Du ggf. ein Problem, denn wenn der angepasste Treiber ein abgeleitetes Werk/Kombination von/mit dem LGPL-Treiber und der Apache Bibliothek ist, müsste er nach der LGPL unter die LGPL gestellt werden. Hierzu schreibt die FSF: "Bitte beachten Sie, dass diese [Anm. meinerseits: Apache 2.0] Lizenz unvereinbar mit GPLv2 ist, weil einige Bedingungen enthalten sind, die in dieser Version der GPL nicht enthalten sind. Dazu zählen bestimmte Patentbeendigungs- und Schadenersatzklauseln. "

Kurz: das Ganze ist äußerst kompliziert und nichts für ein Java Forum.

 

[mrBrown]

Kurz: das Ganze ist äußerst kompliziert und nichts für ein Java Forum.

Wobei das ganze deutlich einfacher ist, wenn man das auf obige Fall und das übliche "nur nutzen", aber nicht verändern der Bibliotheken bezieht.

Zu beachtenden Lizenzen sind dann nur Apache License 2.0, BSD, LGPL 2.1 und LGPL 3.0 - keine davon stellt Forderungen an die zu wählende Lizenz. Die geforderten Lizenz- und Copyright-Hinweise kann er einfach erfüllen, die Forderungen der LGPL auch, wenn das ganze am Ende Open Source ist.

 

[java_in_medical_sector]

Vielen Dank für die Antworten,

mihe7: Die Rechtsabteilung meiner Universität hatte keine Ahnung, auch Informatik-Professoren nicht. Aus Praktikabilitätsgründen wurden die Datensätze in Dateien abgelegt. Einen Datenbanktreiber brauche ich in dem Sinne nicht. Für den Server habe ich Jetty zur Kommunikation verwendet. Ich habe die Drittanbieterkomponenten zwar in die JAR-Datei gepackt aber nicht modifiziert. Gegen Reverse Engineering hätte ich nichts einzuwenden. Meine Vermutung ist die, dass sich ein paar Spezialisierte für das Thema interessieren werden. Die Source Codes zu den Libraries würde ich verlinken.

mrBrown: Ich werde die MIT-Lizenz wählen. Die State Changes der Apache-Lizenz finde ich nicht so wichtig. Ich dachte anfangs, ich müsste auf die verlinkten Klassen mehr Acht geben.

Ich hoffe ich habe das richtig verstanden, dass die Apache License 2.0, BSD, LGPL 2.1 und LGPL 3.0 kein Problem als verwendete Libraries mehr darstellen und ich meinen Teil unter die MIT-Lizenz stellen kann.

 

[mihe7]

Wobei das ganze deutlich einfacher ist, wenn man das auf obige Fall und das übliche "nur nutzen", aber nicht verändern der Bibliotheken bezieht.

Klar, noch einfacher wird es, wenn man nur eine Lizenz verwendet 🙂 Bei uns kommt nur die Apache Lizenz oder MIT/BSD ins Haus. Lizenzen, die "PL" im Namen tragen, sind nicht zugelassen.