GPL und kommerzielle Nutzung ?

radiUS schrieb:
> ich hab eine wissenslücke, es geht um GPL (und ähnlich)  lizenzierte
> Software in Verbindung mit kommerzieller Nutzung der SW.
>
> 1)Ist die kommerzielle Nutzung der SW gestattet, ohne die
> Resultate/Ergebnisse offenlegen zu müssen ?

Die GPL erstreckt sich nur über das Programm und den zugehörigen 
Sourcecode. Dinge die mit Hilfe des jeweiligen Programms erarbeitet 
werden werden davon normalerweise nicht umfasst.

Ggf. muss man etwas genauer hingucken wenn das Ergebnis Bestandteile des 
Programms enthält. Also wie ist das z.B. mit einem Compiler, der in das 
Compilat Code einbindet, der im Lieferumfang des Compilers ist. Das ist 
dann hoffentlich irgendwo in der Doku klargestellt.

> 2)Ich bin neu in der GUI-Programmierung und habe bis hierhin kein
> Hintergrundwissen was ich dafür benötige (Bibliotheken etc.). Wenn ich
> z.B. eine GUI in GTK+ programmiere, besteht dann ein zwang das
> entstandene Programm zu veröffentlichen??

Nein. Du hast immer das Recht, Nichts zu veröffentlichen. Es ist 
vollkommen legitim eine Software zu entwickeln die nur in-house 
verwendet wird. Da kannst Du GPL-Software verwenden soviel Du willst. 
Erst wenn Du das Programm an jemand drittes weitergibst, erwirbt 
derjenige gewisse Rechte Dir gegenüber (z.B. bei der GPL: Anspruch auf 
Sourcecode).

Was GTK+ angeht muss man sich klar machen, dass dieses unter der LGPL 
vertrieben wird, die gegenüber der GPL etwas weniger Bedingungen 
mitbringt. Insbesonders ist es möglich, Closed-Source-Software zu 
entwickeln und zu vertreiben, die GTK+ als Bibliothek verwendet.

Viele Grüße,
        Simon

Konkret: wenn man an der GTK+ selbst Änderungen vornimmt und mit diesen 
Geld verdient, dann muß man diese Änderungen veröffentlichen.
Nicht aber, wenn man die Lib unverändert lässt und nur ein Programm 
draufsetzt.

radiUS schrieb:
> Hallo,
>
> ich hab eine wissenslücke, es geht um GPL (und ähnlich)  lizenzierte
> Software in Verbindung mit kommerzieller Nutzung der SW.
>
> 1)Ist die kommerzielle Nutzung der SW gestattet, ohne die
> Resultate/Ergebnisse offenlegen zu müssen ?

Das kommt darauf an, was du unter Nutzung verstehst.

Wenn du zB ein stück GPL-Software erweiterst und verkaufst,
hat jeder, ver von dir die Binaries bekommt, ein Recht darauf,
von dir auch die Quellen (zum Selbstkostenpreis) zu bekommen.

Insbesondere heisst das, daß du

