Entwickler-Ecke :: Thema anzeigen - Welches Lizenzsystem verwenden für PHP Library?

Zuck - So 07.08.11 17:38
Titel: Welches Lizenzsystem verwenden für PHP Library?

Hallo,

bin derzeit dabei eine recht umfangreiche PHP-Library zu schreiben. Dazu suche ich jetzt eine passende Lizenz, die meine Interessen absichert. Die Library kann alleinstehend genutzt werden, soll später aber Teil eines noch größeren Projektes werden. Für die Library suche ich jetzt aber eine passende Lizenz.

Meine Interessen

Wenn jemand Modifikationen an der Library vornehmen will, muss er sie mit mir absprechen. Wenn sie angenommen werden, kommen sie in die Library rein. Also keine Verästelung, dass dann auf einmal parallel 5 verschiedene Gruppen ihre eigene Suppe kochen. Auch keine Teilentnahmen von Code (die Library besteht aus mehreren Teilen). Die Library soll als ganzes zusammenbleiben. Jede Weiterentwicklung muss mit mir abgesprochen werden. Weiteres in Punkt 3.
Ich möchte mir die Möglichkeit offen halten, später möglicherweise auf kostenpflichtig umzuschalten. Es soll daher von Anfang an nicht möglich sein, dass irgendwo steht, dass es für immer kostenlos bleiben wird. (Da frag ich mich eh öfters wie das mit pngimage.pas und dergleichen aussieht, die erst Opensource waren und dann von Embarcadero gekauft wurden...)
Thema Zusatzpakete: Die Library bietet bestimmte Grundfunktionalitäten, auf die alle anderen Teile der Library aufbauen. Es soll jedem möglich sein, auf diese Grundlage aufbauend weitere Pakete zu schreiben und diese dann selbstständig zu vertreiben, bzw. bei gegenseitigem Interesse in die Library einzupflegen. Delphi-Beispiel für was ich meine: Die VCL bietet bestimmte Grundlagen. Wenn ich mir jetzt eine Komponente schreibe und diese von TWinControl ableite, darf ich diese auch selbst vertreiben, allerdings dazu nicht die VCL mitgeben. Das ist quasi das was ich erreichen möchte. Die Library soll immer von mir kommen, Zusatzpakete darf jeder so viele schreiben wie er will. Der "Komponentenentwickler" darf sein Zusatzpaket aber nur getrennt vertreiben; also kein Download-Paket anbieten, das meine gesamte Library + sein Paket enthält.
Gegenüber Nutzern von Zusatzpaketen, die nicht von mir kommen, möchte ich eine Absicherung, dass die Kompatibilität mit neueren Versionen meiner Library nicht garantiert wird.
Beispiel: Ich hab bspw. Delphi 2007 und schreibe eine Komponente. Nutzer von Delphi 2007 können sie problemlos nutzen, Unter Delphi XE kompiliert die Komponente allerdings nicht mehr, da inzwischen von Embarcadero Änderungen an der VCL vorgenommen wurden. Ich als Komponentenentwickler bin nun selbst dafür zuständig, eine XE-kompatible Version zur Verfügung zu stellen. Das ist nicht Sache von Embarcadero.
Hier möchte ich einen Support für Third-Party-Pakete ausschließen. Jeder Paket-Autor soll seine Pakete selbst auf neuestem Stand halten. Wenn ein Paket in meine Library aufgenommen wird, besteht die Support-Garantie.

Was würdet ihr mir da für eine Lizenz empfehlen? Gibt es überhaupt eine die das für mich zusammenfasst oder muss ich mir da was eigenes überlegen?

Zuck

jaenicke - So 07.08.11 18:16

Da wirst du in der Tat eine eigene Lizenz benutzen müssen, fertig wird es das so nicht geben. Wenn du die aber selbst schreibt, zerreißt die dir vermutlich ein Anwalt innerhalb von Sekunden, das würde dir also bei einer Vermarktung nicht viel bringen.

Wenn jemand eine kostenlose Version hat und dafür Zusatzmodule entwickelt, halte ich es aber für wenig sinnvoll, eine Option in die Lizenz einzubauen, dass du die Version evtl. plötzlich nicht mehr anbietest und er sie auch nicht anbieten darf. Unter einer solchen Lizenz würde ich als Entwickler wohl kaum Mühe in ein Zusatzmodul stecken...

