Liebe Liste,
ich bin heute auf eine interessante Abwandlung einer Standard-Lizenz gestoßen. Der Lizenztext ist zunächst identisch zur 3-Klausel-BSD-Lizenz, enthält jedoch zusätzlich die folgende 4. Klausel:
| Any modification to the source code MUST be made available to [COMPANY] | and contributors free of charge and under the same conditions as stated | in this license.
Ich habe dazu folgende Fragen:
1) Kann man Software unter dieser Lizenz immer noch als "Open Source" beziehungsweise "Freie Software" bezeichnen, oder ist die Einschränkung durch die 4. Klausel zu stark?
2) Falls es kein Open Source mehr ist, wie kategorisiert man diese am besten, ohne gleich "proprietär" zu sagen? Denn mit "proprietär" würde man sie auf eine Stufe stellen mit den klassichem "Ihr dürft nichts. Disassemblieren verboten!" Das erscheint mir dann doch ungerechtfertigt. Gibt es dafür Fachbegriffe? Mir würden spontan "Fast Freie Software" und "Almost Open Source" einfallen, aber ich glaube, diese treffen den Kern nicht ganz.
3) Falls es kein Open Source ist, wäre obige Lizenz trotzdem mit der GPLv3 vereinbar?
4) Gibt es andere Fälle, in denen Autoren (bzw. Firmen) eine ähnliche abgewandelte BSD-Lizenz verwenden? Es gibt doch sicher sehr viele Leute, denen obige Abwandlung naheliegend erscheint. Gibt es zu dem Thema bereits bekannte Fälle, Diskussion oder gar wissenschaftliche Ausarbeitungen?
Vielen Dank schon einmal!
Gruß Volker
Am Dienstag, 29. Oktober 2013 14:51:06 schrieb Volker Grabsch:
Liebe Liste,
ich bin heute auf eine interessante Abwandlung einer Standard-Lizenz gestoßen. Der Lizenztext ist zunächst identisch zur 3-Klausel-BSD-Lizenz, enthält jedoch
zusätzlich die folgende 4. Klausel: | Any modification to the source code MUST be made available to [COMPANY] | and contributors free of charge and under the same conditions as | stated in this license.
Ich habe dazu folgende Fragen:
Kann man Software unter dieser Lizenz immer noch als "Open Source" beziehungsweise "Freie Software" bezeichnen, oder ist die Einschränkung durch die 4. Klausel zu stark?
Es ist dann keine Freie Software mehr (und da Freie Software == Open Source == FLOSS == FOSS == Libre Software), auch kein Open Source.
Das "made available" ist nicht immer erfüllbar, damit ist Freiheit 4 (Verbessern) verletzt in Zusammenhang mit Freiheit 1 (auf immer). Gehen wir davon aus COMPANY acceptiert die "Sendung" der Änderung nicht, oder verschwindet, dann kannst Du die Bedingung nicht mehr erfüllen. COMPANY kann sich beispielsweise entscheiden eine Änderung nicht "anzunehmen" (im Sinne eines Briefes).
Um die Software frei zu machen, müssten Empfänger der Software unabhängig von COMPANY damit weitermachen können. Die Klausel verbietet das.
Falls es kein Open Source mehr ist, wie kategorisiert man diese am besten, ohne gleich "proprietär" zu sagen? Denn mit "proprietär" würde man sie auf eine Stufe stellen mit den klassichem "Ihr dürft nichts. Disassemblieren verboten!" Das erscheint mir dann doch ungerechtfertigt. Gibt es dafür Fachbegriffe? Mir würden spontan "Fast Freie Software" und "Almost Open Source" einfallen, aber ich glaube, diese treffen den Kern nicht ganz.
Nein, "proprietär" ist da meiner Ansicht nach passend. Vielleicht "gerade noch proprietär".
Falls es kein Open Source ist, wäre obige Lizenz trotzdem mit der GPLv3 vereinbar?
Natürlich nicht. Auch nicht mit GNU GPLv2. Ist ja eine weitere Einschränkung (Pflicht).
Gibt es andere Fälle, in denen Autoren (bzw. Firmen) eine ähnliche abgewandelte BSD-Lizenz verwenden? Es gibt doch sicher sehr viele Leute, denen obige Abwandlung naheliegend erscheint. Gibt es zu dem Thema bereits bekannte Fälle, Diskussion oder gar wissenschaftliche Ausarbeitungen?
Ja, so was habe ich bestimmt schon ein paar Mal gesehen. Diskussionen dazu auch. Aber der Fall ist relativ klar. Was das wissenschaftlich auszuarbeiten sein sollte ist mir nicht klar, höchstens noch juristisch/praktisch. Ich erinnere mich dunkel, dass sogar die FSF dazu mal Stellung genommen hat. Vielleicht ist in den FAQ was.
Gruß, Bernhard
On Thursday 31 October 2013 12:22:52 Bernhard Reiter wrote:
Am Dienstag, 29. Oktober 2013 14:51:06 schrieb Volker Grabsch:
zusätzlich die folgende 4. Klausel: | Any modification to the source code MUST be made available to [COMPANY] | and contributors free of charge and under the same conditions as | stated in this license.
Ich habe dazu folgende Fragen:
Kann man Software unter dieser Lizenz immer noch als "Open Source" beziehungsweise "Freie Software" bezeichnen, oder ist die Einschränkung durch die 4. Klausel zu stark?
Es ist dann keine Freie Software mehr (und da Freie Software == Open Source == FLOSS == FOSS == Libre Software), auch kein Open Source.
Das "made available" ist nicht immer erfüllbar, damit ist Freiheit 4 (Verbessern) verletzt in Zusammenhang mit Freiheit 1 (auf immer). Gehen wir davon aus COMPANY acceptiert die "Sendung" der Änderung nicht, oder verschwindet, dann kannst Du die Bedingung nicht mehr erfüllen. COMPANY kann sich beispielsweise entscheiden eine Änderung nicht "anzunehmen" (im Sinne eines Briefes).
Um die Software frei zu machen, müssten Empfänger der Software unabhängig von COMPANY damit weitermachen können. Die Klausel verbietet das.
Also diese Auslegung ist schon *sehr* mutwillig. Ich kann ja auch nicht den kommunalen Wasserversorger verklagen, weil er seiner Versorgungspflicht nicht nachkommt und gleichzeitig nicht zulassen, dass der Bagger auf mein Grundstück kommt.
Natürlich ist die Formulierung "must be made available" sehr schwammig und daher bedenklich. Bei strenger Auslegung als Bringschuld wird auch sicher die Frage interessant, in wie weit man den neuen Rechteinhaber ausfindig machen muss, sollte der ursprüngliche „verschwinden“. Beliebige eskalieren lässt sich die Sache aber IMO nicht.
lg, Johannes
Am Donnerstag, 31. Oktober 2013 15:48:27 schrieb Johannes Zarl:
Um die Software frei zu machen, müssten Empfänger der Software unabhängig von COMPANY damit weitermachen können. Die Klausel verbietet das.
Also diese Auslegung ist schon *sehr* mutwillig. Ich kann ja auch nicht den kommunalen Wasserversorger verklagen, weil er seiner Versorgungspflicht nicht nachkommt und gleichzeitig nicht zulassen, dass der Bagger auf mein Grundstück kommt.
Das würde ja zeitlich vielleicht getrennt voneinander stattfinden. Sprich: Der Bagger kann nicht aufs Grundstück, weil große Gräben drum sind und fährt wieder heim. 1 Jahr später wird geklagt und dann ist der Nachweis, dass es der Baggerfahrer probiert hat nicht mehr so leicht zu führen.
Natürlich ist die Formulierung "must be made available" sehr schwammig und daher bedenklich. Bei strenger Auslegung als Bringschuld wird auch sicher die Frage interessant, in wie weit man den neuen Rechteinhaber ausfindig machen muss, sollte der ursprüngliche „verschwinden“. Beliebige eskalieren lässt sich die Sache aber IMO nicht.
So habe ich die damalige Diskussion in Erinnerung, findet sich sicherlich wieder. Leuchtet mir auch auch ein, wenn ich ohne Interaktion mit jemand anderen die Software nutzen will, dann muss ich in der Lage sein den Nachweis zu führen. Bei einer Veröffentlichung würde das natürlich gehen, wenn das als Hohl-Schuld verstanden würde. Sonst eher nicht, würde ich sagen.
Hallo.
Am 31.10.2013 12:22, schrieb Bernhard Reiter:
Das "made available" ist nicht immer erfüllbar, damit ist Freiheit 4 (Verbessern) verletzt in Zusammenhang mit Freiheit 1 (auf immer). Gehen wir davon aus COMPANY acceptiert die "Sendung" der Änderung nicht, oder verschwindet, dann kannst Du die Bedingung nicht mehr erfüllen. COMPANY kann sich beispielsweise entscheiden eine Änderung nicht "anzunehmen" (im Sinne eines Briefes).
Mal ein Gedankenspiel:
Mein Verständnis der GPL sagt aus, dass ich den Source-Code einer frei verfügbaren GPL-Software kopieren kann um daran Änderungen vorzunehmen. Diese veränderte Software verkaufe ich. Den Source Code der Änderungen muss ich dann nur demjenigen verfügbar machen, der meine Software kauft. Ist das richtig?
D.h. es könnte bei entsprechend loyalen Kunden passieren, dass der ursprüngliche Autor keine Chance hat, den Source-Code meiner Änderungen zu erhalten. Zumindest hat er kein Recht darauf, so lange er meine veränderte Software nicht kauft.
Ich würde also annehmen, dass mit der genannten Klausel genau dieser Fall gemeint war: Wenn jemand Änderungen macht, behält sich der ursprüngliche Autor das Recht vor, den Source-Code dieser Änderungen zu erhalten.
Mal angenommen, damit ist nicht unbedingt eine Bringschuld sondern vielmehr ein Vorbehalt des Autors gemeint, die Herausgabe von Änderungen zu verlangen.
Kann man das so formulieren, dass es echt frei oder gar GPL-kompatibel bleibt?
Gruß, Bernd
On 11/01/2013 10:12 AM, Bernd Wurst wrote:
Hallo.
Am 31.10.2013 12:22, schrieb Bernhard Reiter:
Das "made available" ist nicht immer erfüllbar, damit ist Freiheit 4 (Verbessern) verletzt in Zusammenhang mit Freiheit 1 (auf immer). Gehen wir davon aus COMPANY acceptiert die "Sendung" der Änderung nicht, oder verschwindet, dann kannst Du die Bedingung nicht mehr erfüllen. COMPANY kann sich beispielsweise entscheiden eine Änderung nicht "anzunehmen" (im Sinne eines Briefes).
Mal ein Gedankenspiel:
Mein Verständnis der GPL sagt aus, dass ich den Source-Code einer frei verfügbaren GPL-Software kopieren kann um daran Änderungen vorzunehmen. Diese veränderte Software verkaufe ich. Den Source Code der Änderungen muss ich dann nur demjenigen verfügbar machen, der meine Software kauft. Ist das richtig?
D.h. es könnte bei entsprechend loyalen Kunden passieren, dass der ursprüngliche Autor keine Chance hat, den Source-Code meiner Änderungen zu erhalten. Zumindest hat er kein Recht darauf, so lange er meine veränderte Software nicht kauft.
Ich würde also annehmen, dass mit der genannten Klausel genau dieser Fall gemeint war: Wenn jemand Änderungen macht, behält sich der ursprüngliche Autor das Recht vor, den Source-Code dieser Änderungen zu erhalten.
Es ist schon so, wie ich den GPL verstehe.
Schau mal - aus https://www.gnu.org/licenses/gpl-faq.html:
What does "written offer valid for any third party" mean in GPLv2? Does that mean everyone in the world can get the source to any GPL'ed program no matter what?
If you choose to provide source through a written offer, then anybody who requests the source from you is entitled to receive it.
If you commercially distribute binaries not accompanied with source code, the GPL says you must provide a written offer to distribute the source code later. When users non-commercially redistribute the binaries they received from you, they must pass along a copy of this written offer. This means that people who did not get the binaries directly from you can still receive copies of the source code, along with the written offer.
The reason we require the offer to be valid for any third party is so that people who receive the binaries indirectly in that way can order the source code from you.
Aus ursprüngliche Autor wirst du auch ein "valid third party" sein, und dafür muss der Autor der veränderte Version auch dir den Source-Code zu verfügung stellen, wenn du darum fragst.
Am Freitag, 1. November 2013 11:23:38 schrieb Carsten Agger:
D.h. es könnte bei entsprechend loyalen Kunden passieren, dass der ursprüngliche Autor keine Chance hat, den Source-Code meiner Änderungen zu erhalten. Zumindest hat er kein Recht darauf, so lange er meine veränderte Software nicht kauft.
Richtig. Allerdings kann der Autor auch die Kunden fragen oder es ihnen abkaufen. Denn die Kunden dürfen ja die Software weitergeben.
Ich würde also annehmen, dass mit der genannten Klausel genau dieser Fall gemeint war: Wenn jemand Änderungen macht, behält sich der ursprüngliche Autor das Recht vor, den Source-Code dieser Änderungen zu erhalten.
Es ist schon so, wie ich den GPL verstehe.
Schau mal - aus https://www.gnu.org/licenses/gpl-faq.html:
What does "written offer valid for any third party" mean in GPLv2? Does that mean everyone in the world can get the source to any GPL'ed program no matter what?
If you choose to provide source through a written offer, then anybody who requests the source from you is entitled to receive it. If you commercially distribute binaries not accompanied with source code, the GPL says you must provide a written offer to distribute the source code later. When users non-commercially redistribute the binaries they received from you, they must pass along a copy of this written offer. This means that people who did not get the binaries directly from you can still receive copies of the source code, along with the written offer. The reason we require the offer to be valid for any third party is so that people who receive the binaries indirectly in that way can order the source code from you.
Aus ursprüngliche Autor wirst du auch ein "valid third party" sein, und dafür muss der Autor der veränderte Version auch dir den Source-Code zu verfügung stellen, wenn du darum fragst.
Das stimmt nur, wenn eine "written offer" gemacht wurde. Sofern die "Kunden" im Beispiel immer den jeweiligen Quelltext bekommen, ist ein solches schriftliches Angebot nicht notwendig.
Gruß, Bernhard
Hallo.
Am 04.11.2013 14:53, schrieb Bernhard Reiter:
Am Freitag, 1. November 2013 11:23:38 schrieb Carsten Agger:
D.h. es könnte bei entsprechend loyalen Kunden passieren, dass der ursprüngliche Autor keine Chance hat, den Source-Code meiner Änderungen zu erhalten. Zumindest hat er kein Recht darauf, so lange er meine veränderte Software nicht kauft.
Richtig. Allerdings kann der Autor auch die Kunden fragen oder es ihnen abkaufen. Denn die Kunden dürfen ja die Software weitergeben.
Wie gesagt, bei (dem Verkäufer gegenüber) loyalen Kunden könnte der ursprüngliche Autor da wirklich außen vor bleiben und keine Handhabe erlangen.
Ich bin zwar einerseits ein Freund von maximal liberalen Lizenzen, kann aber den Wunsch verstehen, dass Autoren eine "ich will aber mein Recht auf alle Verbesserungen sichern"-Klausel in ihrer Lizenz haben wollen.
Ob oder wie man das formulieren kann, dass sicherlich keine Bring-Schuld gemeint ist und die Freiheit des einzelnen nicht beschränkt werden soll, steht auf einem anderen Blatt. Aber es wäre interessant, mit welcher Share-Alike-Lizenz sich so etwas darstellen lässt.
Gruß, Bernd
Am Montag, 4. November 2013 18:36:51 schrieb Bernd Wurst:
Wie gesagt, bei (dem Verkäufer gegenüber) loyalen Kunden könnte der ursprüngliche Autor da wirklich außen vor bleiben und keine Handhabe erlangen.
Genau, aber es ist für wirklich nützliche Software unwahrscheinlich und liegt nicht allein in der Hand desjenigen der etwas Verbesserte.
Ich bin zwar einerseits ein Freund von maximal liberalen Lizenzen, kann aber den Wunsch verstehen, dass Autoren eine "ich will aber mein Recht auf alle Verbesserungen sichern"-Klausel in ihrer Lizenz haben wollen.
Ja, die Idee verstehe ich auch. Leider hält die bisherige Diskussion (welche ich sah) und mitterweile ich selbst das halt nicht mehr für Freie Software.
Ob oder wie man das formulieren kann, dass sicherlich keine Bring-Schuld gemeint ist und die Freiheit des einzelnen nicht beschränkt werden soll, steht auf einem anderen Blatt. Aber es wäre interessant, mit welcher Share-Alike-Lizenz sich so etwas darstellen lässt.
Eine dauerhafte Veröffentlichung ist eine dauerhafte Pflicht, also auf Ewig nur schwer erfüllbar ist. Also sollten die Regel eine zeitnahe komplette Erfüllung vorsehen.
Und wenn ich es nicht als Bringschuld mache dann veröffentlichen klevere Leute die Software irgendwo in Polynesien auf Hindi und erledigen ihre passive Pflicht die Software dem Autor zugänglich zu machen.
Ich kann es mir also immer noch nicht vorstellen, dass mit den vier Freiheiten in der Praxis wirklich zuvereinen. Was hilft ist: a) als Autor aktiv bleiben und aktuelle Info herausbringen (schließlich muss der Autor genannt werden) damit erhöht sich die Sichtbarkeit bei Kunden und die wissen ja genau, was verändert wurde und von wem. b) wenn die Software interessant ist, dann wird der Autor die Änderungen früher oder später erhalten (durch einen vernünftigen Kunden).
Gruß, Bernhard
Offensichtlich bin ich kein Anwalt, aber ein paar Bemerkungen zur Debatte kann ich mir trotzdem nicht verkneifen:
On Tuesday 05 November 2013 16:51:47 Bernhard Reiter wrote:
Ob oder wie man das formulieren kann, dass sicherlich keine Bring-Schuld gemeint ist und die Freiheit des einzelnen nicht beschränkt werden soll, steht auf einem anderen Blatt. Aber es wäre interessant, mit welcher Share-Alike-Lizenz sich so etwas darstellen lässt.
Eine dauerhafte Veröffentlichung ist eine dauerhafte Pflicht, also auf Ewig nur schwer erfüllbar ist. Also sollten die Regel eine zeitnahe komplette Erfüllung vorsehen.
Man sollte nicht vergessen, dass eine Lizenz letztendlich nur ein Vertrag ist. „Dauerhaft“ bzw „Ewig“ ist also nicht „bis zum Ende aller Tage“ sondern bis zum Vertragsende. Der Vertrag gilt hier doch nur solange die Vorbedingung gilt: „Redistribution and use in source and binary forms, with or without modification“
Und wenn ich es nicht als Bringschuld mache dann veröffentlichen klevere Leute die Software irgendwo in Polynesien auf Hindi und erledigen ihre passive Pflicht die Software dem Autor zugänglich zu machen.
Wenn die Software am anderen Ende der Welt erfolgreich ist und du nix davon mitkriegst, gibt's ja kein Problem für dich: 1) Du hast keine direkte Konkurrenz in deinem eigenen Markt 2) Wenn die Software dort so erfolgreich wird dass die abgewandelte Fassung auch in deinem eigenen Markt bekannt wird, dann kommst Du auch zu deinem Recht der Holschuld.
Ich kann es mir also immer noch nicht vorstellen, dass mit den vier Freiheiten in der Praxis wirklich zuvereinen. Was hilft ist: a) als Autor aktiv bleiben und aktuelle Info herausbringen (schließlich muss der Autor genannt werden) damit erhöht sich die Sichtbarkeit bei Kunden und die wissen ja genau, was verändert wurde und von wem. b) wenn die Software interessant ist, dann wird der Autor die Änderungen früher oder später erhalten (durch einen vernünftigen Kunden).
Sehe ich auch so…
lg, Johannes
On 05.11.2013 17:14, Johannes Zarl wrote:
Offensichtlich bin ich kein Anwalt, aber ein paar Bemerkungen zur Debatte kann ich mir trotzdem nicht verkneifen:
On Tuesday 05 November 2013 16:51:47 Bernhard Reiter wrote:
Ob oder wie man das formulieren kann, dass sicherlich keine Bring-Schuld gemeint ist und die Freiheit des einzelnen nicht beschränkt werden soll, steht auf einem anderen Blatt. Aber es wäre interessant, mit welcher Share-Alike-Lizenz sich so etwas darstellen lässt.
Eine dauerhafte Veröffentlichung ist eine dauerhafte Pflicht, also auf Ewig nur schwer erfüllbar ist. Also sollten die Regel eine zeitnahe komplette Erfüllung vorsehen.
Man sollte nicht vergessen, dass eine Lizenz letztendlich nur ein Vertrag ist. „Dauerhaft“ bzw „Ewig“ ist also nicht „bis zum Ende aller Tage“ sondern bis zum Vertragsende. Der Vertrag gilt hier doch nur solange die Vorbedingung gilt: „Redistribution and use in source and binary forms, with or without modification“
Au "immer" und "ewig" gilt der Lizenzvertrag nicht, höchstens solange das der Lizenz zugrunde liegende Urheberrecht andauert, danach die die Software "public domain" und es bedarf keiner Lizenz mehr.
Allerdings endet der Lizenzvertrag nicht automatisch dadurch, dass der Lizenznehmer von den ihm eingeräumten Rechten keinen Gebrauch mehr macht. Vielmehr dauern zunächst diese Rechte fort und der Lizenznehmer kann jederzeit wieder von ihnen Gebrauch machen.
Gerade die in Rede stehende Klausel zeigt dies deutlich. Der Lizenznehmer kann sich von der Pflicht zur Herausgabe des Quellcodes seiner Änderungen nicht dadurch befreien, dass er erklärt, er werde das Werk in Zukunft weder nutzen noch ändern, noch mit oder ohne Änderungen weitergeben - und auch auf das Studium des Quellcodes verzichte er.
Vielmehr besteht seine vertragliche Herausgabepflicht (wie immer die im Einzelnen aussehen mag) zunächst fort.
Dies zeigt eine weitere Belastung durch dieselbe: Wenn man unter der GPL ein Werk verändert und mit dem Quellcode weitergibt, hat man seine Pflicht und Schuldigkeit getan.
Bei einer Herausgabeklausel müsste man den Quellcode der Änderung zumindest bis zum Ablauf einer Verjährung aufbewahren, es sei denn, man gibt ihn vorher zum Begünstigen der Herausgabeklausel heraus (und lässt sich eine Quittung geben).
Gruß Michael
Wo hier gerade so begeistert Lizenzen diskutiert werden, was meint ihr zu diesem Vorschlag?
Intent of the license
This section is meant to clarify the spirit of the license.
The intent of the license is to offer an alternative to open source software as specified by the OSI open source definition with the aim to generate revenue for charity. Software licensed under the CSL can be made available in source code but there is no obligation to do so, unless the open source variant OSCSL is chosen. The software is made available with guarantees about the use of revenue generated by software sales. The license will include a list of trusted third parties, usually non-profit organizations, who can sell software licensed under the CSL. Depending on country of residence this may require two entities: a for-profit business and a foundation or other non-profit organization as its owner. A group of authors cannot sell their own software under the CSL without first becoming a Licensor (a trusted reseller) in the sense of the license. The rationale is that the CSL is intended as a unique selling point for software licensed under the CSL and arbitrary software authors are not expected to reliably handle the financial resources in the intent of the license. Thus the CSL can increase the trustworthiness of authors without any disadvantages for software authors who mean to take the CSL seriously. Licensors in the sense of the license require external auditors, as, for instance, the Deutsche Zentralinstitut für soziale Fragen (dzi.de). A share of the generated revenue can, within predefined limits, be used to develop the software. The recipient of revenue shares is the maintainer. The maintainer can distribute funding, hire contractors, fork the project or pass on the office of maintainer to another person. The office of maintainer is meant to allow a software development process similar to that of the open source community, although slightly less inclusive.
Compatible licenses
The CSL is intended to allow use of software components licensed under LGPL License http://en.wikipedia.org/wiki/GNU_Lesser_General_Public_License, BSD License http://en.wikipedia.org/wiki/BSD_licenses, Apache License http://en.wikipedia.org/wiki/Apache_License or Mozilla Public License http://en.wikipedia.org/wiki/Mozilla_Public_License.
Dual licensing
A software author can make his work compatible with the CSL by dual-licensing the work. A program licensed under the GPL and the CSL can, for instance, be used under the terms of the GPL but can be incorporated into a derivative work licensed under the CSL. The program is consequently available as open source software but can be used for charitable purposes to generate revenue as part of a derivative work. Many other open source licenses do not require a dual licensing option because they are fully compatible with the CSL.
Recommendation: GPL+CSL
There is a conceivable synergy between the GPL and the CSL that deserves independent attention: A GPL-licensed parent project can to a degree discourage competitors: because a very similar program is available as free software, making a very similar program or derivative work is a less likely goal for a commercial developer. At the same time CSL-licensed derivatives can give additional meaning to the GPL-licensed parent project. Thus the recommendation for open source authors considering to support the CSL is to choose GPL+CSL as their license.
Alternative dual-licensing options
Dual-licensing with any other open source license is useful, even if it may have only symbolic value. You can dual-license a program under BSD+CSL for instance, which doesn't change the licensing conditions in any way, because the BSD license allows proprietary use, but you endorse the CSL license by mentioning it.
Philosophy
The difference in philosophy between CSL and open source in a nutshell is that CSL is about prevention while open source is about creation.
Terms and conditions for use, reproduction and distribution
Definitions
"Maintainer" shall mean the individual or Legal Entity identified as the initial developer or an individual or Legal Entity appointed (in writing) by the previous Maintainer as the current Maintainer.
"License" shall mean the terms and conditions for use, reproduction, and distribution as defined by this document.
"Licensor" shall mean any entity authorized by the License that is granting the License to a consumer or would be permitted to grant the License to a consumer.
"Licensee" shall mean an individual or Legal Entity exercising permissions granted by this License.
"Legal Entity" shall mean the union of the acting entity and all other entities that control, are controlled by, or are under common control with that entity. For the purposes of this definition, "control" means (i) the power, direct or indirect, to cause the direction or management of such entity, whether by contract or otherwise, or (ii) ownership of fifty percent (50%) or more of the outstanding shares, or (iii) beneficial ownership of such entity.
"Source" form shall mean the preferred form for making modifications, including but not limited to software source code, documentation source, and configuration files.
"Object" form shall mean any form resulting from mechanical transformation or translation of a Source form, including but not limited to compiled object code, generated documentation, and conversions to other media types.
"Work" shall mean the work of authorship, whether in Source or Object form, made available under the License, as indicated by a copyright notice that is included in or attached to the work (an example is provided in the Appendix below).
"Derivative Works" shall mean any work, whether in Source or Object form, that is based on (or derived from) the Work and for which the editorial revisions, annotations, elaborations, or other modifications represent, as a whole, an original work of authorship. For the purposes of this License, Derivative Works shall not include works that remain separable from, or merely link (or bind by name) to the interfaces of, the Work and Derivative Works thereof.
"Contribution" shall mean any work of authorship, including the original version of the Work and any modifications or additions to that Work or Derivative Works thereof, that is intentionally submitted to a Licensor for inclusion in the Work by the copyright owner or by an individual or Legal Entity authorized to submit on behalf of the copyright owner. For the purposes of this definition, "submitted" means any form of electronic, verbal, or written communication sent to the Licensor or its representatives, including but not limited to communication on electronic mailing lists, source code control systems, and issue tracking systems that are managed by, or on behalf of, the Licensor for the purpose of discussing and improving the Work, but excluding communication that is conspicuously marked or otherwise designated in writing by the copyright owner as "Not a Contribution."
"Contributor" shall mean any Licensor and any individual or Legal Entity on behalf of whom a Contribution has been received by any Licensor and subsequently incorporated within the Work.
"License Steward" shall mean the Legal Entity that is defined as the License Steward under the identically named section of the License.
License grants
Evaluation grant
For the purpose of evaluating the Work each Contributor hereby grants the Licensee a limited non-exclusive and non-transferable right of use for his Contributions to the Work in order to make use of the Work for up to one month without interruptions or new beginnings. Each new version of the software can be evaluated anew under the evaluation grant.
Contributor grant
Subject to third party intellectual property claims, each Contributor hereby grants the Licensee a non-exclusive and non-transferable right of use for his Contributions to the Work in order to make use of the Work, provided the Work has been purchased from a Licensor.
Licensor obligations
Revenue from purchases
The Licensor accepts the obligation to provide appropriate funding for further development of the Work to the Maintainer, which shall not constitute more than 10% of the revenue from purchases of the Work. The Licensor accepts the obligation to refuse funding to a project if the use of funding has not been made sufficiently transparent or is seen as inappropriate according to published policies of the Licensor. The Licensor accepts the obligation to use at least 95% of the remaining revenue from purchases of the Work for charitable purposes. The Licensor accepts the obligation to document use of financial resources derived from purchases of the Work to the general public and to employ an external auditor to validate the use of financial resources derived from purchases of the Work.
Pricing
The Licensor accepts the obligation to sell the Work for no less than the prices determined by the Maintainer. A preliminary default for price deductions is that residents of developing countries receive a deduction of 2% for each step in the Human Development Index their country of residence is below position 127.
Discontinuation
The Licensor retains the right to sell the Work under the License only while the Maintainer of the Work and the License Steward both endorse the Licensor. The right to sell the Work can be terminated either by the Maintainer or by the License Steward at any time.
Distribution obligations
Source distribution
Parts of the Work that have been received in Source form can be distributed in Source form, unless otherwise specified by the Maintainer or the Licensor. Distribution in Source form does not constitute a right of use for the Work in Object form for the recipient.
Distribution of Modifications
Derivative Works that the Licensee creates or to which the Licensee contributes are governed by the terms of this License. The Maintainer of Derivative Works remains the original Maintainer of the Work, unless the Maintainer agrees to share or to transfer the office in writing.
Versions of the license
License Steward
The License Steward is [ ... to be determined ... ] and may publish revised and/or new versions of this License from time to time. Each version will be given a distinguishing version number. No one other than the License Steward has the right to modify this License.
Effect of new versions
The Licensee may choose to use the Work under the terms of the version of the License under which the Licensee originally received the Work or any subsequent version of the License published by the License Steward.
Multiple-licensed code
If the Work is available under other licenses the Licensee is free to choose the License as the governing contract and to terminate other licenses only if the Work has been purchased from a Licensor.
Disclaimer of warranty
The Work is provided by the Licensor ``as is´´ and any express or implied warranties, including, but not limited to, the implied warranties of merchantability, fitness for a particular purpose or non-infringement are disclaimed, except to the extent that these disclaimers are held to be legally invalid. In no event shall the Licensor 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 the Work, even if advised of the possibility of such damage.
Headings not controlling
The headings in this License are for reference purposes only and shall not be construed as a part of the License.
Variants
CSL Freemium
The freemium http://en.wikipedia.org/wiki/freemium variant offers a CSL or GPL+CSL licensed version for free (or for a CSL minimum licensing fee) but an advanced version of the program or advanced features require a commercial license.
If the source is released as open source at the same time the Maintainer should make it clear that open source releases should not try to rebuild the features of the program that are only available with a commercial license (unless this is tolerable). Users are free to make such changes and even to release them to the general public but should be aware that this could be seen as impolite and may motivate a change of the business model.
CSL/75
The CSL/75 allows the development team to retain up to 25% of the revenues. The purpose is to accomodate developers who would be scared away by the prospect of donating 90% of their revenues. The use of the money must follow the established policies of the Licensor (the reseller) as in the standard version.
CSL/50
The CSL/50 allows the development team to retain up to 50% of the revenues. The purpose is to extend the CSL/75 and to allow licensing fees for commercial third party software components included with the Work or Derivative Works. The additional 25% of the revenues must be used solely for licensing fees of such software components and must follow the established policies of the Licensor (the reseller). A Licensor could, for instance, regulate what constitutes inappropriate licensing fees.
Open source
An open source variant (OSCSL) could change the section "Source distribution" to:
The Licensor makes the Work available in Object form and in Source form. The Licensee is granted the right to distribute the Work or Derivative Works in Source form to third parties. Distribution in Source form does not constitute a right of use for the Work in Object form for the recipient.
Electronic Publishing Charity Source License (EPCSL)
An "electronic publishing" version of the CSL could allow an author to release a book, a piece of music or another work under a license similar in goal to the CSL. An important difference is that a published work is likely to be completed and not to require maintenance.
A single author could be eligible to receive 10% of the revenues of his works or up to 30%, if below $3500/month. Furthermore an author could be eligible to consume up to 30% of the revenues of his works for future projects at the average rate of previous payments over the last 5 years (or less, at the author's option) if revenues of currently sold works fell below the average rate of previous payments.
Wikibooks could be treated like software projects and be published under the original CSL, not the EPCSL. That could put the PDF form under the CSL while the original Wiki source code would remain available under whatever license was used for the form (e.g. GFDL http://wiki.laptop.org/go/GFDL or Creative Commons http://wiki.laptop.org/go/Creative_Commons).
Hallo zusammen,
ich will das mal etwas anders beantworten als die bisherigen Reaktionen: In der vim-Lizenz [1] gibt es ja so eine ähnliche Klausel, nämlich, dass der ursprüngliche Autor die Modifikationen erhalten muss. Es gibt da verschiedene Varianten, aber im Grunde heißt es "entweder Source Code für alle oder zumindest für den Maintainer".
Laut FSF ist das eine freie Lizenz. [2]
Volker Grabsch, 2013-10-29, 14:51 CET (+0100):
Kann man Software unter dieser Lizenz immer noch als "Open Source" beziehungsweise "Freie Software" bezeichnen, oder ist die Einschränkung durch die 4. Klausel zu stark?
In Anlehnung an die Aussage bei der vim-Lizenz würde ich sagen ja, es ist Freie Software (Open Source kann ich nicht so genau beurteilen, da müsstest du bei der OSI nachfragen). Der einzige Unterschied ist, dass es bei vim immer um die Verbreitung geht, wie bei der GPL auch. In der von dir zitierten Lizenz geht es eventuell schon um Modifikationen. Die Frage ist wie sowas überhaupt rechtlich zu beurteilen ist, denn wenn ich das komplett für mich mache, dann weiß das ja niemand. Den Desert-Island-Test bestehen aber beide Lizenzen nicht.
Die vier Freiheiten sind aber alle erfüllt. Man muss hier denke ich auch aufpassen auf was man testet. Die DFSG sind z.B. leicht anders als die vier Freiheiten und in mancherlei Hinsicht strenger. Der Desert-Island-Test kommt eher aus dem DFSG-Bereich, also ist das eine andere Einschätzung.
Falls es kein Open Source ist, wäre obige Lizenz trotzdem mit der GPLv3 vereinbar?
Ich denke die Lizenz wäre trotzdem mit der GPL(v3) vereinbar, da sie ja nur sagt, dass ein bestimmter Personenkreis die Modifikationen unter gleichen Bedingungen erhalten muss, nicht jeder. Also man kann die Lizenz beliebig ändern, solange [COMPANY] die Änderungen unter den usprünglichen Bedingungen erhält. Bei der vim-Lizenz ist das noch etwas anders, weil sie Kombination mit der GPL explizit erlaubt.
Liebe Grüße Florian
[1] http://directory.fsf.org/wiki/License:Vim7.2 [2] http://www.gnu.org/licenses/license-list.html
On 01.11.2013 19:12, Florian Snow wrote:
Falls es kein Open Source ist, wäre obige Lizenz trotzdem mit der GPLv3 vereinbar?
Ich denke die Lizenz wäre trotzdem mit der GPL(v3) vereinbar, da sie ja nur sagt, dass ein bestimmter Personenkreis die Modifikationen unter gleichen Bedingungen erhalten muss, nicht jeder. Also man kann die Lizenz beliebig ändern, solange [COMPANY] die Änderungen unter den usprünglichen Bedingungen erhält. Bei der vim-Lizenz ist das noch etwas anders, weil sie Kombination mit der GPL explizit erlaubt.
Wenn Du den Code, der unter der ergänzten BSD-Lizenz steht, mit GPL-Code zu einem einheitlichen Werk verbindest, das dann unter der GPL stehen muss, hast Du ein Problem:
Du müsstest die fragliche Ergänzung mit in die Lizenz aufnehmen, darfst aber den Text der GPL nicht verändern.
Andererseits muss der GPL-Code, den Du verwendest, auch nach einer Veränderung unter der gleichen Lizenz weiterverbreitet werden. Ergänzungen - im Sinne von Einschränkungen oder zusätzlichen Pflichten - sind also nicht erlaubt.
Man mag darüber streiten, ob der Code unter der ergänzten BSD-Lizenz noch "frei" ist, die Lizenz selbst scheint mir nicht GPL-kompatibel (im Gegensatz zur unveränderten BSD-Lizenz) zu sein.
Gruß Michael
Hallo zusammen,
RA Stehmann, 2013-11-04, 10:27 CET (+0100):
Du müsstest die fragliche Ergänzung mit in die Lizenz aufnehmen, darfst aber den Text der GPL nicht verändern
Da hast du natürlich Recht. Ich habe nicht weit genug gedacht, sondern sozusagen bei "einer Generation" der Weiterentwicklung aufgehört. Meine eigenen Modifikationen könnte ich ja noch unter beide Lizenzen stellen, beim nächsten, der den Code unter GPL bekäme könnte ich ohne GPL-Anpassungen nicht mehr garantieren, dass er den Code auch unter ursprünglichen Bedingungen an den Autoren zurückgibt. Und die Anpassung der GPL geht natürlich nicht.
Liebe Grüße Florian