· Freie Software verkaufen kannst ("Free as in freedom not
  as in free beer ").
· Ein Dritter, die die Binaries nicht (auf rechtmässigem Wege)
  von der bekommen hat, hat kein Anrecht auf die Quellen.

Du kannst Software mit GPL-Software erstellen, zB ein Programm
mit GCC compilieren und dieses Verkaufen oder was auch immer.
Dadurch wird deine eigene Software, die du damit übersetzt, aber
nicht zu GPL-Software.

radiUS schrieb:

> (Nebenbei: Welches der beiden könnte man empfehlen, wenn es darum geht
> die Einarbeitung kurz zu halten und als Ziel-OS Windows gedacht ist?)

GTK unter Windows ist eine Baustelle. QT unter Windows ist stabil.

Wenn Portabilität keine Rolle spielt, nimm die MFC. Das macht Microsoft 
auch. Das scheint in dieser Zeit etwas altmodisch zu sein, ist aber auch 
unter Windows 7 und wahrscheinlich auch Windows 8 immer noch problemlos, 
und Du musst keine riesen Runtime mitliefern.

Ansonsten gibts auch noch wxWidgets. Das gibts auch schon sehr lange 
(>15 Jahre), und es sind auch etliche kommerzielle Programme damit 
entstanden.

QT ist meiner Ansicht nicht das passende für "kurze Einarbeitung".

fchk

Reinhard Kern schrieb:
> Johann L. schrieb:
>> Du kannst Software mit GPL-Software erstellen, zB ein Programm
>> mit GCC compilieren und dieses Verkaufen oder was auch immer.
>> Dadurch wird deine eigene Software, die du damit übersetzt, aber
>> nicht zu GPL-Software.
>
> Dazu muss man aber sagen, dass diese Ansicht stark umstritten ist.
> Thorvalds selbst hat die Meinung geäussert, allein die Tatsache, dass

Mag sein, es gibt diese und jene Ansichten uns Meinungen.
Was zählt, ist was ni der GPL steht.

> ein Programm unter dem Betriebssystem Linux läuft, stellt es bereits
> unter Veröffentlichungszwang. Auch das ist natürlich umstritten.

· Daß ein Progenn mit GCC übersetzt ist, bedeutet nicht, daß es unter
  Linux lauffähig ist.
· GCC läuft auch unter Solaris, HP-UX, MS-Windows, Max OS, ...

Reinhard Kern schrieb:
> Dazu muss man aber sagen, dass diese Ansicht stark umstritten ist.
> Thorvalds selbst hat die Meinung geäussert, allein die Tatsache, dass
> ein Programm unter dem Betriebssystem Linux läuft, stellt es bereits
> unter Veröffentlichungszwang. Auch das ist natürlich umstritten.

Ähbittewas?

Das behauptet ja nichtmal Richard Stallman.

Ist das derselbe Torvalds, der der proprietäre Module im Linux-Kernel 
zulässt?

> If somebody wants to port his SVR4 driver to Linux but doesn't want to
> GPL it, I feel that he should have the right to do that, using modules.
> After all, the driver wasn't actually derived from Linux itself: it's a
> real driver in its own right, so I don't feel that I have the moral right
> to force him to switch copyrights.

(aus http://linuxmafia.com/faq/Kernel/proprietary-kernel-modules.html )

Viele Grüße,
        Simon

Reinhard Kern schrieb:
> The term is most often used to describe the GPL,[1] which requires that
> any derivative work also be licensed with the GPL.
> [...]
> Das ist nun mal das Gegenteil deiner Aussage.

"Derivative work" ist ein abgeleitetes Werk. D.h. Du nimmst das Original 
(oder Teile davon) her und leitest daraus ein Werk ab.

Das ist etwas anderes als ein Programm unter einem Betriebssystem laufen 
zu lassen.

Viele Grüße,
        Simon

Simon Budig schrieb:
> Reinhard Kern schrieb:
>> The term is most often used to describe the GPL,[1] which requires that
>> any derivative work also be licensed with the GPL.
>> [...]
>> Das ist nun mal das Gegenteil deiner Aussage.
>
> "Derivative work" ist ein abgeleitetes Werk. D.h. Du nimmst das Original
> (oder Teile davon) her und leitest daraus ein Werk ab.
>
> Das ist etwas anderes als ein Programm unter einem Betriebssystem laufen
> zu lassen.

Jein.
- Für Programme die eigene Klassen von unter GPL stehenden Klassen 
ableiten und nutzen gilt, "Subclassing is creating a derivative work. 
Therefore, the terms of the GPL affect the whole program where you 
create a subclass of a GPL'ed class." 1)

- Für Programme die LGPL-Libs nutzen gilt: "However, linking a "work 
that uses the Library" with the Library creates an executable that is a 
derivative of the Library" 2) mit der Ausnahme: "If such an object file 
uses only numerical parameters, data structure layouts and accessors, 
and small macros and small inline functions (ten lines or less in 
length), then the use of the object file is unrestricted, regardless of 
whether it is legally a derivative work."

- Für Qt hat Nokia zwei Ausnahmen in die Lizenzen aufgenommen, die diese 
Probleme z.T. vermeiden: Zum einen darf man zur GPL inkompatible 
Lizenzen verwenden und nicht-OSS dagegen linken 3), zum anderen wird 
eine LGPL-Ausnahme vereinbart "As a special exception to the GNU Lesser 
General Public License version 2.1, the object code form of a "work that 
uses the Library" may incorporate material from a header file that is 
part of the Library. You may distribute such object code under terms of 
your choice, provided that the incorporated material (i) does not exceed 
more than 5% of the total size of the Library; and (ii) is limited to 
numerical parameters, data structure layouts, accessors, macros, inline 
functions and templates." 4)

Da man davon ausgehen kann, dass Nokia diese Ausnahmen nicht nur zum 
Spaß macht, heißt das im Umkehrschluss: Wenn andere Libs nicht ähnliche 
Ausnahmen haben, gibt es u.U. Probleme.

1) http://www.gnu.org/licenses/old-licenses/gpl-2.0-faq.html
2) http://www.gnu.org/licenses/lgpl-2.1.html
3) http://doc.qt.nokia.com/4.4/license-gpl-exceptions.html
4) http://doc.qt.nokia.com/latest/lgpl.html

> Viele Grüße,
>         Simon

Arc Net schrieb:
> Simon Budig schrieb:
>> Reinhard Kern schrieb:
>>> The term is most often used to describe the GPL,[1] which requires that
>>> any derivative work also be licensed with the GPL.
>>> [...]
>>> Das ist nun mal das Gegenteil deiner Aussage.
>>
>> "Derivative work" ist ein abgeleitetes Werk. D.h. Du nimmst das Original
>> (oder Teile davon) her und leitest daraus ein Werk ab.
>>
>> Das ist etwas anderes als ein Programm unter einem Betriebssystem laufen
>> zu lassen.
>
> Jein.

