Hallo,
QT steht ja seit Januar 2009 unter der LGPL Lizenz. Was heißt das genau?
Die GPL Lizenz habe ich grob so verstanden, dass man wenn man Projekte
und Bibliotheken nutzen möchte, die unter GPL stehen, dann muss man sein
Projekt auch unter die GPL stellen. Das bedeutet, man muss auch den
Quellcode offen legen.
Untersagt die GPL Lizenz vollständig kommerzielle Nutzung, oder wäre
kommerzielle Nutzung möglich, wenn man seinen Quellcode offen legt
(nicht ganz praxisnah)
Wie sieht es nun mit LGPL aus? Da steht auf Wiki, dass man wenn man LGPL
Projekte verändert, diese auch unter die LGPL stellen muss und den
Quellcode veröffentlichen. Unterscheidet die LGPL von der GPL Lizenz
nun, dass wenn man ein LGPL Projekt nur extern nutzt z.B. als
Bibliothek, man sein Projekt nicht unter die LGPL stellen muss?
Beispiele:
Ich verändere die QT Bibliotheken. Dann muss ich dieses Projekt auch
unter LGPL stellen, den Sourcecode veröffentlichen etc.
Ich verwende die QT Bibliotheken in einem eigenen Projekt, ohne sie zu
verändern. Dann muss ich mein Projekt nicht unter LGPL stellen und somit
den Sourcecode veröffentlichen, wenn ich (statisch/dynamisch)? gegen sie
linke?
Eine weitere Sache ist QT Commercial(http://www.digia.com/en/Qt/). Eine
kommerzielle Lizenz ist ja dank LGPL nicht mehr notwendig. Welchen Sinn
hat dann diese kommerzielle Lizenz? Bezieht sich diese nur auf besseren
Support?
Gruß
LGPLer schrieb:> Ich verwende die QT Bibliotheken in einem eigenen Projekt, ohne sie zu> verändern. Dann muss ich mein Projekt nicht unter LGPL stellen und somit> den Sourcecode veröffentlichen, wenn ich (statisch/dynamisch)? gegen sie> linke?
Kurzum, fass den Quellcode von Qt nicht an, linke dynamisch dagegen und
dein Applikationscode kann geschlossen sein.
Siehe auch:
http://qt.nokia.com/about/licensing/frequently-asked-questions#how-does-the-lgpl
Wenn du den Qt-Quellcode doch veränderst (warum?), dann müsstest du
imho nur die Änderungen vom Qt-Quellcode herausgeben (steht auch so im
obigen Link).
> Eine weitere Sache ist QT Commercial(http://www.digia.com/en/Qt/). Eine> kommerzielle Lizenz ist ja dank LGPL nicht mehr notwendig. Welchen Sinn> hat dann diese kommerzielle Lizenz? Bezieht sich diese nur auf besseren> Support?
Die kommerzielle Variante hat noch ein paar zusätzliche
Funktionalitäten. Ansonsten wollen Firmen halt Support, und der soll
greifbar (haftbar) sein. Einige werden auch dafür zahlen, weil sie
wollen, dass Qt weiter existiert.
Siehe auch:
http://qt.nokia.com/about/licensing/frequently-asked-questions#why-would-i-want
Genauso steht es aber sowieso schon bei Wikipedia, was gibt es da nicht
zu verstehen?
http://de.wikipedia.org/wiki/GNU_Lesser_General_Public_License
LGPLer schrieb:> Untersagt die GPL Lizenz vollständig kommerzielle Nutzung, oder wäre> kommerzielle Nutzung möglich, wenn man seinen Quellcode offen legt
Der GPL ist das egal. Du kannst beliebig viel für die Software
verlangen. Du mußt dann aber zumindest auf Anfrage den Quellcode (zur
Not gegen eine angemessene Kopiergebühr) zur Verfügung stellen, und du
mußt deinem Abnehmer dieselben Rechte einräumen, wie du auch hast.
> (nicht ganz praxisnah)
Naja, ich war mal in einem Vortrag von Richard Stallman. Der hat sich
eine Zeitlang seinen Lebenunterhalt so verdient.
> Wie sieht es nun mit LGPL aus? Da steht auf Wiki, dass man wenn man LGPL> Projekte verändert, diese auch unter die LGPL stellen muss und den> Quellcode veröffentlichen.
Das stimmt.
> Unterscheidet die LGPL von der GPL Lizenz nun, dass wenn man ein LGPL> Projekt nur extern nutzt z.B. als Bibliothek, man sein Projekt nicht> unter die LGPL stellen muss?
Richtig.
> Beispiele:>> Ich verändere die QT Bibliotheken. Dann muss ich dieses Projekt auch> unter LGPL stellen, den Sourcecode veröffentlichen etc.
Ja, aber nur die geänderte Qt.
> Ich verwende die QT Bibliotheken in einem eigenen Projekt, ohne sie zu> verändern. Dann muss ich mein Projekt nicht unter LGPL stellen und somit> den Sourcecode veröffentlichen, wenn ich (statisch/dynamisch)? gegen sie> linke?
Es muß möglich sein, die LGPL-Komponenten mit vertretbarem Aufwand durch
andere, binärkompatible Komponenten zu ersetzen. In der Regel läuft das
auf dynamisches Linken heraus, weil es bei einem statisch gelinkten
Programm schwierig wäre, die LGPL-Komponenten wieder rauszuschälen und
andere stattdessen reinzubauen. Also mußt du dynamisch linken.
> Eine weitere Sache ist QT Commercial(http://www.digia.com/en/Qt/). Eine> kommerzielle Lizenz ist ja dank LGPL nicht mehr notwendig. Welchen Sinn> hat dann diese kommerzielle Lizenz? Bezieht sich diese nur auf besseren> Support?
Besserer Support, die Möglichkeit, statisch zu linken und die
Möglichkeit, eigene Änderungen an Qt selbst nicht als Quellcode
veröffentlichen zu müssen.
Andi schrieb:> Man kann auch mit dem normalen QT Statisch linken, wie das> lizenztechnisch aussieht weiß ich allerdings nicht.
Dann musst du deinen Quelltext mitliefern. Oder zumindest precompilierte
Object-Files und Makefiles, damit der Endanwender gegen eine geänderte
QT-Version linken kann.
Statt mitliefern reicht ggfs. auch eine Download-Möglichkeit.
Die Idee ist: Du darfst die "Freiheit" der QT nicht durch die Art wie du
sie in deinem kommerziellen Produkt verwendest mindern.
Die LGPL erlaubt jedem (...), die Bibliothek nach eigenem Gutdünken zu
verändern und die veränderte Version zu nutzen. Das muss auch mit der
statisch gelinkten QT innerhalb deines Programms möglich sein.
Ich habe noch eine Frage bezüglich Lgpl/gpl. Qt wird ja unter beiden
Lizenzen vertrieben, aber wie kann ich auswählen, unter welcher dass ich
das verwende?
https://qt-project.org/products/licensing
Nicht dass mir dann jemand unterjubelt Qt sei unter GPL und ich muss
alles veröffentlichen. Es geht lediglich um die lizenzrechtliche
Absicherung, nicht ob mein Code schützenswert ist (ist er eh nicht...)
operator schrieb:> aber wie kann ich auswählen, unter welcher dass ich das verwende?
Du erklärst das einfach. Du musst es ja sowieso in der Doku und/oder
Hilfe zum Programm ausdrücken.
Das heisst ich schreibe einfach: Diese Anwendung benutzt Qt unter LGPL
v2.1?
Mir kommt es komisch vor, dass man die Lizenzen auswählen kann,
insbesondere da diese sich ja überschneiden. Aber wenn dem so ist, ists
ja gut.
Danke für die Hilfe!
operator schrieb:> Das heisst ich schreibe einfach: Diese Anwendung benutzt Qt unter LGPL> v2.1?
Ja.
> Mir kommt es komisch vor, dass man die Lizenzen auswählen kann,> insbesondere da diese sich ja überschneiden.
Es gibt doch viele Leute, die ihre eigenen Arbeit ausschließlich unter
GPL veröffentlichen wollen, für die dürfte die GPL-Variante dann
schlüssiger sein, denn alles zusammen kommt dann mit einer Lizenz aus.
Ist aber nur eine Vermutung.
Jörg Wunsch schrieb:>> Mir kommt es komisch vor, dass man die Lizenzen auswählen kann,>> insbesondere da diese sich ja überschneiden.>> Es gibt doch viele Leute, die ihre eigenen Arbeit ausschließlich unter> GPL veröffentlichen wollen, für die dürfte die GPL-Variante dann> schlüssiger sein, denn alles zusammen kommt dann mit einer Lizenz aus.>> Ist aber nur eine Vermutung.
Unter GPL gibt's die Qt schon wesentlich länger als unter LGPL. Die GPL
als Lizenz nachträglich wieder zu entfernen, dürfte nicht so ohne
weiteres gehen.
Rolf Magnus schrieb:> Jörg Wunsch schrieb:>> Es gibt doch viele Leute, die ihre eigenen Arbeit ausschließlich unter>> GPL veröffentlichen wollen, für die dürfte die GPL-Variante dann>> schlüssiger sein, denn alles zusammen kommt dann mit einer Lizenz aus.>> Unter GPL gibt's die Qt schon wesentlich länger als unter LGPL. Die GPL> als Lizenz nachträglich wieder zu entfernen, dürfte nicht so ohne> weiteres gehen.
Es geht schon, aber nur für zukünftige Versionen.
Andererseits empfinde ich es als Rückschritt, daß Qt jetzt(?) auch unter
LGPL verfügbar ist. Genaugenommen war das einer der sexy Punkte an Qt,
daß man es nur entweder unter GPL oder einer kommerziellen Lizenz
bekommen konnte. Das zwang alle Kunde zur Lüftung des Visiers. Denn es
gibt keinen Graubereich zwischen open source und closed source. IMHO.
XL
Axel Schwenke schrieb:> Es geht schon, aber nur für zukünftige Versionen.
Zukünftige Versionen sind aber doch auch nur abgeletete Werke der
aktuellen Version und stehen somit automatisch auch unter GPL. Meines
Wissens kann man das nur ändern, wenn alle Entwickler, die je
signifikant zur Qt beigetragen haben, zustimmen.
Rolf Magnus schrieb:> Meines Wissens kann man das nur ändern, wenn alle Entwickler, die je> signifikant zur Qt beigetragen haben, zustimmen.
Ja. Da es aber primär sowieso kommerziell entwickelt worden ist,
dürfte das kein wesentliches Problem für Nokia/Digia gewesen sein.
Axel Schwenke schrieb:> Denn es gibt keinen Graubereich zwischen open source und closed source.
Es gibt auch Opensource, die keine virulente GPL wünschen. Solche
Projekte sind mit der LGPL-Version ganz gut bedient.
Aber ich denke, der wesentliche Punkt für Nokia war es schon, die
komplette Plattform eben auch für kommerzielle Projekte schmackhaft
zu machen, die vom Umfang/Umsatz halt nicht in der Lage sind, die
(wirklich nicht gerade preiswerten) kommerziellen Lizenzen zu erwerben.
Die Einschränkung, Qt selbst nicht ändern zu dürfen, stellt dabei im
Allgemeinen keine große Hürde dar. Wird das Projekt doch größer (und
ertragreicher), kann man allemal noch eine kommerzielle Lizenz kaufen,
um in den Genuss des Supports zu kommen. Am Ende gewinnt damit auch
Digia also (potenzielle) Kunden: diejenigen hätten sonst ja was anderes
wählen müssen, und ggf. jemandem anders dann das Geld für den Support
gegeben.
Rolf Magnus schrieb:> Axel Schwenke schrieb:>> Es geht schon, aber nur für zukünftige Versionen.>> Zukünftige Versionen sind aber doch auch nur abgeletete Werke der> aktuellen Version und stehen somit automatisch auch unter GPL.
Das gilt so zwingend nur für Dritte. Als Eigentümer des Codes kannst du
deinen Code jederzeit unter eine neue/weitere Lizenz stellen. Du
kannst das nur eben nicht rückgängig machen. Oder einmal gewährte
Lizenzen zurückziehen.
> Meines> Wissens kann man das nur ändern, wenn alle Entwickler, die je> signifikant zur Qt beigetragen haben, zustimmen.
Da Qt auch unter einer kommerziellen Lizenz verfügbar ist, werden alle
Kontributoren die Rechte an ihren Beiträgen an Nokia abgetreten haben
(müssen). Das war bei meinem ex-Arbeitgeber jedenfalls das Hauptproblem
mit Kontributoren, daß die ihre Codespenden lieber nur in einem
GPL-Branch sehen wollten. Andererseits will man als Eigentümer eher
keine eigenen Branches für GPL- und kommerzielle Version.
Jörg Wunsch schrieb:> Es gibt auch Opensource, die keine virulente GPL wünschen.
Soll vorkommen. Aber das Leben ist kein Wunschkonzert ;)
> Aber ich denke, der wesentliche Punkt für Nokia war es schon, die> komplette Plattform eben auch für kommerzielle Projekte schmackhaft> zu machen, die vom Umfang/Umsatz halt nicht in der Lage sind, die> (wirklich nicht gerade preiswerten) kommerziellen Lizenzen zu erwerben.
Das ist das Standardargument für nichtvirulente offene Lizenzen. Z.B.
die BSD Lizenz. Aber wenn es um die Abwägung geht, ob man lieber
potentielle Marktanteile aufgibt (nur GPL) oder ob man den Feinden der
Freiheit hilft indem man ihnen Code für ihre kommerziellen Produkte
schenkt, dann tendiere ich klar zu ersterem. Quid pro quo. Muß aber
letztlich jeder selber entscheiden.
Man muß allerdings auch bedenken, daß man Code den man ganz ohne
Bedingungen freigibt (z.B. unter BSD Lizenz) kaum jemals wieder
kostenpflichtig relizenzieren kann. Welchem Mehrwert will man denn noch
bieten? Support ist ja von der Lizensierung erstmal unabhängig.
XL
Axel Schwenke schrieb:> Man muß allerdings auch bedenken, daß man Code den man ganz ohne> Bedingungen freigibt (z.B. unter BSD Lizenz) kaum jemals wieder> kostenpflichtig relizenzieren kann.
Wenn man keinen Mehrwert zu bieten hat, dann gibt es auch keinen Grund,
warum $KUNDE dafür Geld bezahlen müsste. Das ist (in sehr knapper
Form) der wesentliche Gedanke hinter der BSD-Lizenz (und bezogen auf
das Thread-Thema durchaus auch der LGPL-Variante einer Qt-Appliation).
Aber das heißt ja nicht, dass andere nicht Mehrwert schaffen können
damit, den jemand gewillt ist zu bezahlen. Da der Kunde keine
schweineteure Lizenzkosten refinanzieren muss, muss er wirklich nur
den Mehrwert finanzieren, den der Dritte damit geschaffen hat.
Demjenigen, der das Framework bereitgestellt hat, dient das dann einfach
als Reklame.
Das ist ein interessanter Gedankengang den ich so noch nicht hatte.
Ich als Privatperson werde mit meiner Software wohl niemals Geld
verdienen. Selbst wenn meine SW so gut wäre dass jemand dafür bezahlen
würde - mir fehlt die Infrastruktur etc.
Also stell ich das Ganze unter eine möglichst restriktiven Lizenz (GPL)
um zu verhindern dass findige Firmen, die über die nötige Infrastruktur
verfügen, mit meiner Arbeit Geld scheffeln.
bal schrieb:> Also stell ich das Ganze unter eine möglichst restriktiven Lizenz (GPL)> um zu verhindern dass findige Firmen, die über die nötige Infrastruktur> verfügen, mit meiner Arbeit Geld scheffeln.
Dafür brauchst du die GPL nicht. Jede andere, freizügigere OSS-Lizenz
verhindert das ebenso gut/schlecht.
Anders ist das bei Code-Bibliotheken, wie z.B. QT, also Sachen, die
As-Is für den Endanwender erstmal keinen Wert haben.
Εrnst B✶ schrieb:> bal schrieb:>> Also stell ich das Ganze unter eine möglichst restriktiven Lizenz (GPL)>> um zu verhindern dass findige Firmen, die über die nötige Infrastruktur>> verfügen, mit meiner Arbeit Geld scheffeln.>> Dafür brauchst du die GPL nicht. Jede andere, freizügigere OSS-Lizenz> verhindert das ebenso gut/schlecht.
Die BSD-Lizenz verhindert das nicht nur schlechter, sondern gar nicht.
bal schrieb:> Das ist ein interessanter Gedankengang den ich so noch nicht hatte.
Ach komm! Das war doch eine wesentliche Motivation, die GPL überhaupt
erst in die Welt zu setzen.
> Also stell ich das Ganze unter eine möglichst restriktiven Lizenz (GPL)> um zu verhindern dass findige Firmen, die über die nötige Infrastruktur> verfügen, mit meiner Arbeit Geld scheffeln.
Ich würde diese Vorgehensweise nicht findig nennen. Außerdem ist dein
Blickwinkel auch zu eng. Bei freier Software geht es zuerst um die
Freiheit. Es soll aber nicht verschwiegen werden, daß es durchaus auch
eine ideologische Komponente gibt: freie Software versteht sich als
Gegenentwurf zu unfreier Software und will anders, und zwar besser sein.
Wenn aber alle freie Software beliebig verwendbar wäre (Lizenz im
BSD-Stil) dann hätte freie Software gegenüber der unfreien einen
strukturellen Nachteil. Die Entwickler unfreier Software würden ihre
Goodies für sich behalten, sich aber gleichzeitig nach Belieben bei den
Goodies der freien Software bedienen können. Mit der Konsequenz, daß die
unfreie Software am Ende besser [1] wäre ... durch die unfreiwillige
Mitarbeit derer, die sie selber als Konkurrenz ansieht. Und Konkurrenz
ist hier kein leeres Wort, erinnere dich an die Haßtiraden von Microsoft
oder SCO in Richtung Linux: "Open Source ist Kommunismus" etc.
Der Geniestreich der GPL ist nun, die Methoden des unfreien Lagers,
nämlich restriktive Lizenzen, gegen sie zu kehren. Ich finde das
wunderbar ironisch.
XL
[1] ein einfaches Beispiel möge das beleuchten: ein Open Source
Entwickler implementiert einen tollen neuen Algorithmus, der sagen wir
mal einen C++ Compiler um Faktor 10 schneller macht. Allerdings hat die
Implementierung irgendwo noch einen Bug, der ganz selten mal zuschlägt.
Eine Firma, die unfreie Software baut, nimmt nun den freien Code und
baut ihn in ihren Compiler ein. Sie ist nun nicht nur auch Faktor 10
schneller, sondern wenn sie den Bug zuerst findet und behebt (ist ja
vielleicht nur ein Vertipper) dann muß sie den Original-Autor nicht
davon in Kenntnis setzen und wird das (aus geschäftlichen Gründen oder
wie du vielleicht sagen würdest: Findigkeit) auch nicht tun. So kommt
die Firma am Ende mit deutlich weniger Arbeit zum besseren Produkt.
Noch ein Nachtrag: manch einer wird beim Lesen des letzten Absatzes mit
den Schultern zucken und sagen "mir doch egal, sollen sie halt.
Hauptsache mein Code und meine Idee steckt in möglichst vielen C++
Compilern". Das ist ein berechtigter Standpunkt. Ich teile ihn zwar
nicht, aber ich erkenne ihn an. Diese Leute sind es, die ihren Code dann
unter LGPL oder BSD oder sonst eine nichtvirale Lizenz stellen.