# LGPL-Lizenz und Entwicklung kommerzieller Software



## dflasjjs (29. Mrz 2010)

Hi,

1) mal angenommen bei baut sich eine Anwendung die später kommerziell vertrieben werden soll.
Dazu nutzt man externe Bibliotheken die unter LGPL stehen, dann ist das doch alles legal, solange ich 
in der Doku darauf hinweise, oder? 

2) Wenn eine Software, unter zwei Lizenzen steht MPL/LGPL, kann man sich dann aussuchen welche man nimmt oder wie ist das gedacht? Konkret geht es um iText in der Version 2.1.7.

3) iText 2.1.7. ist unter MPL/LGPL, die neue Version (5.0.0), ist unter AGPL veröffentlicht. Wenn man nun die 2.1.7er nutzt, dann gilt doch weiterhin die MPL/LGPL, oder? 

Hintergrund ist eben, dass eine kommerzielle Anwendung einen PDF-Export haben soll, der aber nicht Hauptbestandteil ist, sondern nur "nice-to-have", dementsprechend sollen dafür nicht Unsummen investiert werden. Die 5er-Version von iText kostet aber 4-stellige Beträge im Jahr. Wenn man nun die 2.1.7er-Version nutzt, dann müsste das ganze doch "kostenlos" sein, oder?


----------



## Guybrush Threepwood (29. Mrz 2010)

dflasjjs hat gesagt.:


> 1) mal angenommen bei baut sich eine Anwendung die später kommerziell vertrieben werden soll.
> Dazu nutzt man externe Bibliotheken die unter LGPL stehen, dann ist das doch alles legal, solange ich
> in der Doku darauf hinweise, oder?


Ja. Weiterhin musst Du eine Kopie der LGPL und den Source Code der verwendeten Bibliothek mitliefern. Alternativ kannst Du anbieten, dass Du den Source-Code auf Anfrage per E-Mail rausrückst, oder sonstwie verfügbar machst.



dflasjjs hat gesagt.:


> 2) Wenn eine Software, unter zwei Lizenzen steht MPL/LGPL, kann man sich dann aussuchen welche man nimmt oder wie ist das gedacht? Konkret geht es um iText in der Version 2.1.7.


Ja.



dflasjjs hat gesagt.:


> 3) iText 2.1.7. ist unter MPL/LGPL, die neue Version (5.0.0), ist unter AGPL veröffentlicht. Wenn man nun die 2.1.7er nutzt, dann gilt doch weiterhin die MPL/LGPL, oder?


Auch die AGPL ist kein Problem. In den erstellten PDFs steht dann lediglich im Kommentar, dass das PDF mit iText erstellt wurde.



dflasjjs hat gesagt.:


> Hintergrund ist eben, dass eine kommerzielle Anwendung einen PDF-Export haben soll, der aber nicht Hauptbestandteil ist, sondern nur "nice-to-have", dementsprechend sollen dafür nicht Unsummen investiert werden. Die 5er-Version von iText kostet aber 4-stellige Beträge im Jahr. Wenn man nun die 2.1.7er-Version nutzt, dann müsste das ganze doch "kostenlos" sein, oder?


Nein, die 5er Version von iText kostet nur, wenn der Hinweis in den Eigenschaften des PDFs wegfallen soll.


----------



## dflasjjs (29. Mrz 2010)

Super, das hört sich spitze an. Vielen Dank


----------



## Gast2 (30. Mrz 2010)

blödsinn gelöscht


----------



## Guybrush Threepwood (30. Mrz 2010)

Ups! Ich muss mich in Bezug auf iText korrigieren: AGPL ist nicht geeignet, um kommerzielle Software (Closed Source) zu entwickeln. Die letzte Version unter LGPL ist 4.2 (SourceForge.net Repository - [itext] Index of /tags/iText_4_2_0).


----------



## MarderFahrer (14. Apr 2010)

Sorry wenn ich dieses Thema noch mal nach vorne bringe. Aber da sind immer noch ein paar Fragen bei mir aufgekommen.