Wenn du später eine Version entwickelst, die du dann kommerziell anbieten möchtest, reicht es auch, wenn du der so interessante neue Features verpasst, dass die Nutzer freiwillig auf diese Version wechseln. Dann kannst du die alte Version unter eine existierende Lizenz stellen und nur eine neue Version dann unter eine kommerzielle. Denn wenn du die dann wirklich verkaufen willst, lohnt es sich auch eher Geld in einen Anwalt zu investieren um dir eine Lizenz zu verfassen.

Zuck hat folgendes geschrieben :

Da frag ich mich eh öfters wie das mit pngimage.pas und dergleichen aussieht, die erst Opensource waren und dann von Embarcadero gekauft wurden...

Dort hat Embarcadero den rechtlich IMHO äußerst problematischen Versuch unternommen die alte Lizenz für ungültig zu erklären. Denn in der stand eindeutig drin, dass die Verbreitung erlaubt ist, während von Seiten von Embarcadero dieses zu verbieten versucht wurde. Die meisten Seiten haben einer Aufforderung (z.B. mit einer Drohung über den DCMA) Folge geleistet, weil sie einen Rechtsstreit gefürchtet haben. Letztendlich hätte Embarcadero bei einem solchen Versuch aber baden gehen müssen, da der Wortlaut der Lizenz vollkommen eindeutig formuliert war...
Aber sie haben wohl (zu Recht) darauf gehofft, dass es die meisten nicht darauf ankommen lassen würden.

Zuck - So 07.08.11 18:59

Hallo Sebastian,

dein Argument mit der Feature-Auslese ist gut - das hab ich bisher noch gar nicht bedacht :zustimm:

Das ich mir da höchstwahrscheinlich selbst etwas schreiben müsste, hab ich mir gedacht, deshalb hab ich mir da auch schon eine zweite Lösung überlegt, mit der ich mich anfreunden könnte; bin schließlich kein Jurist.
BTW, was haltet ihr von den Creative Commons? Sind ja eigentlich nicht für Software gedacht, allerdings sind dort ein paar Aspekte sehr schön gemacht.

Meine Alternativ-Interessen

Grundsätzlich soll die Library (im Weiteren Core genannt) kostenlos zur Verfügung gestellt werden, Änderungen aber vorbehalten. Version 1, 2 und 3 kostenlos. Version 4 möchte ich dann aber verkaufen.
Ich möchte ausschließen, dass Dritte eine Version des Cores beziehen und ihn dann auf eigene Weise vertreiben, da ansonsten möglicherweise alte Versionen noch als "neu" angeboten werden. No Share
Weiters möchte ich es anderen untersagen, den Core selbstständig zu modifizieren. No Derive
Zusatzpakete können von jedem erstellt werden. Sie bauen auf den Core auf, verändern diesen aber nicht, sondern nutzen die Schnittstellen, bzw. leiten von Core-Klassen ab. Zusatzpakete werden vom jeweiligen Autor gewartet. Core-Pakete werden vom Core-Team gewartet, erweitert, gebugfixed, etc. Es besteht die Möglichkeit das gute Zusatzpakete in den Core aufgenommen werden.
Bzgl. deinem Argument, dass Features wegfallen könnten: Das ist sehr unwahrscheinlich. Es ist eine sehr große Klassensammlung mit vielen Abhängigkeiten. Diese Klassen sind so wie sie sind und werden höchst wahrscheinlich nicht mal mehr erweitert werden. Wenn Erweiterungen stattfinden, dann im Zuge von neuen Klassen, die von bereits bestehenden erben. Beispiel: Wenn ich in Delphi eine Komponente entwickle, leite ich sie auch von einem VCL-Typ ab und ändere nicht dort beispielsweise den Typ TWinControl ab ;). Deshalb könnte von mir aus auch eine Klausel in der Lizenz stehen, dass die Klassen, wie sie jetzt sind für immer ihre Funktionalität anbieten werden.

