Ich hab mal wieder ein rechtliches Problem, vielleicht kann mir da einer weiterhelfen

Und zwar: Ich benutze die bass.dll, die, wenn ich das richtig sehe, Closed-Source ist und für nicht-kommerzielle Anwendungen kostenlos verwendbar ist. Jetzt gibt es diverse Plugins für die Bass.dll, z.B. die bass_aac.dll, die über den Befehl Bass_PluginLoad eingebunden werden können. Die bass_aac benötige ich, damit ich auch aac+-Streams abspielen kann.

Jetzt ist es so, dass diese dll unter der GPL steht. Im Bass-Forum tauchte auch mal das Gerücht auf, dass damit die bass.dll die GPL verletzt, da die bass.dll Funktionen in der aac-dll nutzt. Das scheint nicht so zu sein, da die aac nicht "vital" für die Funktion der bass.dll selbst ist (d.h. es geht auch ohne diese, nur halt nicht mit den Zusatzfunktionen). Bzw. der Autor der bass.dll hat die Erlaubnis vom Autor der bass_aac.dll das so zu verwenden. Oder, noch anders ausgedrückt, die Rechtslage scheint nicht 100%ig geklärt zu sein, ob man eine GPL-dll ins eigene Programm verlinken darf, wenn das Programm auch ohne diese dll funktionieren würde.
(wobei hier "darf man..." immer meint, dass ich das darf ohne mein Programm selbst unter die GPL zu stellen)

Jetzt stellt sich mir die Frage, wie ich dieses Plugin verwenden darf...Darf ich dieses Plugin einfach so benutzen, wenn es da ist (d.h. der User hat das Plugin installiert, bzw. die bass_aac.dll kopiert)?
Oder darf ich auch die bass_aac.dll in mein Download-Archiv mit reinpacken, und wenn ja, was muss ich dabei ggf. beachten?

Anmerkung: Für Bibliotheken gibt es die weniger restriktive LGPL, die solche Probleme in der Regel verhindert. Vielleicht fragst du den Author, ob er diese Lizenz für seine DLL wählt.

Könnte man, ja. Das Problem geht aber noch weiter, wie ich fürchte...

Die bass_aac basiert auf der faad2 (oder so ähnlich), welche unter der GPL steht, also muss die bass_aac auch unter der GPL stehen. Der "Eigentümer" der faad2 ist scheinbar die NeroAG. Die Lizenz umzuändern, scheint also nicht so einfach zu gehen.

Ein weiteres Problem sind die Lizenzkosten, die man für AAC-Support zahlen muss. Inwieweit ich als Entwickler auch zahlen muss, wenn ich AAC nur über Plugins liefere, scheint nicht so ganz klar zu sein

Schließlich gibt es auch recht viele Freeware-MP3-Encoder, und fürs codieren von mp3s werden ja eigentlich auch Lizenzkosten fällig. Die Freeware-Encoder umgehen das, indem sie die lame.dll nutzen, die allerdings unter der LGPL steht, und somit von ClosedSource-Programmen benutzt werden darf.

(Das habe ich mir aus dem Bass-Forum zusammengereimt, inwiefern das auf einer sicheren rechtlichen Grundlage steht, kann ich nicht sagen . Die meisten Äußerungen dazu kommen von Sebastian Mares, der an der Entwicklung der bass_aac wohl beteiligt war. Er ist auch der Meinung, dass eine PlugIn-Verwendung für AAC "höchstwahrscheinlich legal" ist, aber sicher ist er da auch nicht.)
Ich werde auch im Bass-Forum nachfragen, bzw. die recht aktuelle Diskussion diesbzgl. verfolgen und hier ggf. anfügen.

Anfragen ob sie es auf BSD umlizensieren. GPL für Libraries ist echt beschissen.

Also ich hab mich mit so Zeug auch svhon bisschen beschäftigt. Bin aber selbst auf die Schlüsse gekommen, also ohne "rechtlichen Beistand" (Rechtsanwalt o.ä.), deswegen geb ich mal keine Garantie drauf, dass das alles stimmt!
So wie ich das verstehe darf mal eine Software, die unter der GPL steht auch nur mit GPL Software benutzen. Sprich: Meiner Meinung begeht die Bass.dll da einen Rechtsverstoß. Wenn der Autor der Dass_aac das dem Autor der Bass.dll aber erlaubt hat, begeht der autor der bass_aac den Rechtsverstoß, weil er eben auch Code benutzt, der unter der GPL steht. Die Autoren der beiden Dlls sollten mal nen Rechtsanwalt bezügl. diesem Problem befragen. Sonst bekommen sie evtl. später noch irgendwelche größeren Probleme... Ausschlaggebend ist der Abstaz 2. b) der GPL:

GPL 2.b):

You must cause any work that you distribute or publish, that in whole or in part contains or is derived from the Program or any part thereof, to be licensed as a whole at no charge to all third parties under the terms of this License.

Für Bibliotheken gitb es wie obven schon erwähnt die LGPL, welche das dynamische Linken erlaubt. Ich weiß grad leider nicht, ob das "linkende Programm" bei der LGPL auch OpenSource sein muss, ich glaub aber, dass es da egal ist, unter welcher Lizenz es steht.


Ich glaube auch nicht, dass die Autoren das unter die BSD-Lizenz stellen.. Das ist ja was ganz anderes als die GPL... Höchstens dass sie vielleicht einen Wechsel zu LGPL machen...


MrSaint


EDIT: hab jetzt in der LGPL mal nachgeschaut:

LGPL:

6. As an exception to the Sections above, you may also combine or link a "work that uses the Library" with the Library to produce a work containing portions of the Library, and distribute that work under terms of your choice, provided that the terms permit modification of the work for the customer's own use and reverse engineering for debugging such modifications. You must give prominent notice with each copy of the work that the Library is used in it and that the Library and its use are covered by this License. You must supply a copy of this License. If the work during execution displays copyright notices, you must include the copyright notice for the Library among them, as well as a reference directing the user to the copy of this License. Also, you must do one of these things: * a) Accompany the work with the complete corresponding machine-readable source code for the Library including whatever changes were used in the work (which must be distributed under Sections 1 and 2 above); and, if the work is an executable linked with the Library, with the complete machine-readable "work that uses the Library", as object code and/or source code, so that the user can modify the Library and then relink to produce a modified executable containing the modified Library. (It is understood that the user who changes the contents of definitions files in the Library will not necessarily be able to recompile the application to use the modified definitions.) * b) Use a suitable shared library mechanism for linking with the Library. A suitable mechanism is one that (1) uses at run time a copy of the library already present on the user's computer system, rather than copying library functions into the executable, and (2) will operate properly with a modified version of the library, if the user installs one, as long as the modified version is interface-compatible with the version that the work was made with. * c) Accompany the work with a written offer, valid for at least three years, to give the same user the materials specified in Subsection 6a, above, for a charge no more than the cost of performing this distribution. * d) If distribution of the work is made by offering access to copy from a designated place, offer equivalent access to copy the above specified materials from the same place. * e) Verify that the user has already received a copy of these materials or that you have already sent this user a copy. For an executable, the required form of the "work that uses the Library" must include any data and utility programs needed for reproducing the executable from it. However, as a special exception, the materials to be distributed need not include anything that is normally distributed (in either source or binary form) with the major components (compiler, kernel, and so on) of the operating system on which the executable runs, unless that component itself accompanies the executable. It may happen that this requirement contradicts the license restrictions of other proprietary libraries that do not normally accompany the operating system. Such a contradiction means you cannot use both them and the Library together in an executable that you distribute.

Die LGPL ist mir einigermaßen bekannt, und daher ist mein mp3-Player auch nicht wirklich Closed-Source. Der Quellcode kann angefordert werden, so dass der USer Änderungen vornehmen kann. Die Veränderungen darf er dann aber nicht ohne Absprache mit mir weiterveröffentlichen - da möchte ich etwas die Kontrolle behalten

Zu der Legalität der beiden dlls zitiere ich mal aus dem Bass-Forum

Sebastian Mares hat im Bass-Forum folgendes geschrieben:

First of all, I asked Menno Bakker (the author of FAAD2) if Sebastian Andersson is allowed to develop a plugin based on FAAD2 and he gave me green light. Additionally, the person's claims that GPL plugins are illegal when linked to non-GPL callers are not 100% valid, and until a court decides what is legal or not regarding this grey zone (since the license isn't clear about this matter), nothing can be told for sure. Some persons say it is illegal, some persons state that as long as the plugin is not vital for the caller (and in our case, BASS can perfectly operate without our add-ons), its usage is allowed. There are various GPL plugins available for Adobe Audition, Adobe PhotoShop, Winamp, foobar2000, etc. Does this make Adobe Audition, Adobe PhotoShop, etc. illegal? Also, MaresWEB or Ian Luck aren't breaking the licensing terms for sure. The only person who might be breaking them is the developer who is using BASS and BASS_AAC / BASS_AC3.