Achtung, ich habe hier gegen Reinhards etwas hanebüchene Auffassung 
argumentiert, dass bereits das Starten eines Programms unter einem 
Linux-Kernel dieses Programm viral unter die GPL stellen würde. Da ist 
allgemein akzeptierte Auffassung, dass das nicht der Fall ist und ich 
bin mir sicher, dass - wenn das so wäre - Linux im kommerziellen Umfeld 
keine Schnitte hätte.

Du hingegen betrachtest, ab wann das Linken gegen eine Library eine 
"derivative work" herstellt, und da ist natürlich die Situation nicht so 
einfach, das ist richtig. Insbesonders wenn die Library unter der GPL 
steht ist man sehr schnell in der Pflicht.

Bei der LGPL hingegen ("Lesser GPL") gibt es die von Dir zitierte 
Regelung, die es ermöglicht die LGPL-Library in proprietären 
Applikationen zu nutzen.

Die Ausnahmeregelung bei QT klingt mir der LGPL-Ausnahme sehr ähnlich, 
d.h. die wollten das vermutlich nur klarstellen. Bei QT hat es ja auch 
in der Vergangenheit mehrere Lizenzmodelländerungen gegeben, von daher 
müssen sie etwas expliziter sein, was sie eigentlich meinen...  :-)

Viele Grüße,
        Simon

Martin schrieb im Beitrag #2293791:
> Arc Net schrieb:
>> Jein.
>
> Das war viel Text, der aber nichts mit den beiden Fragen zu tun hat,
> auf die du dich bezogen hast.
>
> Nämlich "ist der Output eines GPL-Programms dann auch GPL" (Antwort:
> Nein)

Jein, s. die FAQs. Nämlich nur dann, wenn das entsprechend in der Lizenz 
angegeben ist bzw. wenn es nur eine Transformation ist ohne das etwas 
hinzugefügt wird. Wird etwas hinzugefügt ist das Ergebnis ein 
abgeleitetes Werk:
"Some programs copy parts of themselves into the output for technical 
reasons—for example, Bison copies a standard parser program into its 
output file. In such cases, the copied text in the output is covered by 
the same license that covers it in the source code. Meanwhile, the part 
of the output which is derived from the program's input inherits the 
copyright status of the input."
http://www.gnu.org/licenses/gpl-faq.html#CanIUseGPLToolsForNF

> und "müssen Programme, die unter GPL-OSen laufen, auch GPL sein"
> (Antwort: Nein)

Genau das ist aber u.U. problematisch: Welches Programm nutzt/linkt denn 
keine Bibliotheken, sondern nur die Kernel Traps?

Arc Net schrieb:
>> und "müssen Programme, die unter GPL-OSen laufen, auch GPL sein"
>> (Antwort: Nein)
>
> Genau das ist aber u.U. problematisch: Welches Programm nutzt/linkt denn
> keine Bibliotheken, sondern nur die Kernel Traps?

Der Kernel schreibt dir aber keine bestimmte (z.B.) libc vor (und da 
gibt es ja durchaus Alternativen).

Die Lizenz der libc ist hier relevant (für die glibc: LGPL), die des 
Kernels aber nicht.

Viele Grüße,
        Simon

Arc Net schrieb:

> "Some programs copy parts of themselves into the output for technical
> reasons—for example, Bison copies a standard parser program into its
> output file. In such cases, the copied text in the output is covered by
> the same license that covers it in the source code. Meanwhile, the part
> of the output which is derived from the program's input inherits the
> copyright status of the input."
> http://www.gnu.org/licenses/gpl-faq.html#CanIUseGPLToolsForNF

(1) Es gibt einen Bison-hairy Zusatz

(2) Was hat das mit GCC tzu tun?

GCC 4.1 (02-2006) Release Notes:

· The old Bison-based C and Objective-C parser has been replaced
  by a new, faster hand-written recursive-descent parser.

Für Ada/C++... wird das eh händisch gemacht da nicht LALR(1).

agp schrieb:
> Woraus besteht denn ein GPL'ed OS im wesentlichen? Doch gemeinhin aus
> einer Ansammlung von Bibliotheken, die widerrum GPL'ed Bibliotheken
> sind, oder etwa nicht?

Je nach Definition des Worts "Betriebssystem". Im engsten Sinne ist das 
nur der Linux-Kernel (der unter der GPL steht), im weitesten Sinne ist 
es das was eine Distribution umfasst, inkl. diverser Utilities und 
Programmen. Letzteres hat aber natürlich keine einheitliche Lizenz mehr.

Von einem "GPL"-Betriebssystem zu sprechen ist bestenfalls irreführend, 
sobald man von mehr als nur dem Kernel spricht. Schon die 
grundlegendsten Libraries (libc) stehen unter anderen Lizenzen (in 
diesem Fall die LGPL).

