Recht so ! LGPL ist die richtige Lizenz dafür. Damit dürften sich die Vapourware-Produzenten von lindows und Xandros etwas schwerer tun, es ist aber immer noch nicht ausreichend, wenn man sich vor kommerzieller Vereinnahmung schützen will (siehe Zend und PHP z.B.).
Wer sich vor kommerzieller Vereinnahmung schützen will, ist nichts weiter als paranoid. Die BSDs tun das auch nicht, unter der weitgehend korrekten Annahme, daß es für eine Firma viel einfacher ist, ihre Modifikationen an das Projekt zurückzugeben, als eine Kopie des Codes im eigenen Haus zu verwalten.
Seit wann ist es schwierig, Code "im eigenen Haus zu verwalten"?
Mit dem Argument dürfte es ja gar keine Closed Soft mehr geben, immerhin müssen sich die armen Softwarefirmen da alle um ihren Code kümmern.
Im übrigen muß auch Code, der nach außen offen gelegt wurde, intern weiter verwaltet werden, Du kannst also ebenso gut einen Schulhof mit einem Vollkornbrot vergleichen.
@Doki: Es ist schwierig, einen eigenen Patch an einem Projekt wie z.B. Wine selbst zu verwalten, weil man diesen Patch für jede neue Version von Wine anpassen muß. Und gerade das macht manchmal ziemlich viel Arbeit, besonders dann, wenn es jede Woche eine neue Version gibt. Da ist es m.E. viel einfacher, den Patch in das Projekt zu integrieren, dann machen nämlich andere die Anpassungsarbeit.
Patches sind das eine, proprietär erweiterte Versionen sind etwas anderes.
Wenn es das *Ziel* ist, eine eigene Version herauszubringen, die man auch im eigenen Namen vermarkten darf, wird man gar nicht erst auf die Idee kommen, das Original-Produkt um irgendwelche Patches zu erweitern. Darum geht es.
Es wäre allerdings zu begrüßen, wenn Pro-Linux.de den Unterschied zwischen kommerziell und proprietär vermitteln würde.
Die (L)GPL erlaubt auch kommerzielle Nutzung - eine vollständige Proprietarisierung des WINE wird damit aber unmöglich gemacht, auch wenn die LGPL proprietären Projekten u.A. auch das Linken erlaubt.
Es ging nicht um kommerzielle *Nutzung* des Programms, sondern darum, ob man den Code in ein kommerzielles *Programm* einbauen darf.
Das wurde im Artikel völlig richtig dargestellt.
Zum Vergleich: gcc darf auch kommerziell genutzt werden. Du darfst den Code aber nicht in einen proprietären Privat-Compiler einbauen, den Du danach verkaufst.
Wenn kommerzielle Nutzung ausschließlich das Zahlen von Software-Lizenzkosten beinhalten würde, wäre beispielsweise AOL nichtkommerziell.
Betrachtet man kommerzielle Nutzung als vom Verkauf abhängig, so sollte gesagt werden, daß GPL Software verkauft werden kann und auch verkauft wird. Mandrake und RedHat demonstrieren das seit Jahren.
Die sinnvollste Definition kommerzieller Nutzung bezieht sich auf die Frage der Verfolgung kommerzieller Interessen. Das ist vollkommen unabhängig von der Frage der Lizenzierung.
Die Gleichstellung kommerziell=proprietär ist eine der üblichen FUD-Taktiken der proprietären Softwareindustrie.
Nochmal päzise: Unabhängig von der Frage der Kommerzialisierung erlaubt die LGPL eine proprietäre Nutzung, aber keine Proprietarisierung.
Ich halte von der Aladin-Lizenz überhaupt nichts. Das Hauptproblem der Aladin-Lizenz ist in meinen Augen die Tatsache, dass diese das Recht zur Weiterbreitung eines Programmes u. a. davon abhängig macht, ob nicht-freie Programme in der selben Distributation vertrieben werden.
Kann man mir als Nicht-Programmierer in drei Sätzen eigentlich erklären, worin eigentlich die Unterschiede zwschen den einzelnen Lizenzmodellen liegen, bzw. welche der Open Source Bewegung am dienlichsten sind?
LGPL ist die richtige Lizenz dafür.
Damit dürften sich die Vapourware-Produzenten von lindows und Xandros etwas schwerer tun, es ist aber immer noch nicht ausreichend, wenn man sich vor kommerzieller Vereinnahmung schützen will (siehe Zend und PHP z.B.).
X.
Mit dem Argument dürfte es ja gar keine Closed Soft mehr geben, immerhin müssen sich die armen Softwarefirmen da alle um ihren Code kümmern.
Im übrigen muß auch Code, der nach außen offen gelegt wurde, intern weiter verwaltet werden, Du kannst also ebenso gut einen Schulhof mit einem Vollkornbrot vergleichen.
Gruß,
Heinzi
Wenn es das *Ziel* ist, eine eigene Version herauszubringen, die man auch im eigenen Namen vermarkten darf, wird man gar nicht erst auf die Idee kommen, das Original-Produkt um irgendwelche Patches zu erweitern. Darum geht es.
was laberst du nur für eine scheisse?
warum wollen denn lindows oder gar xandros (die haben nichts mit wine zu tun - xandros ist nur die basis für lindows) wine kommerzialisieren??
@Micronuke:
Xandros ist IIRC der Aufkäufer der Corel-Debian-distroversion.
Sollte also mit Wine nichts näheres zu tun haben.
Ciao,
Steve
cu Jörn
Es wäre allerdings zu begrüßen, wenn Pro-Linux.de den Unterschied zwischen kommerziell und proprietär vermitteln würde.
Die (L)GPL erlaubt auch kommerzielle Nutzung - eine vollständige Proprietarisierung des WINE wird damit aber unmöglich gemacht, auch wenn die LGPL proprietären Projekten u.A. auch das Linken erlaubt.
Das wurde im Artikel völlig richtig dargestellt.
Zum Vergleich: gcc darf auch kommerziell genutzt werden. Du darfst den Code aber nicht in einen proprietären Privat-Compiler einbauen, den Du danach verkaufst.
Betrachtet man kommerzielle Nutzung als vom Verkauf abhängig, so sollte gesagt werden, daß GPL Software verkauft werden kann und auch verkauft wird. Mandrake und RedHat demonstrieren das seit Jahren.
Die sinnvollste Definition kommerzieller Nutzung bezieht sich auf die Frage der Verfolgung kommerzieller Interessen. Das ist vollkommen unabhängig von der Frage der Lizenzierung.
Die Gleichstellung kommerziell=proprietär ist eine der üblichen FUD-Taktiken der proprietären Softwareindustrie.
Nochmal päzise: Unabhängig von der Frage der Kommerzialisierung erlaubt die LGPL eine proprietäre Nutzung, aber keine Proprietarisierung.
also 3x wine ?
#1 normal wine ( jetzt mit neuen lizenzen ) [ codeweavers, winehq ]
#2 WineX ( aladin lizenz )[ transgaming ]
#3 Theleme initiierte Wine ( alte X11/MIT lizenz ) [ ??? ]
- was soll ich eigenlich von der aladin lizenz halten !? ...