Im Bezug auf die LGPL in Verbindung mit Java gab es schon Unmengen an Forum Posts, weil der Text der LGPL sich auf "dynamisches und statisches Linken von Libraries" bezieht was viele Leute in Bezug auf Java verwirrt. 
Dann gab es eine Stellungnahme direkt auf gnu.org. The LGPL and Java

Darin enthalten dieser Auszug:


> "If you distribute a Java application that imports LGPL libraries, it's easy to comply with the LGPL. Your application's license needs to allow users to modify the library, and reverse engineer *your* code to debug these modifications.



Darin liegt doch eigentlich das Problem schlechthin, oder? Welche Firma, die kommerziell eine SW vertreibt erlaubt in ihrer Lizenz ein "reverse engineering" ihres Produktes? Vor allem nur zu dem Zweck eine von ihnen verwendete LGPL Library gegen eine neuere Version auszutauschen?
Wobei ich sowieso nicht verstehe, warum der Autor des oben verlinkten Dokumentes meint man müsse "reverse engineering" betreiben um in einem Java Programm eine Library austauschen zu können. Er beschreibt ja selber den Vorgang, wie man Libraries in Java benutzt.


> The typical arrangement for Java is that each library an application uses is distributed as a separate JAR (Java Archive) file. Applications use Java's “import” functionality to access classes from these libraries.


Gehe ich nicht Recht in der Annahme, dass man eine solche Library nicht einfach austauschen kann, in dem man das entsprechende .jar File löscht und an dessen Stelle die neue Version des .jar Files kopiert? Natürlich muss Sie den gleichen Namen besitzen. Aber das kann man im Code ja entsprechend einbauen. Wenn ich z.b libXY(LGPL) benutze muss ich ja nicht unbedingt das .jar File libXY-1.2.4.jar nennen, welches ich importiere. Ich kann es doch einfach libXY.jar nennen. Oder etwa nicht? Natürlich muss ich einen Lizenz Ordner in meinem Programm haben, in der die LGPL Lizenz liegt. Dazu noch eine Übersicht, welche Open Source Komponenten ich benutze und in welcher Version usw. 

Es geht also keine Information verloren. Warum also dieses Hickhack mit "reverse engineering" in einem Dokument, welches sich NUR auf den Java Aspekt und LGPL bezieht? Ich hatte mich schon gefreut endlich ein Dokument gefunden zu haben, welches auf allzu vage Beschreibungen verzichtet, die eh nur für andere Programmiersprachen gedacht sind. Und dann sowas...


----------



## Noctarius (14. Apr 2010)

Also bei reinem Java kannst du nicht nur das JAR umbenennen (solange weiterhin der Classpath stimmt) sondern sogar die Version austauschen, immer unter der Prämisse, dass die neue / alte Version kompatibel zueinander sind.

Java wird beim Laden der Class dynamisch "gelinkt" und das auf Basis des Canonical Path der Class welche benutzt werden soll. Im Prinzip hat Java selber keinen echten Import-Mechanismus, da im Bytecode keine Imports mehr existieren, sondern immer der volle eindeutige Name der Klasse zur Adressierung genutzt wird. Daher steht das Import im Zitat auch in Anführungsstrichen.

Warum man zum Debuggen aber Reverse Engineering brauchen sollte ist mir auch schleierhaft. Zumal dies die Richtung des Austausches umdreht. Abgesehen davon entsteht dir als Firma aber kein Verlust, da viele Länder eine spezielle Regelung für Reverse Engineering besitzen, welches dieses zum Zwecke von Lernens eh legitimiert. Zusätzlich ist Obfuscation eigentlich keine Verhinderung von Reverse Engineering und dürfte (meiner Meinung nach) nicht gegen die LGPL verstoßen. Ich verhindere ja nichts durch Verschlüsselung, sondern ich mache es nur schwieriger durch unschöne Bezeichner. Hardcore-Programmierer könnten sowas auch von Hand, trotzdem wäre es dann kein LGPL Verstoß


----------



## Guybrush Threepwood (14. Apr 2010)

Dem Dokument entsprechend wäre es dann ja eigentlich verboten, ein Jar in einen exe-Wrapper zu packen, da man dann nicht mehr ohne weiteres Reverse Engineering betreiben kann, und zwar selbst dann, wenn die LGPL-lizensierte Lib offen beiligt und nicht in die eigene Jar gepackt wurde.