Viele Grüße,
         Simon

agp schrieb:
> Ich hab jetzt momentan kein Linux OS installiert, aber ich kann mich
> düster daran erinnern, dass man die GPL-Lizenz an irgend einer Stelle
> bei der Installation abzunicken hat oder nicht?

Wär etwas unpraktisch, wo man doch heute schon in jedem zweiten 
Fernseher und Waschmaschinen-Handbuch einen GPL-Ausdruck findet...

Gab da IIRC ein paar auch deutsche Gerichtsentscheide zu: Wenn du mit 
der GPL nicht einverstanden bist, verlierst du schlicht und einfach das 
Recht, die Software zu verwenden (bzw: darauf aufbauende Software zu 
verkaufen).
Vorheriges wegklicken oder Unterschreiben der GPL ist nicht nötig.

agp schrieb:
> Ich hab jetzt momentan kein Linux OS installiert, aber ich kann mich
> düster daran erinnern, dass man die GPL-Lizenz an irgend einer Stelle
> bei der Installation abzunicken hat oder nicht?

Meine Erfahrung ist, dass man - im Gegensatz zu z.B. Windows - 
normalerweise keinen Dialog zum Abnicken präsentiert bekommt, schon gar 
nicht "umfassend" für die ganze Distribution.

Einige Programme ermöglichen es, den Lizenztext über ein Hilfe-Menü 
abzurufen, andere haben gar nichts in der Hinsicht.

Für reine Benutzer ist das auch normalerweise nicht nötig: Die (L)GPL 
hat keine Einschränkungen bzgl. der Nutzung von Programmen (wobei wir 
wieder bei der Ausgangsfrage sind: Die Daten die mit GPL-Programmen 
verarbeitet werden sind in keiner Form von der Lizenz betroffen). Die 
Einschränkungen kommen erst dann zum Tragen, wenn man anfängt, mit dem 
Sourcecode (und/oder z.B. den Header-Dateien von Libraries) oder den 
Binärdateien des Programms selber zu arbeiten und mit deren Hilfe 
abgeleitete Werke zu schaffen.

Viele Grüße,
        Simon

Reinhard Kern schrieb:
> Rechtssicherheit sieht leider anders aus.

Man kann sich Rechtsunsicherheit auch herbeireden.

Tatsache ist, dass es eine funktionierende Ökonomie auch um quelloffene 
Software herum gibt. Wenn das so ein Vabanque-Spiel wäre wie es 
anscheinend ein paar Spinner behaupten, dann würden da nicht so viele 
Leute mitmischen.

Nochmal ein paar Punkte:

Viele Grüße,
        Simon

... Äh, jetzt.

Reinhard Kern schrieb:
> Ich habe nicht behauptet, dass das so ist oder dass es sinnvoll ist
> (ganz im Gegenteil, aber meine Meinung ist halt nicht massgebend)

Aber die Meinung irgendwelcher ungenannten Open-Source-Ultras ist 
relevant genug, dass Du sie hier weiterpropagierst?

Wenn es tatsächlich eine signifikante Angriffsfläche gäbe, dann wären 
die üblichen Verdächtigen wie Microsoft inzwischen in ihren Lawsuits 
erfolgreicher gewesen...

> Das widerspricht auch klar der weiter oben geäusserten
> Auffassung, nur der Käufer solcher Software hätte ein Recht auf
> Offenlegung.

(nicht nur "Käufer", sondern alle, an die Du das Programm weitergibst. 
Ob Geld fließt oder nicht ist zweitrangig.)

Ansonsten hilft Lesen der GPL:

"Each time you convey a covered work, the recipient automatically 
receives a license from the original licensors, to run, modify and 
propagate that work, subject to this License. You are not responsible 
for enforcing compliance by third parties with this License."

Ich lese das als: Wenn ich jemandem eine von mir modifizierte Version 
einer GPL-Software weitergebe und die Bedingungen der GPL erfülle, dann 
bin ich nicht dafür zuständig, wenn derjenige die Software dritten 
weitergibt und diesen gegenüber aber die GPL-Bedingungen nicht 
einhält. Insbesonders bin ich nicht verpflichtet, ihnen den Sourcecode 
bereitzustellen.

Viele Grüße,
        Simon

Peter Stegemann schrieb:
> Jasch schrieb:
>
>> "Derivative Work" ist eine legale Definition aus dem Urheberrecht.
>
> Und die Definition kann man wo nachlesen?

Z.B. in der GPL (jetzt mal v2, weil es um den Linux-Kernel geht), wobei 
die allerdings auf das (US) Copyright-System bezug nimmt:

"a "work based on the Program" means either the Program or any 
derivative work under copyright law: that is to say, a work containing 
the Program or a portion of it, either verbatim or with modifications 
and/or translated into another language."

>> Ein unter Linux ausführbares Programm ist schon überhaupt kein von Linux
>> abgeleitetes Werk.
>
> Hat das schon mal ein Gericht bestaetigt?

