Ist vielleicht die LGPL das richtige für mich? Brauche Hilfe

[sape]

Ja ich bins mal wider mit der Lizenz Frage

Wäre die LGPL OK für mich? Ermöglicht ja auch OpenSource, ClosedSource und ist mit anderen Lizenzen kompatibel. Sehe ich das richtig? (Sorry aber ich steige da Wirklich nicht durch, auch nicht wenn ich das mehrmals Lese. Die Formulierungen sind so schwammig und lässt zuviel Interpretationsspielraum.)

Pocoo nutzt ja z.B. auch die LGPL. Dann kann es doch nicht so verkehrt sein oder? Warum habt ihr euch Blackbird und Birkenfeld zur LGPL entschlossen und wäre das vielleicht auch was für mich?

Wenn ich das nötige Geld hätte würde ich einen Rechtskundigen der sich mit Lizenzen und den Auslegung auskennt bezahlen, der mir das alles Idiotensicher erklärt. Hab aber leider nicht soviel Geld...

Danke schon mal.

lg
xtra

P.S.: Und sorry das ich euch wider mit dieser Frage belästige

Edit (Leonidas): Nach Offtopic verschoben.

[lunar]

Wäre die LGPL OK für mich?

Kommt darauf an, was du erreichen willst und was du damit lizensieren willst...
Für Pythonmodule für ich die LGPL allerdings nicht nehmen...

Ermöglicht ja auch OpenSource, ClosedSource und ist mit anderen Lizenzen kompatibel. Sehe ich das richtig? (Sorry aber ich steige da wirlcih nciht durch auch cnith wenn ich das mehrmals lses. Die Formulierungen sind so schwamig und da kann ich alles mögliche hinein interpretieren.)

Genau dieses Interpretieren ist das Problem. Für binäre Programme (insbesondere C) ist die LGPL wunderbar. Auf diese Art der Programme wird präzise eingegangen, ist doch sogar von "linking", "compiling" und "header file" die Rede. Aber Python kennt weder "header files", noch wird bei Python im eigentlichen Sinne kompiliert oder gelinkt.

Zum anderen ist der Begriff der "derivative work" - also ein Programm, welches von der Bibliothek "abgeleitet" ist - imo problematisch. Die LGPL definiert den Unterschied zwischen "derivative work " weitgehend auf der binären Ebene sowie über "header files". Python kennt aber keinenwirklichen Objectcode (ich denke nicht, dass man Bytecode damit gleichsetzen kann), also auch keine binäre Ebene.

Für binäre Sprache (insbesondere für C/C++) ist die LGPL klar definiert, bei so hoch dynamischen Sprachen wie Python oder anderen Skriptsprache sind Begriffe wie "linking" oder "header file" nicht angebracht und lassen deswegen imo zu viel Raum für Interpretationen.

Wenn es dir nur darum geht, dass die Bibliothek frei ist, aber trotzdem auch in proprietären Programmen verwendet werden kann, würde ich die X11 Lizenz (aka BSD revised) empfehlen. Allerdings verlierst du damit die Garantie, dass Änderungen am Bibliothekscode selbst frei verfügbar gemacht werden...

just my 2 cents...
IANAL, deswegen kann ich mich natürlich irren. Immerhin ist das ein sehr komplexes Thema

Gruß
lunar

[mitsuhiko]

Pocoo nutzt ja z.B. auch die LGPL. Dann kann es doch nicht so verkehrt sein oder? Warum habt ihr euch Blackbird und Birkenfeld zur LGPL entschlossen und wäre das vielleicht auch was für mich?

Negativ. Pocoo nutzt die GPL. GPL für Libraries ist sehr dumm weil deine Lib dann nur in GPL Programmen verwendet werden kann. Jinja/Colubrid stehen unter der BSD, pygments momentan unter der LGPL.

[sape]

@blackbird:
Warum alles unter verschiedenen Lizenzen? Verstehe den Sinn nicht darin?

@lunar:

Immerhin ist das ein sehr komplexes Thema

Leider

So, wie ich das nun sehe ist eigentlich jede Lizenz sch*** :/