Mal rein praktisch: Gab es da überhaupt schon irgendwann einmal eine juristische Auseinandersetzung zu LGPL in kommerzieller Software in Deutschland? Ich gehe davon aus, dass man lediglich den Source-Code der verwendeten Lib und den Lizenztext beilegen muss, sowie an prominenter Stelle im Programm darauf hinweisen muss. Gab es eigentlich in der BRD schon einmal eine Verurteilung aufgrund der Verwendung von GPL-lizensierter Software in Closed-Source-Produkten?


----------



## MarderFahrer (14. Apr 2010)

Guybrush Threepwood hat gesagt.:


> Mal rein praktisch: Gab es da überhaupt schon irgendwann einmal eine juristische Auseinandersetzung zu LGPL in kommerzieller Software in Deutschland? Ich gehe davon aus, dass man lediglich den Source-Code der verwendeten Lib und den Lizenztext beilegen muss, sowie an prominenter Stelle im Programm darauf hinweisen muss. Gab es eigentlich in der BRD schon einmal eine Verurteilung aufgrund der Verwendung von GPL-lizensierter Software in Closed-Source-Produkten?



Ich denke nicht. Dann hätte man ja mal eine einigermaßen verlässliche Aussage was legal ist und was nicht. Vllt. machen sich Firmen auf Grund dessen keinen allzu großen Kopf ob es nun legal ist LGPL Libraries zu nutzen in ihrer kommerziellen Software. 
Das Mindset schein zu sein:

Wir verändern die lib nicht - check
Wir legen den Lizenztext der lib bei - check
Wir weisen darauf hin, dass die lib 3rd Party ist und wo sie her kommt - check
Wir machen das Angebot auf Wunsch den Quelltext der lib zuzuschicken - check
Das sollte ja reichen. Bisher wurde noch niemand deswegen verklagt. Und falls doch haben wir ja diese Maßnahmen nach bestem Wissen und Gewissen getroffen.

Nur das Problem ist doch "Unwissenheit schütz vor Strafe nicht". Also meine Firma hat die Richtlinie "Kein LGPL Code benutzen, falls er in das Shipment mit reinkommen müsste". Heißt, Test Tools u.Ä ist erlaubt. Alles das nur um Sicher zu gehen, dass man nicht vor den Kadi gezerrt wird. Denn auch wenn das Risiko gering ist, wenn's passiert wird's teuer!

Aber von meiner Firma mal abgesehen. Mir gings auch eigentlich darum wenn ich als einzel Person mal auf die Idee kommen würde eine Software in Java zu schreiben. Sie sollte closed source sein und konstenpflichtig vertrieben werden. Um die Entwicklungskosten klein zu halten wollte man auf Open Source Komponenten zurückgreifen. Was macht man dann?

Ich denke, dass ist das Szenario, was die meisten Leute haben wenn es um Open Source Lizenz in Verbindung mit Closed Source Lizenz Problematik geht. 
So wie ich das sehe meiden viele Java Entwickler lieber die LGPL Lizensierten Projekte und suchen nach "permissive licenses" wie BSD oder Apache. Nur um nicht Gefahr zu laufen da irgendwelche Sachen zu machen, die später zu Problemen führen könnten.

Nur, das müsste doch nicht sein. Die LGPL müsste sich nur deutlicher ausdrücken und gerade in Bezug auf Java klarer werden. Wenn sie im Text von "Linking" und "Imports" sprechen ist man versucht das direkt auf Java umzulegen. Was ja offensichtlich falsch wäre denn sogesehen gibt es in Java keine Imports.

Liest man den Abschnitt 5 der LGPL steht dort folgendes:


> 5. A program that contains no derivative of any portion of the Library, but is designed to work with the Library by being compiled or linked with it, is called a "work that uses the Library". Such a work, in isolation, is not a derivative work of the Library, and therefore falls outside the scope of this License.


