Folgt man den Verlinkungen auf der Seite landet man auf einem anderen Artikel. Dort ist scheinbar auch der File Chooser abgebildet. Weiß aber nicht ob das Aktuell ist:
Glade ist ein standalone GUI-Builder, damit kannst Du für jedes GTK-Binding das GUI designen, allerdings musst Du das GUI dann "händisch" anbinden. Hat halt andere Vorteile.
Für gtk-sharp gibt es Monodevlop.
gazpacho für python, habe ich aber noch nie benutzt.
Je öfter ich darüber nachdenke, ein GUI Toolkit für eine proprietäre kommerzielle Anwendung zu verwenden, desto besser erscheint mir die Nutzung eines GUI Toolkits, daß unter der BSD Lizenz steht.
Denn auch wenn man das dynamische Linken, welches die LGPL gewährt, weitgehend versucht zu verwenden, kann immer mal der Punkt kommen, wo eine statische Lösung besser wäre. Und wenn man den Code erweitern muß, dann ist ein GUI Toolkit mit BSD Lizenz auch langfristig sicherer, weil die Erlaubnis zum statischen Einbinden es erlaubt, das Notwendige für die Anwendung zu nutzen, ohne später einen eigenen Fork einer ganzen Bibliothek pflegen zu müssen. Der Aufwand der Codepflege ist also geringer, wenn man zusätzliche Funktionen in die Lib einbringen muß und nicht erwarten kann, daß diese Funktionen in die Original-Lib aufgenommen werden, so daß es zwangsläufig zu einem Fork führt.
Auch droht der Fork, wenn auf eine Majorversion gewechselt wird, und ein Wechsel zur neuen Majorversion zu aufwendig ist. Dann ist es kostengünstiger die alte Lib Version zu nutzen, aber deren Support läuft aus und ob man den Support selbst aufrechterhalten kann, hängt davon ab, ob man die alte Version offiziell weitersupporten darf. Denn es könnte ja sein, daß das Offizielle GTK Projekt keine Patches für die alte Version mehr annimmt. Spätestens dann ist man zu einem Fork gezwungen.
Natürlich gilt all diese Betrachtung nur unter der Prämise, wenn man vor dem Problem steht, eine proprietäre Anwendung zu entwickeln. Aus reiner Open Source Sicht, kann die LGPL die bessere Wahl sein, allerdings erhält man dann auch weniger Unterstützung von Firmen, die vielleicht beim GUI Toolkit mitmachen würde, wenn es unter einer für sie freieren Lizenz stehen würde.
Und es ist ja nun jetzt nicht so, daß man vom schlimmsten ausgehen müßte, und die propritären SW Hersteller immer nur den BSD Lizenz Code klauen und unter einer propritären SW stellen wollten.
"Und es ist ja nun jetzt nicht so, daß man vom schlimmsten ausgehen müßte, und die propritären SW Hersteller immer nur den BSD Lizenz Code klauen und unter einer propritären SW stellen wollten."
Das passiert aber und wenn es dann passiert, dann ist mitunter der Ärger groß, vor allem dann, wenn es anders lautende Absprachen gab. Wine ist hierfür wohl das berühmteste Beispiel. Das Wine-Team war von seinem diesbezüglichen "Erlebnis" so betroffen, dass sie deshalb vom BSD/MIT- ins (L)GPL-Lizenzlager gewechselt sind.
Und hat es Nachteile gebracht? Nein, das hat es nicht. Mit Crossover gibt es mittlerweile einen hervorragenden kommerziell agierenden (L)GPL-Wine-Partner, der seinen Code natürlich ins Wine-Projekt zurückfließen lässt. Letzteres schadet auch Crossover nicht im Geringsten, eben, weil ihre Wine-Softwareversion herausragend ist.
Wine ist ein schlechtes Beispiel, da es sich nicht wirklich um ein Toolkit für SW Entwickler handelt und im Fall von Cedega (oder wie hieß das doch gleich) die eigentliche Arbeit ja Wine selbst darstellte, während bei Anwendungen, die nur ein GUI Toolkit zur Darstellung der Buttons & Fenster verwenden, die eigentliche Arbeit immer noch von der SW Entwicklungsfirma selbst getragen werden muß und im Anwendungscode steckt.
Und hat es Nachteile gebracht?
Bei Toolkits kann so etwas durchaus Nachteile bringen, da Firmen fehlen die Code beisteuern. Und man sieht das auch an der Dokumentation von GTK+ oder dem technischen Status von gtkmm.
Bessere Beispiele sind daher die zlib Library (steht unter zlib Lizenz, aber vom Handling her ähnlich wie die BSD L.) oder die SDL 2.x die extra deswegen von der LGPL auf eine freiere Lizenz (AFAIK zlib) umsteigt. Die SDL 1.x hat als LGPL Lib nämlich keine Verbreitung bei kommerziellen propritären Spielen erhalten. Die paar Linux Ports die die SDL nutzen, sind stark in der Minderheit und nicht der Rede wert. Die SDL wird gemieden, daher hat man für die Vers. 2.x die Lizenz geändert.
Es kommt also immer darauf an, was für eine Art von Library man mit der LGPL schützen will. Bei Wine, daß mehr schon eine Anwendung selbst darstellt, als eine Lib, war die LGPL vielleicht sinnvoll, aber bei generischen Basisbibliotheken wie eben ein GUI Toolkit kann das nunmal deutlich anders aussehen.
Das passiert aber und wenn es dann passiert, dann ist mitunter der Ärger groß,
Der Originalcode ist weiterhin frei verfügbar und gerade bei Anwendungen die nur eine Basisbibliothek nutzen ist der Verlust minimal, weil es 100 andere Firmen geben kann, die weiterhin auf die Original Basisbibliothek setzen und diese weitersupported. Da stört das eine schwarze Schaf dann nicht und geht auch in der Bedeutung unter, da dessen Software eh wieder eine ganz bestimmte Anwendung darstellt.
Bei einem GUI Toolkit würde es nur dann ein Problem geben, wenn jemand hergehen würde, das Teil closen würde und dann das eigentliche GUI Toolkit anstatt eine Anwendung selbst vermarkten würde. Aber die Wahrscheinlichkeit daß so etwas passiert ist eher gering und Dritte, die ne Bibliothek für ihre Anwendung nutzen wollen, wären dann ja doof, wenn sie eine Lizenz von dieser Firma kaufen würden, während sie selbst mit der freien Open Source Lizenz Bibliothek viel mehr Möglichkeiten hätte und sich nicht in eine Abhängigkeit von nur einer Firma begeben würden.
Von Anonymous am Di, 27. September 2011 um 19:09 #
Und es ist ja nun jetzt nicht so, daß man vom schlimmsten ausgehen müßte, und die propritären SW Hersteller immer nur den BSD Lizenz Code klauen und unter einer propritären SW stellen wollten.
Doch, genau davon muss man ausgehen, weil es mehrfach passiert ist: FreeBSD-Code in Mac OS X, Wine-Code in Cedega (was dann auch die Lizenzänderung von der MIT-Lizenz zur LGPL nach sich zog), der TCP/IP-Stack in Windows NT 3.1.
Ist doch gut, wenn proprietäre Entwickler Nachteile haben, finde ich.
Inwiefern soll das gut sein?
Die Lib wird dadurch nicht besser, sondern eher schlechter, da zusätzliche Entwickler (die der Firmen) fehlen und das Potential, was möglich wäre (also eine noch bessere Lib), nicht ausgeschöpft werden kann.
Meiner Meinung nach ist es kleingeistig. Gerade bei so Basis/Grundsachen wie GUI Toolkit Bibliotheken.
Von freedom lover am Di, 27. September 2011 um 16:10 #
Proprietäre Entwickler gehen mir sowas am Hintern vorbei. Die schau ich nichtmal mit dem Hintern an. Deren Probleme interessieren mich einen feuchten Kehricht.
Die Open Source Lib ist dir also auch egal. Das geht aus deinem Kommentar nämlich hervor.
Oder warum überliest du, daß Proprietäre Entwickler auch die Open Source Lib verbessern können?
Und die Nutzer sind dir ebenso egal. Manche wären froh, wenn sie Anwendung XY, z.B. Elster unter Linux hätten. Crossplattform Toolkit können das ermöglichen, aber dann muß auch die Lizenz stimmen, wenn man proprietäre Entwickler anlocken will, diese zu nutzen.
Von freedom lover am Di, 27. September 2011 um 16:19 #
Oder warum überliest du, daß Proprietäre Entwickler auch die Open Source Lib verbessern können?
Ich habe Prinzipien. Ich würde mir als Greis auch nicht von einem Mörder über die Straße helfen lassen wollen, selbst wenn er mir damit im Kleinen was Gutes tun würde.
Von Anonymous am Di, 27. September 2011 um 16:49 #
Oder warum überliest du, daß Proprietäre Entwickler auch die Open Source Lib verbessern können?
Weil die Argumentation Schwachsinn ist, denn wenn der Entwickler proprietärer Software bereit wäre, seine Änderungen unter einer Open-Source-Lizenz zu veröffentlichen, dann wäre für ihn auch die Verwendung einer LGPL-Bibliothek kein Problem.
Die LGPL ist genau dann ein Problem, wenn man Zukunftssicherheit braucht und aus welchen Gründen auch immer (Juristen können da viel drehen und dir das Genick brechen!) während der Projektentwicklung statisches Linken plötzlich eine Notwendigkeit wird. Und bis dahin, kann IMMER Code zum Open Source Projekt beigesteuert werden, die freie Lizenz ist also die Rettungsschnur wenn alles schief läuft. Denn ein gewachsenens Projekt, daß vielleicht 5 Jahre schon immer von Majorversion zu Majorversion weiterentwickelt wird, kann man nicht mal auf die schnelle auf andere Libs umstellen. Man braucht also Zukunftssicherheit auf mind. > 20 Jahre und die erhält man durch eine möglichst freie Lizenz, bei der einem kein Jurist nen Strick drehen kann.
Was meinst denn du, warum in der Praxis kaum ein proprietäres Projekt auf LGPL Bibliotheken aufsetzt? Zlib, libPNG, OpenAL werden alle gerne genommen, weil deren Lizenzen statisches Linken für den Fall der Fälle zulassen. Die LGPL wird aber, obwohl sie den Anschein zeigt, für propritäere Projekte geeignet zu sein, wie das Teufel das Weihwasser gemieden.
Deswegen sollte man als Lib Entwickler die LGPL eher vermeiden.
Von Anonymous am Di, 27. September 2011 um 17:45 #
Die LGPL ist genau dann ein Problem, wenn man Zukunftssicherheit braucht und aus welchen Gründen auch immer (Juristen können da viel drehen und dir das Genick brechen!) während der Projektentwicklung statisches Linken plötzlich eine Notwendigkeit wird.
Die Formulierung "aus welchen Gründen auch immer" lässt mit ziemlicher Sicherheit darauf schließen, dass Dir kein sinnvoller Grund eingefallen ist. Wie auch, es gibt ja keinen...
Was meinst denn du, warum in der Praxis kaum ein proprietäres Projekt auf LGPL Bibliotheken aufsetzt?
So ziemlich jedes proprietäre Projekt unter Linux verwendet die glibc, welche unter der LGPL steht. Und auch Gtk ist ein Beispiel für eine Bibliothek, die durchaus von proprietären Projekten genutzt wird, z. B. vom Adobe Reader.
So ziemlich jedes proprietäre Projekt unter Linux verwendet die glibc, welche unter der LGPL steht.
Und fast alle diese proprietären Projekte werden vornehmlich auch unter Windows oder andere Unixe entwickelt, wo es andere libc Bibliotheken gibt, weswegen die Zukunftsichheit in keinster Weise gefährdet ist. Das ist sie auch nichtmal bei der glibc, denn dazu ist diese Lib zu wichtig. Als C lib um mehrere Größenordnungen wichtiger als eine GUI Lib, wie GTK+. Das die glibc also trotz LGPL verwendet wird, hat andere Gründe.
Und auch Gtk ist ein Beispiel für eine Bibliothek, die durchaus von proprietären Projekten genutzt wird, z. B. vom Adobe Reader.
Ich könnte dir 500 kommerzielle proprietäre AAA Computerspiele nennen, die die zlib Lizenz verwenden. Nenne du mir 500 kommerzielle proprietäre AAA Computerspiele die die SDL 1.x (LGPL) verwenden.
Von Anonymous am Di, 27. September 2011 um 18:30 #
Und fast alle diese proprietären Projekte werden vornehmlich auch unter Windows oder andere Unixe entwickelt, wo es andere libc Bibliotheken gibt, weswegen die Zukunftsichheit in keinster Weise gefährdet ist.
Zukunftssicherheit hat mit der Lizenz exakt gar nichts zu tun. Entweder, man ist mit der Entwicklung der Upstream-Version einverstanden und verwendet diese weiter. Oder man ist es nicht, dann forkt man die Bibliothek, was mit der LGPL genauso möglich ist wie bei der BSD-Lizenz. Die Ausnahme ist natürlich, wenn man ein Problem damit hat, die Änderungen unter eine freie Lizenz zu stellen. In diesem Fall hat der Upstream-Entwickler aber ohnehin keinen Vorteil davon, dass man die Bibliothek verwendet, dann kann es ihm also egal sein.
Ich könnte dir 500 kommerzielle proprietäre AAA Computerspiele nennen, die die zlib Lizenz verwenden. Nenne du mir 500 kommerzielle proprietäre AAA Computerspiele die die SDL 1.x (LGPL) verwenden.
Der Vergleich ist absurd, schließlich werden Computerspiele in der Regel für Windows und DirectX entwickelt, wobei letzteres eine mit SDL vergleichbare Funktionalität bereitstellt. Der Grund, warum man SDL nicht so oft verwendet, dürfte einfach sein, dass man diese Bibliothek unter Windows nicht braucht. Besteht dagegen ein Bedarf für derartige Funktionalität (wie unter Linux), so wird SDL durchaus genutzt. http://en.wikipedia.org/wiki/List_of_games_using_SDL
Und selbst wenn das nicht so wäre, müsstest Du immer noch nachweisen, dass die Entscheidung der Spieleentwickler, nicht SDL zu verwenden, auf der Lizenz basiert und nicht einfach z. B. auf technischen Gründen. Ansonsten stellst Du hier nur haltlose Behauptungen auf.
Und selbst wenn das nicht so wäre, müsstest Du immer noch nachweisen, dass die Entscheidung der Spieleentwickler, nicht SDL zu verwenden, auf der Lizenz basiert und nicht einfach z. B. auf technischen Gründen
Dann stelle dir die Frage, warum die SDL Macher jetzt bei der Version 2.0 auf die zlib Lizenz umsteigen.
Die restriktive LGPL Lizenz war dem Projekt nicht zweckdienlich, die SDL wurde zu selten benutzt, die Crossplattformprodukte, die man sich auch als Konsument erhoffte blieben aus und auf Konsolen und geschlossenen Plattformen wurde die SDL erst gar nicht benutzt, eben auch wieder aufgrund der Lizenz.
Die LGPL erwies der SDL also einen Bärendienst. Deswegen ändert man das nun mit SDL 2.x
Von Anonymous am Di, 27. September 2011 um 20:49 #
Die restriktive LGPL Lizenz war dem Projekt nicht zweckdienlich, die SDL wurde zu selten benutzt, die Crossplattformprodukte, die man sich auch als Konsument erhoffte blieben aus und auf Konsolen und geschlossenen Plattformen wurde die SDL erst gar nicht benutzt, eben auch wieder aufgrund der Lizenz.
Das ist eine völlig unbewiesene und unbelegte Behauptung. Der Mangel an Spielen für Linux dürfte ganz andere Gründe haben, nämlich dass es sich für den kleinen Markt einfach nicht lohnt, die Spiele zu porten. Aber so etwas interessiert Lizenztrolle natürlich nicht.
Ach ja, etwas anderes ist übrigens ein Fakt und keine wohlfeile Behauptung, nämlich dass Firmen wie Epic, Bioware und Raven Software SDL erfolgreich genutzt haben, um ihre Software auf Linux zu porten. In der echten Welt stellt die LGPL also kein Problem dar.
Der Mangel an Spielen für Linux dürfte ganz andere Gründe haben, nämlich dass es sich für den kleinen Markt einfach nicht lohnt, die Spiele zu porten.
Mit einer Crossplattform API wie SDL wäre der Port eigentlich ein Kinderspiel, es muß also an der Lizenz der SDL liegen. Aber wie dem auch sei, wir werden sehen wie sich die Lizenzänderung bei der SDL Ver. 2.x auf die kommerziellen Spiele auswirken wird.
Ach ja, etwas anderes ist übrigens ein Fakt und keine wohlfeile Behauptung, nämlich dass Firmen wie Epic, Bioware und Raven Software SDL erfolgreich genutzt haben, um ihre Software auf Linux zu porten. In der echten Welt stellt die LGPL also kein Problem dar.
Und das war alles unsupported, damit man im Notfall den Stecker rausziehen kann. Zählt also nicht.
Von Anonymous am Mi, 28. September 2011 um 00:26 #
Mit einer Crossplattform API wie SDL wäre der Port eigentlich ein Kinderspiel
Nein, wäre er nicht. Mit so einer Behauptung machst Du Dich lächerlich.
Und das war alles unsupported, damit man im Notfall den Stecker rausziehen kann.
Wie soll dieser "Notfall" denn aussehen? Du hast noch kein realistisches Szenario genannt, wo die LGPL tatsächlich ein Problem darstellt.
Dieser Beitrag wurde 1 mal editiert. Zuletzt am 28. Sep 2011 um 00:27.
Nein, wäre er nicht. Mit so einer Behauptung machst Du Dich lächerlich.
Definiere du "Kinderspiel".
Ich weiß schon was ich sage, SDL, OpenGL, OpenAL und natürlich gehe ich jetzt nicht von einer bestehenden Game Engine aus, die für DirectX geschrieben wurde.
Wie soll dieser "Notfall" denn aussehen? Du hast noch kein realistisches Szenario genannt, wo die LGPL tatsächlich ein Problem darstellt.
Die Formulierung "aus welchen Gründen auch immer" lässt mit ziemlicher Sicherheit darauf schließen, dass Dir kein sinnvoller Grund eingefallen ist. Wie auch, es gibt ja keinen...
Die Version der Lizenz könnte sich ändern und die Änderungen könnten Restriktiver sein. Das ist nicht Zukunftssicher.
Von Anonymous am Di, 27. September 2011 um 18:20 #
Die Version der Lizenz könnte sich ändern und die Änderungen könnten Restriktiver sein. Das ist nicht Zukunftssicher.
Unsinn, wenn man Code einmal lizenziert hat, ändert sich die Lizenz nicht von selbst. Natürlich könnte das Upstream-Projekt die Lizenz ändern, aber das kann auch bei Projekten unter BSD- oder MIT-Lizenz passieren. Wine ist beispielsweise von der MIT-Lizenz zur LGPL gewechselt.
Von Anonymous am Di, 27. September 2011 um 18:58 #
Richtig, aber bei denen kann man wenigstens dann den ganzen Code der letzten Version ohne nennenswerte Einschränkungen nutzen.
Die Argumentation ist Unsinn. Angenommen, das Upstream-Projekt ändert seine Lizenz, z. B. von der LGPL zu einer proprietären Lizenz. Wieso sollten mich die Verpflichtungen, die die LGPL mir auferlegt mich jetzt mehr stören als vor der Lizenzänderung? Das ergibt keinen Sinn.
Doch, weil du nun die alte Version selbst weiterpflegen müßtest.
Bei BSD nimmst du den Code und kannst damit machen was du willst. Also 80 % wegschmeisen und 20 % in den eigenen Code aufnehmen. Damit sind die weiteren Wartungskosten minimiert.
Von Anonymous am Mi, 28. September 2011 um 00:24 #
Das hatten wir doch schon geklärt, daß du den LGPL Code nicht in deinen propritären Code reinkopieren kannst.
Das "Geht auch bei LGPL-Code" bezog sich auf "Also 80 % wegschmeisen". Du kannst gerne Deinen persönlichen gtk-Fork bauen, beim dem 80% fehlen. Du musst nur die Quellen veröffentlichen.
Wenn der Code Modular aufgebaut ist, dann kann man den unnötigen Rest gut rausschmeißen.
Genau, und zwar unabhängig davon, ob er BSD- oder LGPL-lizenziert ist.
Ist doch gut, wenn proprietäre Entwickler Nachteile haben, finde ich.
Die proprietären Entwickler nehmen in solchen Fällen einfach andere Bibliotheken. Und im Fall von GUI Toolkits ist das dann Qt oder eben MFC & Co.
Und die MFC läuft nicht unter Linux -> Nachteil für die Linux Anwender.
Sprich, die Linux und FreeBSD Nutzer verlieren durch solche Engstirnigkeitspolitik. Die Firmen verwenden einfach andere GUI Toolkits die es nur unter Windows gibt und der Support von Microsoft ist bei deren Libs ja nicht schlecht.
Von freedom lover am Di, 27. September 2011 um 16:16 #
Ist doch super, wenn die Pest zur Cholera zieht. Soll man den proprietären Entwicklern nachtrauern?
Und die MFC läuft nicht unter Linux -> Nachteil für die Linux Anwender.
Wieso Nachteil? Wenn die Software eh proprietär ist, würde ich sie auch nicht unter Linux benutzen wollen.
Sprich, die Linux und FreeBSD Nutzer verlieren durch solche Engstirnigkeitspolitik.
Mir geht es nicht darum, irgendwas zu gewinnen, sondern darum, dass ich freie Software benutze und auf meiner Plattform von proprietärer Software unbehelligt bleibe.
Wieso Nachteil? Wenn die Software eh proprietär ist, würde ich sie auch nicht unter Linux benutzen wollen.
Du denkst nur an dich und nicht an die anderen Anwender. Du bist also ein Egoist.
Viele hätten gerne MS Office oder Photoshop unter Linux und der Staat (für den du Steuern zahlst) hätte es dann ebenfalls viel einfacher bei der Linux Migration.
Außerdem, ich weiß nicht wo und ob du arbeitest, aber die Chancen sind groß, daß man als Arbeitnehmer wegen solchen Sachen dazu gezwungen ist, unter Windows zu arbeiten, weil Anwendung XY eben nur unter Windows läuft, weil damals das entsprechende crossplattform GUI Toolkit mit der richtigen Lizenz gefehlt hat, als es vom beauftragen Entwickler der Firma entwickelt wurde.
Und vielleicht müssen sich deswegen auch manche Arbeitnehmer mit langsamen JAVA Anwendungen zufrieden geben, weil die Firma Plattformunabhängigkeit als Sicherheit wollte, anstatt 3 native Binarys für die drei großen Desktopsysteme.
Mir geht es nicht darum, irgendwas zu gewinnen, sondern darum, dass ich freie Software benutze und auf meiner Plattform von proprietärer Software unbehelligt bleibe.
Ja, du bist Egoist, das haben wir jetzt schon erkannt. Du denkst nur an dich. Und was bitteschön ist für dich das Problem, die proprietäre Software einfach nicht auf deinem Rechner zu installieren? Du bist dazu doch nicht gezwungen. (ist auf deinem Rechner übrigens Google Earth, die CS NVidia Treiber und das Adobe Flash Plugin installiert, würde mich mal interessieren)
Und wer weiß, vielleicht wirst du, wenn du mal den Job wechselst oder mit arbeiten anfängst, mit einem schönen proprietären Windows Desktop behelligt, weil du heute so engstirnig warst. Ich würde das gut finden.
Denn auch wenn man das dynamische Linken, welches die LGPL gewährt, weitgehend versucht zu verwenden, kann immer mal der Punkt kommen, wo eine statische Lösung besser wäre.
Du kannst auch eine LGPL Bibliothek statisch linken.
Ist für den Empfänger komplizierter den LGPL Teil der Anwendung auszutauschen, d.h. man muss neu Linken und kann nicht einfach eine Datei austauschen oder einen Symlink umbiegen, aber nicht desto trotz machbar.
Und wenn man den Code erweitern muß, dann ist ein GUI Toolkit mit BSD Lizenz auch langfristig sicherer, weil die Erlaubnis zum statischen Einbinden es erlaubt, das Notwendige für die Anwendung zu nutzen, ohne später einen eigenen Fork einer ganzen Bibliothek pflegen zu müssen.
Das versteh ich nicht ganz. Wenn du Änderungen am Code der Bibliothek vornimmst und nicht an den Ursprung weitergibts, hast du immer einen Fork, unabhängig von der Lizenz der Bibliothek.
Du kannst auch eine LGPL Bibliothek statisch linken.
Und die resultierende proprietäre closed source Anwendung verkaufen? Ja klar!
Das versteh ich nicht ganz. Wenn du Änderungen am Code der Bibliothek vornimmst und nicht an den Ursprung weitergibts, hast du immer einen Fork, unabhängig von der Lizenz der Bibliothek.
Beim statischen Linken wird nur das verwendet, was man tatsächlich nutzt. Das erleichtert die Codepflege, da man die unbenutzen Sachen ignorieren oder wegrationalisieren kann.
Und die resultierende proprietäre closed source Anwendung verkaufen? Ja klar!
Natürlich, warum sollte das nicht gehen? Sollte man Änderungen am Code der Biblothek gemacht haben, muss man diese Änderungen unter LGPL kompatiblen Lizenzbegingungen zugänglich machen und der Empfänger der Anwendung muss in der Lage sein, die LGPL lizenzierten Teile zu verändern und auszutauschen.
Wie schon vorhin geschrieben ist das bei einem statisch gelinkten Programm schwieriger, weil man neu linken muss, aber nicht unmöglich.
Beim statischen Linken wird nur das verwendet, was man tatsächlich nutzt. Das erleichtert die Codepflege, da man die unbenutzen Sachen ignorieren oder wegrationalisieren kann.
Wenn man nur gegen bestimmte Teile linken möchte macht es doch keinen Unterschied, ob man gegen eine zurecht gestutzte statische oder dynamische Bibliothek linkt, in beiden Fällen benutzt man nicht mehr die originale Fassung. Man hat also schon dann einen Fork, ob dann noch Änderungen an den Dateien der Bibliothek hinzukommen ist dann schon egal (macht den Fork natürlich noch unterschiedlicher, klar)
Danke, also kennen weder du noch Krake die LGPL aus dem juristischen Standpunkt so gut wie ich. Aber Hauptsache mir vorwerfen, dass ich die Lizenz lesen soll, bevor ich sie kritisiere.
Vielleicht solltet ihr beide die Lizenz mal lesen.
Da es aber für statisches Linken ohnehin keine sinnvollen Gründe gibt, spielt das keine Rolle.
Die Datenmenge wird kleiner, man muß nicht noch eine gesamte Lib in Form einer DLL & Co mitliefern. Bei Embedded Anwendungen kann das ebenfalls sehr nützlich sein.
Die Datenmenge wird kleiner, man muß nicht noch eine gesamte Lib in Form einer DLL & Co mitliefern.
Bei einer in Quellen vorliegenden Bibliothek ist man nicht gezwungen die Bibliothek in ihrem maximalen Umfang zu verwenden. Unabhängig davon ob die Quellen dabei LGPL, BSD, MIT, Public Domain, etc. lizenziert sind.
Diese Anpassbarkeit ist schließlich einer der Vorteile von in Quellen vorliegender Software.
Nein, auch ohne solche Ausnahme ist statisches Linken erlaubt.
Wie andere reziproke Lizenzen geht es bei der LGPL erst mal um den Code der Bibliothek. Dieser muss über einen von mehreren Wegen für den Empfänger der Software verfügbar sein.
Nach Erhalt der Quellen muss dem es dem Empfänger möglich sein, diese zu ändern und wieder zu Objektcode umzuwandeln (zu bauen) und die Software dann mit dieser Abhängigkeit zu betreiben.
Bei dynamisch gelinkten Bibliotheken ist das einfach, der Empfänger ersetzt einfach die ausgelieferte Bibliotheksdatei mit der selbst erstellten, oder erreicht das Äquivalent mit Symlinks oder Preload Tricks.
Bei statisch gelinkten Bibliotheken ist das schwieriger, weil das Linken eben nicht erst zur Laufzeit erfolgt, sondern Teil des Bauens ist. Das wird oftmals als Notwendigkeit missinterpretiert, dass dafür dem Empfänger die Quelle der Software selbst zur Verfügung stehen müssten.
Das Übersetzen (Compilieren) der Software und das Linken sind aber zwei getrennte Schritte, die unabhängig von irgendwelchen Lizenzen immer nacheinander ausgeführt werden.
Beim Linken ist es irrelevant ob man viele kleine Objektdateien oder wenige große verbindet, d.h. die übersetzte Software kann in eine Datei kombiniert werden, praktisch so wie wenn sie dynamische Bibliotheken verwenden würde.
Der Empfänger muss dann eben noch den geänderten Teil mit diesem Hauptteil zusammenführen, was bei den meisten Compilern ein trivialer Aufruf ist.
Meistens kommt ein Hersteller den Lizenzbedingungen der LGPL derart nach, in dem der Bibliotheksteil dynamisch gelinkt verwendet wird. Es wird daher oft fälschlicherweise davon ausgegangen, dass diese Vorgehensweise die einzig mögliche ist.
Da das ohnehin für den Empfänger die bevorzugte Lösung ist, wird dem auch selten widersprochen, aber es schadet nicht, hin und wieder klar zu stellen, dass die Lizenz keine technische Einschränkung wie die Art des Linkens festlegt. So lange dem Empfänger die geschützten Möglichkeiten offen bleiben, ist der Lizenz genüge getan. Und das kann man eben auch, wenn auch ein bischen komplizierter, bei statisch gelinkten Bibliotheken erfüllen.
Von Anonymous am Do, 29. September 2011 um 02:36 #
Du hast natürlich Recht, statisches Linken ist erlaubt. Ich hatte nach seiner Behauptung, dass die LGPL dynamisches Linken fordere, noch einmal in der LGPL nachgelesen, um sicher zu gehen, dass ich mich nicht getäuscht hatte. Dann bin ich auf §6 Absatz b gestoßen, und da ist eindeutig von dynamlischem Linken die Rede, daher habe ich ihm dann vorschnell zugestimmt. Ich hatte aber übersehen, dass lediglich die Umsetzung _eines_ der Absätze a-e gefordert ist.
Von Anonymous am Di, 27. September 2011 um 16:44 #
Denn auch wenn man das dynamische Linken, welches die LGPL gewährt, weitgehend versucht zu verwenden, kann immer mal der Punkt kommen, wo eine statische Lösung besser wäre.
Nein. Welchen Vorteil sollte statisches Linken denn bieten? Selbst wenn man der Ansicht ist, eine ganz bestimmte Version einer Bibliothek nutzen zu müssen, kann man diese Version als shared object mitliefern und in der ELF-Datei über den rpath festlegen, dass im Programmverzeichnis (statt in /usr/lib/) nach dem shared object gesucht werden soll.
Und wenn man den Code erweitern muß, dann ist ein GUI Toolkit mit BSD Lizenz auch langfristig sicherer, weil die Erlaubnis zum statischen Einbinden es erlaubt, das Notwendige für die Anwendung zu nutzen, ohne später einen eigenen Fork einer ganzen Bibliothek pflegen zu müssen. Der Aufwand der Codepflege ist also geringer, wenn man zusätzliche Funktionen in die Lib einbringen muß und nicht erwarten kann, daß diese Funktionen in die Original-Lib aufgenommen werden, so daß es zwangsläufig zu einem Fork führt.
Was ist das denn für ein Unsinn? Wenn man Veränderungen vornimmt, die man ins Upstream-Projekt nicht einbringen kann, dann hat man völlig unabhängig von der Lizenz einen Fork an der Backe.
Auch droht der Fork, wenn auf eine Majorversion gewechselt wird, und ein Wechsel zur neuen Majorversion zu aufwendig ist. Dann ist es kostengünstiger die alte Lib Version zu nutzen, aber deren Support läuft aus und ob man den Support selbst aufrechterhalten kann, hängt davon ab, ob man die alte Version offiziell weitersupporten darf. Denn es könnte ja sein, daß das Offizielle GTK Projekt keine Patches für die alte Version mehr annimmt. Spätestens dann ist man zu einem Fork gezwungen.
Auch hier macht die Lizenz keinen Unterschied. Das Gtk-Projekt könnte Patches für Legacy-Versionen auch dann zurückweisen, wenn es die BSD-Lizenz verwendete, man hätte also auch hier mit dem Pflegeaufwand für einen Fork zu kämpfen.
Nein. Welchen Vorteil sollte statisches Linken denn bieten? Selbst wenn man der Ansicht ist, eine ganz bestimmte Version einer Bibliothek nutzen zu müssen, kann man diese Version als shared object mitliefern und in der ELF-Datei über den rpath festlegen, dass im Programmverzeichnis (statt in /usr/lib/) nach dem shared object gesucht werden soll.
ELF und rpath gibt es nicht unter Windows. Denk an Crossplatform Anwendungen. Für Linux alleine entwickelt niemand, dann schon eher nur für Windows, aber dann kann man gleich die MFC verwenden, wenn's nur Windows sein soll.
Was ist das denn für ein Unsinn? Wenn man Veränderungen vornimmt, die man ins Upstream-Projekt nicht einbringen kann, dann hat man völlig unabhängig von der Lizenz einen Fork an der Backe.
Und wenn du so weit bist, dann kannst du auch gleich die Codeteile aus der Lib nehmen und in deinen Code einbauen. Das spart die Pflege und erhöht die Zukunftsicherheit.
Aber dazu braucht man halt eine Lizenz, die so etwas erlaubt. Die BSD Lizenz erlaubt das.
wenn es die BSD-Lizenz verwendete, man hätte also auch hier mit dem Pflegeaufwand für einen Fork zu kämpfen.
Mit BSD-Lizenz setzt man den notwendigen Code einfach in das Projekt und hat weiterhin nur einen Code zu pflegen.
Und wieso sollte das auf irgendeine Art den Code wartbarer machen?
Weil du nur das nötigste nimmst. Der zu wartende Code wird kleiner.
Behälst du das ganze als dynamisch Lib bei, dann mußt du die gesamte Lib warten, wenn sich sonst niemand dafür findet. Bei einem Fork dürfte das der Fall sein.
Sinnvoll ist so etwas doch bestenfalls für Anwendungen, die sowieso im Browser laufen sollen. Also die ganze Intranet Firmensoftware, die irgendwelche Sachen mit dem Browser zugänglich machen sollen und die Software mit nur einer Lizenz auf dem Server läuft.
Aber wozu soll das für klassische Desktopanwendungen gut sein? Das Zeugs wird übers Netzwerk verschickt und ist im Vergleich zur direkten Lösung unter X entsprechend lahm, wenn da viele Daten oder Animationen drinstecken. Der Browser erhöht den Overhead ebenfalls noch.
Was für Anwendungsgebiete sollte broadway haben? Ja schaut nett aus ist supercool, aber den Entwicklungsaufwand nicht wert. Ich nehme nicht an das du schon mal was mit einem der beiden Toolkits programmiert hast, sonst würdest du nicht solchen Schwachsinn posten.
> Was für Anwendungsgebiete sollte broadway haben? In etwa die, die durch die Netzwerktransparenz von X abgedeckt werden. Nur eben auf Toolkit-Ebene und damit wirklich Cross-Plattform. Es wird kein X-Server auf Windows, MacOS oder irgendein Tablet/SmartphoneOS benötigt. Wer einen Browser hat kann die Anwendung remote nutzen. Der dürfte inzwischen verbreiteter sein als das X-Protokoll.
Mit X und seinen Unterstützungslibrarys (insbesondere hier Xdnd) ist aber mehr möglich, Z.B. Drag & Drop von Dateien von der einen X Anwendung in die nächste.
Mag ja sein das es hier und dort klein Einschränkungen gibt, aber ist das jetzt wirklich so relevant? Es hat nun mal unbestritten seinen Vorteil, wenn man auf Client-Seite nix weiter als einen Browser braucht um eine Anwendung zu nutzen. Kein X-Stack ist notwendig und das ganze läuft sofort auf X-Plattformen bis zum Tablet.
Gibt es irgendwo Screenshots von den neuen Dialogen?
Hab das hier auf die schnelle gefunden. Im Kommentarbereich ist auch ein Video verlinkt das Broadway demonstriert:
http://derstandard.at/1317018478344/Toolkit-GTK-32-Mit-HTML5--und-Wayland-Backends
Jetzt weiß ich auch warum bei Wayland Netzwerktransparenz keine große Priorität mehr hat.
intressant wäre was am file dialog geändert worden ist
Folgt man den Verlinkungen auf der Seite landet man auf einem anderen Artikel. Dort ist scheinbar auch der File Chooser abgebildet. Weiß aber nicht ob das Aktuell ist:
http://derstandard.at/1311802917508/Linux-Zukunft-Gerade-erst-GTK3---schon-auf-dem-Weg-zu-GTK4
>> Das Widget GtkFontSelection hingegen wurde durch eine ganze Familie von GtkFontChooser-Widgets ersetzt.
GtkFontSelection war doch schon in den späten 2.x als veraltet markiert, hat es den Sprung in 3.0 doch noch geschafft?
... mit grafischen GUI - Builder mit denen man GTK Programme entwickeln kann? Ähnlich Qt-Creator/Netbeans etc.
Anjuta hat sowas.
Glade ist ein standalone GUI-Builder, damit kannst Du für jedes GTK-Binding das GUI designen, allerdings musst Du das GUI dann "händisch" anbinden. Hat halt andere Vorteile.
Für gtk-sharp gibt es Monodevlop.
gazpacho für python, habe ich aber noch nie benutzt.
Glade gibt es bereits seit gut 10 Jahren
In Anjuta ist Glade direkt integriert.
Je öfter ich darüber nachdenke, ein GUI Toolkit für eine proprietäre kommerzielle Anwendung zu verwenden, desto besser erscheint mir die Nutzung eines GUI Toolkits, daß unter der BSD Lizenz steht.
Denn auch wenn man das dynamische Linken, welches die LGPL gewährt, weitgehend versucht zu verwenden, kann immer mal der Punkt kommen, wo eine statische Lösung besser wäre.
Und wenn man den Code erweitern muß, dann ist ein GUI Toolkit mit BSD Lizenz auch langfristig sicherer, weil die Erlaubnis zum statischen Einbinden es erlaubt, das Notwendige für die Anwendung zu nutzen, ohne später einen eigenen Fork einer ganzen Bibliothek pflegen zu müssen.
Der Aufwand der Codepflege ist also geringer, wenn man zusätzliche Funktionen in die Lib einbringen muß und nicht erwarten kann, daß diese Funktionen in die Original-Lib aufgenommen werden, so daß es zwangsläufig zu einem Fork führt.
Auch droht der Fork, wenn auf eine Majorversion gewechselt wird, und ein Wechsel zur neuen Majorversion zu aufwendig ist. Dann ist es kostengünstiger die alte Lib Version zu nutzen, aber deren Support läuft aus und ob man den Support selbst aufrechterhalten kann, hängt davon ab, ob man die alte Version offiziell weitersupporten darf.
Denn es könnte ja sein, daß das Offizielle GTK Projekt keine Patches für die alte Version mehr annimmt.
Spätestens dann ist man zu einem Fork gezwungen.
PS:
Natürlich gilt all diese Betrachtung nur unter der Prämise, wenn man vor dem Problem steht, eine proprietäre Anwendung zu entwickeln.
Aus reiner Open Source Sicht, kann die LGPL die bessere Wahl sein, allerdings erhält man dann auch weniger Unterstützung von Firmen, die vielleicht beim GUI Toolkit mitmachen würde, wenn es unter einer für sie freieren Lizenz stehen würde.
Und es ist ja nun jetzt nicht so, daß man vom schlimmsten ausgehen müßte, und die propritären SW Hersteller immer nur den BSD Lizenz Code klauen und unter einer propritären SW stellen wollten.
"Und es ist ja nun jetzt nicht so, daß man vom schlimmsten ausgehen müßte, und die propritären SW Hersteller immer nur den BSD Lizenz Code klauen und unter einer propritären SW stellen wollten."
Das passiert aber und wenn es dann passiert, dann ist mitunter der Ärger groß, vor allem dann, wenn es anders lautende Absprachen gab.
Wine ist hierfür wohl das berühmteste Beispiel. Das Wine-Team war von seinem diesbezüglichen "Erlebnis" so betroffen, dass sie deshalb vom BSD/MIT- ins (L)GPL-Lizenzlager gewechselt sind.
Und hat es Nachteile gebracht?
Nein, das hat es nicht. Mit Crossover gibt es mittlerweile einen hervorragenden kommerziell agierenden (L)GPL-Wine-Partner, der seinen Code natürlich ins Wine-Projekt zurückfließen lässt. Letzteres schadet auch Crossover nicht im Geringsten, eben, weil ihre Wine-Softwareversion herausragend ist.
Wine ist ein schlechtes Beispiel, da es sich nicht wirklich um ein Toolkit für SW Entwickler handelt
Bei Toolkits kann so etwas durchaus Nachteile bringen, da Firmen fehlen die Code beisteuern.und im Fall von Cedega (oder wie hieß das doch gleich) die eigentliche Arbeit ja Wine selbst darstellte,
während bei Anwendungen, die nur ein GUI Toolkit zur Darstellung der Buttons & Fenster verwenden, die eigentliche Arbeit immer noch von der SW Entwicklungsfirma selbst getragen werden muß und im Anwendungscode steckt.
Und man sieht das auch an der Dokumentation von GTK+ oder dem technischen Status von gtkmm.
Bessere Beispiele sind daher die zlib Library (steht unter zlib Lizenz, aber vom Handling her ähnlich wie die BSD L.) oder die SDL 2.x die extra deswegen von der LGPL auf eine freiere Lizenz (AFAIK zlib) umsteigt.
Die SDL 1.x hat als LGPL Lib nämlich keine Verbreitung bei kommerziellen propritären Spielen erhalten.
Die paar Linux Ports die die SDL nutzen, sind stark in der Minderheit und nicht der Rede wert.
Die SDL wird gemieden, daher hat man für die Vers. 2.x die Lizenz geändert.
Der Originalcode ist weiterhin frei verfügbar und gerade bei Anwendungen die nur eine Basisbibliothek nutzen ist der Verlust minimal, weil es 100 andere Firmen geben kann, die weiterhin auf die Original Basisbibliothek setzen und diese weitersupported.Es kommt also immer darauf an, was für eine Art von Library man mit der LGPL schützen will.
Bei Wine, daß mehr schon eine Anwendung selbst darstellt, als eine Lib, war die LGPL vielleicht sinnvoll,
aber bei generischen Basisbibliotheken wie eben ein GUI Toolkit kann das nunmal deutlich anders aussehen.
Da stört das eine schwarze Schaf dann nicht und geht auch in der Bedeutung unter, da dessen Software eh wieder eine ganz bestimmte Anwendung darstellt.
Bei einem GUI Toolkit würde es nur dann ein Problem geben, wenn jemand hergehen würde, das Teil closen würde und dann das eigentliche GUI Toolkit anstatt eine Anwendung selbst vermarkten würde.
Aber die Wahrscheinlichkeit daß so etwas passiert ist eher gering und Dritte, die ne Bibliothek für ihre Anwendung nutzen wollen, wären dann ja doof, wenn sie eine Lizenz von dieser Firma kaufen würden, während sie selbst mit der freien Open Source Lizenz Bibliothek viel mehr Möglichkeiten hätte und sich nicht in eine Abhängigkeit von nur einer Firma begeben würden.
Und Crossover gab Code an Wine zurück. Auch damals schon!
Du zählst hier ein paar wenige Fälle auf und unterschlägst die Fälle, in denen BSD Lizenzprojekte gewinnen.
Das ist albern.
Es geht um Transgaming/Cedega.
Ich wüsste nicht, was an diesem damaligen Vorkommnis albern sein soll.
Von daher ist Dein Einwand gegenstandslos.
Nein, um dir die positiven Aspekte der Coderückgabe aufzuzeigen ging es hier diesmal um Crossover und nicht um Cedega.
Crossover != Cedega/Transgaming
Ist doch gut, wenn proprietäre Entwickler Nachteile haben, finde ich.
Inwiefern soll das gut sein?
Die Lib wird dadurch nicht besser, sondern eher schlechter, da zusätzliche Entwickler (die der Firmen) fehlen und das Potential, was möglich wäre (also eine noch bessere Lib), nicht ausgeschöpft werden kann.
Meiner Meinung nach ist es kleingeistig. Gerade bei so Basis/Grundsachen wie GUI Toolkit Bibliotheken.
Proprietäre Entwickler gehen mir sowas am Hintern vorbei. Die schau ich nichtmal mit dem Hintern an. Deren Probleme interessieren mich einen feuchten Kehricht.
Die Open Source Lib ist dir also auch egal. Das geht aus deinem Kommentar nämlich hervor.
Oder warum überliest du, daß Proprietäre Entwickler auch die Open Source Lib verbessern können?
Und die Nutzer sind dir ebenso egal.
Manche wären froh, wenn sie Anwendung XY, z.B. Elster unter Linux hätten.
Crossplattform Toolkit können das ermöglichen, aber dann muß auch die Lizenz stimmen, wenn man proprietäre Entwickler anlocken will, diese zu nutzen.
Ich habe Prinzipien. Ich würde mir als Greis auch nicht von einem Mörder über die Straße helfen lassen wollen, selbst wenn er mir damit im Kleinen was Gutes tun würde.
Du redest Käse.
Die LGPL ist genau dann ein Problem, wenn man Zukunftssicherheit braucht und aus welchen Gründen auch immer (Juristen können da viel drehen und dir das Genick brechen!) während der Projektentwicklung statisches Linken plötzlich eine Notwendigkeit wird.
Und bis dahin, kann IMMER Code zum Open Source Projekt beigesteuert werden, die freie Lizenz ist also die Rettungsschnur wenn alles schief läuft.
Denn ein gewachsenens Projekt, daß vielleicht 5 Jahre schon immer von Majorversion zu Majorversion weiterentwickelt wird, kann man nicht mal auf die schnelle auf andere Libs umstellen.
Man braucht also Zukunftssicherheit auf mind. > 20 Jahre und die erhält man durch eine möglichst freie Lizenz, bei der einem kein Jurist nen Strick drehen kann.
Was meinst denn du, warum in der Praxis kaum ein proprietäres Projekt auf LGPL Bibliotheken aufsetzt?
Zlib, libPNG, OpenAL werden alle gerne genommen, weil deren Lizenzen statisches Linken für den Fall der Fälle zulassen.
Die LGPL wird aber, obwohl sie den Anschein zeigt, für propritäere Projekte geeignet zu sein, wie das Teufel das Weihwasser gemieden.
Deswegen sollte man als Lib Entwickler die LGPL eher vermeiden.
Und fast alle diese proprietären Projekte werden vornehmlich auch unter Windows oder andere Unixe entwickelt, wo es andere libc Bibliotheken gibt, weswegen die Zukunftsichheit in keinster Weise gefährdet ist.
Das ist sie auch nichtmal bei der glibc, denn dazu ist diese Lib zu wichtig. Als C lib um mehrere Größenordnungen wichtiger als eine GUI Lib, wie GTK+.
Das die glibc also trotz LGPL verwendet wird, hat andere Gründe.
Ich könnte dir 500 kommerzielle proprietäre AAA Computerspiele nennen, die die zlib Lizenz verwenden.
Nenne du mir 500 kommerzielle proprietäre AAA Computerspiele die die SDL 1.x (LGPL) verwenden.
Die Ausnahme ist natürlich, wenn man ein Problem damit hat, die Änderungen unter eine freie Lizenz zu stellen. In diesem Fall hat der Upstream-Entwickler aber ohnehin keinen Vorteil davon, dass man die Bibliothek verwendet, dann kann es ihm also egal sein.Der Vergleich ist absurd, schließlich werden Computerspiele in der Regel für Windows und DirectX entwickelt, wobei letzteres eine mit SDL vergleichbare Funktionalität bereitstellt. Der Grund, warum man SDL nicht so oft verwendet, dürfte einfach sein, dass man diese Bibliothek unter Windows nicht braucht. Besteht dagegen ein Bedarf für derartige Funktionalität (wie unter Linux), so wird SDL durchaus genutzt.
http://en.wikipedia.org/wiki/List_of_games_using_SDL
Und selbst wenn das nicht so wäre, müsstest Du immer noch nachweisen, dass die Entscheidung der Spieleentwickler, nicht SDL zu verwenden, auf der Lizenz basiert und nicht einfach z. B. auf technischen Gründen. Ansonsten stellst Du hier nur haltlose Behauptungen auf.
Dann stelle dir die Frage, warum die SDL Macher jetzt bei der Version 2.0 auf die zlib Lizenz umsteigen.
Woher soll ich das wissen?! Das musst Du die SDL-Entwickler fragen.
Dann sag ich es dir eben.
Die restriktive LGPL Lizenz war dem Projekt nicht zweckdienlich, die SDL wurde zu selten benutzt, die Crossplattformprodukte, die man sich auch als Konsument erhoffte blieben aus und auf Konsolen und geschlossenen Plattformen wurde die SDL erst gar nicht benutzt, eben auch wieder aufgrund der Lizenz.
Die LGPL erwies der SDL also einen Bärendienst.
Deswegen ändert man das nun mit SDL 2.x
Ach ja, etwas anderes ist übrigens ein Fakt und keine wohlfeile Behauptung, nämlich dass Firmen wie Epic, Bioware und Raven Software SDL erfolgreich genutzt haben, um ihre Software auf Linux zu porten. In der echten Welt stellt die LGPL also kein Problem dar.
Aber wie dem auch sei, wir werden sehen wie sich die Lizenzänderung bei der SDL Ver. 2.x auf die kommerziellen Spiele auswirken wird.
Und das war alles unsupported, damit man im Notfall den Stecker rausziehen kann.
Zählt also nicht.
Wie soll dieser "Notfall" denn aussehen? Du hast noch kein realistisches Szenario genannt, wo die LGPL tatsächlich ein Problem darstellt. Dieser Beitrag wurde 1 mal editiert. Zuletzt am 28. Sep 2011 um 00:27.
Ich weiß schon was ich sage, SDL, OpenGL, OpenAL und natürlich gehe ich jetzt nicht von einer bestehenden Game Engine aus, die für DirectX geschrieben wurde.
Ich bin kein Jurist.Die Version der Lizenz könnte sich ändern und die Änderungen könnten Restriktiver sein.
Das ist nicht Zukunftssicher.
Zukunftssicherheit bedeutet nicht, daß du bei alten Lib Versionen stehen bleibst.
Richtig, aber bei denen kann man wenigstens dann den ganzen Code der letzten Version ohne nennenswerte Einschränkungen nutzen.Doch, weil du nun die alte Version selbst weiterpflegen müßtest.
Bei BSD nimmst du den Code und kannst damit machen was du willst. Also 80 % wegschmeisen und 20 % in den eigenen Code aufnehmen.
Damit sind die weiteren Wartungskosten minimiert.
Das hatten wir doch schon geklärt, daß du den LGPL Code nicht in deinen propritären Code reinkopieren kannst.
Wenn der Code Modular aufgebaut ist, dann kann man den unnötigen Rest gut rausschmeißen.Und noch etwas:
Die proprietären Entwickler nehmen in solchen Fällen einfach andere Bibliotheken.
Und im Fall von GUI Toolkits ist das dann Qt oder eben MFC & Co.
Und die MFC läuft nicht unter Linux -> Nachteil für die Linux Anwender.
Sprich, die Linux und FreeBSD Nutzer verlieren durch solche Engstirnigkeitspolitik.
Die Firmen verwenden einfach andere GUI Toolkits die es nur unter Windows gibt und der Support von Microsoft ist bei deren Libs ja nicht schlecht.
Ist doch super, wenn die Pest zur Cholera zieht. Soll man den proprietären Entwicklern nachtrauern?
Wieso Nachteil? Wenn die Software eh proprietär ist, würde ich sie auch nicht unter Linux benutzen wollen.
Mir geht es nicht darum, irgendwas zu gewinnen, sondern darum, dass ich freie Software benutze und auf meiner Plattform von proprietärer Software unbehelligt bleibe.
Du denkst nur an dich und nicht an die anderen Anwender. Du bist also ein Egoist.
Viele hätten gerne MS Office oder Photoshop unter Linux
und der Staat (für den du Steuern zahlst) hätte es dann ebenfalls viel einfacher bei der Linux Migration.
Außerdem, ich weiß nicht wo und ob du arbeitest, aber die Chancen sind groß, daß man als Arbeitnehmer wegen solchen Sachen dazu gezwungen ist, unter Windows zu arbeiten, weil Anwendung XY eben nur unter Windows läuft, weil damals das entsprechende crossplattform GUI Toolkit mit der richtigen Lizenz gefehlt hat, als es vom beauftragen Entwickler der Firma entwickelt wurde.
Und vielleicht müssen sich deswegen auch manche Arbeitnehmer mit langsamen JAVA Anwendungen zufrieden geben, weil die Firma Plattformunabhängigkeit als Sicherheit wollte, anstatt 3 native Binarys für die drei großen Desktopsysteme.
Ja, du bist Egoist, das haben wir jetzt schon erkannt. Du denkst nur an dich.Und was bitteschön ist für dich das Problem, die proprietäre Software einfach nicht auf deinem Rechner zu installieren? Du bist dazu doch nicht gezwungen.
(ist auf deinem Rechner übrigens Google Earth, die CS NVidia Treiber und das Adobe Flash Plugin installiert, würde mich mal interessieren)
Und wer weiß, vielleicht wirst du, wenn du mal den Job wechselst oder mit arbeiten anfängst, mit einem schönen proprietären Windows Desktop behelligt, weil du heute so engstirnig warst.
Ich würde das gut finden.
Du kannst auch eine LGPL Bibliothek statisch linken.
Ist für den Empfänger komplizierter den LGPL Teil der Anwendung auszutauschen, d.h. man muss neu Linken und kann nicht einfach eine Datei austauschen oder einen Symlink umbiegen, aber nicht desto trotz machbar.
Das versteh ich nicht ganz. Wenn du Änderungen am Code der Bibliothek vornimmst und nicht an den Ursprung weitergibts, hast du immer einen Fork, unabhängig von der Lizenz der Bibliothek.
Und die resultierende proprietäre closed source Anwendung verkaufen? Ja klar!
Beim statischen Linken wird nur das verwendet, was man tatsächlich nutzt.
Das erleichtert die Codepflege, da man die unbenutzen Sachen ignorieren oder wegrationalisieren kann.
Natürlich, warum sollte das nicht gehen?
Sollte man Änderungen am Code der Biblothek gemacht haben, muss man diese Änderungen unter LGPL kompatiblen Lizenzbegingungen zugänglich machen und der Empfänger der Anwendung muss in der Lage sein, die LGPL lizenzierten Teile zu verändern und auszutauschen.
Wie schon vorhin geschrieben ist das bei einem statisch gelinkten Programm schwieriger, weil man neu linken muss, aber nicht unmöglich.
Wenn man nur gegen bestimmte Teile linken möchte macht es doch keinen Unterschied, ob man gegen eine zurecht gestutzte statische oder dynamische Bibliothek linkt, in beiden Fällen benutzt man nicht mehr die originale Fassung. Man hat also schon dann einen Fork, ob dann noch Änderungen an den Dateien der Bibliothek hinzukommen ist dann schon egal (macht den Fork natürlich noch unterschiedlicher, klar)
Kann man nicht, dazu Bedarf es nämlich immer der "with static Linking exception".
Die GKT+ hat diese aber nicht.
Das FLTK hat sie aber z.Beispiel.
OK, das scheint tatsächlich so zu sein. Da es aber für statisches Linken ohnehin keine sinnvollen Gründe gibt, spielt das keine Rolle.
Danke, also kennen weder du noch Krake die LGPL aus dem juristischen Standpunkt so gut wie ich.
Aber Hauptsache mir vorwerfen, dass ich die Lizenz lesen soll, bevor ich sie kritisiere.
Vielleicht solltet ihr beide die Lizenz mal lesen.
Die Datenmenge wird kleiner, man muß nicht noch eine gesamte Lib in Form einer DLL & Co mitliefern.
Bei Embedded Anwendungen kann das ebenfalls sehr nützlich sein.
Bei einer in Quellen vorliegenden Bibliothek ist man nicht gezwungen die Bibliothek in ihrem maximalen Umfang zu verwenden. Unabhängig davon ob die Quellen dabei LGPL, BSD, MIT, Public Domain, etc. lizenziert sind.
Diese Anpassbarkeit ist schließlich einer der Vorteile von in Quellen vorliegender Software.
Nein, auch ohne solche Ausnahme ist statisches Linken erlaubt.
Wie andere reziproke Lizenzen geht es bei der LGPL erst mal um den Code der Bibliothek. Dieser muss über einen von mehreren Wegen für den Empfänger der Software verfügbar sein.
Nach Erhalt der Quellen muss dem es dem Empfänger möglich sein, diese zu ändern und wieder zu Objektcode umzuwandeln (zu bauen) und die Software dann mit dieser Abhängigkeit zu betreiben.
Bei dynamisch gelinkten Bibliotheken ist das einfach, der Empfänger ersetzt einfach die ausgelieferte Bibliotheksdatei mit der selbst erstellten, oder erreicht das Äquivalent mit Symlinks oder Preload Tricks.
Bei statisch gelinkten Bibliotheken ist das schwieriger, weil das Linken eben nicht erst zur Laufzeit erfolgt, sondern Teil des Bauens ist.
Das wird oftmals als Notwendigkeit missinterpretiert, dass dafür dem Empfänger die Quelle der Software selbst zur Verfügung stehen müssten.
Das Übersetzen (Compilieren) der Software und das Linken sind aber zwei getrennte Schritte, die unabhängig von irgendwelchen Lizenzen immer nacheinander ausgeführt werden.
Beim Linken ist es irrelevant ob man viele kleine Objektdateien oder wenige große verbindet, d.h. die übersetzte Software kann in eine Datei kombiniert werden, praktisch so wie wenn sie dynamische Bibliotheken verwenden würde.
Der Empfänger muss dann eben noch den geänderten Teil mit diesem Hauptteil zusammenführen, was bei den meisten Compilern ein trivialer Aufruf ist.
Meistens kommt ein Hersteller den Lizenzbedingungen der LGPL derart nach, in dem der Bibliotheksteil dynamisch gelinkt verwendet wird. Es wird daher oft fälschlicherweise davon ausgegangen, dass diese Vorgehensweise die einzig mögliche ist.
Da das ohnehin für den Empfänger die bevorzugte Lösung ist, wird dem auch selten widersprochen, aber es schadet nicht, hin und wieder klar zu stellen, dass die Lizenz keine technische Einschränkung wie die Art des Linkens festlegt.
So lange dem Empfänger die geschützten Möglichkeiten offen bleiben, ist der Lizenz genüge getan. Und das kann man eben auch, wenn auch ein bischen komplizierter, bei statisch gelinkten Bibliotheken erfüllen.
Du hast natürlich Recht, statisches Linken ist erlaubt. Ich hatte nach seiner Behauptung, dass die LGPL dynamisches Linken fordere, noch einmal in der LGPL nachgelesen, um sicher zu gehen, dass ich mich nicht getäuscht hatte. Dann bin ich auf §6 Absatz b gestoßen, und da ist eindeutig von dynamlischem Linken die Rede, daher habe ich ihm dann vorschnell zugestimmt. Ich hatte aber übersehen, dass lediglich die Umsetzung _eines_ der Absätze a-e gefordert ist.
ELF und rpath gibt es nicht unter Windows.
Denk an Crossplatform Anwendungen.
Für Linux alleine entwickelt niemand, dann schon eher nur für Windows, aber dann kann man gleich die MFC verwenden, wenn's nur Windows sein soll.
Und wenn du so weit bist, dann kannst du auch gleich die Codeteile aus der Lib nehmen und in deinen Code einbauen.
Das spart die Pflege und erhöht die Zukunftsicherheit.
Aber dazu braucht man halt eine Lizenz, die so etwas erlaubt.
Mit BSD-Lizenz setzt man den notwendigen Code einfach in das Projekt und hat weiterhin nur einen Code zu pflegen.Die BSD Lizenz erlaubt das.
Der zu wartende Code wird kleiner.
Behälst du das ganze als dynamisch Lib bei, dann mußt du die gesamte Lib warten, wenn sich sonst niemand dafür findet. Bei einem Fork dürfte das der Fall sein.
Schaut euch mal die Broadway Demo an! Da kann das von Nokia zu tote gebastelte Qt-Gefrickel entgültig einpacken! Jawohl!!!
Sinnvoll ist so etwas doch bestenfalls für Anwendungen, die sowieso im Browser laufen sollen.
Also die ganze Intranet Firmensoftware, die irgendwelche Sachen mit dem Browser zugänglich machen sollen und die Software mit nur einer Lizenz auf dem Server läuft.
Aber wozu soll das für klassische Desktopanwendungen gut sein?
Das Zeugs wird übers Netzwerk verschickt und ist im Vergleich zur direkten Lösung unter X entsprechend lahm, wenn da viele Daten oder Animationen drinstecken.
Der Browser erhöht den Overhead ebenfalls noch.
Bevor ich aber eine GTK Anwendung im Browser nutze, mache ich das lieber über X.
... was eine lokale Installation von X voraussetzt.
Dafür gibts keinen Fisch!!!111elf
Was für Anwendungsgebiete sollte broadway haben? Ja schaut nett aus ist supercool, aber den Entwicklungsaufwand nicht wert.
Ich nehme nicht an das du schon mal was mit einem der beiden Toolkits programmiert hast, sonst würdest du nicht solchen Schwachsinn posten.
> Was für Anwendungsgebiete sollte broadway haben?
In etwa die, die durch die Netzwerktransparenz von X abgedeckt werden. Nur eben auf Toolkit-Ebene und damit wirklich Cross-Plattform. Es wird kein X-Server auf Windows, MacOS oder irgendein Tablet/SmartphoneOS benötigt. Wer einen Browser hat kann die Anwendung remote nutzen. Der dürfte inzwischen verbreiteter sein als das X-Protokoll.
Mit X und seinen Unterstützungslibrarys (insbesondere hier Xdnd) ist aber mehr möglich,
Z.B. Drag & Drop von Dateien von der einen X Anwendung in die nächste.
Mach das mal im Browser.
Mag ja sein das es hier und dort klein Einschränkungen gibt, aber ist das jetzt wirklich so relevant? Es hat nun mal unbestritten seinen Vorteil, wenn man auf Client-Seite nix weiter als einen Browser braucht um eine Anwendung zu nutzen. Kein X-Stack ist notwendig und das ganze läuft sofort auf X-Plattformen bis zum Tablet.