Dazu müsste man in der GPL erstmal eine Formulierung finden, die eine 
Klage rechtfertigt. Ich bin kein Rechtsexperte und weiß nicht, wie 
flexibel man bei der Interpretation des Texts sein kann, aber ich finde 
nix.

Ausgehend von obiger Definition sehe ich keinen Ansatzpunkt, wo ein 
Programm Bestandteile des Linux-Kernels enthält. Ganz im Gegenteil: Es 
ist ja genau die Kernfunktion eines Kernels, einen Abstraktionslayer 
bereitzustellen und eine Trennung zwischen Kernel-Space und User-Space 
herzustellen.

Es wird etwas komplizierter, wenn man Header-Files vom Linux-Kernel 
verwendet, da bin ich nicht sicher, was die Implikationen sind. Da das 
allerdings optional ist, kann das nicht alle Programme betreffen.

Viele Grüße,
        Simon

Simon Budig schrieb:
> Es wird etwas komplizierter, wenn man Header-Files vom Linux-Kernel
> verwendet, da bin ich nicht sicher, was die Implikationen sind. Da das
> allerdings optional ist, kann das nicht alle Programme betreffen.

Gerade gefunden: Zumindest Linus scheint der Auffassung zu sein, dass 
die Verwendung der Header-Files keine "GPL-Infektion" zur Folge hat:

http://www.heise.de/open/meldung/Linus-Torvalds-Android-verstoesst-nicht-gegen-die-GPL-1212177.html

Der dort angesprochene Abschnitt in dem COPYING-File ist folgender:

>   NOTE! This copyright does not cover user programs that use kernel
> services by normal system calls - this is merely considered normal use
> of the kernel, and does not fall under the heading of "derived work".

Die Intention ist damit zumindest schonmal klar. Was Anwälte draus 
machen steht natürlich nochmal auf einem anderen Blatt.

In dem Originalartikel zur Meldung von heise werden dann die Headerfiles 
nochmal explizit angesprochen. Linus wird zitiert mit:

> The kernel headers contain various definitions for the interfaces to
> user space, and we even actively try to make sure that the headers can
> be used by user space (and try to mark which of the headers are expected
> to be usable in such a way). Exactly because we know user space needs
> those details in order to interact with the kernel.

Viele Grüße,
        Simon

Peter Stegemann schrieb:
> Simon Budig schrieb:
>> "a "work based on the Program" means either the Program or any
>> derivative work under copyright law: that is to say, a work containing
>> the Program or a portion of it, either verbatim or with modifications
>> and/or translated into another language."
>
> So wie das da steht, waere auch eine Distribution "derivative work". Sie
> enthalt ja das Programm das (oder besser: Programme die) unter GPL steht
> (stehen). Mit der Konsequenz, dass auch die Distribution als Ganzes
> unter GPL stehen muesste.

Ich darf nochmal die GPL v2 zitieren (nu lies sie doch mal!):

"If identifiable sections of that work are not derived from the Program, 
and can be reasonably considered independent and separate works in 
themselves, then this License, and its terms, do not apply to those 
sections when you distribute them as separate works."
[...]
"In addition, mere aggregation of another work not based on the Program 
with the Program (or with a work based on the Program) on a volume of a 
storage or distribution medium does not bring the other work under the 
scope of this License."

>> Ausgehend von obiger Definition sehe ich keinen Ansatzpunkt, wo ein
>> Programm Bestandteile des Linux-Kernels enthält.
>
> Wenn ich gegen eine Bibliothek linke, enthaelt man Programm auch keine
> Bestandteile dieser Bibliothek. Dennoch wird das allgemein als
> "derivative work" betrachtet und deswegen wurde die LGPL geschaffen.

Natürlich enthält das Programm Bestandteile der Bibliothek: Der Code der 
Library wird beim Start des Programms in den Adressraum des Programms 
eingebunden. Nicht so beim Kernel.

Viele Grüße,
        Simon

Peter Stegemann schrieb:
> Er verwies ja auf das Urheberrecht, also dachte ich, er weiss wo das
> dort steht. Anscheinend leider nicht. Bleibt also nur die von dir
> zitierte Definition aus der GPL selbst:

17 US Code § 101
"A “derivative work” is a work based upon one or more preexisting works, 
such as a translation, musical arrangement, dramatization, 
fictionalization, motion picture version, sound recording, art 
reproduction, abridgment, condensation, or any other form in which a 
work may be recast, transformed, or adapted. A work consisting of 
editorial revisions, annotations, elaborations, or other modifications 
which, as a whole, represent an original work of authorship, is a 
“derivative work”." 1)
Ähnlich auch im 69c UrhG: Zustimmungsbedürftige Handlungen
"die Übersetzung, die Bearbeitung, das Arrangement und andere 
Umarbeitungen eines Computerprogramms sowie die Vervielfältigung der 
erzielten Ergebnisse..."