Alles klar, Meine Java Klasse importiert eine Klasse einer LGPL Library ala "import org.lgpl.lib.class". Meine Klasse muss zusammen mit der Library kompiliert werden damit der Compiler keine Fehler wirft. Sollte also eigentlich passen oder? Meine Software ist also "work that uses the Library"



> However, linking a "work that uses the Library" with the Library creates an executable that is a derivative of the Library (because it contains portions of the Library), rather than a "work that uses the library". The executable is therefore covered by this License. Section 6 states terms for distribution of such executables.


???
Diesen Abschnitt verstehe ich beim besten Willen nicht. Eben noch wurde definiert, dass "work that uses the Library" eine Software ist, die Klassen/Methoden der Library nutzt und zusammen mit ihr kompiliert wird. Warum sollte so etwas dann noch mal mit der Library verlinkt werden? Und dann ist meine Klasse auf einmal eine Abgeleitet Form der Library anstelle "Einer Arbeit die die Lib benutzt"? Und warum ist dass ganze dann plötzlich eine executable?

Ich finde das ganze ist wirklich schlimm geschrieben. Ob ein Anwalt da wohl durchsteigen würde? Eigentlich ist dieser Text ja mehr technisch gehalten als juristisch. Ich finde nur, dass das mit meinem Java Wissen über Nutzung und Funktion von external Jars nicht zu vereinbaren ist. Evtl. fehlt mir da auch noch einiges. Aber bisher bin ich eigentlich recht gut gefahren was das einbinden von Jars angeht.


----------



## Guybrush Threepwood (14. Apr 2010)

MarderFahrer hat gesagt.:


> ???
> Diesen Abschnitt verstehe ich beim besten Willen nicht. Eben noch wurde definiert, dass "work that uses the Library" eine Software ist, die Klassen/Methoden der Library nutzt und zusammen mit ihr kompiliert wird. Warum sollte so etwas dann noch mal mit der Library verlinkt werden? Und dann ist meine Klasse auf einmal eine Abgeleitet Form der Library anstelle "Einer Arbeit die die Lib benutzt"? Und warum ist dass ganze dann plötzlich eine executable?
> 
> Ich finde das ganze ist wirklich schlimm geschrieben. Ob ein Anwalt da wohl durchsteigen würde? Eigentlich ist dieser Text ja mehr technisch gehalten als juristisch. Ich finde nur, dass das mit meinem Java Wissen über Nutzung und Funktion von external Jars nicht zu vereinbaren ist. Evtl. fehlt mir da auch noch einiges. Aber bisher bin ich eigentlich recht gut gefahren was das einbinden von Jars angeht.



Ich wollte das mal vom Justiziariat meiner Uni klären lassen und dort konnte man mir auch nicht weiterhelfen (immerhin ein Stall voll promovierter Juristen). Ich glaube der Abschnitt bezieht sich darauf, wenn Du direkt Source-Code in Dein Programm einbindest oder die Jar in Deine Jar einbettest. 

Ich persönlich hatte noch nie Probleme bei Verwendung LGPL-lizensierter Software und viele Projekte schreiben explizit auf ihren Webpages, dass die kostenlose Verwendung in closed-source-Projekten zulässig ist. Man kann ja immer noch einmal in der entsprechenden Mailing-Liste oder direkt bei den Autoren nachfragen. Dann hat man es schwarz auf weiß.


----------



## Noctarius (14. Apr 2010)

MarderFahrer hat gesagt.:


> Liest man den Abschnitt 5 der LGPL steht dort folgendes:
> 
> Alles klar, Meine Java Klasse importiert eine Klasse einer LGPL Library ala "import org.lgpl.lib.class". Meine Klasse muss zusammen mit der Library kompiliert werden damit der Compiler keine Fehler wirft. Sollte also eigentlich passen oder? Meine Software ist also "work that uses the Library"



Hört sich für mich auch so an, als würde es auf die typische Java-Anwendung zutreffen.



MarderFahrer hat gesagt.:


