GPL vs. JuSchG/USK

[gpl-knight]

1. Kann ich ein Spiel unter der GPL veröffentlichen, wenn es erst ab 18 Jahren ist?
1.1 Die GPL schreibt ja vor dass der Quellcode jedem verfügbar gemacht werden muss, auch für Kids?!

2. Oder mit einem ab-18-Patch (der kann ja wie in 1.1 geschrieben nicht unter der GPL stehen)- oder ist es erlaubt den Patch unter einer anderen Lizenz zu veröffentlichen?!

Gruß
Robert

[Flightbase]

GPL kann aber auch heissen: dem Kunden den Quellcode geben.

wenn du das programm allen zur verfügung stellst, mußt du auch allen den quelltext geben. wenn das game selbst indiziert ist, also ab 18 - dann müssen auch die sourcen "ab 18" sein. stellst du also kids den source nicht zur verfügung, brichst du die GPL.

anderer ansatz:

veröffentliche keine binarys.
stell nur den source unter die GPL und gut. quelltext wird nicht indiziert.
kräftig warnhinweise und es sollte für D alles im lot sein.


greets, Nik

um auf der sicheren seite zu stehen, solltest du dich aber an einen echten rechtsverdreher wenden, wenns ernst wird.

[gpl-knight]

und wie sieht es mit der LGPL aus?

Robert

[foerbyratte]

Hast du/Habe sie denn schon ein Spiel fertig? gibt es Screenshots/Links/Beschreibung?

[GrafKoks]

1. JA

1.1. Das schreibt die GPL - wie Flightbase schon sagte - _nicht_ vor. Die GPL schreibt nur vor, dass Du dem Binary auch die Sourcen beilegen musst (bzw. Sourcen irgendwie "verfügbar machen" für den Kunden). Da nun das Binary aber nur 18+-Leute erwerben können, kommen die Kids auch nicht an den Sourcecode. Wenn irgendein Kunde das Spiel kauft und nem Kid kopiert (das kopieren an sich ist wegen der GPL ja legal) so macht sich Dein Kunde damit strafbar, Du aber nicht (der Hersteller wird ja auch nicht belangt, wenn ein Händler einem Minderjährigen ein ab-18-Game verkauft).

2. Blödsinn (s.o., Problem existiert so nicht)

3. Mit der LGPL sieht es genauso aus. Bloss könnten hier auch andere sich die Sourcen schnappen, ggf. modifizieren und als Binary-only-Version verkaufen. Hat aber alles keinen Einfluss auf die Altersfreigabe.

[PrakashKC]

Das mit der LGPL stimmt nicht. Man muß zu den bins genauso die sourcen zugänglich machen. Der Unterschied ist, daß ein binary-only Prog LGPL Komponenten nutzen darf. Bei GPL wäre dies nicht erlaubt - außer die binary only wäre keine derived work.

Beispiele:

Lame.dll ist LGPL, also dürfen Prgramme wie HeadAC3he, BeSweet diese benutzen, obwohl diese closed-source sind und mehr oder weniger Nutzen aus Lame ziehen und nicht umgekehrt ("derived work").

Lame.exe ist (oder mittlerwiele nicht mehr?) GPL, also müssen alle abgeleiteten Projekte quell offen sein. Eine GUI aber muß es nicht sein, da es kein "derived work" ist, bzw Lame eher den Nutzen aus der GUI zieht.

Der Linux kernel ist GPL, trotzdem darf es binary-only Module geben, da diese ebenfalls dem kernel nutzen und nicht umgekehrt. Es ist keine abgeleitete Arbeit sondern ein Hinzufügen eines features. Umgekehrt, wenn man Sachen im kernel selbst verändern wollte, müßte man diese auch öffnen, weil man den kernel für seine Änderung benutzt.

Der Vergleich mit dem "nutzen ziehen" steht so nicht in den Lizenzen drin, aber anhand dessen kann man sich sehr schön erklären, was erlaubt ist und was nicht. Für den genauen Wortlaut sollte man schon die entsprechenden Lizenzen lesen.

Kompliziert?

[GrafKoks]

Hast natürlich recht - ich bin davon ausgegangen, dass das Produkt die LGPL'ed-Programmteile statisch einbindet und dann selber nicht offen ist. Ein mitliefern des LGPL'ed-Ursprungscodes sollte ja kein Problem sein, erweitern braucht man auch nicht die ursprüngliche Lib sondern nur das closed source Produkt... Es gibt schon Gründe, warum http://www.gnu.org/licenses/why-not-lgpl.html existiert.

Der Linux kernel ist GPL, trotzdem darf es binary-only Module geben, da diese ebenfalls dem kernel nutzen und nicht umgekehrt.

Schwieriges Thema.
Ich bin kein Rechtsexperte, aber ich denke, die meisten Kernel-Module verletzen eigentlich die GPL (sie nutzen z.B. oft die Kernelheader, welcher unter der GPL stehen). Aber man muss hier wohl von Fall zu Fall genauer unterscheiden.

http://www.kernelnewbies.org/kernels...OPYING.modules
http://www.gnu.org/licenses/gpl-faq.html#GPLAndPlugins


Ändert aber alles nichts an der Tatsache, dass die GPL / LGPL sich nicht mit dem Jugendschutzgesetz beisst.

[PrakashKC]

Naja header sind mehr oder minder ein interface, und insofern darfst du ja auch den lame header in dein closed source Programm einbinden, auch wenn es Teil eines LGPL Progs ist. (Wäre sonst etwas müßig die dll einzubinden.)

Bezüglich der Module gab es vor einigen Wochen einen größere Diskussion auf der lkml. Linux selbst meinte, daß Module an sich binary-only sein dürften.

Was die ursprüngliche Frage angeht, das stimmt natürlich.

[GrafKoks]

Original geschrieben von PrakashKC
Naja header sind mehr oder minder ein interface, und insofern darfst du ja auch den lame header in dein closed source Programm einbinden, auch wenn es Teil eines LGPL Progs ist. (Wäre sonst etwas müßig die dll einzubinden.)

Der Kernel ist GPL'ed, nicht LGPL'ed... von daher können die Header _nicht_ für closed-Source-Module genutzt werden.
Zitat von: http://kerneltrap.org/node/view/1735/5291

BUT YOU CAN NOT USE THE KERNEL HEADER FILES TO CREATE NON-GPL'D BINARIES.

Comprende?

Linus.

Bezüglich der Module gab es vor einigen Wochen einen größere Diskussion auf der lkml. Linux selbst meinte, daß Module an sich binary-only sein dürften.

Linus, nicht Linux
Wahrscheinlich meintest Du die Diskussion, die ich gerade oben verlinkt habe, oder? In selbiger wird jedenfalls deutlich, dass sich Hersteller von closed-Source-Modulen ziemlich schnell auf's juristische Glatteis begeben können - einmal die Header verlinkt, schon hat man den Copyright-Verstoß.

[PrakashKC]

Ja, du hast recht, ich habe die Diskussion irgendwann nicht mehr verfolgt, wurde doch etwas länglich.

[City][Sepp]

Um aufs Thema zurückzukommen: Das Jugendschutzgesetz gilt definitiv nicht für Spiele, die ausschliesslich zum Download angeboten werden (sieh RtCW: ET).

Mehr kann man dazu nicht sagen