1) http://www.copyright.gov/title17/92chap1.html
2) http://www.gesetze-im-internet.de/urhg/__69c.html

> Headerfiles muss man nie verwenden, im Zweifelsfall kann man die neu
> schreiben. Das macht in einigen Laendern einen grossen Unterschied, in
> anderen nicht.

Siehe die Diskussion über das Vorgehen Googles bei Android (Bionic, 
Headerfiles)
http://fosspatents.blogspot.com/2011/03/googles-android-faces-serious-linux.html
(abschließend geklärt wurde das afaik noch nicht)
http://www.zdnet.com/blog/burnette/patrick-brady-dissects-android/584
"License: they wanted to keep GPL out of user-space. Bionic code uses 
the BSD license."

Jasch schrieb:
> Merke: es geht prinzipiell um (auch partielle) Kopien von Werken und
> einige verwandte Rechte. Weder das Lesen eines Werkes, Ausführen eines
> Programmes unter einem OS, Verarbeiten von Daten durch ein Programm oder
> literaturwissenschaftliche Analyse eines Werkes fallen überhaupt unter
> Urheberrecht/Copyright.

Sie fallen in DE z.T. unter das Urheberrecht. Siehe 69c, d UrhG
genauer gesagt, man könnte einen Teil dieser Handlungen vertraglich 
zustimmungsbedürftig machen.

Peter Stegemann schrieb:
> Simon Budig schrieb:
> Ich habe sie schon oft gelesen. Anderen Leuten zu unterstellen, sie
> haetten die  Quellenarbeit nicht gemacht, nur weil sie eine andere
> Interpretation dieser haben, ist einfach nur unhoeflich.

Sorry, wenn das als Affront angekommen ist. Ich hatte nur den Eindruck, 
dass Du genau die Teile der GPL nicht kennst, die genau über Aggregation 
sprechen (was IMHO die Kernaufgabe einer Distribution ist).

In meinen Augen stellt die GPL v2 in weiten Teilen sehr klar und 
deutlich dar, wie sie verstanden werden möchte. In anderen Teilen ist 
sie weniger deutlich, aber es ist für mich ziemlich klar, dass sie nicht 
beansprucht, dass alles, was irgendwie in Kontakt mit einem GPL-Programm 
kommt, selber GPL wird. Die Zitate die ich gebracht habe, bringen diese 
Intention auf den Punkt. Mir ist völlig klar, dass Rechtsanwälte das 
völlig auf den Kopf drehen können und solange Worte klauben, bis von der 
Intention nix mehr übrig ist, aber das ist nicht das Niveau auf dem ich 
argumentieren möchte (oder überhaupt kann).

Das Problem was ich mit dieser Diskussion habe ist, dass die GPL seit 
Jahrzehnten eingesetzt wird und eigentlich ganz gut funktioniert. 
Trotzdem kommen immer wieder Leute die behaupten, sie sei gefährlich, 
wäre antikommerziell, unverständlich oder was auch immer, aber Belege 
für diese Behauptungen unterbleiben. Stattdessen wird einfach nur 
Zweifel gesät und Stimmung gemacht.

Das ist wie "Evolution ist auch nur eine Theorie!"

>> "If identifiable sections of that work are not derived from the Program,
>> and can be reasonably considered independent and separate works in
>> themselves, then this License, and its terms, do not apply to those
>> sections when you distribute them as separate works."
>
> Verstehst du nicht, wie viel Interpretationsspielraum dies offen laesst?
>
>> [...]
>> "In addition, mere aggregation of another work not based on the Program
>> with the Program (or with a work based on the Program) on a volume of a
>> storage or distribution medium does not bring the other work under the
>> scope of this License."
>
> Nehmen wir also nochmal das Beispiel der Distribution. Die
> Distributionen die ich kenne, sind nicht einfach nur Sammlungen, sondern
> eigene Werke, die auf den enthaltenen Komponenten basieren.

Was ist deine Arbeitshypothese? Dass alle Distributionen automatisch mit 
allen enthaltenen Komponenten unter die GPL fallen, weil sie z.B. einen 
Linux-Kernel enthalten?

Deine Definition von "Derivative Work" ist offensichtlich eine deutlich 
breitere als die von mir und der, die meiner Auffassung nach in der 
Free-Software-Community vorherrscht. Ich glaube nicht, dass eine 
Distribution als "das eine Werk" aufgefasst werden kann, für das genau 
eine Lizenz gilt. Es gibt verschiedene Komponenten unter verschiedenen 
Lizenzen, die auch als solche behandelt werden. Wo da das Problem ist, 
verstehe ich nicht. Eine Distribution (oder die Software auf einem NAS) 
ist in meinen Augen ganz klar kein von jeder ihrer Komponenten 
abgeleitetes Werk.

> Wie sieht deine Interpretation aus, wenn ich mein Programm nicht gegen
> die Bibliothek linke, sondern die Bibliothek nachlade und verwende?