Tja, was tun? Hmm, am besten lass ich das wohl alles sein *resigniere* :-[
Kann mich nicht entscheiden und bin auch nicht in der Lage das alles zu beurteilen. Falsch machen möchte ich auch nichts und von daher ist es wohl das Beste wenn ich mich garnicht erst darauf einlasse und die Sache einfach bleiben lasse...Sachen wie "Könnte sein. Vielleicht" sind mir zu unsicher...

Danke und LG

P.S.:

Negativ. Pocoo nutzt die GPL. GPL für Libraries ist sehr dumm weil deine Lib dann nur in GPL Programmen verwendet werden kann. Jinja/Colubrid stehen unter der BSD, pygments momentan unter der LGPL.

Wie definiert man Library? Ist pygments eine Library? Wenn ja warum Pocoo nicht? Ist doch schließlich auch nicht viel anders Strukturiert(?). Wäre es dann nicht auch angebracht das wie pygments unter LGPL zu stellen oder ist vielleicht die Entscheidung (wenn es ja dumm ist für Librarys LGPL zu benutzen) pygments unter LGPL zu stellen eher dumm? Sorry aber ich steige durch deinen Post beim besten willen nicht durch. Da widerspricht sich alles.

xtra

[Leonidas]

So, wie ich das nun sehe ist eigentlich jede Lizenz sch*** :/

Nö - hängt einfach nur davon ab, was du mit einer Lizenz bezwecken willst. Für einige Zwecke gibt es nun mal keine juristische Formulierung die genau das eindeutig aussagt, was du bezwecken willst.

Tja, was tun? Hmm, am besten lass ich das wohl alles sein *resigniere* :-[
Kann mich nicht entscheiden und bin auch nicht in der Lage das alles zu beurteilen. Falsch machen möchte ich auch nichts und von daher ist es wohl das Beste wenn ich mich garnicht erst darauf einlasse und die Sache einfach bleiben lasse...Sachen wie "Könnte sein. Vielleicht" sind mir zu unsicher...

Wieso? Wenn ich etwas unter BSD oder X11 stelle bin ich auf der sicheren Seite. Es kann jemand meinen Code verbessern, es kann aber auch jemand meinen Code in seinem verwenden oder meinen Code in irgendeiner Business-Anwendung verwenden. Ich habe kein Problem damit.

Wie definiert man Library? Ist pygments eine Library? Wenn ja warum Pocoo nicht? Ist doch schließlich auch nicht viel anders Strukturiert(?). Wäre es dann nicht auch angebracht das wie pygments unter LGPL zu stellen oder ist vielleicht die Entscheidung (wenn es ja dumm ist für Librarys LGPL zu benutzen) pygments unter LGPL zu stellen eher dumm? Sorry aber ich steige durch deinen Post beim besten willen nicht durch. Da widerspricht sich alles.

Pygments ist von birkenfeld, daher hat er es anders lizensiert - du musst ihn nach seinen Gründen fragen.
Aber technisch gesehen gibt es zwischen Programm und Library gesehen unter Python keinen Unterschied - ein Quelltext kann sowohl ein Programm als auch Library sein - sogar gleichzeitig. Daher ist die LGPL an dieser Stelle etwas wenig zutreffend. Wäre ein Vorschlag für die LGPL3, aber wie will man dort den Unterschied festhalten, wenn es technisch keinen gibt?

[sape]

Wieso? Wenn ich etwas unter BSD oder X11 stelle bin ich auf der sicheren Seite. Es kann jemand meinen Code verbessern, es kann aber auch jemand meinen Code in seinem verwenden oder meinen Code in irgendeiner Business-Anwendung verwenden. Ich habe kein Problem damit.

Ok, wenn das wirklich so einfach ist und sonst nichts zu beachten ist für mich dann finde ich das gut Dan werde ich die BSD nehmen.

Aber da hätte ich dann noch eine frage:
Welche Fassung soll ich nehmen?
http://de.wikipedia.org/wiki/BSD-Lizenz
Die..

Code: Alles auswählen

-clause BSD" (3-Klausel-BSD) bzw. "modified BSD license",

...hört sich doch gut an oder?

Und dann noch eine Frage: Was soll ich bei <ORGANIZATION> eintragen?
Hab kein Firma Geht auch das ich da meinen Namen wie bei <OWNER> eintrage oder sollte ich da vielleicht den Namen des Programms eintragen?
http://www.opensource.org/licenses/bsd-license.php

Danke.

lg

[Leonidas]

Die..

Code: Alles auswählen

-clause BSD" (3-Klausel-BSD) bzw. "modified BSD license",

...hört sich doch gut an oder?

Ja. Die ursprüngliche mit Advertising-Klausel wurde von einigen auch als unfrei angesehen.

Und dann noch eine Frage: Was soll ich bei <ORGANIZATION> eintragen?
Hab kein Firma Geht auch das ich da meinen Namen wie bei <OWNER> eintrage oder sollte ich da vielleicht den Namen des Programms eintragen?

Ich denke dein Name reicht.

Wäre aber vielleicht nicht schlecht, wenn du dir ein paar der kürzeren und bekannteren Lizenzen durchliest: Revised BSD und MIT (X11), zlib. Vielleicht findest du auch irgendwo eine Übersetzung davon. Meist steht da eben drin, dass da so wenige Beschränkungen wie möglich drauf sind.

[birkenfeld]

@blackbird:
Warum alles unter verschiedenen Lizenzen? Verstehe den Sinn nicht darin?

Weil für verschiedene Projekte verschiedene Lizenzen sinnvoll sind.

So, wie ich das nun sehe ist eigentlich jede Lizenz sch*** :/

Was willst du damit ausdrücken?

Negativ. Pocoo nutzt die GPL. GPL für Libraries ist sehr dumm weil deine Lib dann nur in GPL Programmen verwendet werden kann. Jinja/Colubrid stehen unter der BSD, pygments momentan unter der LGPL.

Wie definiert man Library? Ist pygments eine Library? Wenn ja warum Pocoo nicht?

Pygments ist ein Stück Code, das (auch) dazu gedacht ist von anderen Anwendungen verwendet zu werden, z.B. Trac. Pocoo dagegen ist eine eigenständige Webanwendung. Es wird wohl keiner auf die Idee kommen, Pocoo als Library zu verwenden.

Ist doch schließlich auch nicht viel anders Strukturiert(?).

Welche Struktur meinst du?

Wäre es dann nicht auch angebracht das wie pygments unter LGPL zu stellen oder ist vielleicht die Entscheidung (wenn es ja dumm ist für Librarys LGPL zu benutzen) pygments unter LGPL zu stellen eher dumm?

Momentan diskutieren wir, wie bei Jinja die BSD-Lizenz zu verwenden.

Sorry aber ich steige durch deinen Post beim besten willen nicht durch. Da widerspricht sich alles.

Wie wärs, wenn du dir einfach einen Überblick über die Lizenzen verschaffst, von denen hier die Rede ist. Dann kannst du vielleicht auch nachvollziehen, warum welcher Code unter welcher Lizenz steht.

[sape]

[...]
Wie wärs, wenn du dir einfach einen Überblick über die Lizenzen verschaffst, von denen hier die Rede ist.[...]

Habe ich ja schon längst. Sonst hätte ich den Thread nicht geöffnet. Sehe dazu auch den Eingangspost von mir.

[...]
Dann kannst du vielleicht auch nachvollziehen, warum welcher Code unter welcher Lizenz steht.

Ne leider nicht.

[sape]

@blackbird:
Warum alles unter verschiedenen Lizenzen? Verstehe den Sinn nicht darin?

Weil für verschiedene Projekte verschiedene Lizenzen sinnvoll sind.

Warum sind für verschieden Projekte verschieden Lizenzen sinnvoll? Ergibt für mich kein Sinn

[birkenfeld]

Dann ist aber doch die Auswahl nicht so schwer:

- Ist es dir völlig egal, was andere mit deinem Code machen, nimm BSD.
- Willst du, dass dein Code frei bleibt, aber in kommerziellen Projekten verwendet werden darf, nimm LGPL.
- Willst du, dass dein Code frei ist und jedes Projekt, das ihn nutzt automatisch auch frei werden muss, nimm GPL.

[birkenfeld]

Warum sind für verschieden Projekte verschieden Lizenzen sinnvoll? Ergibt für mich kein Sinn

Weil eben z.B. Pygments eine Library, Pocoo dagegen nicht ist.

[sape]

Warum sind für verschieden Projekte verschieden Lizenzen sinnvoll? Ergibt für mich kein Sinn

Weil eben z.B. Pygments eine Library, Pocoo dagegen nicht ist.

Ah, ok. Nun habe ichs

Im Gegensatz zur GPL dürfen alle Programme, die LGPL-lizenzierte Software nur extern benutzen, zum Beispiel als DLL Files, ihre eigene Lizenz behalten. Damit eignet sich die LGPL besonders als Lizenz für Bibliotheken, deren Benutzung man auch Programmierern proprietärer Programme erlauben will. Soll die unter der LGPL lizenzierte Software dagegen fest in ein anderes Programm eingebunden werden, muss auch das andere Programm unter der LGPL bzw. einer kompatiblen Lizenz stehen.

So der Fett gedruckte teil bereitet mir Schwierigkeiten beim Interpretieren. Wie definieren die Fest eingebunden?

Bedeutet das, dass in proprietärer Software X, die unter LGPL gestellte Library-/Software-Y nicht in X mitgeliefert werden darf? Also das Y nachträglich installiert werden muss und es ausdrücklich verboten ist, das mit seiner Software mitzuliefern? Oder heißt "Fest-Eingebunden", das der Code oder Teile des Codes nicht im Quelltext der proprietären Software vorhanden sein darf?

<ot>
Warum könne die nicht mal klar definieren was gemeint ist und müssen immer alles so Formulieren das es für einen nicht Juristen wie mich alles mögliche bedeuten kann Echt bei solchen wichtigen Sachen hasse ich das wenn _zuviel_ Interpretationsmöglichkeiten vorhanden sind! (BTW: Das hasse ich allgemeinen nicht nur dar!)
</ot>

lg

[BlackJack]

Im Gegensatz zur GPL dürfen alle Programme, die LGPL-lizenzierte Software nur extern benutzen, zum Beispiel als DLL Files, ihre eigene Lizenz behalten. Damit eignet sich die LGPL besonders als Lizenz für Bibliotheken, deren Benutzung man auch Programmierern proprietärer Programme erlauben will. Soll die unter der LGPL lizenzierte Software dagegen fest in ein anderes Programm eingebunden werden, muss auch das andere Programm unter der LGPL bzw. einer kompatiblen Lizenz stehen.

So der Fett gedruckte teil bereitet mir Schwierigkeiten beim Interpretieren. Wie definieren die Fest eingebunden?

Gar nicht.

Wie schon von lunar festgestellt, sind diese Lizenzen anscheinend mit statisch übersetzten Programmiersprachen im Hinterkopf entworfen worden. Da ist ziemlich klar was statisch, also fest, gebunden und dynamisch gebunden bedeutet.

Bei Sprachen wie Python wird diese Formulierung unglaublich schwammig.

Bedeutet das, dass in proprietärer Software X, die unter LGPL gestellte Library-/Software-Y nicht in X mitgeliefert werden darf? Also das Y nachträglich installiert werden muss und es ausdrücklich verboten ist, das mit seiner Software mitzuliefern?

Nein Du darfst Code der unter der LGPL steht natürlich zusammen mit dem "closed source"-Programm ausliefern. Das ist ja gerade der Unterschied zur GPL.

Oder heißt "Fest-Eingebunden", das der Code oder Teile des Codes nicht im Quelltext der proprietären Software vorhanden sein darf?

Das darf auf keinen Fall sein. Dann wäre es aber auch keine Bibliothek mehr die nur benutzt wird.

<ot>
Warum könne die nicht mal klar definieren was gemeint ist

Weil das nicht geht. Das ist schlichtweg unmöglich. Natürliche Sprache ist einfach mehrdeutig und interpretationsfähig. Je klarer Du so etwas definieren willst, umso komplexer wird die Definition, weil Du alles haarklein beschreiben und einschränken musst, um es wasserdicht zu machen. Soweit das überhaupt geht. Und dann versteht's kein Schwein mehr oder trotzdem falsch. Im schlimmsten Fall versteht's ein gegnerischer Anwalt absichtlich falsch und zwar mit einer mindestens genauso komplexen Begründung wie die Definition, die das ganze wasserdicht machen sollte.