Lizenz - Open Source mit Delphi und Fremdkomponenten

[jr1510]

Liebe Forumsgemeinde,

in unserer Uni-Arbeitsgruppe wird seit vielen Jahren ein Programmsystem mit Delphi 6 entwickelt und gepflegt.

Diese Software kommt bei uns intern und bei drei weiteren externen Anwendern zum Einsatz. Den drei externen Anwendern wird die Software vollständig kostenlos zur Verfügung gestellt. Die von uns erstellten Quelltexte sind für sie frei verfügbar.

Eine Vermarktung der Software findet nicht statt und ist auch nicht vorgesehen.

Bisher gibt es keine Lizenz oder anderweitige textliche Abmachungen mit den Anwendern.

Bei der Programmierung werden natürlich Delphi 6 selbst sowie eine Sammlung aus Fremdkomponenten eingesetzt. Die Fremdkomponenten sind z.T. von uns erworbene kommerzielle Produkte oder Komponenten, die unter verschiedenen Open-Source-Lizenzen (z.B. MIT, MPL, LGPL) veröffentlicht wurden.

Seit einiger Zeit denken wir darüber nach, das Software-System unter einer (gängigen) Open-Source-Lizenz zu lizensieren, um es den bisherigen und weiteren interessierten Nutzern unter definierten Bedingungen zur Verfügung stellen zu können und ggf. auch Mitstreiter bei der Weiterentwicklung und Pflege zu gewinnen.

Hier stellt sich nun die Frage, welche Open-Source-Lizenz wir verwenden könnten, die sich einerseits mit den Open-Source-Lizenzen der Fremdkomponenten aber auch mit dem Einsatz der kommerziellen Komponenten verträgt.

Oder wäre es vielleicht besser, wie bisher ganz auf eine Lizenz zu verzichten? Oder eine eigene Lizenz zu entwerfen, die den bisherigen Zustand abbildet?

Ich bedanke mich ganz herzlich für Eure Expertise und Meinungen und freue mich auf Eure Rückmeldungen!

Vielen Dank und viele Grüße
Jörg

[Jens01]

Zitat:

Oder wäre es vielleicht besser, wie bisher ganz auf eine Lizenz zu verzichten? Oder eine eigene Lizenz zu entwerfen, die den bisherigen Zustand abbildet?

Ohne Lizenz dürfte für Deutschland das Urheberrecht gelten, sprich ohne Eure direkte Zustimmung dürfte das keiner nutzen. Ja, eine Verbreitung wäre eine Straftat.

Ansonsten würde ich sowas mit einer MPL Lizenz verbreiten. Die ist relativ frei. Wenn jemand etwas am Quellcode ändert, ist er verpflichtet, das zu veröffentlichen.

Ein Problem sind andere Quelltexte und Komponenten mit anderen Lizenzen. Die Kompatibilität ist manchmal echt schwierig. Man könnte das eventuell mit den Urhebern dieser Quellcode absprechen und die Lizenzen anpassen.
Ich würde den Nutzern trotzdem sagen, besorgt euch die Quellcodes direkt bei den Urhebern.

[TurboMagic]

Irgendwo gab's mal eine Liste welche Open Source Lizenzen mit welchen kompatibel sind.
Evtl. in Wikipedia...
Alternativ zur MPL die Apache 2.0 Lizenz. Die ist auch recht offen und verpflichtet
anders als die GPL den benutzer eures Quellcodes nicht auch seinen open source zu machen.

Andere Frage: wär's nicht mal an der Zeit auf ein neueres Delphi zu wechseln? Da hat sich
ja doch einiges getan.

[himitsu]

Es gibt hier schon mehrere Threads, bezüglich Lizenzen.
Die SuFu würde sich über Besuch bestimmt freuen.