Das Nachladen (per dlopen()) einer GPL-Bibliothek durch ein proprietär 
lizensiertes Programm wird AFAIK üblicherweise auch als eine Verletzung 
der GPL gewertet. Auch hier ist die Richtschnur letztlich das, was sich 
beim Programmablauf im Adressraum des Programms befindet.

Ich kann und will jetzt nicht anfangen zu diskutieren, ob bereits das 
Linken eines Executable-files gegen eine GPL-Library und das 
darauffolgende Vertreiben eine GPL-Verletzung darstellt, oder ob man 
sich auf den Standpunkt stellen kann "Hey, das sind doch nur alle meine 
Nutzer, die die GPL-Verletzung durch den Programmstart begehen".

Der Programmhersteller vertreibt sein Programm damit es benutzt wird 
(und damit die GPL-Library in den Adressraum des Programms eingebunden 
werden muss). Insofern ist er da in meinen Augen zumindest moralisch in 
der Pflicht, sich selbst korrekt zu verhalten und einfach nicht gegen 
GPL-Lizenzen zu linken, wenn er sein Programm nicht unter die GPL 
stellen möchte.

Der Kernel stellt seine Funktionalität hier bewusst über einen anderen 
Mechanismus bereit und die Maintainer haben wiederholt klar gemacht, wie 
sie das verstanden wissen wollen. Insofern sehe ich keine Verletzung der 
GPL, wenn man sein proprietäres Programm unter Linux laufen lässt.

Viele Grüße,
        Simon

Peter Stegemann schrieb:
> Simon Budig schrieb:
>> Was ist deine Arbeitshypothese? Dass alle Distributionen automatisch mit
>> allen enthaltenen Komponenten unter die GPL fallen, weil sie z.B. einen
>> Linux-Kernel enthalten?
>
> Das ist eine moegliche Interpretation und ich moechte sagen, eine der
> interessantesten.

Hm, ich halte sie eher für eine der abwegigsten, aber nun gut  :)

Das Problem was ich gerade habe ist, dass mir zumindest bewusst noch 
keine Distribution untergekommen ist, die in irgendeiner Form eine 
proprietäre Lizenz für die Zusammenstellung für sich in Anspruch nimmt 
oder überhaupt eine Lizenz "über das gesamte Pakete" versucht zu 
vereinbaren. Von vielen Distributionen gibt es durchaus mehr oder 
weniger von der Community vorangetriebene Varianten und das scheint kein 
Problem zu sein.

Insofern ist das eher ein hypothetisches Problem.

> Das Problem ist die seltsame Trennung, die aus der gaengigen
> Interpretation der GPL erfolgt. Sie stellt Software, die kompiliert und
> in Binaerform ausgeliefert wird auf eine Seite, den Rest wie Skripte
> aber auch Hardware auf die andere Seite.

Woraus leitest Du das denn jetzt ab? Ich habe durchaus schon 
Shell-skripte gesehen, die unter der GPL stehen. Ich sehe nix, was daran 
großartig anders sein sollte. Ok, das dynamische Linken ist nicht so ein 
akutes Problem, aber in leichter Variante ist ja schon spannend, dass 
das Skript durch einen unter der GPL stehenden Interpreter ausgeführt 
wird (aber das ist ja genau die Daten-Verarbeitungs-Geschichte, die das 
Ausgansposting thematisiert hatte).

> Kurz gesagt: Der klassische
> Softwareentwickler hat in dieser Geschichte die Arschkarte, er muss
> praktisch seine ganze Arbeit unter die GPL stellen, waehrend Jemand der
> zum Beispiel ein Geraet baut, den groessten Teil seines Werkes nach
> Belieben schuetzen kann.

Ich kann Dir gerade nicht folgen. Wieso kann ein Hardware-Entwickler 
mehr "schützen" als der Software-Entwickler? Wenn er ein 
Embedded-Linux-Gerät baut und darauf GPL-Software läuft, dann vertreibt 
er diese mit dem Verkauf des Geräts und er unterliegt den entsprechenden 
Bedingungen der GPL. Das ist noch nicht bei allen Hardware-Herstellern 
angekommen und entsprechend gibt es da sehr aktive Menschen die das mit 
Nachdruck erklären, aber prinzipiell ist die Situation die gleiche.

Der klassische Softwareentwickler kann selber entscheiden, ob er eine 
GPL-basierte Library verwendet oder nicht. Ggf. muss er halt mehr selber 
machen als ihm lieb ist, aber das ist genau der Preis den er dafür 
zahlt, dass er kein Teil der Free-Software-Community sein möchte.

> Wir sind uns aber schon darueber einig, dass das nun eine sehr freie
> Interpretation ist? Die GPL spricht nirgends von solchen technischen
> Details. Solche Dinge findet man nur in Stallmans Anmerkungen zur GPL.

