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.

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.

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

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

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).

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