Creative Commons decken mindestens die Hälfte meiner Forderungen ab. Ist es ratsam, diese zu verwenden?

Zuck

Zuck - Mo 08.08.11 00:46

Hallo nochmal,

ich hab jetzt folgenden Copyright-Block in meine Dateien eingefügt.

C#-Quelltext

1:
2:
3:
4:
5:
6:
7:
8:
9:
10:
11:
12:
13:
14:
15:
16:
17:
18:
19:

<?php

/**
*  This file is part of the ____________________
*
*  Copyright (c) 2011 __________ <email@domain.com>
*
*  Checkout AUTHORS file for more information on the developers.
*
*  Checkout LICENSE file for more information on the terms under
*  which XCL is provided.
*
*  This library 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.
*
*/

?>

Ist das so erlaubt, wenn ich die AUTHORS und LICENSE Dateien dazulege, oder muss die Lizenz unbedingt in jede einzelne Datei? Ich hab mir jetzt einige PHP-Opensource-Projekte angesehen, aber diese machen immer nur einen Verweis auf die GPL und dass man sie von der Free Software Foundation bekommen kann. In der LICENSE werde ich dann die Lizenz der jeweiligen Release angeben. So ist es leichter, da ich dann nur diese zwei Dateien ändern muss, anstatt bei den über 100 einzelnen PHP-Dateien der Library.

Für die komplette Lizenz in LICENSE werde ich mir wohl aus den einzelnen "berühmten" Lizenzen die einzelnen Teile zusammensuchen und so zurechtschnipseln, wie ich es gerne hätte. Hab jetzt über 2 Stunden verschiedene Lizenzen durchgelesen aber in allen gabs was, das mir gegen den Strich ging ;). Über Vorschläge bin ich aber immer noch sehr erfreut, da es möglicherweise irgendwo genau diese Lizenz schon irgendwo gibt und ich sie nur nicht gefunden habe.

Zuck

Zuck - Mo 08.08.11 09:30

jaenicke hat folgendes geschrieben :

Zuck hat folgendes geschrieben :

Für die komplette Lizenz in LICENSE werde ich mir wohl aus den einzelnen "berühmten" Lizenzen die einzelnen Teile zusammensuchen und so zurechtschnipseln, wie ich es gerne hätte.

Vorsicht, pass auf, dass du nicht wegen Copyrightverletzungen Probleme bekommst.

Die GPL darf z.B. nur als Ganzes verwendet, aber nicht verändert werden...

OK, danke für den Hinweis, dann werd ich einfach in ein paar kurzen einfachen klaren Sätzen schreiben, was ich erlaube und was für Bedingungen bestehen und sie mir von nem Bekannten, der Jurist ist, anschauen lassen.

Zuck

Gausi - Mo 08.08.11 09:41

Ich würde mir erstmal überlegen, ob so eine Lizenz überhaupt sinnvoll ist. Wenn ich ein Entwickler wäre, der deine Library verwenden möchte, und in der Lizenz lauter Pflichten und Verbote sehe und fast keinerlei Rechte, dann würde ich mich wahrscheinlich ganz schnell nach einer Alternative umsehen.

Denn das ist es, waa du hier vorhast. Du erlaubst die Nutzung, ok. Aber du verbietest die Veränderung. Du verbietest die Verbreitung. Du hältst die die Möglichkeit offen, die Library zu einem Zeitpunkt deiner Wahl unbrauchbar zu machen (durch Änderung der Lizenz).

Hört sich nicht besonders attraktiv an. :nixweiss:

Zuck - Mo 08.08.11 10:49

Gausi hat folgendes geschrieben :

Eine Lizenz finde ich notwendig, gibt nichts schlimmeres als ein Projekt oder ne Library, über deren Lizenz man nichts in Erfahrung bringen kann und sie aufgrund dessen gleich in die Tonne schmeißen kann.

Gausi hat folgendes geschrieben :

Denn das ist es, waa du hier vorhast. Du erlaubst die Nutzung, ok. Aber du verbietest die Veränderung. Du verbietest die Verbreitung. Du hältst die die Möglichkeit offen, die Library zu einem Zeitpunkt deiner Wahl unbrauchbar zu machen (durch Änderung der Lizenz).

