Hallo,
ich bin der Autor von Lino, eines Frameworks in Python, das auf Django und Sencha ExtJS aufbaut. Django ist BSD, ExtJS ist GPL.
Mein Lino ist bisher LGPL-lizenziert, aber ich bin möglicherweise kurz vorm Umkippen in dieser Frage, weil alles einfacher würde, wenn ich auf die BSD wechsle.
Meine bisherige Verteidigungsrede für die LGPL (statt BSD) steht hier:
http://lino-framework.org/about/license.html
Was mich wanken macht, sind Gedanken wie:
- LGPL bedeutet, dass ich viel Zeit mit der Rechtfertigung meiner Wahl verbringe.
- Es haben sich vermutlich schon einige Leute schnell wieder von Lino abgewendet, weil sie "GPL" gesehen haben. Und zwar ohne dass ich das je erfahren werde.
- Die Idee hinter der GPL mag ja im Endeffekt stimmen, aber bis alle Menschen das eingesehen haben, wird (1) noch viel Zeit vergehen und (2) wird mein Lino das weder entscheiden noch beschleunigen.
Was meint ihr? Soll ich die Lizenz meines Lino von LGPL nach BSD wechseln?
Luc
Hallo.
Es ist zwar richtig, Meinungen und Stimmungen einzuholen aber ich denke nicht, dass dir jemand diese Entscheidung abnehmen kann.
Wir bei schokokeks.org erstellen zwar nicht viel Software aber alles was wir veröffentlichen lizenzieren wir (sofern möglich) als CC0. Der Grund ist einfach: Möglichst unkompliziert.
So lange man sich in der Free-Software-Szene bewegt ist es immer ärgerlich, wenn einzelne Lizenzen zwar inhaltlich fast gleich sind, dann aber wegen irgendwelcher Befindlichkeiten doch inkompatibel sind (z.B. 4-clause-BSD).
Am 14.09.2014 um 21:51 schrieb Luc Saffre:
Mein Lino ist bisher LGPL-lizenziert, aber ich bin möglicherweise kurz vorm Umkippen in dieser Frage, weil alles einfacher würde, wenn ich auf die BSD wechsle. Meine bisherige Verteidigungsrede für die LGPL (statt BSD) steht hier: http://lino-framework.org/about/license.html
An diesem Text stört mich sofort ein gewaltiger Denkfehler in der Einleitung: "because we want to make sure that our work will [...] never be controlled by some proprietary organisation."
Hier stört das "controlled". Wer die Entwicklung letztlich steuert ist unabhängig von der Lizenz. Auch wenn du als CC0/Public-Domain veröffentlichst, hat deshalb noch niemand anderes Schreibzugriff auf dein GIT-Repository. Jemand anderes kann die Steuerung der Entwicklung nur übernehmen, wenn er ein Produkt daraus ableitet, selbst veröffentlicht und dabei so gut ist, dass deine Benutzer nachher seine Benutzer sind. Nur dann kann er wirklich sagen, dass er das "bessere lino" macht und selbst steuert wo's lang geht.
Richtig ist, dass wenn du das Projekt einfach aufgibst, keinen Nachfolger suchst sondern einfach einen letzten Snapshot veröffentlichst, dann kann jeder der auch nur ein bisschen was erweitert sofort die Entwicklung an sich reißen.
Gleichzeitig kann eine Firma deinen Code unter LGPL nehmen, mit eigenen Erweiterungen wieder unter LGPL veröffentlichen und wenn deren Erweiterungen gut sind, dann nutzen die Nutzer das und die Firma kontrolliert die weitere Entwicklung.
Der für mich naheliegendste Fall den du mit dem Verzicht auf Copyleft möglich machst ist der, dass jemand anderes eine Erweiterung programmiert und diese nur in einem proprietären Paket mit veränderter Basis angeboten wird. Damit kann es passieren, dass einige Nutzer zu einer proprietären Variante deiner Software gezwungen werden, wenn sie seine Erweiterung nutzen möchten.
Wenn du via copyleft veröffentlichst, wird es diese Erweiterung dann aber vermutlich einfach gar nicht geben, sofern Code-Änderungen an der Basis dafür nötig sind.
- Die Idee hinter der GPL mag ja im Endeffekt stimmen, aber bis alle Menschen das eingesehen haben, wird (1) noch viel Zeit vergehen und (2) wird mein Lino das weder entscheiden noch beschleunigen.
Ich finde nicht, dass die GPL für eine bessere Welt unbedingt notwendig sein muss. Die GPL rüttelt wach und die GPL hatte damals einen sehr richtungsweisenden Charakter.
Die GPL ist großartig für elementare Komponenten die bereits einen stattlichen Umfang und eine langfristige Entwicklung hinter sich haben. Kurz gesagt für Sachen, die man nicht einfach mal nachprogrammieren oder durch was anderes ersetzen kann. Dass der Linux-Kernel GPL ist, hat uns vermutlich insgesamt viel gebracht, auch was die breite Akzeptanz von Copyleft angeht.
Aber *wenn* alle Menschen das eingesehen haben, *dann* brauchst du die GPL nicht mehr. Denn dann sind die Vorteile die offener Code bringt ja bekannt und dann will gar niemand mehr proprietäre Software einsetzen und entwickeln. :)
Gruß, Bernd
Ach ja, eins noch:
Am 15.09.2014 um 07:28 schrieb Bernd Wurst:
Der für mich naheliegendste Fall den du mit dem Verzicht auf Copyleft möglich machst ist
Es gibt Software-Autoren, die ihre GPL-Software dual lizenzieren: GPL für alle und proprietär für Leute die den Support oder eine individuelle Änderung dazu kaufen. Damit kann der zahlende Kunde nachträglich für jede zusätzliche Änderung immer nur den selben Autor wieder buchen und der Autor verdient damit sein Geld.
Durch die Lizenzierung als GPL hat man als alleiniger Autor ein Monopol auf dieses Geschäftsmodell.
Ich bin kein Freund dieses Geschäftsmodells aber genau das würde man mit einer liberaleren Lizenz dann auch für andere Entwickler möglich machen.
Gruß, Bernd
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 15/09/14 08:36, Bernd Wurst wrote:
Es gibt Software-Autoren, die ihre GPL-Software dual lizenzieren: GPL
Ich sehe darin einen weiteren Grund, von der LGPL auf die BSD umzusteigen.
Karikiert formuliert:
1. Ich möchte Gutes tun (freie Software schreiben) 2. Ich sähe es nicht gerne, wenn meine Arbeit missbraucht werden kann um Böses zu tun. 3. Bisher glaubte ich, dass GPL das verhindert 4. Tut sie aber nicht (z.B. duale Lizenzierung) 5. Dann kann ich ja auch gleich die BSD nehmen
Luc
On 15.09.2014 08:40, Luc Saffre wrote:
- Bisher glaubte ich, dass GPL das verhindert
- Tut sie aber nicht (z.B. duale Lizenzierung)
Was ist an einer dualen Lizenzierung böse?
Und was ist an einer copyleft-losen Lizenz gut?
War es beispielsweise gut, dass sich Apple BSD "geschnappt" und in sein proprietäres Betriebssystem eingebaut hat? Was hat das (Free-)BSD gebracht? Ruhm und Ehre?
Gruß Michael
Hallo.
Am 15.09.2014 um 09:08 schrieb RA Stehmann:
War es beispielsweise gut, dass sich Apple BSD "geschnappt" und in sein proprietäres Betriebssystem eingebaut hat? Was hat das (Free-)BSD gebracht? Ruhm und Ehre?
Es hat der Algmemeinheit vermutlich gebracht, dass es ein proprietäres Betriebssystem gibt das offensichtlich einigermaßen stabil funktioniert (vom Hörensagen, kenne es selbst nicht). Ob das ohne die Vorleistung von (Free-)BSD auch geklappt hätte ist ungewiss.
Für die Gesellschaft ist es durchaus ein Vorteil, dass jetzt auch Leute die bewusst unfreie Software einsetzen möchten trotzdem ein einigermaßen sicheres System nutzen können.
Oder anders gefragt: Hat es BSD geschadet, dass Teile ihres Codes in ein proprietäres System geflossen sind? Siehst du einen relevanten Anteil der Nutzer, die statt dieser proprietären Alternative jetzt (Free-)BSD nutzen würden?
Gruß, Bernd
On 15.09.2014 10:25, Bernd Wurst wrote:
Oder anders gefragt: Hat es BSD geschadet, dass Teile ihres Codes in ein proprietäres System geflossen sind? Siehst du einen relevanten Anteil der Nutzer, die statt dieser proprietären Alternative jetzt (Free-)BSD nutzen würden?
Anders gefragt, wieviel Prozent, der Apple-"Fanboys", die die Genialität von Steve Jobs nicht hoch genug preisen können, wissen, dass sie ein BSD-basiertes OS benutzen?
Gruß Michael
Bernd Wurst bernd@bwurst.org wrote:
Am 15.09.2014 um 09:08 schrieb RA Stehmann:
War es beispielsweise gut, dass sich Apple BSD "geschnappt" und in sein proprietäres Betriebssystem eingebaut hat? Was hat das (Free-)BSD gebracht? Ruhm und Ehre?
Dass auch bekannte Firmen wie Apple, Google, Microsoft etc. freie Software nutzen und weiterentwickeln hilft mir regelmäßig bei Gesprächen mit Leuten, die noch nicht mit freier Software vertraut sind.
Es hat der Algmemeinheit vermutlich gebracht, dass es ein proprietäres Betriebssystem gibt das offensichtlich einigermaßen stabil funktioniert (vom Hörensagen, kenne es selbst nicht). Ob das ohne die Vorleistung von (Free-)BSD auch geklappt hätte ist ungewiss.
Für die Gesellschaft ist es durchaus ein Vorteil, dass jetzt auch Leute die bewusst unfreie Software einsetzen möchten trotzdem ein einigermaßen sicheres System nutzen können.
Oder anders gefragt: Hat es BSD geschadet, dass Teile ihres Codes in ein proprietäres System geflossen sind?
Ganz im Gegenteil. FreeBSD und andere Projekte haben von Apples Erweiterungen und Bugfixes profitiert.
Fabian
On 09/15/2014 02:19 PM, Fabian Keil wrote:
Bernd Wurst bernd@bwurst.org wrote:
Am 15.09.2014 um 09:08 schrieb RA Stehmann:
War es beispielsweise gut, dass sich Apple BSD "geschnappt" und in sein proprietäres Betriebssystem eingebaut hat? Was hat das (Free-)BSD gebracht? Ruhm und Ehre?
Dass auch bekannte Firmen wie Apple, Google, Microsoft etc. freie Software nutzen und weiterentwickeln hilft mir regelmäßig bei Gesprächen mit Leuten, die noch nicht mit freier Software vertraut sind.
Irgendwie traurig, dass Freie Software es anscheinend immer noch nötig hat, von den Anbietern proprietärer Software "geadelt" zu werden, um von der breiten Bevölkerung ernst genommen zu werden.
--StefCT
Hallo.
Am 15.09.2014 um 08:40 schrieb Luc Saffre:
On 15/09/14 08:36, Bernd Wurst wrote:
Es gibt Software-Autoren, die ihre GPL-Software dual lizenzieren: GPL
Ich sehe darin einen weiteren Grund, von der LGPL auf die BSD umzusteigen.
Karikiert formuliert:
- Ich möchte Gutes tun (freie Software schreiben)
- Ich sähe es nicht gerne, wenn meine Arbeit missbraucht werden kann um Böses zu tun.
- Bisher glaubte ich, dass GPL das verhindert
- Tut sie aber nicht (z.B. duale Lizenzierung)
- Dann kann ich ja auch gleich die BSD nehmen
Ja nee, Moment.
Die GPL verhindert das was du da skizzierst durchaus. Nur wenn du selbst Urheber bist und alle nötigen Rechte an dem Code hast, kannst du diesen zusätzlich dual lizenzieren.
Die BSD-Lizenz ermöglicht zusätzlich, dass andere diesen Code für proprietäre Veränderungen nutzen.
Gruß, Bernd
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 15/09/14 11:13, Bernd Wurst wrote:
Am 15.09.2014 um 08:40 schrieb Luc Saffre:
Ich sehe darin einen weiteren Grund, von der LGPL auf die BSD umzusteigen.
Karikiert formuliert: (...)
Ja nee, Moment.
Die GPL verhindert das was du da skizzierst durchaus. Nur wenn du selbst Urheber bist und alle nötigen Rechte an dem Code hast, kannst du diesen zusätzlich dual lizenzieren.
Upps, natürlich hast du Recht. In der Tat war meine Karikatur sogar doppelter Unsinn, denn auch ich finde duale Lizenzierung nicht unbedingt böse.
Luc
Am 15.09.2014 um 08:40 schrieb Luc Saffre:
- Ich sähe es nicht gerne, wenn meine Arbeit missbraucht werden kann um Böses zu tun.
- Bisher glaubte ich, dass GPL das verhindert
- Tut sie aber nicht (z.B. duale Lizenzierung)
Für duale Lizenzierung ist immer noch der Autor des Teiles der Software zuständig. Sollte dieser Teil ein abgeleitetes Werk sein, dann fällt es ihm auch schwer, da er ja das Original nicht umlizensieren kann. Also GPL schütz eigentlich schon vor dualen Lizenzen, die die original Autoren nicht möchten.
Gruß Frank
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 17/09/14 00:14, Frank Lanitz wrote:
Am 15.09.2014 um 08:40 schrieb Luc Saffre:
- Ich sähe es nicht gerne, wenn meine Arbeit missbraucht werden
kann um Böses zu tun. 3. Bisher glaubte ich, dass GPL das verhindert 4. Tut sie aber nicht (z.B. duale Lizenzierung)
Für duale Lizenzierung ist immer noch der Autor des Teiles der Software zuständig. Sollte dieser Teil ein abgeleitetes Werk sein, dann fällt es ihm auch schwer, da er ja das Original nicht umlizensieren kann. Also GPL schütz eigentlich schon vor dualen Lizenzen, die die original Autoren nicht möchten.
Richtig, das war der Denkfehler, den ich auch schon eingesehen hatte.
Luc
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 15/09/14 08:28, Bernd Wurst wrote:
Am 14.09.2014 um 21:51 schrieb Luc Saffre:
Meine bisherige Verteidigungsrede für die LGPL (statt BSD) steht hier: http://lino-framework.org/about/license.html
An diesem Text stört mich sofort ein gewaltiger Denkfehler in der Einleitung: "because we want to make sure that our work will [...] never be controlled by some proprietary organisation."
Danke für den Hinweis! Ich habe die anstößliche Formulierung ersetzt durch "because we want to make sure that our work will always remain freely available for everybody."
Luc
Hallo Bernd,
On Mon, 15 Sep 2014 07:28:42 +0200 Bernd Wurst wrote:
Der für mich naheliegendste Fall den du mit dem Verzicht auf Copyleft möglich machst ist der, dass jemand anderes eine Erweiterung programmiert und diese nur in einem proprietären Paket mit veränderter Basis angeboten wird. Damit kann es passieren, dass einige Nutzer zu einer proprietären Variante deiner Software gezwungen werden, wenn sie seine Erweiterung nutzen möchten.
Wenn du via copyleft veröffentlichst, wird es diese Erweiterung dann aber vermutlich einfach gar nicht geben, sofern Code-Änderungen an der Basis dafür nötig sind.
Oder die Erweiterung wird dann eben doch unter die LGPL gestellt. Damit hätte die LGPL ihr Ziel erreicht und sowohl den original Code geschützt als auch für mehr Freie Software gesorgt.
Ich erlebe das relativ häufig das Leute erstmal nach einem einfachen "Ausweg" suchen um ihren Code nicht zu veröffentlichen. Wenn es dann Dank Copyleft nicht anders geht ist es am Ende meist doch kein Problem. Ohne Copyleft hätte die Welt den Code aber mit hoher Wahrscheinlichkeit nie zu Gesicht bekommen.
Ein prominentes Beispiel hierfür ist der Objective-C Übersetzer im gcc. Ohne der GPL hätte Apple diesen vermutlich nie unter einer freien Lizenz veröffentlicht.
Siehe (leider in Englisch, habe auf die schnelle keinen deutschen Artikel gefunden): http://www.informit.com/articles/article.aspx?p=1390172
Aber *wenn* alle Menschen das eingesehen haben, *dann* brauchst du die GPL nicht mehr. Denn dann sind die Vorteile die offener Code bringt ja bekannt und dann will gar niemand mehr proprietäre Software einsetzen und entwickeln. :)
Dieses Argument höre ich gelegentlich als Argument gegen Copyleft. Meine Antwort: In dieser Welt schadet die GPL auch nicht, da alle eh das machen was die GPL fordert. Solang diese Welt aber noch Wunschdenken ist schadet es auch nicht aktiv (indem man die Freiheit schützt) darauf hinzuwirken. Die GPL funktioniert also in beiden Welten gut, damit ist eine solche Zukunftsvision kein Argument gegen schützende Lizenzen.
Viele Grüße, Björn
Bjoern Schiessle schiessle@fsfe.org wrote:
On Mon, 15 Sep 2014 07:28:42 +0200 Bernd Wurst wrote:
Der für mich naheliegendste Fall den du mit dem Verzicht auf Copyleft möglich machst ist der, dass jemand anderes eine Erweiterung programmiert und diese nur in einem proprietären Paket mit veränderter Basis angeboten wird. Damit kann es passieren, dass einige Nutzer zu einer proprietären Variante deiner Software gezwungen werden, wenn sie seine Erweiterung nutzen möchten.
Wenn du via copyleft veröffentlichst, wird es diese Erweiterung dann aber vermutlich einfach gar nicht geben, sofern Code-Änderungen an der Basis dafür nötig sind.
Oder die Erweiterung wird dann eben doch unter die LGPL gestellt. Damit hätte die LGPL ihr Ziel erreicht und sowohl den original Code geschützt als auch für mehr Freie Software gesorgt.
Ich erlebe das relativ häufig das Leute erstmal nach einem einfachen "Ausweg" suchen um ihren Code nicht zu veröffentlichen. Wenn es dann Dank Copyleft nicht anders geht ist es am Ende meist doch kein Problem. Ohne Copyleft hätte die Welt den Code aber mit hoher Wahrscheinlichkeit nie zu Gesicht bekommen.
Ein prominentes Beispiel hierfür ist der Objective-C Übersetzer im gcc. Ohne der GPL hätte Apple diesen vermutlich nie unter einer freien Lizenz veröffentlicht.
Aus meiner Sicht ist das ein schlechtes Beispiel. Apple hat auch die gcc-Alternative Clang unter einer freien Lizenz veröffentlicht: http://en.wikipedia.org/wiki/Clang
Fabian
On Mon, 15 Sep 2014 13:56:38 +0200 Fabian Keil wrote:
Bjoern Schiessle schiessle@fsfe.org wrote:
Ein prominentes Beispiel hierfür ist der Objective-C Übersetzer im gcc. Ohne der GPL hätte Apple diesen vermutlich nie unter einer freien Lizenz veröffentlicht.
Aus meiner Sicht ist das ein schlechtes Beispiel. Apple hat auch die gcc-Alternative Clang unter einer freien Lizenz veröffentlicht: http://en.wikipedia.org/wiki/Clang
Das ist ein anderer Fall zu einer anderen Zeit, vermutlich mit einer anderen Motivation und anderen Entscheidungsträgern.
Das lässt sich nicht auf die damalige Objective-C Entscheidung übertragen. Es ist historisch belegt, wir hätten heute mit sehr hoher Wahrscheinlichkeit keinen Objective-C Übersetzer im GCC wenn der GCC nicht unter der GPL stehen würde.
Viele Grüße, Björn
Am 14.09.2014 21:51, schrieb Luc Saffre:
Hallo,
ich bin der Autor von Lino, eines Frameworks in Python, das auf Django und Sencha ExtJS aufbaut. Django ist BSD, ExtJS ist GPL.
Ich weiß nicht, was Du unter "aufbauen" verstehst, wenn Dein Werk jedoch ein "abgeleitetes" Werk von ExtJS ist, musst Du die GPL verwenden.
Dies ist kein Rechtsrat im Einzelfall, sondern nur eine allgemeine Belehrung zur Volksbildung.
Gruß Michael
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 15/09/14 08:31, Dr. Michael Stehmann wrote:
Am 14.09.2014 21:51, schrieb Luc Saffre:
Hallo,
ich bin der Autor von Lino, eines Frameworks in Python, das auf Django und Sencha ExtJS aufbaut. Django ist BSD, ExtJS ist GPL.
Ich weiß nicht, was Du unter "aufbauen" verstehst, wenn Dein Werk jedoch ein "abgeleitetes" Werk von ExtJS ist, musst Du die GPL verwenden.
So weit ich verstanden habe brauche ich das nicht, weil Sencha explizit die LGPL und BSD aus Ausnahme nennen:
http://www.sencha.com/legal/open-source-faq/open-source-license-exception-fo...
Eine ähnliche Ausnahme haben sie auch für Anwendungen:
http://www.sencha.com/legal/open-source-faq/open-source-license-exception-fo...
Luc
Luc Saffre luc.saffre@gmx.net Sun 2014-09-14 22:51:
Mein Lino ist bisher LGPL-lizenziert, aber ich bin möglicherweise kurz vorm Umkippen in dieser Frage, weil alles einfacher würde, wenn ich auf die BSD wechsle.
Wie Bernd schon sagt, die Entscheidung kann dir ultimativ niemand abnehmen. Nur eine kleine Denkanregung hier:
Was mich wanken macht, sind Gedanken wie:
- LGPL bedeutet, dass ich viel Zeit mit der Rechtfertigung meiner Wahl
verbringe.
Hast du zu rechtfertigen, dass du die LGPL statt der BSD-Lizenz nimmst? Bei dem Diskussionslevel leidest du ja dann an sich auf recht hohem Niveau.
Oder musst du vor Verteidigern proprietärer Software rechtfertigen, wie du deine armen Kinder ernährst? Aus der Misere hilft dir dann auch die BSD-Lizenz nicht raus.
Oder musst du dich vor ohnehin unangenehmen Zeitgenossen rechtfertigen, die von vornherein deinen Code eigentlich nur in ihre proprietären Projekte forken wollen? Dann fühle dich an den Grund erinnert, aus dem du dich für die LGPL entschieden hast.
- Es haben sich vermutlich schon einige Leute schnell wieder von Lino abgewendet, weil sie "GPL" gesehen haben. Und zwar ohne dass ich das
je erfahren werde.
Hmmm.... ich weiß nicht. Für mich ist das mit der freien Lizenz immer ein binäre Entscheidung, innerhalb der freien Lizenzen bin ich da selbst nicht wählerisch. Meinst du Leute trauen sich nicht ein Projekt auf deiner Library basieren zu lassen? Das wäre dann ja nur Unkenntnis. Ein gut platzierter Erklärungssatz auf der Webseite kann das schon ändern. Denkst du, dass potentielle Zuarbeitende sich von dem Projekt abgewendet haben? Welche Zuarbeit erhoffst du dir denn von jemandem, der eine starke Copyleft-Lizenz gegenüber einer schwachen ablehnt?
- Die Idee hinter der GPL mag ja im Endeffekt stimmen, aber bis alle Menschen das eingesehen haben, wird (1) noch viel Zeit vergehen
und (2) wird mein Lino das weder entscheiden noch beschleunigen.
Dem letzten Punkt stimme ich nicht ganz zu. Jede Software ist Teil des Umfeldes, das die Wahrnehmung von jungen wie alten Entwicklern bestimmt. Viele kleine Projekte schaffen die Normalität und das Brauchtum, das die Marc Zuckerbergs und Larry Pages der nächsten Jahre umgibt (unabhängig davon, wie viel oder wenig sympathisch dir die Genannten jetzt sind).
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 15/09/14 17:44, Paul Hänsch wrote:
Hast du zu rechtfertigen, dass du die LGPL statt der BSD-Lizenz nimmst? Bei dem Diskussionslevel leidest du ja dann an sich auf recht hohem Niveau.
Oder musst du vor Verteidigern proprietärer Software rechtfertigen, wie du deine armen Kinder ernährst? Aus der Misere hilft dir dann auch die BSD-Lizenz nicht raus.
Oder musst du dich vor ohnehin unangenehmen Zeitgenossen rechtfertigen, die von vornherein deinen Code eigentlich nur in ihre proprietären Projekte forken wollen? Dann fühle dich an den Grund erinnert, aus dem du dich für die LGPL entschieden hast.
Ich meine vor allem Rechtfertigung vor mir selber. Und das ist es ja gerade, was ich dokumentieren will: weshalb ich mich für die LGPL entschieden habe.
Luc
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 15/09/14 17:44, Paul Hänsch wrote:
Luc Saffre luc.saffre@gmx.net Sun 2014-09-14 22:51:
- Es haben sich vermutlich schon einige Leute schnell wieder von
Lino abgewendet, weil sie "GPL" gesehen haben. Und zwar ohne dass ich das je erfahren werde.
Hmmm.... ich weiß nicht. Für mich ist das mit der freien Lizenz immer ein binäre Entscheidung, innerhalb der freien Lizenzen bin ich da selbst nicht wählerisch.
Hier ein Beispiel: ich hatte der Django-Community eine Methode "non-serializing fixtures" vorgeschlagen:
https://code.djangoproject.com/ticket/10664
Im Kommentar 7 nennt aaugustin zunächst einige ganz plausible Beobachtungen, bricht dann aber die Diskussion ab indem er hinzufügt "EDIT: I just noticed Lino is licensed under the GPL, so we can't merge it anyway."
Luc
Hi,
Am 16.09.2014 um 03:43 schrieb Luc Saffre:
On 15/09/14 17:44, Paul Hänsch wrote:
Luc Saffre luc.saffre@gmx.net Sun 2014-09-14 22:51:
- Es haben sich vermutlich schon einige Leute schnell wieder von
Lino abgewendet, weil sie "GPL" gesehen haben. Und zwar ohne dass ich das je erfahren werde.
Hmmm.... ich weiß nicht. Für mich ist das mit der freien Lizenz immer ein binäre Entscheidung, innerhalb der freien Lizenzen bin ich da selbst nicht wählerisch.
Hier ein Beispiel: ich hatte der Django-Community eine Methode "non-serializing fixtures" vorgeschlagen:
https://code.djangoproject.com/ticket/10664
Im Kommentar 7 nennt aaugustin zunächst einige ganz plausible Beobachtungen, bricht dann aber die Diskussion ab indem er hinzufügt "EDIT: I just noticed Lino is licensed under the GPL, so we can't merge it anyway."
Ich glaube hier liegen Fehlannahmen vor.
Django steht unter einer BSD-Lizenz. Wenn jemand Code zu Django beitragen will, der auch dort aufgenommen wird, stellt sie/er den Code folglich unter die selbe Lizenz (sonst wird er nicht aufgenommen).
Lino steht unter (L)GPL. Wenn jemand zu Lino beitragen will ...
Wenn jetzt du, Luc, dem Django-Projekt Code aus dem Lino-Projekt übertragen willst, dessen Urheber du bist, dann darfst du das auch gerne unter der BSD-Lizenz machen. Das hat aber keinerlei Auswirkungen auf dein anderes Projekt Lino.
Wenn der Code-CLOB ein Eigenleben führen kann, dann macht es vielleicht sogar Sinn, diesen als eigenes Projekt zu veröffentlichen, mit einer Lizenz die für beide Projekte passt.
Du allein entscheidest mit jeder Mitarbeit, welche Lizenz dein Werk erhält. Problematisch ist es halt nur, wenn du nicht der alleinige Urheber bist, dann musst du dir das OK deiner Mitstreiter holen.
Kurz gesagt, es ist nicht so, dass jede Zeile Code einen Fingerprint trägt und mit diesem Fingerprint nur eine Lizenz verbunden sein darf. :)
Viele Grüße Christian
On 16/09/14 19:09, Christian Kalkhoff wrote:
Am 16.09.2014 um 03:43 schrieb Luc Saffre:
On 15/09/14 17:44, Paul Hänsch wrote:
Luc Saffre luc.saffre@gmx.net Sun 2014-09-14 22:51:
- Es haben sich vermutlich schon einige Leute schnell wieder von
Lino abgewendet, weil sie "GPL" gesehen haben. Und zwar ohne dass ich das je erfahren werde.
Hmmm.... ich weiß nicht. Für mich ist das mit der freien Lizenz immer ein binäre Entscheidung, innerhalb der freien Lizenzen bin ich da selbst nicht wählerisch.
Im Kommentar 7 nennt aaugustin zunächst einige ganz plausible Beobachtungen, bricht dann aber die Diskussion ab indem er hinzufügt "EDIT: I just noticed Lino is licensed under the GPL, so we can't merge it anyway."
Ich glaube hier liegen Fehlannahmen vor.
Django steht unter einer BSD-Lizenz. Wenn jemand Code zu Django beitragen will, der auch dort aufgenommen wird, stellt sie/er den Code folglich unter die selbe Lizenz (sonst wird er nicht aufgenommen).
Das stimmt natürlich, danke für Präzisierung.
Das habe ich damals dann übrigens sogar getan: diesen Teil aus Lino rausgekoppelt und unter BSD veröffentlicht. Das war viel Arbeit und hat im Endeffekt gar nichts gebracht, denn als es getan war, hatte ich keine Lust, das jetzt auch noch für die Django-Entwickler aufzubereiten und zu dokumentieren, weil ich keine Hoffnung mehr hatte, dass die sich dafür interessieren würden.
Was ich sagen wollte: die LGPL ist in Situationen wie dieser ein echtes Hindernis für die Zusammenarbeit zwischen Lino und Django. Und weil Lino funktional ziemlich weit mit Django verzahnt ist, wäre mehr Zusammenarbeit eigentlich wünschenswert.
Ich denke, dass dieser vorige Absatz nun auch endlich der Auslöser ist, weshalb ich voraussichtlich Lino von der LGPL unter die BSD setzen werde. Ein paarmal drüber schlafen werde ich trotzdem noch.
Danke für euer aller Feedback, das mir für meine Entscheidungsfindung sehr wichtig war!
Luc
On Tue, 16 Sep 2014 18:36, luc.saffre@gmx.net said:
Was ich sagen wollte: die LGPL ist in Situationen wie dieser ein echtes Hindernis für die Zusammenarbeit zwischen Lino und Django. Und weil Lino
Da gibt es doch eine einfache Möglichkeit. Wenn ich es für sinnvoll halte, stelle ich einzelne Files aus meinen Projekten unter eine Dual LGPL/BSD Lizenz. Am Besten geht das, falls es sich um einen geschlossenen Funktionsumfang handelt - dann kann man das unter dieser Dual Lizenz einfach weiter pflegen. Das Herauspflücken von Code unter der einen oder andere Lizenz geht aber auch (je nach Formulierung der Dual-Lizenz). Oder aber einfach unter CC-0 stellen.
Salam-Shalom,
Werner
Hi Werner,
Am 16.09.2014 um 21:06 schrieb Werner Koch:
On Tue, 16 Sep 2014 18:36, luc.saffre@gmx.net said:
Was ich sagen wollte: die LGPL ist in Situationen wie dieser ein echtes Hindernis für die Zusammenarbeit zwischen Lino und Django. Und weil Lino
Da gibt es doch eine einfache Möglichkeit. Wenn ich es für sinnvoll halte, stelle ich einzelne Files aus meinen Projekten unter eine Dual LGPL/BSD Lizenz. Am Besten geht das, falls es sich um einen geschlossenen Funktionsumfang handelt - dann kann man das unter dieser Dual Lizenz einfach weiter pflegen. Das Herauspflücken von Code unter der einen oder andere Lizenz geht aber auch (je nach Formulierung der Dual-Lizenz). Oder aber einfach unter CC-0 stellen.
Das klingt auch nach einer guten Idee. Machst du dann irgendetwas spezielles mit den File-Headern oder packst du nur den von z.B. BSD und GPL untereinander?
Gibt es eigentlich sowas wie eine Dual-Licensing FAQ (mit mehreren Free Software Lizenzen) irgendwo?
Viele Grüße Christian
On Wed, 17 Sep 2014 09:40, softmetz@fsfe.org said:
Das klingt auch nach einer guten Idee. Machst du dann irgendetwas spezielles mit den File-Headern oder packst du nur den von z.B. BSD und GPL untereinander?
* This file is part of GnuPG. * * GnuPG is free software; you can redistribute it and/or modify * it under the terms of the GNU General Public License as published by * the Free Software Foundation; either version 3 of the License, or * (at your option) any later version. * * GnuPG is distributed in the hope that it will be useful, * but WITHOUT ANY WARRANTY; without even the implied warranty of * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the * GNU General Public License for more details. * * You should have received a copy of the GNU General Public License * along with this program; if not, see http://www.gnu.org/licenses/. * !* ALTERNATIVELY, this file may be distributed under the terms of the !* following license, in which case the provisions of this license are !* required INSTEAD OF the GNU General Public License. If you wish to !* allow use of your version of this file only under the terms of the !* GNU General Public License, and not to allow others to use your !* version of this file under the terms of the following license, !* indicate your decision by deleting this paragraph and the license !* below. * * Redistribution and use in source and binary forms, with or without * modification, are permitted provided that the following conditions * are met: * 1. Redistributions of source code must retain the above copyright * notice, and the entire permission notice in its entirety, * including the disclaimer of warranties. * 2. Redistributions in binary form must reproduce the above copyright * notice, this list of conditions and the following disclaimer in the * documentation and/or other materials provided with the distribution. * 3. The name of the author may not be used to endorse or promote * products derived from this software without specific prior * written permission. * * THIS SOFTWARE IS PROVIDED ``AS IS'' AND ANY EXPRESS OR IMPLIED * WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES * OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE * DISCLAIMED. IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR ANY DIRECT, * INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES * (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR * SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, * STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) * ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED * OF THE POSSIBILITY OF SUCH DAMAGE.
Man kann das aber auch anders gestalten - so dass beide Lizenzen gleichberechtigt sind. Hatte ich auch mal irgendwo gesehen.
Gibt es eigentlich sowas wie eine Dual-Licensing FAQ (mit mehreren Free Software Lizenzen) irgendwo?
Ich glaube unter softwarefreeedom.org hatte ich mal was gesehen.
Shalom-Salam,
Werner