> Diesen Abschnitt verstehe ich beim besten Willen nicht. Eben noch wurde definiert, dass "work that uses the Library" eine Software ist, die Klassen/Methoden der Library nutzt und zusammen mit ihr kompiliert wird. Warum sollte so etwas dann noch mal mit der Library verlinkt werden? Und dann ist meine Klasse auf einmal eine Abgeleitet Form der Library anstelle "Einer Arbeit die die Lib benutzt"? Und warum ist dass ganze dann plötzlich eine executable?
> 
> Ich finde das ganze ist wirklich schlimm geschrieben. Ob ein Anwalt da wohl durchsteigen würde? Eigentlich ist dieser Text ja mehr technisch gehalten als juristisch. Ich finde nur, dass das mit meinem Java Wissen über Nutzung und Funktion von external Jars nicht zu vereinbaren ist. Evtl. fehlt mir da auch noch einiges. Aber bisher bin ich eigentlich recht gut gefahren was das einbinden von Jars angeht.



Hört sich nach Executables an. Also alle Binary-Executables, da diese normalerweise fest gelinkt werden. Ganz haarig wird ab einem Punkt wo eine Anwendung (in Java) ein Interface für externe Plugins bietet. Dann mache ich zur Not ein Plugin unter GPL, welches die Lib nutzt und sich an das Interface hängt. Schon brauche ich das Pluginund die Lib nicht mehr zum kompilieren vom Hauptprogramm


----------



## MarderFahrer (14. Apr 2010)

Ich sag ja, für mich liest sich die LGPL wirklich eher so als ob man beim schreiben nur darauf geachtet hat, dass es mit Programmiersprachen wie C kompatibel ist. 
Dass da ein paar Sachen auch auf Java zutreffen ist dann wohl eher Zufall. Wenn da von executables die Rede ist werden wohl .exe Files mit gemeint sein oder? 

In dieser "Erklärung" der LGPL und Java von David Turner von der FSF: The LGPL and Java erklärt er ja wie Libraries unter Java generell benutzt werden; Als .jars. Ob er auch berücksichtigt, dass "executables" unter Java ebenfalls .jar Dateien sind? Da sieht für mich die ganze Definition der LGPL was "work that uses the Library" und "linking a "work that uses the Library" with the Library creates an executable that is a derivative of the Library" betrifft nochmal anders aus...

Ich habe gerade noch einmal die neueste Version der LGPL durchgelesen. Dort gibt es am Anfang folgende Definitionen:


> An “*Application*” is any work that makes use of an interface provided by the *Library*, but which is not otherwise based on the Library. Defining a subclass of a class defined by the Library is deemed a mode of using an interface provided by the Library.
> 
> A “*Combined Work*” is a work produced by combining or linking an *Application *with the *Library*. The particular version of the Library with which the Combined Work was made is also called the “Linked Version”.




Irgendwie würde für mich als Java Developer die erste Definition schon ausreichen, meint ihr nicht? Meine *Application *besteht aus Klassen, welche Methoden einer *Library *benutzen. Da die Klassen die Library Methoden benutzen ist es ja klar, dass die Library vorhanden sein muss, damit die Application funktioniert. Ich sehe hier keinen weiteren Grund, warum ich diese fertige *Application *nochmals "*combinen*" sollte mit der *Library*. Welches dann laut zweiter Definition eine "*Combined Work*" ergeben würde.

hmm, also da ich diese Definition wirklich verstehen möchte habe ich mich mal an einer Interpretation versucht. So wie auf dem angehängten Bild beschrieben könnte ich mir die Definitionen der LGPL vorstellen. 

Demnach wäre "Application" nur mein Quellcode an sich, welcher eine "Library" benutzt. Das Gesamte Produkt (sprich meine jar und die Library jar) wäre dann "Combined Work".
Vielleicht könnte man auch sagen, dass "Application" sich nicht nur auf meine Quellcodes bezieht, sondern auch auf meine kompilierte myApp.jar. Erst wen ich die ausliefere zusammen mit der Library ergbit das die Definition von "Combined Work".

Dann würde die ganze Haarspalterei auch Sinn machen, die ich in anderen Foren gesehen habe. Dort wurde immer wieder diskutiert, dass die "Application" nicht automatisch unter der LGPL stehen muss, nur weil sie eine LGPL Library benutzt. Wohl aber die executable davon...
Das habe ich nie verstanden. Für mich war die Application, welche die Library nutzt ja die executable.