Veränderungen am Core sind schon erlaubt, aber diese müssen durch uns bestätigt werden - quasi Änderungen machen, uns zusenden und wir entscheiden dann schlussendlich ob es in den Core aufgenommen wird, oder was viel wahrscheinlicher ist, als Zusatzpaket angeboten wird. Änderungen am Core sind in den seltensten Fällen sinnvoll, eine Erweiterung kann nie schaden. Übrigens sind Veränderungen durch einen einzelnen nicht gerade zu seinem Vorteil. Anwendungen die auf den Core aufbauen funktionieren dann möglicherweise mit seiner veränderten Version nicht mehr.
Wieso sollte die Library unbrauchbar werden? Wenn Version 2 kostenlos ist, dann bleibt sie das auch noch, wenn ich Version 3 unter einer leicht abgeänderten Version vertreibe. Das wirkt nicht rückwirkend auf frühere Versionen. Es steht dann jedem frei, entweder v2 zu behalten oder auf v3 umzusteigen.

Gausi hat folgendes geschrieben :

Hört sich nicht besonders attraktiv an. :nixweiss:

Ich hab mir in den letzten Stunden auch noch einiges zu dem Thema durchgelesen. Gibt verschiedene Standpunkt dazu, allerdings möchte ich schon, dass die Library für den Nutzer attraktiv ist. Deshalb werde ich auch an vielen Stellen nicht von Pflichten sprechen sondern von gern gesehenen Vorgehensweisen. Soll heißen: Wer ein Zusatzpaket entwickelt kann es uns zusenden, damit sein Paket und er in den Core aufgenommen werden. Er ist dann im Zuge neuer Versionen für den Support seines Paketes zuständig. Das bringt ihm eine bessere Verbreitung und eine sichere Kompatibilität (welche auch vorhanden wäre, wenn er es auf eigene Faust weiterentwickelt, allerdings müsste er dann immer auf die Release warten; wenn er im Team ist, kann er schon während der Entwicklung sein Paket auf neuestem Stand halten).

Zuck

platzwart - Mo 08.08.11 12:03

Zitat:

Und wenn du - Gott bewahre - morgen vom Auto überfahren wirst? Dann sind alle Entwickler, die auf deine Library gesetzt haben, verloren. So oder so kann ich nur meinen Vorrednern zustimmen, dass eine solche Lizenz niemals ernsthaft von einem professionellem Entwickler akzeptiert würde. Solche Lizenzen erlauben sich nichtmals die Softwareriesen...

Zuck - Mo 08.08.11 12:55

platzwart hat folgendes geschrieben :

Zitat:

Und wie ist das bei der Delphi-VCL? Darf man die verändern?

Wie gesagt: Die Library ist quasi eine Box, die man nicht verändern muss. Es ist viel praktischer, Zusatzpakete zu entwickeln. Wie das Beispiel weiter oben mit dem Verändern von TWinControl.. du leitest auch einfach ne neue Klasse davon ab.

Allerdings muss ich da langsam wirklich einlenken. Da es praktisch keinen Sinn macht, die Library zu verändern, kann ich den Punkt eigentlich auch weglassen. Wer dumm genug ist, an den Core-Klassen rumzuhantieren ist selber schuld, wenn dann nicht mehr alles so funktioniert wie es sollte. -> Guter Einwand von dir, Danke :)

Zusammengefasst nochmal:
- Core kann verändert werden, wird aber nicht empfohlen
- kostenlose Verwendung, eventuell Namensnennung
- Zusatzpakete entwickeln ist erlaubt und gewünscht. Bei Interesse können die in den Core einfließen
- Urheberrecht besteht
- Unterscheidung zwischen Projekt und Zusatzpaket
-- kommerzielle Zusatzpakete erlaubt (in Delphi: Komponente)
-- kommerzielle Projekte gegen Lizenzzahlung erlaubt (in Delphi: Anwendung)

Werd mich weiter über Software-Lizenzen informieren (bin überschlagmäßig jetzt schon insgesamt etwa 7-8 Stunden mit dem Suchen und Lesen verschiedener Modelle beschäftigt; da kommen immer neue Aspekte raus; auch mit eurer Hilfe :)), hab aber das Gefühl, dass meine jetzigen Forderungen möglich und "human" sein sollten, oder?