Der letzte Satz macht mir etwas Kopfschmerzen

Und weiter:

Zitat:

Scenario 2: I am creating a closed source application and would like it to be able to support plugins (like Winamp, foobar2000 or XMPlay do). What I do is write a routine that checks what DLLs are in the application's folder and if they look like valid plugins, I dynamically load them. It happens that someone (or even I) writes a plugin based on FAAD2 for decoding MP4 files. My application sees the plugin, loads it and passes all MP4 files to it. If the plugin wouldn't be there, my application would still load and operate properly. AAC decoding is not an advertised feature. This is pretty much what BASS_AAC and BASS are doing and most likely it is legal (again, only a court can say for sure).

Ich verstehe das so, dass ich mein Programm so gestalten kann, dass es die dlls dynamisch lädt, wenn sie vorhanden sind. Sind sie es nicht, dann funktioniert mein Programm auch noch (es unterstützt dann halt keine AAC-Dateien/Streams). Kopiert der Anwender die entsprechenden Dateien ins Anwendungsverzeichnis, so erweitert sich die Funktionalität entsprechend, womit ich als Entwickler dann aber nichts mehr zu tun habe, wenn ich keine spezifischen dlls einbinde, sondern einfach alle, die da sind (wodrunter dann auch die GPL-geschützte dll sein kann)...

Ich kann als Entwickler ja nichts dafür, wenn der User eine dll in das Verzeichnis kopiert, die unter der GPL steht, und die "kompatibel" mit evtl anderen dlls ist, die mir keinen Ärger mit Lizenzen machen...

Hmm... Also in der LGPL wird ja explizit auf Header-Files eingegangen (ich glaub im 5. Abschnitt). Dies geschieht in der GPL nicht. Ich würde es jetzt so ansehen, dass bei einer DLL die exportierten Funktionen nach einem bestimmten Schema aufgebaut sind, das dem Anwender der DLL bekannt sein muss (Parameter etc.), sprich eine Art Header haben. Dies wiederum wäre Teil des "Programms" (unter der GPL). Und nochmal obiger Abschnitt:

Zitat:

You must cause any work that you distribute or publish, that in whole or in part contains or is derived from the Program or any part thereof, to be licensed as a whole at no charge to all third parties under the terms of this License.

Wie gesagt, ich bin kein Experte und leite mir das nur selbst her. Aber ich sehe auf jeden Fall die Möglichkeit, dass es Probleme geben könnte. Auch wenn man sich das mal überlegt: Warum sollte die FSF die LGPL gemacht haben, wenn man die Bibliotheken auch unter den gleichen Vorraussetzungen unter der GPL anwenden kann?

Gausi hat folgendes geschrieben:

Die LGPL ist mir einigermaßen bekannt, und daher ist mein mp3-Player auch nicht wirklich Closed-Source. Der Quellcode kann angefordert werden, so dass der USer Änderungen vornehmen kann. Die Veränderungen darf er dann aber nicht ohne Absprache mit mir weiterveröffentlichen - da möchte ich etwas die Kontrolle behalten

Das ist glaub leider nicht ganz okay. Weil in §1 und §2 steht, dass "er" es weitergeben und verändern darf, wenn er bestimmte Regeln einhält. Wenn du da die Kontrolle behalten willst, kannst du die Lizenz ja ein klein wenig abändern und einfach bei §2 einen Absatz dazuschreiben... Nur dass es dann auch wirklich eindeutig ist Ich weiß nämlich nicht genau, inwiefern solche "Extra Absprachen" geltend gemacht werden können...



MrSaint

Zu den Extra-Absprachen (also nicht zum eigentlichen Thema):

aus der LGPL:

6. As an exception to the Sections above, you may also combine or link a "work that uses the Library" with the Library to produce a work containing portions of the Library, and distribute that work under terms of your choice, provided that the terms permit modification of the work for the customer's own use and reverse engineering for debugging such modifications.

Also, wenn ich LGPL-Code verwende, dann muss ich dem User die Möglichkeit geben, Änderungen an der Software vorzunehmen. Möchte er die Änderungen weiterverbreiten, so möchte ich da mitreden (das wären meine "Terms"). Unter welcher Lizenz dann das veränderte Programm steht, kann man dann regeln. Wichtig ist, dass "private Änderungen" möglich sind.