Ich nutze immernoch eine Multilizenz aus MPL, GPL und LGPL. (gut, ich müsste die Versionen mal upgraden

Delphi-Quellcode:

MPL v1.1 , GPL v3.0 or LGPL v3.0

, aber so einfach geht das halt nicht immer)
Da war für Vieles was dabei, da sich jeder Eine der drei raussuchen konnte, welche zu seinem Lizenzmodel am Besten passt.

Es gibt viele "freie" Lizenzen, aber manche sind untereinander einfach vollkommen inkompatibel,
weswegen man auch nicht alles "blind" zu eine Multilizenz verbinden kann,
ebenso wie beim Mischen der eigenen Lizenz, mit Anderen, welche man in sein sein Projekt reinziehen möchte.

Viele OpenSource-Lizenzen verlangen z.B. dass auch damit erstellte Programme ihren Quellcode offenlegen müssen, was aber nicht immer erwünscht ist.


Der Witz ist ja auch, dass selbst Lizenzen unter einer Lizenz stehen, weswegen man sie einmal nicht einfach so ändern darf und für die Verwendung braucht man quasi auch die Erlaubnis usw.

[himitsu]

Ach ja, eine Sammlung an Lizenzen findet man auch im GitHub, z.B. wenn man ein neues Repository erstellen möchte, in der Auswahl dort.
https://docs.github.com/de/repositor...g-a-repository
https://choosealicense.com/licenses/ / https://choosealicense-com.translate..._x_tr_pto=wapp
https://wikijs.opencode.de/de/Hilfes...zenzcompliance


https://de.wikipedia.org/wiki/Mehrfachlizenzierung
https://www.gnu.org/licenses/why-not-lgpl.de.html

Hier noch ein paar Beispiele:

C:\Program Files (x86)\Embarcadero\Studio\23.0\source\xml\Xml.Internal.OBufferedStreams.pas
* MPL 1.1 / GPLv2 / LGPLv2 / FPC modified LGPLv2

C:\Users\Public\Documents\Embarcadero\Studio\23.0\CatalogRepository\AndroidSDK-2525-23.0.50491.5718\build-tools\33.0.2\NOTICE.txt
* MPL 1.1 / GPL 2.0 / LGPL 2.1


(WTFPL) Do What The F*ck You Want To Public License
:lol: (Link)

[Der schöne Günther]

https://ChooseALicense.com/

[jr1510]

Vielen Dank für Eure ausführlichen Rückmeldungen und Tipps!

Vor meinem Beitrag und auch schon länger davor hatte ich mich schon intensiv mit der Lizenzfrage beschäftigt. Auch hier im Forum konnte ich schon viel dazu finden. Die SuFu wurde also ausgiebig besucht. :wink:

Da aber viele Open-Source-Projekte, über die man so Informationen im Netz findet, vor allem auch mit freien anderen Open-Source-Bibliotheken und Programmierwerkzeugen erstellt werden, drehen sich die bisher gefundenen Lizenz-Diskussionen meist nicht um kommerzielle Programmbausteine, die enthalten sein könnten. Was deshalb bisher für uns immer fraglich blieb, war der Umgang mit den erwähnten Fremdkomponenten, wenn wir offiziell mit einer Open-Source-Lizenz veröffentlichen wollen. Was und in welchem Umfang muss dann wirklich veröffentlicht werden?

Die wichtigste Fremdkomponente, die wir einsetzen, ist eine TeeChart Pro Version (also nicht die mit Delphi 6 mitgelieferte Version), die wir damals bei Projektbeginn erworben haben, und die tief in den Programmen verankert ist und deshalb auch nicht so ohne weiteres durch andere Komponenten ersetzt werden kann. (Das ist u.a. auch ein Grund dafür, dass wir noch mit dem Uralt-Delphi 6 herumwerkeln, mit dem wir aber bisher alle Aufgaben unseres Programmsystems zufriedenstellend lösen können.) Hier dürfen wir natürlich nichts veröffentlichen oder weitergeben. Wäre das eventuell ein Hindernis für eine Open-Source-Veröffentlichung unserer Quelltexte?