Ich versuche mich mal an einem Gleichnis: 
(der Vergleich könnte hinken, aber das Prinzip sollte klar werden)

1) Application (myApp.jar)
2) Library (3rdParty.jar)
3) Combined Work (myApp.zip = 3rdParty.jar+myApp.jar)

wäre dasselbe wie:

1) Rohbau (4 Mauern, ohne Dach)
2) Dach (von anderer Firma geliefert)
3) Haus (4 Mauern + Dach)

Soll heißen, technisch gesehen sollte man immer auf das 3) Element achten. Das ist das fertige Produkt. In vielen Foren wird oft gefragt "Muss ich meine Application auch unter LGPL stellen wenn ich eine Library benutze die LGPL ist?" Als Antwort liest man dann "Nein, brauchst du nicht. Deine Application kannst du unter jede Lizenz stellen die du willst."
Das ist natürlich alles richtig. Nur nach dem was ich jetzt glaube zu wissen wurde nichts anderes gesagt als "Den "Rohbau" musst du nicht auch unter die LGPL stellen." Was aber unter die LGPL gehört wäre das "Haus". Dumm nur, dass das den Rohbau praktisch beinhaltet.

Um zurück zu Java zu kommen, ich denke das ganze bedeutet nichts anderes als "myApp.jar" KÖNNTE ich lizensieren wie ich will. ABER sobald ich das zusammen mit der 3rdParty.jar betreibe wird daraus die Definition der "Combined Work" und ich kann es nicht mehr ohne weiteres unter irgendeine von mir gewählte Lizenz stellen. Das heißt, wenn ich myApp.jar unter meiner eigenen Lizenz vertreiben will könnte ich das machen. Würde nur nicht viel nützen, da es alleine nicht lauffähig ist. Erst wenn der Nutzer selbständig die 3rdParty.jar in den selben Ordner packt funktioniert die SW. Dann wäre die Definition des ganzen zwar nicht mehr "Application" sondern "Combined Work" aber davon wüsste ich als Hersteller ja nichts.


----------



## Noctarius (14. Apr 2010)

Ich denke das eigentliche Problem bei dir ist, du versuchst wieder alles auf Java zu beziehen. Genau so wie die LGPL aussieht als ob sie explizit für Native-Compiler/-Linker Sprachen konzipiert wäre.

Wie ich oben bereits erklärt habe, lässt sich jede Interpretation unter Java (und vielen anderen Sprachen) komplett ohne Problem umgehen. Die Application darf einfach keine Methoden direkt aus der Lib nutzen sondern muss sie über ein "Plugininterface" weg abstrahieren. Das einzige was dann die Lib direkt benutzt ist das Plugin und das kann man ja unter die GPL / LGPL stellen ;-)


----------



## MarderFahrer (15. Apr 2010)

OK, das Plugin nutzt die Lib und muss darum unter LGPL.
Aber das eigentliche Program nutzt das Plugin. Welches unter LGPL steht... also müsste das Programm dann doch auch unter LGPL.
Meiner Meinung nach hätte man mit der zusätzlichen Schicht nicht viel gewonnen. Ob mein Programm nun die Lib direkt benutzt, welche unter LGPL steht oder ein Plugin was unter LGPL steht weil es die Lib benutzt käme da doch aufs selbe raus.


----------



## Noctarius (15. Apr 2010)

Ein Plugin ist dazu da um ein Programm zu erweitern. Natürlich muss dein Programm auch ohne dieses Plugin funktionieren, nur halt ohne diese Funktionalität vom Plugin. Wenn das Interface im Mainprogramm ist nutzt das Plugin das Main und nicht umgekehrt. Es muss sich halt nur irgendwie anmelden und darf nicht zwangsweise benötigt sein.

Z.B. könnte man einen Cache als Plugin implementieren. Ist das Plugin nicht da wird entweder ein anderer Cache oder eben gar keiner genutzt. Hier wäre der Fall: Plugin ist nicht benötigt und kann extra installiert werden. Weil einer ein Outlook Addon schreibt welches unter LGPL steht ist MS ja nicht gezwungen Outlook ebenso unter diese zu stellen.