Und zu meinem GPL-Plugin-Problem: viele Addons der bass.dll sind so aufgebaut, dass sie per Bass_Pluginload('bass_XXX.dll') eingebunden werden können. Das bewirkt dann, dass die bass.dll-Funktion "lade Musik aus Datei sowieso" auch die Formate versteht, die über das Add-On ermöglicht werden. D.h. wenn ich im OnCreate einfach alle dlls lade, die im Anwendungsverzeichnis liegen, dann erfolgt die Unterstützung der weiteren Formate durch diese Plugin-Technik quasi von selbst. Wenn ich nun davon ausgehe (und so wird das auf der Bass-Homepage erklärt), dass auch die spezielle GPL-dll "bass_aac" so mit der bass.dll zusammenarbeiten darf, dann kann man mir doch nicht mehr ans Bein pinkeln, weil ich durch ein paar Zeilen Code auch eine dll miteinbinde, die unter der GPL steht.
Ebenso würde ich da kein Problem sehen, wenn der User eine dll in das Verzeichnis kopiert, wodurch sich auf einmal Formate abspielen lassen, wofür man eigentlich zahlen müsste. Ich weiß, dass ich jetzt ein bißchen spitzfindig werde, aber funktioniert das nicht so?

Gausi hat folgendes geschrieben:

Also, wenn ich LGPL-Code verwende, dann muss ich dem User die Möglichkeit geben, Änderungen an der Software vorzunehmen. Möchte er die Änderungen weiterverbreiten, so möchte ich da mitreden (das wären meine "Terms"). Unter welcher Lizenz dann das veränderte Programm steht, kann man dann regeln. Wichtig ist, dass "private Änderungen" möglich sind.

Sehe ich anders: In diesem Abschnitt geht es um "work that uses the Library". Bei Änderungen am Code greift allerdings §2 in dem steht:

LGPL 2. c):

You must cause the whole of the work to be licensed at no charge to all third parties under the terms of this License.

Zum eigentlichen Problem: Hmm... Ich denke das kann man so sehen. Und ich verstehe das auch alles voll. Was kann den ein Programmierer dafür, dass irgendeiner ein Plugin für sein Programm schreibt und das unter die GPL stellt. Darin stimme ich dir also absolut zu. Nur leider les ich das aus der GPL halt so raus, dass man in fremden nicht-GPL Programmen keinen GPL-Code benutzen darf. Ich sag nochmal: Bin nur ein Laie! Ich kann das nicht 100%ig klären. Das kann, wie in den quotes auch angemerkt ist, nur ein Gericht. Um das zu umgehen sehe ich gerade nur die Möglichkeit, mit den ursprünglichen Autoren zu reden und zu fragen, ob sie den Code vielleicht nicht doch unter der LGPL veröffentlichen wollen, bzw. eine explizite Erlaubnis für dein Projekt (bzw. für das Bass_aac Projekt) einzuholen.
Auf realistischer Ebene denke ich nicht, dass dir da irgendjemand einen Strick draus dreht, wenn du die DLL ansprichst/benutzt, aber theoretisch sehe ich da auf jeden Fall.. naja... ein "Problem". Ob dann im Endeffekt, sollte der theoretische Fall eintreten, du der schuldige bist, oder der Entwickler von Bass.dll oder von Bass_aac kann ich jetzt aber nicht sagen


MrSaint

Zur LGPL: (ich weiss jetzt langsam, warum ich immer Topic schließe, wo zwei Fragen parallel diskutiert werden )
Bei mir ist der Fall so: Ich verwende verschiedene Klassen (z.B. mein MP3FileUtils, aber auch Teile der ATL), die unter der LGPL stehen. Da "Klassen und dll" nicht so einfach sind, kann man nicht einfach die Klassen extern lassen (wie es bei dlls sonst so ist), sondern muss diese ins Programm mit einkompilieren. Dieser Fall ist, so wie ich das sehe, in Sektion 6 geregelt..

Und wieder zu dem GPL: Das muss eigentlich erlaubt sein, denn andernfalls kann man jede Closed-Source-Software, die ein Plugin-System bietet, unter die GPL zwingen, indem man einfach ein passendes Plugin schreibt, und dieses unter die GPL stellt.
Die bass.dll war ja zuerst da, und dann kam die bass_aac, die von sich aus so aufgebaut ist, dass die bass.dll sie einbinden kann.

Gausi hat folgendes geschrieben:

