> Wäre das der Kerngedanke, sollte es keine LGPL geben. Die LGPL ist eine Convenience-Entscheidung für proprietäre Software, die an bestimmten Stellen ihren Sinn hat.
> Sun hat OpenOffice unter LGPL lizenziert Und Java unter der GPL, aus ganz bestimmten Gründen, die unter anderem den von mir genannten recht ähnlich sind.
> was eigentlich zeigt, wie wenig wichtig diesen Unternehmen die GPL ist Das ist doch kein Widerspruch, es zeigt nur, dass sie bei anderen Produkten andere Überlegungen als entscheidend ansehen. Ich schrieb genau deshalb übrigens Sun "in Teilen". Es gibt natürlich wichtige Gründe für Code, der unter einer BSD-Style-Lizenz steht, wenn er auch in proprietäre Produkte einfließen können soll, und wenn das der "wichtigere" Beweggrund ist.
> weshalb die Nutzung von Bibliotheken sowieso meist besser ist Das ist kein Widerspruch, es ist einfach ein weiteres Modell des Code-Sharings. Ich meinte aber eher Code, der eben kleinere Teilaufgaben erfüllt. Was weiß ich, nur eine handvoll Funktionen, die ich in meinem neuen Programm gerade gebrauchen könnte. Deshalb schreibt natürlich niemand eine Bibliothek, erst recht nicht, wenn sie für meinen Zweck noch leicht abgewandelt werden.
> nd drittens wegen den Eigenheiten von Programmiern, die häufig anderer Leute Code "unschön", "unleserlich" oder schlicht > für schlecht halten und deshalb neu schreiben. Das wertet das Vorhandensein des Pools aber nicht ab. Vor allem dann, wenn man ihn nicht neu schreibt, sondern eben modifiziert, umformatiert, falls einem die Einrückungen nicht passen, oder ähnliches. Solche Code-Pools gibt es doch auch intern in größeren Softwareunternehmen. Mein Kollege und ich haben häufig die Situation, dass der eine schon ein mal ein ähnliches, artverwandtes Problem des anderen gelöst hat. Genauso verhält es sich mit einem Code-Pool wie dem GPL-Biotop.
> Zudem sichert es keineswegs die Bidirektionalität, denn Code kann über andere Schnittstellen verfügbar gemacht werden (Bsp: Web) Deshalb wirkt unter anderem die GPL 3 diesem Phänomen entgegen, genauso wie den Softwarepatenten. Sie sind, wenn man so will, Designfehler der alten Lizenz, die solche Modelle nicht kannte, damals nicht kennen konnte.
> Wobei "entnehmen" ja schon falsche Assoziationen weckt, denn vom ursprünglichen Code verschwindet ja nichts. Eine Kopie entnimmt man natürlich ebenso. Deine Assoziationen sind Dein Problem. ;)
> Zudem sorgt es dafür, dass sich Andere aus Furcht vor Infizierung abwenden und dadurch eben nicht zur Mehrung beitragen, > sondern zur Schaffung von Substituten -- also konkurrierendem, eventuell proprietärem Code Was ich ohne die Existenz des Pools auch hätte. Es geht hier ja nicht um Allaussagen, sondern um die Teilmengenaussage: Wer mitmacht(!), der kann sich sicher sein, dass sich alle, die ebenfalls mitmachen, an die Spielregeln halten und den Wert des Pools gemeinsam mehren. Und seit Version 3 der GPL gehören Softwarepatente und proprietär durch SAAS ebenfalls zu den unerwünschten Spielregeln.
> Wer mit zuviel Mißtrauen gegenüber proprietären Unternehmen agiert, schießt sich nur selbst ins Knie. Es ist doch einfach eine Clubfrage. Wer nicht mitmachen will, der wird dazu nicht gezwungen, der kann dann aber natürlich auch nicht profitieren. Wenn die Frau des Vorsitzenden des Kaninchenzüchtervereins zum Vereinstreffen Schnittchen schmiert, liegt das gewiss nicht an der Tatsache, dass ein Schnittchen Geld in der Erstellung kostet, dass sie Vereinsfremden das "Trittbrettfahren" nicht erlaubt. Der Verein lebt von der Mitarbeit der Mitglieder und als solche stehen ihnen auch die Schnittchen zu.
> Denn gerade sie wären ein Lieferant von Open Source Code, wenn ihre Projekte nicht mehr vermarktungsfähig sind. Oh, sie dürfen ihren Code dann gerne unter BSD-Style-Lizenz vermarkten. Mich persönlich ärgert es konkret am Beispiel des AmigaOS. Es gibt ein freies, Wine-ähnliches Projekt für den Kern des Amiga-Betriebssystems: AROS. Und obwohl das Original praktisch in der Versenkung verschwunden ist, bleibt der Code nicht nur geschlossen, sondern der Halter der Marke und des Codes sorgt sogar dafür, dass es für AROS kein öffentliches Code-Repository gibt. Was für ein Verhalten, und das hat mit Sicherheit nichts mit der GPL zu tun. ;)
Gut, nehmen wir an, die GPL-Nutzer sind eine Art Club, der sich selbst Spielregeln gibt, die Beiträge und Nutzung des Clubgutes regeln. Dann gilt:
1.) Die individuelle Wahl der Mitglieder kann man nicht diskutieren. Sie sind Privatsache und wesentlich eine Frage der Präferenzen: De gustibus non est disputandum. Ein solches Argument habe ich nie benutzt.
2.) Was man aber diskutieren kann, sind zwei Dinge: Erstens, ob die Wahl der Regeln zweckrational ist -- ob die gewünschten Ziele des Clubs durch die Regeln auch erreicht werden -- und zweitens, ob diese Regeln auch für die Gesellschaft als Ganzen Sinn machen und diese daraufhin am Club teilnehmen sollte.
Betrachten wir den ersten Fall: Hier gilt festzustellen, dass die Regeln die gewünschten Ziele nicht erreicht. Zwar erzwingen die Regeln manchmal die Vermehrung des Clubgutes, aber sie reduzieren auch die Vermehrung des Clubgutes -- zum einen durch die Verbreitung von Angst vor Infizierung und damit über eine verringter Teilnehmerzahl, und zum anderen durch die Schaffung von Substituten, also dem Wertverlust des Clubgutes.
Dein Hinweis, das wäre sowieso passiert, ist falsch. Denn zum einen gilt es ja heute schon verschiedene Pools und zum anderen könnten die Regeln ja auch anders sein. Du sagst ja selbst, dass die LGPL auch nur ein weiteres Modell des Code-Sharings ist, also ein anderer Code-Pool und Club.
Betrachten wir den zweiten Fall: Hier sind die Regeln für die Gesellschaft unannehmbar. Denn proprietäre Unternehmen gehören zur Gesellschaft und die Mitglieder der Gesellschaft profitieren (direkt oder indirekt) von eben diesen proprietären Unternehmen und deren Produkten. Ein proprietäres Produkt schafft mehr Wohlfahrt als kein Produkt.
Weiterhin ist Dein Kriterium der Clubregeln ja nicht auf die GPL beschränkt: Auch bei anderen Lizenzen kann der, der mitmacht, sich sicher sein, dass alle anderen Teilnehmer sich an die Spielregeln halten (von Lizenzverletzungen abgesehen).
Bei BSD zum Beispiel: Es ist nicht nur anderen erlaubt, den Code zu jeden Zweck zu verwenden, sondern auch mir selbst.
Deine Zusatzbedingung, dass die Mitglieder den Wert (!) des Pools wegen der Regeln gemeinsam mehren, wird auch durch die GPL nicht erreicht:
1.) Ein Zwang zur Veröffentlichung privater Änderungen besteht nicht, also können Mitglieder teilnehmen ohne zur Mehrung beizutragen. Die SaaS-Klausel wurde zwar im GPL3-Verfahren diskutiert, aber verworfen. Du bist hier, glaube ich, falsch informiert.
2.) Gerade wegen der Angst vor Infizierung reduziert sich der Wert des Clubgutes, was bei anderen Regeln -- etwa LGPL-ähnlichen Regeln -- nicht der Fall gewesen wäre. Denn das Clubgut hilft Dir als Teilnehmer ja nicht, wenn Du Aufträge verlierst, weil die Aufraggeber Angst vor Infizierung haben.
Nochmal: wenn jemand meint, das entspricht seinen Präferenzen, will ich ihm nicht reinreden. Trotzdem bleibt festzuhalten, dass er zum einem Club beiträgt, dessen Regeln (a) schlecht sind, weil sie die gewünschten Ziele nicht erreichen, bzw. diese behindern, und (b) ein schlechtes Modell für die Gesellschaft als Ganzen sind.
Diese Fragen sind im übrigen nicht unwesentlich. Denn die übliche Ausweichantwort -- wer nicht teilnehmen will, der braucht es auch nicht -- ist gerade wegen der starken Monopolisierungstendenzen bei Software im Allgemeinen keine rein private Frage.
Das wird faktisch relevant, wenn es um die öffentliche Förderung eben dieses Club geht -- was aufgrund der vorherigen Gründe rundweg abzulehnen ist, sofern die Bedürfnisse der Gesellschaft auf andere Weise befriedigt werden können; etwa durch Förderung des BSD-Code-Clubes oder der Schaffung eines eigenen Clubs.
Die LGPL ist eine Convenience-Entscheidung für proprietäre Software, die an bestimmten Stellen ihren Sinn hat.
> Sun hat OpenOffice unter LGPL lizenziert
Und Java unter der GPL, aus ganz bestimmten Gründen, die unter anderem den von mir genannten recht ähnlich sind.
> was eigentlich zeigt, wie wenig wichtig diesen Unternehmen die GPL ist
Das ist doch kein Widerspruch, es zeigt nur, dass sie bei anderen Produkten andere Überlegungen als entscheidend ansehen. Ich schrieb genau deshalb übrigens Sun "in Teilen". Es gibt natürlich wichtige Gründe für Code, der unter einer BSD-Style-Lizenz steht, wenn er auch in proprietäre Produkte einfließen können soll, und wenn das der "wichtigere" Beweggrund ist.
> weshalb die Nutzung von Bibliotheken sowieso meist besser ist
Das ist kein Widerspruch, es ist einfach ein weiteres Modell des Code-Sharings. Ich meinte aber eher Code, der eben kleinere Teilaufgaben erfüllt. Was weiß ich, nur eine handvoll Funktionen, die ich in meinem neuen Programm gerade gebrauchen könnte. Deshalb schreibt natürlich niemand eine Bibliothek, erst recht nicht, wenn sie für meinen Zweck noch leicht abgewandelt werden.
> nd drittens wegen den Eigenheiten von Programmiern, die häufig anderer Leute Code "unschön", "unleserlich" oder schlicht
> für schlecht halten und deshalb neu schreiben.
Das wertet das Vorhandensein des Pools aber nicht ab. Vor allem dann, wenn man ihn nicht neu schreibt, sondern eben modifiziert, umformatiert, falls einem die Einrückungen nicht passen, oder ähnliches. Solche Code-Pools gibt es doch auch intern in größeren Softwareunternehmen. Mein Kollege und ich haben häufig die Situation, dass der eine schon ein mal ein ähnliches, artverwandtes Problem des anderen gelöst hat. Genauso verhält es sich mit einem Code-Pool wie dem GPL-Biotop.
> Zudem sichert es keineswegs die Bidirektionalität, denn Code kann über andere Schnittstellen verfügbar gemacht werden (Bsp: Web)
Deshalb wirkt unter anderem die GPL 3 diesem Phänomen entgegen, genauso wie den Softwarepatenten. Sie sind, wenn man so will, Designfehler der alten Lizenz, die solche Modelle nicht kannte, damals nicht kennen konnte.
> Wobei "entnehmen" ja schon falsche Assoziationen weckt, denn vom ursprünglichen Code verschwindet ja nichts.
Eine Kopie entnimmt man natürlich ebenso. Deine Assoziationen sind Dein Problem. ;)
> Zudem sorgt es dafür, dass sich Andere aus Furcht vor Infizierung abwenden und dadurch eben nicht zur Mehrung beitragen,
> sondern zur Schaffung von Substituten -- also konkurrierendem, eventuell proprietärem Code
Was ich ohne die Existenz des Pools auch hätte. Es geht hier ja nicht um Allaussagen, sondern um die Teilmengenaussage: Wer mitmacht(!), der kann sich sicher sein, dass sich alle, die ebenfalls mitmachen, an die Spielregeln halten und den Wert des Pools gemeinsam mehren. Und seit Version 3 der GPL gehören Softwarepatente und proprietär durch SAAS ebenfalls zu den unerwünschten Spielregeln.
> Wer mit zuviel Mißtrauen gegenüber proprietären Unternehmen agiert, schießt sich nur selbst ins Knie.
Es ist doch einfach eine Clubfrage. Wer nicht mitmachen will, der wird dazu nicht gezwungen, der kann dann aber natürlich auch nicht profitieren. Wenn die Frau des Vorsitzenden des Kaninchenzüchtervereins zum Vereinstreffen Schnittchen schmiert, liegt das gewiss nicht an der Tatsache, dass ein Schnittchen Geld in der Erstellung kostet, dass sie Vereinsfremden das "Trittbrettfahren" nicht erlaubt. Der Verein lebt von der Mitarbeit der Mitglieder und als solche stehen ihnen auch die Schnittchen zu.
> Denn gerade sie wären ein Lieferant von Open Source Code, wenn ihre Projekte nicht mehr vermarktungsfähig sind.
Oh, sie dürfen ihren Code dann gerne unter BSD-Style-Lizenz vermarkten. Mich persönlich ärgert es konkret am Beispiel des AmigaOS. Es gibt ein freies, Wine-ähnliches Projekt für den Kern des Amiga-Betriebssystems: AROS. Und obwohl das Original praktisch in der Versenkung verschwunden ist, bleibt der Code nicht nur geschlossen, sondern der Halter der Marke und des Codes sorgt sogar dafür, dass es für AROS kein öffentliches Code-Repository gibt. Was für ein Verhalten, und das hat mit Sicherheit nichts mit der GPL zu tun. ;)
lg
Erik
1.) Die individuelle Wahl der Mitglieder kann man nicht diskutieren. Sie sind Privatsache und wesentlich eine Frage der Präferenzen: De gustibus non est disputandum. Ein solches Argument habe ich nie benutzt.
2.) Was man aber diskutieren kann, sind zwei Dinge: Erstens, ob die Wahl der Regeln zweckrational ist -- ob die gewünschten Ziele des Clubs durch die Regeln auch erreicht werden -- und zweitens, ob diese Regeln auch für die Gesellschaft als Ganzen Sinn machen und diese daraufhin am Club teilnehmen sollte.
Betrachten wir den ersten Fall: Hier gilt festzustellen, dass die Regeln die gewünschten Ziele nicht erreicht. Zwar erzwingen die Regeln manchmal die Vermehrung des Clubgutes, aber sie reduzieren auch die Vermehrung des Clubgutes -- zum einen durch die Verbreitung von Angst vor Infizierung und damit über eine verringter Teilnehmerzahl, und zum anderen durch die Schaffung von Substituten, also dem Wertverlust des Clubgutes.
Dein Hinweis, das wäre sowieso passiert, ist falsch. Denn zum einen gilt es ja heute schon verschiedene Pools und zum anderen könnten die Regeln ja auch anders sein. Du sagst ja selbst, dass die LGPL auch nur ein weiteres Modell des Code-Sharings ist, also ein anderer Code-Pool und Club.
Betrachten wir den zweiten Fall: Hier sind die Regeln für die Gesellschaft unannehmbar. Denn proprietäre Unternehmen gehören zur Gesellschaft und die Mitglieder der Gesellschaft profitieren (direkt oder indirekt) von eben diesen proprietären Unternehmen und deren Produkten. Ein proprietäres Produkt schafft mehr Wohlfahrt als kein Produkt.
Weiterhin ist Dein Kriterium der Clubregeln ja nicht auf die GPL beschränkt: Auch bei anderen Lizenzen kann der, der mitmacht, sich sicher sein, dass alle anderen Teilnehmer sich an die Spielregeln halten (von Lizenzverletzungen abgesehen).
Bei BSD zum Beispiel: Es ist nicht nur anderen erlaubt, den Code zu jeden Zweck zu verwenden, sondern auch mir selbst.
Deine Zusatzbedingung, dass die Mitglieder den Wert (!) des Pools wegen der Regeln gemeinsam mehren, wird auch durch die GPL nicht erreicht:
1.) Ein Zwang zur Veröffentlichung privater Änderungen besteht nicht, also können Mitglieder teilnehmen ohne zur Mehrung beizutragen. Die SaaS-Klausel wurde zwar im GPL3-Verfahren diskutiert, aber verworfen. Du bist hier, glaube ich, falsch informiert.
2.) Gerade wegen der Angst vor Infizierung reduziert sich der Wert des Clubgutes, was bei anderen Regeln -- etwa LGPL-ähnlichen Regeln -- nicht der Fall gewesen wäre. Denn das Clubgut hilft Dir als Teilnehmer ja nicht, wenn Du Aufträge verlierst, weil die Aufraggeber Angst vor Infizierung haben.
Nochmal: wenn jemand meint, das entspricht seinen Präferenzen, will ich ihm nicht reinreden. Trotzdem bleibt festzuhalten, dass er zum einem Club beiträgt, dessen Regeln (a) schlecht sind, weil sie die gewünschten Ziele nicht erreichen, bzw. diese behindern, und (b) ein schlechtes Modell für die Gesellschaft als Ganzen sind.
Diese Fragen sind im übrigen nicht unwesentlich. Denn die übliche Ausweichantwort -- wer nicht teilnehmen will, der braucht es auch nicht -- ist gerade wegen der starken Monopolisierungstendenzen bei Software im Allgemeinen keine rein private Frage.
Das wird faktisch relevant, wenn es um die öffentliche Förderung eben dieses Club geht -- was aufgrund der vorherigen Gründe rundweg abzulehnen ist, sofern die Bedürfnisse der Gesellschaft auf andere Weise befriedigt werden können; etwa durch Förderung des BSD-Code-Clubes oder der Schaffung eines eigenen Clubs.
Aber selbst für mich als Laien ist klar geworden, das du die BSD-Lizenz favorisierst. :-)
Ciao