Es bringt allerdings nichts Funktionen in Plugins zu kapseln die zwanghaft benötigt werden, z.B. der GUI Renderer oder ähnliches.


----------



## MarderFahrer (15. Apr 2010)

Verstanden. Ich denke die Gerichte würden schon dafür sorgen, dass die Definition von Plugin eingehalten wird. Wenn da Funktionen drin sind, ohne die ein Programm nicht laufen kann, wird man bestimmt nicht mehr von Plugins reden können.

Abgesehen davon sähe es für eine Firma wirklich nicht sehr vorteilhaft aus wenn die ein Produkt verkaufen wo dann nach der Installation eine Meldung hochkommt:
"Downloaden Sie bitte folgene Open Source Komponenten und packen diese in das "lib" Verzeichnis dieser Installation:Apache 1.5, JUnit 2.0, MySQL 1.4"

Aber ein verwertbares Gerichtsurteil über diese Problematik würde mich schon mal interessieren.
Es gibt ja schon Möglichkeiten... Man könnte das Programm ja "laufen" lassen mit Dummy Funktionen solange die "Plugins" nicht vorhanden sind. Wo man sonst über einen Button einen Webserver starten würde käme z.b nur eine Meldung "Webserver wird hier gestartet" ö.Ä
Also wäre Funktion auch ohne die "Plugins" gegeben. Nur eben nicht die "richtige". Aber welches Gericht kann schon definieren was die "richtige" Funktion der Software ist? (Von einem Web Server mal abgesehen. Da trau ich denen dann schon zu, dass die definieren können wann ein Button mit "Webserver starten" die gewünschte Funktion liefert) :lol:


----------



## Guybrush Threepwood (15. Apr 2010)