Zuck

BenBE - Di 09.08.11 02:04

Man merkt eindeutig, dass hier jemand bisher wenig OpenSource-Erfahrung hat. :twisted: Denn wie bereits erwähnt, ist in deiner Lizenz sehr viel Einschränkung drinnen, aber wenig, was ich wirklich damit darf. Für das Omorphia-Projekt stand zuerst auch die Frage nach einer eigenen Lizenz (im wesentlichen ne stark vereinfachte LGPL), in der u.a. auch eine "Rückmeldung von Änderungen" nach Upstream vorgesehen war - also eine stark abgeschwächte Version deiner "wir wollen das Abnicken"-Variante. Und trotzdem hat SourceForge die Lizenz damals nicht angenommen, da sie die Freiheiten, die eine OpenSource-Lizenz haben sollte, eingeschränkt hat (siehe hier speziel DFSG AKA Debian Free Software Guidelines). Da stand nicht mal MUSS, sondern SOLLTE. Wir hätten damals versuchen können, die Lizenz bei der OSI approven zu lassen, haben uns im Team dann aber für LGPL (um)entschieden. Damit haben wir zwar ein wenig Kontrolle abgegeben, aber wer sich OpenSource-Projekte einmal anschaut, wird schnell sehen, dass auch über Forks hinweg sehr viele Patches eingepflegt werden. Wenn Du also keine Versionen Müller 2.0, Maier 3.0 und Kunze 3.1 als "offizielle" Versionen willst, dann sorg am besten dafür, dass deine Community hinter Dir steht und Du die Patches entsprechend zeitnah in die Code Base integrierst. Alternativ hoste bei GitHub und merge die von Usern beigetragenen Features einfach per Klick im Webinterface. Das ist offener UND ehrlicher der Community gegenüber, als einen auf "Open Source" zu machen und im Endeffekt ne kommerzielle Knebel-Lizenz zu nehmen. Free as in Free Speach, not as in Free Beer.

BTW: Meine Sachen sind i.d.R. GPL, LGPL oder BSD; für Texte und andere Inhalte oftmals eine CC-Lizenz (häufig mit BY und NC).

Zuck - Di 09.08.11 13:02

BenBE hat folgendes geschrieben :

Wenn Du also keine Versionen Müller 2.0, Maier 3.0 und Kunze 3.1 als "offizielle" Versionen willst, dann sorg am besten dafür, dass deine Community hinter Dir steht und Du die Patches entsprechend zeitnah in die Code Base integrierst. (...) Das ist offener UND ehrlicher der Community gegenüber, als einen auf "Open Source" zu machen und im Endeffekt ne kommerzielle Knebel-Lizenz zu nehmen. Free as in Free Speach, not as in Free Beer.

Naja mein Problem ist es ja, dass ich es eben eigentlich nicht als Opensource machen möchte, aber das lässt sich bei PHP ja schlecht verhindern. Jedem dem ich das Zeug gebe, hat natürlich die original Quelltexte. Könnte es natürlich erschweren, in dem ich das Zeug packe - alle unnötigen Leerzeichen, alle Zeilenumbrüche, etc. entferne, aber das ist auch nicht wirklich die Lösung.

Werd mir die von dir angesprochenen Lizenzen LGPL, etc. nochmal genauer ansehen.

Eure Einwände bezüglich der Einschränkungen und wie diese aufgenommen werden könnten, haben mich doch etwas dazu gebracht, die Lizenz sehr abzuschwächen. Danke dafür im Voraus, dann muss ich mich später nicht wundern, weshalb es nicht so gut angekommen ist :)

Zuck

Entwickler-Ecke.de based on phpBB
Copyright 2002 - 2011 by Tino Teuber, Copyright 2011 - 2026 by Christian Stelzmann Alle Rechte vorbehalten.
Alle Beiträge stammen von dritten Personen und dürfen geltendes Recht nicht verletzen.
Entwickler-Ecke und die zugehörigen Webseiten distanzieren sich ausdrücklich von Fremdinhalten jeglicher Art!