Die anderen Komponenten laufen unter der LGPL, der MPL oder haben eigene Lizenztexte, die die Weitergabe zulassen, und wären daher bei der Weitergabe als Open-Source wohl unkritisch. Aber auch hier die Frage: Müssten wir die Komponenten samt Quelltexten mitliefern, wenn wir Open-Source veröffentlichen wollen? Oder reicht ggf. ein Verweis auf die Bezugsmöglichkeit? Was macht man, wenn's da gar keine aktuelle mehr gibt, weil der Urheber gar nicht mehr aktiv ist?

Vielleicht hat ja der ein oder andere hier selbst Erfahrungen mit Open-Source-Projekten unter Delphi und kann noch mal darstellen, wie er damit umgeht. Vielleicht wäre ja für uns auch so eine Multilizenz, wie himitsu beschreibt, eine Lösung.

Nochmals herzlichen Dank an alle!
Jörg

[himitsu]

Ja, da muß man bissl in das Kleingedruckte gucken.

Es gibt OpenSource-Lizenzen, da muß dann auch das Programm, wo sie drin verwendet werden, zwingend auch OpenSource sein, teilweise sogar unter der selben Lizenz.
Dann muß oft nur der Lizenztext und ein Absatz/Erwähnung der Fremdkomponente im Info-Dialogs und der eigenen Readme/Lizenz-Datei stehen,
andere Lizenzen halten es gleich, außer der Code wurde verändert, dann muß dieser Quellcode mit veröffentlicht werden.
Manchmal ist es aber auch ganz verboten den Code der Fremdkomponente mit seinem Code auszuliefern.
usw.

Außerdem sind einige Lizenzen inkompatibel und es ist nicht möglich die so lizenzierte Komponente in einem Programm zu nutzen, welches eine andere inkompatible Lizenz verwendet ... hier wird es dann ganz schwer.
Nur bei der GPL v3 aktuell eine Info dazu gefunden, also was mindestens kompatibel ist, laut deren Aussage.

Man denke auch mal an MySQL.
Dort kommt es drauf an, wie die Komponente eingebunden ist, also ob es einkompiliert ist, oder als DLL beiliegt, und ob das Programm auch ohne die Komponente lauffähig ist, schon fällst du in jeweils unterschiedliche Lizenzbedingungen, welche teilweise die Verwendung für kleine Entwickler nahezu unmöglich macht. (weil das kostenfreie Produkt urplötzlich extrem teuer wird)

Es gab auch Extremisten extreme OpenSource- / freie Software-Anhänger, die andere dazu zwingen wollten, ebenfalls OptenSource+Kostenlos zu veröffentliche, weshalb ihre Lizenz es nur erlaubt seinen Code ausschließlich unter der selben Lizenz zu veröffentlichen, sobald man deren Komponente benutzen möchte.


Das ist auch der Grund, warum ich mein Zeugs meist unter eine Multilizenz veröffentliche. So kann sich jeder Eine davon aussuchen, welche in sein Projekt am Besten rein passt.
Zu Mehrfachlizenzen ist aber fast garnichts zu finden, bzw. ich bin zu doof passende Suchbegriffe mir einfallen zu lassen.
Selbst Wiki ist da recht wortkarg dazu. https://de.wikipedia.org/wiki/Mehrfachlizenzierung

In Github kann man nicht nur im Namen/Text/Code nach Repositories suchen, sondern auch nach Lizenzen, aber Github selbst bietet hierfür direkt eigentlich garnichts an.
Bei meiner Lizenz wird im Repo nur angezeigt, dass es eine Lizenz gibt (der Link da rechts im About), aber nicht was es für eine Lizenz ist. Bei Anderen klappt es besser und es wird zumindestens die "Erste" der Mehrfachlizenzen angezeigt.
Siehe da ganz unten, was ich da bisher für Lizenzmodelle fand. https://github.com/geheimniswelten/L.../INFO.xml#L163