Vielleicht sollte man einfach mal an licensing@fsf.org schreiben, um den Sachverhalt zu klären.
Insgesamt scheint aber FSF eine sehr starke, ideologische Motivation zu haben (siehe z. B. Why you shouldn't use the Lesser GPL for your next library - GNU Project - Free Software Foundation (FSF)). Für mich hat das nur noch wenig mit Rationalität zu tun.


----------



## Noctarius (15. Apr 2010)

Die FSF ist sowieso eine rein ideologisch getriebene Organisation. Wenn du dir die Reden vom Richard Stallman anschaust, merkt man das diese auch nur wenig mit Rationalität (zu mindestens an vielen Stellen) zu tun hat.


----------



## Gast2 (15. Apr 2010)

Moin,


betrachten wir das Ganze mal vom logischen Standpunkt



MarderFahrer hat gesagt.:


> Im Bezug auf die LGPL in Verbindung mit Java gab es schon Unmengen an Forum Posts, weil der Text der LGPL sich auf "dynamisches und statisches Linken von Libraries" bezieht was viele Leute in Bezug auf Java verwirrt.


Java kann nur dynamisch ... vom Prinzip her wie DLL bzw. SO ... am Ende kommt das Programm raus und ein Library ... das verwenden der Library passiert zu Laufzeit ... statisch sind das Linken der LIB-Dateien zu Compilerzeit - am Ende steht nur noch das Programm



> Darin liegt doch eigentlich das Problem schlechthin, oder? Welche Firma, die kommerziell eine SW vertreibt erlaubt in ihrer Lizenz ein "reverse engineering" ihres Produktes? Vor allem nur zu dem Zweck eine von ihnen verwendete LGPL Library gegen eine neuere Version auszutauschen?


ich weis nicht wo da Dein Problem liegt ... soll der Kunde doch die Library gegen ein Neue austauschen - meintet wegen mit "reverse engineering" ... hast Du mal RE gemacht? ... mit Java kannst Du recht leicht wieder Code herstellen ... aber denk mal über Java hinweg ... mit C/C++ und diverse andere Sprachen ist das garnicht mal so einfach ... und wenn Du ein großes komplexes Programm hast ist selbst mit Java (respk. .NET) alles andere als schnell gemacht



> Gehe ich nicht Recht in der Annahme, dass man eine solche Library nicht einfach austauschen kann, in dem man das entsprechende .jar File löscht und an dessen Stelle die neue Version des .jar Files kopiert?


im Normalfall ja ... das Problem ist wenn das Projekt einen Teil der API ändert ... eine Funktion rausschmeißt etc. ... dann funktioniert es nicht mehr



MarderFahrer hat gesagt.:


> Diesen Abschnitt verstehe ich beim besten Willen nicht. Eben noch wurde definiert, dass "work that uses the Library" eine Software ist, die Klassen/Methoden der Library nutzt und zusammen mit ihr kompiliert wird. Warum sollte so etwas dann noch mal mit der Library verlinkt werden? Und dann ist meine Klasse auf einmal eine Abgeleitet Form der Library anstelle "Einer Arbeit die die Lib benutzt"? Und warum ist dass ganze dann plötzlich eine executable?


DLL/SO vs. LIB - siehe ob ... Du hast Java - da geht nur DLL/SO ... ich glaube aber Du darfst keine Class via *extends* erweitern nur nutzen



MarderFahrer hat gesagt.:


> OK, das Plugin nutzt die Lib und muss darum unter LGPL.
> Aber das eigentliche Program nutzt das Plugin. Welches unter LGPL steht... also müsste das Programm dann doch auch unter LGPL.
> Meiner Meinung nach hätte man mit der zusätzlichen Schicht nicht viel gewonnen. Ob mein Programm nun die Lib direkt benutzt, welche unter LGPL steht oder ein Plugin was unter LGPL steht weil es die Lib benutzt käme da doch aufs selbe raus.


ACK ... damit würde der Sinn von LGPL sich im Nichts auflösen, weil der Gedankengang (weitergeführt) dazuführen würde das ich mein Programm offen legen muss ... der Sinn von LGPL ist aber das ich es nicht machen muss ... ich muss nur die Library offen legen - auch wenn ich die Library ändere, damit sie besser zu meinem Programm passt



> Weil einer ein Outlook Addon schreibt welches unter LGPL steht ist MS ja nicht gezwungen Outlook ebenso unter diese zu stellen.


Microsoft hat keine Einfluss darauf was da für Plugins kommen und unter welcher Lizenz die existieren ... Du hast aber Einfluß auf die Librarys (respk. Plugins) die Du für Dein Programm nutzen willst ... Du vergleichst gerade Äpfel mit Birnen



> Es bringt allerdings nichts Funktionen in Plugins zu kapseln die zwanghaft benötigt werden, z.B. der GUI Renderer oder ähnliches.


damit wird man vor Gericht definitiv hinfallen


----------



## Noctarius (15. Apr 2010)

Birnen mit Äpfeln nicht, irgendwie hast du die Sätze interessant aus dem Kontext gezogen oder ich habe sie ungünstig formuliert.
Ich sagte ein Programm kann ein Interface zur Verfügung stellen welches z.B. einen Caching-Algo anbindet. Es braucht das Caching aber nicht oder bringt einen ganz rudimentären Standardcache mit. So nun können andere Caching-Plugins aber das Standardverhalten ersetzen. In dieser Sekunde bin ich in der Situation von Microsoft (wie bei Outlook). Ich habe ein Programm welches vollständig lauffähig ist ohne, dass ich z.B. eine unter der LGPL (GPL, ...) stehende Caching-Lib nutze. Es kann aber ein Plugin geschrieben werden, welche diese nutzt und diese Plugins können sehr wohl unter der LGPL stehen.

Zu Punkt 2:
Wieso sollte das vor Gericht auch stand halten? Genau das war ja der Punkt. Das Plugin darf niemals nie nicht zwangsweise benötigt werden um das Programm auszuführen, weil dann kein voll lauffähiges Programm existieren würde. Ausnahme wäre auch hier (um beim Beispiel Renderer zu bleiben), das Programm bringt einen Softwarerenderer mit, langsam aber lauffähig. So damit ist das Programm voll funktionell. Ein Plugin könnte jetzt JMonkey (ist das GPL, ka is ja auch egal) oder eine andere Engine im Hintergrund anbinden. Sie wäre aber nicht notwendig erforderlich.


----------

