[erledigt]FPC LGPL Lizenz für Bytecode Compiler/Interpreter?

[Keifor]

Hallo ans Board,

Ich arbeite derzeit an einem Template Prozessor (Trickonos). Mittlerweile ist dieses Projekt derart gewachsen, dass ich über ein Pre Release nachdenke, eventuell um andere Programmierer mit einzubeziehen und frühe (funktionalitäts-bildende) Modifikationen zu erlauben und Fehler zu vermindern.

Allerdings habe ich ein Problem damit, bestimmte Fragen zu der Lizenz (FPC modified LGPLv2.1) zu beantworten. Vorerst, ein kleiner Überblick über den Template Prozessor:

• Die Hauptapplikation besteht aus einem "Bytecode" Compiler, Loader, einer Virtual Machine (die den Bytecode ausführt) und einem Script Object System welches von der VM genutzt wird (mit simplem Garbage Collector, erweiterbares System etc.). Templates werden beim ausführen direkt in Bytecode übersetzt (oder geladen, falls eine entsprechende Bytecode Datei gefunden wird), und von der VM ausgeführt, was wiederum eine Ausgabe erzeugt. (alles FPC/FPC RTL, keine Packages oder 3d Party Quellen/Libs/Packete verwendet.)
• Aktuell ist die Hauptapplikation bzw. vm/compiler/script objects nicht darauf ausgelegt, separat genutzt zu werden (bspw. als Bibliothek oder Unit), was allerdings mit wenigen Handgriffen möglich ist.
• Eine (Standard) Template Bibliothek ist vorgesehen.

--

Zu den Fragen. Ich würde gerne die FPC modified LGPLv2.1 (GPL mit linking exception und FPC disambiguation, die sowohl statisches als auch dynamisches linken erlaubt) nutzen, was es erlauben würde, Trickonos mit Lazarus/FPC zusammen weiter zu verbreiten.

Kann mir jemand kurz und "nicht in Anwaltssprache" erklären:

1. ob es erlaubt ist, 3rd Party Module mit einer anderen Lizenz hinzuzufügen, die Klassen/ein spezifisches Interface von Trickonos nutzen um die Funktionalität zu erweitern, selbst aber keine Änderungen in Trickonos benötigen.
2. ob es erlaubt ist, dual-lizensierte (bspw. FPC modified LGPLv2.1 und MPL) FPC Packages zu nutzen, ohne Explizit zu erklären, dass das entsprechende Packet unter LGPL Terms genutzt wird.
3. was mit Template Packages ist. Da diese so gesehen keinen Binärcode darstellen, sondern lediglich Quelltext, der durch den Interpreter verarbeitet wird, könnte es da zu Komplikationen kommen, wenn jemand a.) ein Template erweitert, b.) ein Template nutzt, c.) die mitgelieferte Template Bibliothek teilweise eretzt/ganz ersetzt/erweitert?
4. wenn 3. zutrifft, gibt es eine kompatible Lizenz/Möglichkeit diese Probleme zu umgehen um FPC/Lazarus Lizenzkompatibilität zu erreichen? (z.B. eine weitere Lizenz, speziell für das Template Package, die Nutzer/Redistributor Änderungen ohne Komplikationen erlauben würde)

Danke im voraus, auch an jene die sich die Mühe gemacht haben, dass ganze durchzulesen, aber keine Antworten kennen.

[theo]

PS: Bitte sachlich/fachlich/verständlich. Antworten wie "Ich denke .." (subjektive Meinungen) oder "RTFM" äquivalente bringen mich nicht weiter

Was sollen wir denn sonst sagen?
Wenn du verbindliche Antworten haben willst, dann frag die FPC devels doch selber.
http://lists.freepascal.org/mailman/listinfo/fpc-devel

[mse]

Auf jeden Fall vergiss bitte nicht, dass der Free Pascal Compiler selbst und alles im Verzeichnis compiler und möglicherweise auch weitere Dateien nicht LGPL with static linking exception sondern GPL sind.

Martin

[Keifor]

Was sollen wir denn sonst sagen?

@theo
Objektiv, eventuell aus Erfahrung oder weil man Guru in Sachen Recht ist.
Beispiele/Ähnliches, eventuell auch eine andere Möglichkeit, wenn sich jemand damit auskennt.
Es geht auch nicht um etwas verbindliches (Mein Notar guckt mir jedenfalls nicht über die Schulter und Rechtsbeistand hab ich ebenfalls nicht erfragt/bezahlt), nur um schwächen im geplanten Lizenzmodell zu finden / bzw. halt die entsprechenden Fragen zu klären oder festzustellen das sie "nicht klär-bar" sind. In dem Fall werde ich die Lizenz so oder so nehmen.