Die Auffassungen die ich hier vertrete (was das dynamische Linken 
und/oder Verwenden von Kernel-Funktionalität angeht) habe ich mir ja 
nicht selber aus der GPL herbeifantasiert, sondern das sind allgemein 
anerkannte Interpretationsstandards über die sich fast alle einig sind 
und über die garantiert auch schon massiv Jura-Arbeiten geschrieben 
wurden.

> Das ist ein Punkt, auf den ich hinweisen will - sehr viel von dem, was
> der GPL zugeschrieben wird, steht gar nicht in selbiger, sondern in der,
> nennen wir sie mal so - "begleitetenden Literatur".

Aber das ist immer so. Jeder Gesetzestext lässt einen riesigen Spielraum 
der erst durch die Gerichte mit Leben gefüllt wird, teilweise auch mit 
unerwarteten Konsequenzen. Die GPL ist nun zwar kein Gesetz aber die 
Situation ist erstmal grundlegend die gleiche.

> [...] Wer behauptet, dies sei kein Problem, hat
> sich nicht ernsthaft und objektiv mit der GPL beschaeftigt.

Ich sehe ja durchaus ein, dass es gerade für Jura-Laien wie uns durchaus 
problematisch ist, diese Sprache zu interpretieren und das Gefühl zu 
bekommen, dass man verstanden hat, was da eigentlich steht. Ich kann Dir 
nicht erklären, aus welchen Worten genau denn nun diese Geschichte mit 
dem dynamischen Linken folgt. Ich verlasse mich da natürlich auf 
Sekundärliteratur. Das Bild was ich daraus bekomme ist aber ein ziemlich 
konsistentes. Und das reicht mir. Wenn ich mehr bräuchte, müsste ich 
einen Rechtsanwalt fragen.

> Die Adressraum-Theorie funktioniert uebrigens schon aus einem ganz
> einfachen Grund nicht: Ich habe als Autor eines Programms keine absolute
> Kontrolle darueber, welcher Lizenz die Module unterliegen, die spaeter
> in den Adressraum meines Programms geladen werden. Ich koennte zum
> Beispiel jederzeit aus GPL-Code Module fuer Photoshop machen. Welche
> rechtlichen Konsequenzen haette dies fuer Photoshop? Keine.

Aber Du als Photoshop-Autor bist ja auch nicht derjenige, der das 
abgeleitete Werk mit dem GPL-Plugin herstellt und vertreibt.

Wenn Du als Plugin-Autor GPL-Code hernimmst, den mit proprietärem 
Photoshop-API vermengst und das Resultat vertreibst, dann verletzt Du 
vermutlich die GPL und vielleicht sogar die Bedingungen zu denen Du die 
Photoshop-API verwenden darfst. Aber das ist Dein Problem, nicht das der 
Photoshop-Autoren.

Wir haben übrigens bei GIMP lange überlegt, wie wir proprietäre Plugins 
handhaben wollen: Einerseits wollen wir auf den GPL-Schutz für den 
Gimp-Sourcecode nicht verzichten, andererseits wollten wir proprietäre 
Plugins ermöglichen.

Konsequenterweise laufen die Plugins in eigenen Prozessen und 
kommunizieren über ein IPC-Protokoll mit dem GIMP-GPL-Core, Bilddaten 
werden per shared memory ausgetauscht. Es gibt eine Convenience-Library 
die etwas wrapper-code um das IPC-Protokoll drumrumbaut (die libgimp) 
und die Verwendung erleichtert. Diese Bibliothek ist dann nicht mehr 
GPL, sondern LGPL. Damit sind - zumindest nach unserer Interpretation - 
proprietäre Plugins möglich.

Auch wir haben in unserem Source eine explizite Klärung dieses 
Sachverhalts, einfach weil wir klarstellen möchten, wie wir die GPL in 
dieser Hinsicht interpretieren. Dass diese Klarstellung gefühlt nötig 
ist, ist natürlich ein Defizit der GPL. Letztlich war das wohl auch eine 
der Motivationen für die GPL v3, wobei ich aber auch sagen muss, dass 
ich mich mit der noch nicht in dem letzten Detail auseinandergesetzt 
habe.

Abschließend (ich bin jetzt erstmal für eine Woche in einem 
Nerd-Alternativuniversum bei Finowfurt...) möchte ich noch sagen, dass 
ich der festen Überzeugung bin, dass wenn die GPL so virulent wäre wie 
von Dir vermutet, dies schon lange von Gegnern des 
Free-Software-Ökosystems sehr effektiv genutzt worden wäre um den 
Konkurrenten "Linux" kleinzureden und zu -halten. Dann hätte z.B. 
Microsoft Anstrengungen unternommen um Sourcecode von proprietärer 
Software freizupressen, nur um ein Exempel zu statuieren, dass man für 
proprietäre Software eben Windows braucht.

Und Firmen wie IBM, die über eine geradezu legendäre Rechtsabteilung 
verfügen, hätten nie die Fühler in Richtung Linux ausgestreckt.

Viele Grüße,
        Simon