Eine passende Lizenz zu finden scheint aber echt nicht so einfach zu sein, drum hatten mehrere größere Projekte eine/mehrere eigene Lizenzen erfunden, welche sie uns nun teilweise zur Verfügung stellen, damit die Qual der Wahl noch größer wird. :stupid:
Selbst FreePascal hat eine eigene "modifizierte" Version der LGPL v2. (beim Anpassen muß man aber aufpassen, damit die Lizenz nicht unwirksam wird, bzw. ob es überhaupt erlaubt ist, das Original zu verändern)



Was mir persönlich noch fehlt sind Lizenzen für OpenSource-Programme/-Komponenten, wo man aber nicht will, dass sie "komplett" unkontrolliert kopiert/nachgebaut/verbreitet werden dürfen
und für ClosedSource-Freeware,
bzw. wo es den Code nur für den privaten internen Gebauch auf Anfrage gibt, er aber nicht weiter geteilt/veröffentlicht werden sollte.






(Vor)Gestern bissl mehr durch Github geklickt, als ich versuchte eine Komponente zu veröffentlichen, mal ALLES durchgesehn, was Github bezüglich der Lizenz anbietet.
Da gibt es eine kleine Auswahl, wo sie auch die Lizenzdatei bereitstellen.
Dabei fällt auf, dass sie zwar teilweise Variablen (Eingabefelder) für "persönliche Daten" anbieten, aber das nicht bei allen Lizenzen funktioniert. (Einige haben keine persönlichen Infos, aber auch nicht überall dort, wo es gehen sollte)

Dann in den Tiefen werden noch viel mehr Lizenzen genannt, aber da ist es nicht immer möglich sie dann auch im Auswahl-SuchDropdown auszuwählen.
z.B. die MPL (Mozilla Public License) in Version 1.1 kann gewählt werden, aber nicht die 1.0 oder 2.0.

Tipp: in einem eigenen Github-Repo in der "CODE"-Ansicht auf "Add File" (oben rechts, neben dem grünen CODE-Downloadknopf), dann "Create New File", dort "license" als Dateiname eingeben und es erscheint ein Link "Choose a license template". (geht auch, wenn man schon eine Lizenz/Lizenzdatei hat)

[Gausi]

Zitat:

Zitat von jr1510 (Beitrag 1534132)

Die wichtigste Fremdkomponente, die wir einsetzen, ist eine TeeChart Pro Version (also nicht die mit Delphi 6 mitgelieferte Version), die wir damals bei Projektbeginn erworben haben, und die tief in den Programmen verankert ist und deshalb auch nicht so ohne weiteres durch andere Komponenten ersetzt werden kann. (Das ist u.a. auch ein Grund dafür, dass wir noch mit dem Uralt-Delphi 6 herumwerkeln, mit dem wir aber bisher alle Aufgaben unseres Programmsystems zufriedenstellend lösen können.) Hier dürfen wir natürlich nichts veröffentlichen oder weitergeben. Wäre das eventuell ein Hindernis für eine Open-Source-Veröffentlichung unserer Quelltexte?

Delphi und OpenSource ist in dieser Hinsicht generell schon ein Problemchen, weil Delphi selbst nicht OpenSource ist. Der Basis-Code der verwendeten Sprache wird daher in der Regel von der Lizenz ausgenommen. Es wird aber gerade bei der GPL empfohlen, auch an der Stelle auf freie Software zu setzen.

Bei aktuellen Delphi-Versionen ist das ein kleineres Problem, weil die kostenfreie Community-Edition weitgehend Code-kompatibel mit den aktuellen professionellen Lizenzen ist. Man kann also (kosten)frei den Code compilieren und ggf. modifizieren. Ob es eine kostenfreie Delphi-Version gibt, die zu Delphi 6 kompatibel ist, weiß ich nicht. Hauptproblem dürfte "Unicode" sein.