Allerdings, wenigstens zum Punkt 4, wäre es schön zu wissen ob es eine andere Möglichkeit gibt, die Packages abzuändern/erweitern/löschen und das ganze in ein anderes (l)gpl/nicht gpl Projekt einzugliedern OHNE in die Zwicklage zu kommen, das ganze wiederum als eigenständiges Projekt auszuzeichnen und anzubieten (was entsprechend mit gpl notwendig ist, sobald das Projekt als solches modifiziert weiterverbreitet wird.. zugegeben, das ist auch eine subjektive Deutung der GPL).

hmm.. der Zusatz ist etwas einschränkend. *geht den Eintrag editieren*

@mse,
Danke, ich habe lediglich vor die RTL und eventuell Packages zu nutzen. Compiler/Scanner sind handgeschrieben und beruhen auf Basiswissen in Sachen Compilerbau. Alles weitere (syntax/semantik/grobarchitektur/typen) sieht sehr pythonisch/phpisch/pascalisch aus, lässt sich aber nicht vermeiden und wurde auch nicht kopiert von Compiler/Interpreter xyz. Das sollte soweit also kein Problem darstellen, ist aber eine gute Erwähnung.

[marcov]

A.S. ich bin kein Anwalt, habe auch nicht dafuer studiert, verfolge aber schon seit Jahre FPC gerelatierte Copyright Diskussionen.

Kann mir jemand kurz und "nicht in Anwaltssprache" erklären:

[*] ob es erlaubt ist, 3rd Party Module mit einer anderen Lizenz hinzuzufügen, die Klassen/ein spezifisches Interface von Trickonos nutzen um die Funktionalität zu erweitern, selbst aber keine Änderungen in Trickonos benötigen.

Hinzu was ? Der VM (der FPC rtl nutzt) oder VM benutzende bytecode Programme?

Wenn VM: mussen "LGPL2.1 mit static linking exception..." kompatible sein. (Normalerweise ist das kein Problem)

Der Bytecode Fall is schwieriger. (sie auch mehr nach unten). Der LGPL sieht es nicht vor, und weil es nur "linking" unschreibt, konnte es mehrere Interpretationen geben. Teilweise auch konnte der Situation unterschiedlich sein fuer
Interpretation und JIT.

[*] ob es erlaubt ist, dual-lizensierte (bspw. FPC modified LGPLv2.1 und MPL) FPC Packages zu nutzen, ohne Explizit zu erklären, dass das entsprechende Packet unter LGPL Terms genutzt wird.

Weiß ich auch nicht. Es gibt in dual-lizensierungs Bereich eine menge graue Gegenden. Ich wurde schätzen das es nicht erlaubt ist, aber ich habe noch nicht gehoert das zu einem Problem geleitet hat.

[*] was mit Template Packages ist. Da diese so gesehen keinen Binärcode darstellen, sondern lediglich Quelltext, der durch den Interpreter verarbeitet wird, könnte es da zu Komplikationen kommen, wenn jemand a.) ein Template erweitert, b.) ein Template nutzt, c.) die mitgelieferte Template Bibliothek teilweise eretzt/ganz ersetzt/erweitert?

Wenn Mann das sehr genau sieht, dann ist LGPL ein reines linking License. Es vorzieht keine Anwendung anders als Quellen Distribution oder linking.

Weil das linken kein Problem wenn man interpretiert würde (im Gegensatz zu JIT Kompilation, weil Mann Symbollookup als Linking sehen konnte), gibt ein License nicht mehr Rechten als es nennt. Mann konnte das interpretieren das andere Brauchsweisen untersagt sind. Interpretation inklusive.

[*] wenn 3. zutrifft, gibt es eine kompatible Lizenz/Möglichkeit diese Probleme zu umgehen um FPC/Lazarus Lizenzkompatibilität zu erreichen? (z.B. eine weitere Lizenz, speziell für das Template Package, die Nutzer/Redistributor Änderungen ohne Komplikationen erlauben würde)[/list]

Mann konnte Core mailen, aber in Praxis ist das Problem dass die Copyrights auf FPC Quellen verteilt sind ueber alle Teilnehmer, und Core muss in solche Fall alle Autoren identifizieren und jeder um Erlaubnis beten.
FPC vermisst eine Struktur wie zb GNU wo alle Copyrights an eines Vereins übertragen werden.

Aber weil einige FPC Developer mit JVM bytecode generation tätig ist, konnt mann dass mal auf der fpc-devel Maillist oder so fragen. Aber ich wuerde bevor fuer Jurisprudenz auf dem Web suchen. (also (L)GPL in kombination mit bytecode sprachen Interpreters im Licensing Kontext)

