Hallo,
vielleicht kann mir hier jemand einen Rat geben?
Ich bin Autor diverser freier Softwareprojekte, vor allem ein in Python geschriebenes Framework namens Lino. Der Code enthält auch (wie in Python üblich) ein Verzeichnis "docs", in dem die komplette Dokumentation steht. All das ist mein geistiges Werk und ich will, dass es frei ist.
Das gesamte Projekt habe ich auf GitHub unter der GPLv3 veröffentlicht: https://github.com/lsaffre/lino
Jetzt lese ich (auf http://www.gnu.org/licenses/licenses.en.html) folgendes:
Documentation for free software should be free documentation, so that people can redistribute it and improve it along with the software it describes. To make it free documentation, you need to release it under a free documentation license. We normally use the GNU Free Documentation License (GNU FDL), but occasionally we use other free documentation licenses.
Heißt das, dass meine Verfahrensweise nicht ganz korrekt ist? Ist meine Dokumentation nicht automatisch auch frei, wenn sie unter der GPL steht? Was kann ich tun, damit es korrekt ist?
Vielen Dank im Voraus für Kommentare und Hinweise! Luc
Hi Luc,
Jetzt lese ich (auf http://www.gnu.org/licenses/licenses.en.html) folgendes:
Documentation for free software should be free documentation, so that people can redistribute it and improve it along with the software it describes. To make it free documentation, you need to release it under a free documentation license. We normally use the GNU Free Documentation License (GNU FDL), but occasionally we use other free documentation licenses.
Heißt das, dass meine Verfahrensweise nicht ganz korrekt ist? Ist meine Dokumentation nicht automatisch auch frei, wenn sie unter der GPL steht?
Nein, ist absolut in Ordnung!
Die GNU FDL hat selbst zahlreiche Probleme. Deshalb würde ich persönlich für nichts verwenden!
Gruß Michael
On 29/05/14 10:17, Michael Kesper wrote:
Heißt das, dass meine Verfahrensweise nicht ganz korrekt ist? Ist meine Dokumentation nicht automatisch auch frei, wenn sie unter der GPL steht?
Nein, ist absolut in Ordnung!
Die GNU FDL hat selbst zahlreiche Probleme. Deshalb würde ich persönlich für nichts verwenden!
Danke. Na, dann bin ich aber erleichtert. So ist es natürlich am einfachsten für mich.
Luc
Am Donnerstag, 29. Mai 2014 09:48:41 schrieb Luc Saffre:
On 29/05/14 10:17, Michael Kesper wrote:
Heißt das, dass meine Verfahrensweise nicht ganz korrekt ist? Ist meine Dokumentation nicht automatisch auch frei, wenn sie unter der GPL steht?
Nein, ist absolut in Ordnung!
Die GNU FDL hat selbst zahlreiche Probleme. Deshalb würde ich persönlich für nichts verwenden!
Michael, welche denn?
Danke. Na, dann bin ich aber erleichtert. So ist es natürlich am einfachsten für mich.
Bei Dokumentation und Anleitung, welche nahe am Quelltext oder der Anwendung dran ist -- z.B. im gleichen Quelltextverzeichnis verwaltet wird -- läßt sich auch die Hauptlizenz der Freien Software nehmen. Ansonsten sind die CC-BY oder CC-BY-SA auch schöne Lizenzen.
Die GNU FDL eignet sich aus meiner Sicht vor allem für umfangreichere, abgeschlossenere Werke.
Gruß, Bernhard
* Bernhard Reiter:
Die GNU FDL hat selbst zahlreiche Probleme. Deshalb würde ich persönlich für nichts verwenden!
Michael, welche denn?
Werke, die der GNU FDL unterliegen, sind keine freie Software, so daß man nicht beliebig zwischen (Kommentaren im) Quellcode und der Dokumentation hin- und herkopieren kann. Das ist in Zeiten von Javadoc, Doxygen usw. schon eine gewisse Einschränkung.
Am Donnerstag, 5. Juni 2014 23:18:29 schrieb Florian Weimer:
Werke, die der GNU FDL unterliegen, sind keine freie Software,
Klar, es sollte ja auch eine Lizenz für "freie Dokumentation" sein. Und Dokumentation und Software unterscheiden sich in der juristischen Handhabung halt.
so daß man nicht beliebig zwischen (Kommentaren im) Quellcode und der Dokumentation hin- und herkopieren kann. Das ist in Zeiten von Javadoc, Doxygen usw. schon eine gewisse Einschränkung.
Wenn das nötig ist, dann passt die von Dir gemeinte "Dokumentation" eher auf Software und sollte meiner Ansicht nach auch unter eine Software-Lizenz stehen.
On Thu, 5 Jun 2014 23:18, fw@deneb.enyo.de said:
Werke, die der GNU FDL unterliegen, sind keine freie Software, so daß man nicht beliebig zwischen (Kommentaren im) Quellcode und der Dokumentation hin- und herkopieren kann. Das ist in Zeiten von Javadoc, Doxygen usw. schon eine gewisse Einschränkung.
Genau. Beispielsweise ist die Dokumentation eines Public API bei mir sowohl in den Sourcen als auch - leicht überarbeitet - im Manual. Würde das Manual nun unter der FDL stehen, so könnte ich Änderungen nicht mehr beliebig zwischen Source und Manual kopieren. Gut, für die FSF ist das wohl kein Problem, da sie meistens Copyright Assignments verlangt und als Holder des Copyrights hat man da keine wirklichen Probleme. Die Copyright Assignments gehören ja inzwischen doch eher zum alten Eisen und behindern ahnlich wie die FDL.
Ferner kann man z.B. einen kleinen, aber urheberrechtlich relevanten Teil, nicht aus der Dokumentation nehmen und in ein beliebiges anderes HOWTO, FAQ, Wiki(pedia) übernehmen. Selbst dann, wenn das Ziel-Werk auch unter der FDL steht, muß man die gesamte History Section mit kopieren und dafür sorgen das der ellenlange Lizenztext auch im Ziel-Werk vorhanden ist.
Viele weitere Argumente findet man in den uralten Diskussionen auf den Debianlisten. Manchmal kommt mir die FSF so verbohrt vor, wie die ewig gestrigen AKW-Befürworter.
FDL - Nein Danke,
Werner
Am Freitag, 6. Juni 2014 18:07:16 schrieb Werner Koch:
Copyright Assignments gehören ja inzwischen doch eher zum alten Eisen und behindern ahnlich wie die FDL.
Ich glaube, dass ein Konzept, wie das Fiduciary License Agreement weiterhin eine gute Idee ist. Vermutlich ist die Idee ihrere Zeit ein paar Jahre voraus, aber die Problem mit einem juristisch nicht mehr pflegbaren Codebasis gibt es früher oder später.
Bernhard
On Wed, 11 Jun 2014 16:46, reiter@fsfeurope.org said:
ein paar Jahre voraus, aber die Problem mit einem juristisch nicht mehr pflegbaren Codebasis gibt es früher oder später.
Wieso? Das einzige Problem ist doch, daß man die Lizenz nicht mehr von GPL auf LGPL o.ä. andern kann. Das sehe ich nicht als gravierenden Nachteil für freie Software an. Ja, GPLv[23]only wäre problematisch, aber man sollte ja sowieso nur GPLv[23]+ benutzen.
Salam-Shalom,
Werner
Am Mittwoch, 11. Juni 2014 18:48:39 schrieb Werner Koch:
On Wed, 11 Jun 2014 16:46, reiter@fsfeurope.org said:
ein paar Jahre voraus, aber die Problem mit einem juristisch nicht mehr pflegbaren Codebasis gibt es früher oder später.
Wieso? Das einzige Problem ist doch, daß man die Lizenz nicht mehr von GPL auf LGPL o.ä. andern kann.
Ja und andere Lizenzänderungen gehen auch nicht. Auch das juristische Sanktionieren wenn jemand gegen die Lizenz verstößt wird schwieriger.
Das sehe ich nicht als gravierenden Nachteil für freie Software an. Ja, GPLv[23]only wäre problematisch, aber man sollte ja sowieso nur GPLv[23]+ benutzen.
Wir müssten über alle Möglichkeiten nachdenken, bei denen eine Lizenzänderung für Freie Software gut wäre. Da gibt es schon ein paar. Runter von GNU AGPL auf GNU GPL oder Apache 2.0 z.B. oder das Hinzunehmen von Ausnahmen. Was ist wenn die FSF (als Herausgeber von der GNU Lizenzen) bestimmte juristische Löcher nicht in angemessener Zeit stopft oder durch die handelden Personen doch zu sehr auf die Interessen von Großunternehmen achtet.
On Thu, 12 Jun 2014 14:35, reiter@fsfeurope.org said:
Ja und andere Lizenzänderungen gehen auch nicht.
Doch, man kann auf eine neuere GPL Version updaten.
Auch das juristische Sanktionieren wenn jemand gegen die Lizenz verstößt wird schwieriger.
Harald und Till habe bereits gezeigt, daß das kein Argument mehr ist.
Wir müssten über alle Möglichkeiten nachdenken, bei denen eine Lizenzänderung für Freie Software gut wäre. Da gibt es schon ein paar. Runter von GNU AGPL
Wenn es denn unbedingt sein muss, dann geht es mit einigen Aufwand auch ohne CAs. Jean-Baptiste Kempf hat das für VLC gezeigt.
Salam-Shalom,
Werner
Am Donnerstag, 12. Juni 2014 15:16:08 schrieb Werner Koch:
On Thu, 12 Jun 2014 14:35, reiter@fsfeurope.org said:
Ja und andere Lizenzänderungen gehen auch nicht.
Doch, man kann auf eine neuere GPL Version updaten.
Das schränkt die Möglichkeiten ein. Wer auf der GNU AGPL ist, möchte vielleicht doch irgendwann GNU GPL, GNU LGPL oder die von der FSF empfohlene Apache 2.0 haben. Oder die neue GNU GPL Version kommt viel zu spät. Das hat es schon mehrmals gegeben.
Auch das juristische Sanktionieren wenn jemand gegen die Lizenz verstößt wird schwieriger.
Harald und Till habe bereits gezeigt, daß das kein Argument mehr ist.
Sie haben wichtige Arbeit gemacht und gezeigt, dass jemand mit einem größeren Anteil an exklusiven Urheberrechten seine Recht verteidigen kann. Trotzdem war die Arbeit schwieriger, weil Linux (der bekannte Betriebssystemkern) nicht juristisch pflegbar ist. Wir wissen nicht wann dieses Problem anfängt in der Zukunft Auswirkungen zu zeigen, aber es könnte durchaus passieren und unangenehm sein. Die SCO Geschichte zeigt, dass es früher oder später jemanden geben wird, der eine juristische Lüche ausnutzen wird, wenn er Geld wittert.
Wir müssten über alle Möglichkeiten nachdenken, bei denen eine Lizenzänderung für Freie Software gut wäre. Da gibt es schon ein paar. Runter von GNU AGPL
Wenn es denn unbedingt sein muss, dann geht es mit einigen Aufwand auch ohne CAs. Jean-Baptiste Kempf hat das für VLC gezeigt.
Den Fall kenne ich zu wenig, hast Du da einen guten Überblicksartikel dazu?
Gruß, Bernhard
On Tue, 17 Jun 2014 10:16, reiter@fsfeurope.org said:
Wenn es denn unbedingt sein muss, dann geht es mit einigen Aufwand auch ohne CAs. Jean-Baptiste Kempf hat das für VLC gezeigt.
Den Fall kenne ich zu wenig, hast Du da einen guten Überblicksartikel dazu?
Ende 2011: http://www.videolan.org/press/lgpl-libvlc.html
Shalom-Salam,
Werner
Am Dienstag, 17. Juni 2014 14:16:26 schrieb Werner Koch:
On Tue, 17 Jun 2014 10:16, reiter@fsfeurope.org said:
Wenn es denn unbedingt sein muss, dann geht es mit einigen Aufwand auch ohne CAs. Jean-Baptiste Kempf hat das für VLC gezeigt.
Den Fall kenne ich zu wenig, hast Du da einen guten Überblicksartikel dazu?
Danke fürs Nennen. Es steht aber wirklich wenig drin, darüber, wie schwierig oder leicht es im Detail war. Mich würde auch interessieren, wie die juristische Einschätzung war.
On Fri, 20 Jun 2014 09:07, reiter@fsfeurope.org said:
Danke fürs Nennen. Es steht aber wirklich wenig drin, darüber, wie schwierig oder leicht es im
Wir hatten auf den internen FSFE Listen darüber gesprochen und Jean-Baptiste hat das alles im Gespräch detailiert erklärt.
wie die juristische Einschätzung war.
Wenn alle Rechteinhaber zustimmen, ist eine Lizenzänderungen nunmal kein Problem.
Salam-Shalom,
Werner
Hallo,
Am 11.06.2014 16:46, schrieb Bernhard Reiter:
Am Freitag, 6. Juni 2014 18:07:16 schrieb Werner Koch:
Copyright Assignments gehören ja inzwischen doch eher zum alten Eisen und behindern ahnlich wie die FDL.
Ich glaube, dass ein Konzept, wie das Fiduciary License Agreement weiterhin eine gute Idee ist. Vermutlich ist die Idee ihrere Zeit ein paar Jahre voraus, aber die Problem mit einem juristisch nicht mehr pflegbaren Codebasis gibt es früher oder später.
Vielleicht interessant in dem Zusammenhang: http://ebb.org/bkuhn/blog/2014/06/09/do-not-need-cla.html
Gruß Michael
On Thu, 12 Jun 2014 16:37, mkesper@fsfe.org said:
Vielleicht interessant in dem Zusammenhang: http://ebb.org/bkuhn/blog/2014/06/09/do-not-need-cla.html
Denn Qrcc wollte ich nun gerade nicht erwähnen. Auch wenn er wohl meine Position unterstreicht.
Shalom-Salam,
Werner
Am Donnerstag, 12. Juni 2014 19:15:27 schrieb Werner Koch:
On Thu, 12 Jun 2014 16:37, mkesper@fsfe.org said:
Vielleicht interessant in dem Zusammenhang: http://ebb.org/bkuhn/blog/2014/06/09/do-not-need-cla.html
Denn Qrcc wollte ich nun gerade nicht erwähnen. Auch wenn er wohl meine Position unterstreicht.
Nee, nicht wirklich.
Herr Kuhn wendet sich gegen eine bestimmte Form eines Vertrags (den er CLA nennt und der sehr amerikanisch ist), um dann für den Abschluss anderer Art Verträge zu argumentieren (den er DCO nennt). Dann bringt er noch das Argument: "was schon 35 Jahr so gemacht worden ist, kann nicht falsch sein".
Ich finde es auch richtig nicht die Anwälte nicht alles im amerikanischen Stil machen zu lassen, aber die im Artikel geäußerte Position ist aus meiner Sicht zu kurz gedacht.
On Tue, 17 Jun 2014 10:05, reiter@fsfeurope.org said:
(den er CLA nennt und der sehr amerikanisch ist), um dann für den
z.B. Standard FSF copyright assignment.
Abschluss anderer Art Verträge zu argumentieren (den er DCO nennt).
Also wohl was was Linux, Samba und GnuPG benutzen:
GnuPG Developer's Certificate of Origin. Version 1.0 =====================================================
By making a contribution to the GnuPG project, I certify that:
(a) The contribution was created in whole or in part by me and I have the right to submit it under the free software license indicated in the file; or
(b) The contribution is based upon previous work that, to the best of my knowledge, is covered under an appropriate free software license and I have the right under that license to submit that work with modifications, whether created in whole or in part by me, under the same free software license (unless I am permitted to submit under a different license), as indicated in the file; or
(c) The contribution was provided directly to me by some other person who certified (a), (b) or (c) and I have not modified it.
(d) I understand and agree that this project and the contribution are public and that a record of the contribution (including all personal information I submit with it, including my sign-off) is maintained indefinitely and may be redistributed consistent with this project or the free software license(s) involved.
Signed-off-by: [Your name and mail address]
Salam-Shalom,
Werner