Die Frage ist, ob man diese Ausnahme für die IDE auf die Verwendung (gängiger) unfreier Zusatzkomponenten erweitern kann. Mit ausliefern darfst du die natürlich nicht. Ihr könnt natürlich in die Voraussetzungen schreiben, dass zusätzlich zu Delphi 6 auch die Komponenten X, Y und Z benötigt werden.

Wenn der Rest des Codes von euch wäre, könntet ihr dann jede beliebige FOSS-Lizenz benutzen, und diese um die Ausnahmen ergänzen, dass euer Code mit diesen unfreien Komponenten kombiniert werden darf. Da ihr aber auch andere FOSS-Bibliotheken nutzt, wäre der sichere Weg, bei den Urhebern nachzufragen, ob diese die Kombination mit diesem nicht-freien Code erlauben. Ebenso müssten streng genommen die Inkompatibiltäten zwischen MPL und LGPL aufgelöst werden. Die darf man nämlich eigentlich auch nicht mischen.

Bei kleineren OS-Komponenten von Einzelentwicklern steht die Chance dazu ganz gut. Die machen sich oft nämlich nur wenig Gedanken über die Lizenz und nutzen einfach "irgendeine". Wenn man die fragt, ob man auch eine andere nutzen kann, ist das denen oft egal. ;-)
Bei größeren Projekten, bei denen viele Entwickler mitarbeiten, ist das ggf. nicht so einfach möglich.

Zur Mit-Auslieferung des anderen OS-Codes: Ich mach das meinem Player so, dass ich diese Komponenten mit ausliefere. Damit ist man dann auf der sicheren Seite, wenn es in diesem Fremdcode einen breaking change gibt - beim VirtualStringTree ist das z.B. ab und zu der Fall gewesen. Da haben sich dann die Signaturen der Events geändert u.Ä.

[himitsu]

OK, die Delphi-IDE selbst nicht, aber Vieles ist im Delphi ja dennoch OpenSource, zumindest ab der Professional liegt für Vieles, welches für das Kompilat genutzt wird, der Source vor.
Zu beachten wäre es da ja nur für Experten und DesignTimeKomponenten, welche z.B. im FormDesigner genutzt werden können.

Dagegen wäre es dann im Lazarus problematischer, wenn Fremdkomponenten direkt in die IDE kompiliert werden müssen. (die haben doch immernoch nicht sowas, wie DesignTime-Packages?)

Pascal Delphi-Language, Delphi-Compiler+RTL/VCL und Delphi-IDE ist im Delphi ja auch noch gefühlt "Eines",
während man immernoch gut zwischen Lazarus, der LCL und FreePascal unterscheiden kann.

[dummzeuch]

Ich bin mir ziemlich sicher dass Sourcecode, der unter der MPL steht, problemlos zusammen mit kommerziellen Komponenten verwendet werden kann. Es gibt sicherlich auch noch andere Lizenzen, bei denen das möglich ist, aber mir reicht eine. ;-)

GPL und alles, was davon abstammt, verbietet sich allerdings, denn dann müsste man den Sourcecode der kommerziellen Komponenten jedem Executable, das man weitergibt, beilegen, und der Empfänger (Käufer), dürfte dann damit machen, was er will. Das lassen die Lizenzen kommerzieller Komponenten nicht zu.

[jr1510]

Uii, da gibt es viel zu lesen! Ich komme leider erst heute wieder dazu, hier reinzuschauen und sehe Eure umfangreichen Erläuterungen. Ganz herzlichen Dank dafür in die Runde und besonders an himitsu für die sehr ausführlichen Überlegungen und zahlreichen Hinweise auf andere Infoquellen!

Wie bisher schon festgestellt, scheint das Thema Lizensierung wirklich nicht trivial zu sein, wenn man immer wieder so viel dazu schreiben kann. :? Besonders, wenn man sich nur gelegentlich mal damit beschäftigt.