Bei mir ist der Fall so: Ich verwende verschiedene Klassen (z.B. mein MP3FileUtils, aber auch Teile der ATL), die unter der LGPL stehen. Da "Klassen und dll" nicht so einfach sind, kann man nicht einfach die Klassen extern lassen (wie es bei dlls sonst so ist), sondern muss diese ins Programm mit einkompilieren. Dieser Fall ist, so wie ich das sehe, in Sektion 6 geregelt..

Hmm.. Ich habe das von einer anderen Seite her gesehen. Und zwar von dem User, der von dir den Source für dein Programm bekommt. Wenn er es _verändern_ will und weiter veröffentlichen will, hattest du gemeint, dass er das mit dir absprechen müsste. Die LGPL erlaubt ihm das allerdings ohne Absprache. Ich hatte nicht die Verbindung zwischen dir und deinen Klassen angesprochen... Wenn er mit irgendeinem eigenen Programm deinen Source nutzen will, darf _er_ es unter seine eigenen Bedingungen stellen. Deine Bedinungen sind ja eigentlich komplett in der LGPL niedergeschrieben. Ich weiß nun, wie gesagt, nu rnicht, inwiefern eben solche "zusätzlichen Absprachen" untereinander gelten.

Zitat:

Und wieder zu dem GPL: Das muss eigentlich erlaubt sein, denn andernfalls kann man jede Closed-Source-Software, die ein Plugin-System bietet, unter die GPL zwingen, indem man einfach ein passendes Plugin schreibt, und dieses unter die GPL stellt. Die bass.dll war ja zuerst da, und dann kam die bass_aac, die von sich aus so aufgebaut ist, dass die bass.dll sie einbinden kann.

Ja, das ist jetzt ein interessantes Problem, wenn man sich das mal so überlegt Also ich bin der überzeugung, dass solch ein "Lizenzzwang" gehen müsste. Jetzt wieder rein theoretisch. Natürlich wird das kein deutsches Gericht so machen. Bei den amerikanischen z.B. wär ich mir da nicht so sicher
Wobei, da kommt mir folgender Gedanke: Diese PlugIn-Schnittstelle: Ursprünglich kommt die ja eigentlich nicht vom PlugIn sondern wird von "Urprogramm" zur Verfügung gestellt. In sofern wäre das kein Teil des Codes des GPL-PlugIns => Alles wäre so wie man sich das vorstellt. Sprich es wäre auch in der Bass.dll kein Problem, die Bass_aac anzuwenden, weil die Schnittstelle ja von der Bass.dll definiert wird. Hmm... Aber wie rum man das nun sieht, wer jetzt die Schnittstelle definiert ist wohl nicht ganz entscheidbar. Weil man könnte ja auch sagen, die DLL definiert die Schnittstelle und das Urprogramm benutzt diese zufällig oder so...
Andererseits "benutzt" das Urprogramm ja nicht nur die Schnittstelle, sondern eigentlich auch den ganzen PlugIn-Code (sprich: es führt in aus), der ja auch unter der GPL steht..
Puhh, ist das kompliziert



MrSaint

Zum Thema1: Die Teile, die unter der LGPL stehen, kann der User natürlich modifizieren und weiterverbreiten. Dafür braucht er aber nicht den Code meiner Anwendung, sondern den Code der LGPL-Units/dlls. Er hat auch das Recht (seitens der LGPL), meinen Code zu bekommen, damit er die verbesserte/modifizierte Version der LGPL-Teile, die in meinem Code enthalten sind, in mein Programm einzubinden.
Aber dann hörts auf - Mein Programm steht halt nicht unter der LGPL, und so wie ich das verstehe, ist das auch nicht nötig.

Zum Thema2: Parallel hat einer in der DP dasselbe Problem. Da scheint die Diskussion aufs selbe Ergebnis hinauszulaufen...

Gausi hat folgendes geschrieben:

Aber dann hörts auf - Mein Programm steht halt nicht unter der LGPL, und so wie ich das verstehe, ist das auch nicht nötig.

Ahhh, da steckt das Problem ich dachte du hättest dein Programm unter der LGPL lizensiert *d'oh* Na dann geht das natürlich, das ist klar

Zitat:

Zum Thema2: Parallel hat einer in der DP dasselbe Problem. Da scheint die Diskussion aufs selbe Ergebnis hinauszulaufen...

Ich werd da mal nen Link auf hier setzen, dann beteiligen sich vielleicht noch ein paar an der Diskussion hier und wir bekommen mal neue Ideen


MrSaint