Aber es ist eine interessante Frage.

[af0815]

Für den 'Template Pack' hilft dir vielleicht folgender Link http://de.narkive.com/2006/4/12/1586917-re-gpl-auch-f-r-texte-und-andere-werke.html als Anregung weiter. Ein deutsche Diskussion wo auch einige Lizenzen genannt werden.

[Keifor]

Vorab, die ersten Fragen bezügliche Module (VM/Compiler war gemeint) haben sich soweit geklärt. Ich habe die GPL, FAQ und diverse FAQs anderer Projekte "studiert" und im Endeffekt scheint das jeder im (im konkreten) anders zu interpretieren. Die einen sind der Meinung, es ginge lediglich um die kollektive Distribution, die anderen bezeichnen bereits das Nutzen (im Code) des Interfaces als Randfall.

Ich habe mich jetzt für die GPLv2 entschlossen, soweit für das Hauptprogramm.
Die LGPL sollte lediglich erlauben, das Projekt auch in anderen Programmen zu integrieren. Allerdings gibt es dafür auch andere Möglichkeiten wie viele Interpreter es zeigen (z.B. command line interface). (und auch viel ausgereifte Software, wie das oft genutzte LUA)
Die Modulfrage ist einer dieser Randfälle. So lange sie nicht teil der Distribution sind, gibt es im Regelfall auch keine Probleme. Weiterhin ist dies ein Problem mit dem sich dann derjenige Distributor befassen muss.
Das sollte soweit alles geklärt sein.

Der Bytecode Fall is schwieriger. (sie auch mehr nach unten). Der LGPL sieht es nicht vor, und weil es nur "linking" unschreibt, konnte es mehrere Interpretationen geben. Teilweise auch konnte der Situation unterschiedlich sein fuer
Interpretation und JIT.

...

Wenn Mann das sehr genau sieht, dann ist LGPL ein reines linking License. Es vorzieht keine Anwendung anders als Quellen Distribution oder linking.

Weil das linken kein Problem wenn man interpretiert würde (im Gegensatz zu JIT Kompilation, weil Mann Symbollookup als Linking sehen konnte), gibt ein License nicht mehr Rechten als es nennt. Mann konnte das interpretieren das andere Brauchsweisen untersagt sind. Interpretation inklusive.

Das sollte dann soweit kein Problem sein. Danke dennoch im speziellem, das man JIT als Linken sehen könnte hätte ich jetzt so nicht gedacht. Es handelt sich (derzeit) nur um Interpretieren. JIT oder Optimierungs- bedingtes Linken könnte eventuelle kommen, in ferner Zukunft aber sind in keiner Weise geplant. Ursprünglich war es geplant, viel Funktionalität als "Units/Module/.." mit zu liefern, daher auch die Frage. Allerdings werde ich mich wohl darauf beschränken, die Kernfunktionalität in die VM zu integrieren. (Unter anderem auch daher, weil das Laden einer Template Library, z.B. für multiple Templates einfach zu langsam ist.)

Für den 'Template Pack' hilft dir vielleicht folgender Link http://de.narkive.com/2006/4/12/1586917-re-gpl-auch-f-r-texte-und-andere-werke.html als Anregung weiter. Ein deutsche Diskussion wo auch einige Lizenzen genannt werden.

Danke. Recht informativ, unter anderem der Verweis auf die ifross. Da hab ich mich bereits durchgeackert, speziell zur GPL gibt es recht informative Sachen, wie z.B. die GPL nach Urheberrechtsgesetz und Vertragsrecht interpretiert wird. (und das fand ich verständlicher als die GPL selbst, zumal auch Rechte/Pflichten explizit geklärt und aufgelistet werden)

Interessant ist auch der Punkt wie man auf jegliche Nutzerrechte verzichtet. Ich dächte, das es so etwas im deutschen Recht nicht gibt. Das würde sich wenigstens anbieten . Alles in allem werde ich das Thema Template Packages aber erstmal zurückstellen und klären wenn es soweit ist (und Compiler/VM auch entsprechend damit hantieren können). Eventuell ließe sich alles unwichtige/weitere separat mit entsprechendem Public Domain Zusatz anbieten oder wenn es wirklich aufwendig ist, dann wäre es sicher besser dies unter die GPL (und damit unter den "Schutz" der Source Distribution) zu stellen.

Kurz, ich denke damit sind alle Fragen meinerseits soweit geklärt.

Ich danke den beteiligten, für die Mitarbeit. Wenn man das ganze nochmal durch spricht, resümiert und nach-googled versteht man schon viel mehr als vorher.