Als wir damals vor mehr als 20 Jahren unser Projekt begannen, gab es zwar schon Open-Source-Lizenzen, aber darüber, dass unser Projekt auch mal eine richtige Lizenz benötigen könnte, wurde lange Zeit nicht wirklich nachgedacht. Deshalb ist auch das Konglomerat an Komponenten entstanden, die eben alle mit ganz unterschiedlichen Lizenzen daherkommen. Es wäre jetzt schwierig, mit unseren sehr beschränkten Programmiererressource, hier etwas zu ändern. Zum Glück ist unser Projekt nie kommerziell geworden, sonst hätten wir hier echt ein Problem.

Mittlerweile legen zwei der bisherigen Anwender aber schon Wert darauf, dass es bezüglich der offenliegenden Quelltexte definierte Bedingungen gibt, und so müssen wir irgendwas finden was passt und dann möglichst auch zukünftige weitere Anwender und Mitstreiter nicht verschreckt oder verunsichert. Und außerdem einer Veröffentlichung, z.B. auf GitHub, nicht im Wege steht. Eure Beiträge helfen mir da echt weiter!

Vielen Dank noch einmal und viele Grüße
Jörg

[Jens01]

Ich hab jetzt auch nicht alles hier gelesen. Aber kurz zur Aussage von Thomas:

Zitat:

Ich bin mir ziemlich sicher dass Sourcecode, der unter der MPL steht, problemlos zusammen mit kommerziellen Komponenten verwendet werden kann.

Da bin ich mir auch ziemlich sicher. Aber wenn für den MPL-Code noch zusätzlich eine Profi-TeeChart-Version benötigt wird, muss jeder, der den gesamten Code kompilieren will, eine TeeChart Lizenz kaufen.

[Uwe Raabe]

Zitat:

Zitat von Jens01 (Beitrag 1534724)

Aber wenn für den MPL-Code noch zusätzlich eine Profi-TeeChart-Version benötigt wird, muss jeder, der den gesamten Code kompilieren will, eine TeeChart Lizenz kaufen.

So ähnlich ist das auch beim Better Translation Manager von Anders Melander. Der steht ebenfalls unter MPL 2.0, benötigt aber zum Compilieren mindestens eine DevExpress VCL Lizenz und optional eine madExcept Lizenz (falls man das kommerziell nutzt). Deswegen gibt es da auch einen Installer für die fertige Exe.

Grundsätzlich sehe ich sowas nicht als Einschränkung. Es wäre vielmehr eine gravierende Einschränkung, wenn ich etwas Open Source machen möchte, dafür aber wiederum ausschließlich Open Source Bibliotheken verwenden dürfte.

[Jens01]

@Uwe
Man muß sich nur darüber im Klaren sein.

[Gausi]

Zitat:

Zitat von Uwe Raabe (Beitrag 1534726)

Grundsätzlich sehe ich sowas nicht als Einschränkung. Es wäre vielmehr eine gravierende Einschränkung, wenn ich etwas Open Source machen möchte, dafür aber wiederum ausschließlich Open Source Bibliotheken verwenden dürfte.

Da ist dann halt die Frage, aus welchem Blickwinkel man das "frei" in "freie Software" betrachtet.

Lizenzen mit starkem Copyleft wie die GPL haben immer die Freiheit des Endanwenders im Blick. Wenn ich ein Stück Code unter der GPL veröffentliche, dann soll ein Anwender von davon abgeleiteten Werken/Programmen die gleichen Freiheiten haben wie der Entwickler, der mit meinem GPL-Code ein neues Werk erstellt. Wenn in diesem neuen Werk aber auch unfreier Code verwendet wird, wird dadurch die Freiheit des Endanwenders eingeschränkt - denn er kann nicht so ohne weiteres das Werk verändern/compilieren/erweitern.

Lizenzen wie die MPL haben stärker die Freiheiten der Entwickler im Sinn. Da kann der Entwickler den Code fast beliebig benutzen, er muss iirc nur Änderungen an diesem speziellen Stück Code wieder der Allgemeinheit zur Verfügung stellen. Mischen mit unfreiem Code ist aber erlaubt.

Beides hat Vor- und Nachteile. Von daher finde ich eine Dual-Lizenz MPL/GPL bei Bibliotheken o.Ä. sehr sinnvoll, bei vollständigen Programmen neige ich eher zur GPL.

[jr1510]

Zitat:

Zitat von Uwe Raabe (Beitrag 1534726)

Zitat:

Zitat von Jens01 (Beitrag 1534724)

Aber wenn für den MPL-Code noch zusätzlich eine Profi-TeeChart-Version benötigt wird, muss jeder, der den gesamten Code kompilieren will, eine TeeChart Lizenz kaufen.

So ähnlich ist das auch beim Better Translation Manager von Anders Melander. Der steht ebenfalls unter MPL 2.0, benötigt aber zum Compilieren mindestens eine DevExpress VCL Lizenz und optional eine madExcept Lizenz (falls man das kommerziell nutzt). Deswegen gibt es da auch einen Installer für die fertige Exe.

Grundsätzlich sehe ich sowas nicht als Einschränkung. Es wäre vielmehr eine gravierende Einschränkung, wenn ich etwas Open Source machen möchte, dafür aber wiederum ausschließlich Open Source Bibliotheken verwenden dürfte.

Danke, Uwe, für den Hinweis auf dieses konkrete Projekt mit MPL-Lizenz!

Nach allem, was wir bisher so gelesen und recherchiert haben, tendieren wir auch mehr und mehr zu einer MPL 2.0-Lizenz, die ja so, wie ich es hier verstehe, nicht mit der Verwendung unserer kommerziellen Komponenten kollidieren würde. Den Hinweis, dass zur Verwendung unserer Quellen dann natürlich auch die kommerzielle Lizenz von TeeChart notwendig ist, werden wir in einer Readme mit aufnehmen, ebenso für andere Komponenten, die wir nicht mitliefern werden. Mit anderen LGPL- oder anderen MPL-lizensierten Komponenten sollte es ja keine Probleme geben, wenn wir sie nicht verändern und irgendwo angeben, dass wir sie verwenden und wo man sie findet, egal ob wir sie mitveröffentlichen oder nicht, oder?

Alternativ steht bai uns aber auch noch die LGPL v3 zur Debatte. Würde bei der LGPL auch die Verwendung der kommerziellen Komponenten problemlos möglich sein? Gibt's vielleicht noch andere Stolperstellen, die man sich mit der LGPL einhandeln würde, außer dass sie vielleicht noch freieren Umgang mit unseren Quellen zulassen würde (Womit wir kein Problem hätten.)?

[himitsu]

Wie schon mehrmals erwähnt, gibt es deswegen viele Projekte, welcher und einer Dualen oder gar Miltiplen Lizenz stehen,
wo sich die Nutzer eine der Lizenzen aussuchen können, welche zu ihrem Projekt am besten passt.

Ich selbst nutze seit Jahren ja auch so Eine, aus MPL mit GPL und LGPL.
https://github.com/geheimniswelten/L...MPL%2BGPL3.txt


Genauso, wie Lizenzen selbst, stehen auch solche Multilizenzen unter einem Copyright.
Einfach selbst sowas zusammenklöppeln zu wollen ist nicht so einfach und du mußt höllisch auf die Kompatibilität dieser Lizenzen achten, damit sie sich in grundlegenden Belangen nicht gegenseitig ausschließen.

Es gibt aber bereits mehrere solcher dualen/multiplen Lizenzen ... ein paar hatte ich schonmal entdeckt und aufgelistet.
https://github.com/geheimniswelten/L.../INFO.xml#L163