[linux-l] GPL ist nicht Public Domain

[Volker Grabsch]

On Sat, Nov 18, 2006 at 01:52:55PM +0100, Steffen Dettmer wrote:
> * Volker Grabsch wrote on Sat, Nov 18, 2006 at 12:48 +0100:
> > LGPL heißt, dass ich mir erstmal ein komplexes Regelwerk zu Gemüte
> > führen muss. Ich muss aufpassen, ob ich die Bibliothek korrekt erwähnt
> > habe, ob der Kunde an die Lib rankommt (was ihn wahrscheinlich nicht die
> > Bohne interessiert), u.s.w.
> 
> Wenn dem so ist, kannst Du über Deinen Softwarevertrage garantieren,
> dass auf Verlangen die verwendeten LGPL Sourcen bereitgestellt werden.

Das gilt vorallem dann, wenn die Software ohnehin auf einem
Linux-Rechner beim Kunden läuft, wo die entsprechende Bibliotheken drauf
sind und er schon über die Linux-Distribution an die Quellen rankommt.

Okay, das gilt nicht für meine Modifikationen, aber da in meinem
Beispiel der Autor die schon hat, werden sie ohnehin in die nächsten
Versionen der Distro einfließen.

Vorweg: Wiegesagt, das "ich" ist hier hypothetisch, ich versuche mich
nur in die Lage einiger meiner Auftraggeber hinein zu verstzen, die
propritäre Software direkt nach Kundenwunsch entwickeln.

> Dann schickst Du ne Mail mit einem .tgz. Weil das den Kunden natürlich
> nicht interessiert, wirst Du diese Mail vermutlich nie schicken müssen.

ACK. Aber mit diesem einen Satz im Vertrag ist das noch lange nicht
getan, oder?

> Selbst wenn Du die Lib statisch linkst,

Noch sone Sache. Ich könnte dem Kunden ein einziges Binary schicken,
das sofort läuft ohne dass er was installieren muss. Unter Linux
vielleicht nicht sooo wünschenswert, aber z.B. eine statisch gelinkte
*.exe unter Windows hat ne Menge Vorzüge. Das betrifft dann auch die
Benutzerfreundlichkeit als Ganzes, wenn ich dem Kunden die sog.
"DDL-Hölle" erspare.

> musst Du ja, da der Kunde die
> Lib austauschen dürfen muss, das Recht zugestehen, eine eigene Version
> zu benutzen. Auch dass kannst Du einfach garantieren: auf Verlangen
> werden vom Kunden gelieferte Object-Files gelinkt. Damit ist das Recht
> des Kunden gewahrt. Würde Arbeit machen, falls der Kunde tatsächlich mal
> mit Object files kommt, aber wenn ihn das gar nicht interessiert, wird's
> halt nicht dazu kommen, und wieder ist alles fein.

Unnötiges Risiko. Kein vernünftiger Mensch würde sowas in seine Verträge
schreiben. Da wäre es ja einfacher, dem Kunden zusätzlich ein dynamisch
gelinktes Binary zu geben.

> Des weiteren geht bei LGPL folgendes: Du nimmst die Lib, passt sie an,
> veröffentlichst Sie (mail an Autor, Homepage, irgendwas). Dann legst Du
> diese zu Deiner Applikation bei. Kannste ja machen, darfst ja LGPL-libs
> benuzten, die Du Dir "selbst" lizensierst.

Das wäre wohl das einfachste. Dann hat formal gesehen der Kunde dafür
Sorge zu tragen, die benötigte Lib zu holen und zu installieren.

> Solange Du es sinnvoll machst, kann ich mir auch kaum vorstellen, dass
> die FSF oder wer auch immer Dich teuer abmahnt.

Darum ging es mir nicht. Es ging mir darum, dass ich als "unbedarfter
Programmierer" mich mit solchen Sachen erstmal herumschlagen muss, statt
wie bei BSD/MIT/PublicDomain einfach selbst zu entscheiden, in welcher
Form ich etwas der Community zurückgebe.

Bei BSD/MIT ist nach kurzem Lesen klar, was ich darf und was nicht.
Bei GPL/LGPL nicht. Diese Hürde ist nicht technischer Natur, sondern
sie besteht IMHO darin, dass ein komplexes Regelwerk demotiviert, ein
einfaches hingegen motiviert.

> Maximal könnte ich mir
> vorstellen, dass ein Autor Dich bittet, dies und das ins README
> aufzunehmen oder so.

Wieso? Der Autor kriegt mein Produkt nie zu Gesicht. Das war nur für
den Kunden bestimmt. Die README, oder allgemein das Benutzerhandbuch,
ist eine kritische Sache. Als Firma könnte ich es mir nicht leisten,
mir von irgendwem da reinreden zu lassen.

> Na, und *falls* das denn jemals passiert, was ja
> extrem unwahrscheinlich ist, weils die meisten eh sowieso schon gar
> nicht interessiert,

Zusätze im Benutzerhandbuch interessieren sehr wohl, nur eben keine
technischen (welche Lib benutzt wurde), sondern personelle. Einen Zusatz
im Handbuch einer Software, wo dritte Personen erwähnt werden, müsste
man dem Kunden erklären. Eventuell sorgt es dort sogar für Aufregung,
wenn irgenwie der Verdacht auftaucht, dass Unbekannte am Software-
Projekt mitgewirkt haben.

Sicher, hier wäre das eigentliche Problem nicht die LGPL, sondern die
Tatsache, dass der Kunde in diesen Dingen unbedarft und deshalb
ängstlich ist. Nitzdestotrotz (oder gerade deshalb) ist das ne kritische
Sache.

> > Es ist einfach ne größere Hemmschwelle und der Mehrwert für die
> > Community ist IMHO sogar noch größer, wenn ich die Änderungen nicht
> > dem Kunden zugänglich mache (der sich damit gar nicht auseinander
> > setzen *will*), sondern dem Autoren der Bibliothek zurücksende.
> > Schließlich können so meine Verbesserungen gleich in die Distros.
> 
> (Es reicht IMHO nicht, dem [einem] Autor einen Patch zu schicken, sofern
> dieser ihn nicht veröffentlicht.

Laut (L)GPL nicht, das ist korrekt. Aber um etwas zurückzugeben, schon.
Schließlich habe ich die Lib vom Autor "genommen" (verwendet), und genau
diesem "gebe" ich auch etwas zurück.

> Ich würde es immer noch auf eine
> Webseit packen oder ausdrücklich garantieren, jedem ggf. die Sourcen zu
> mailen oder was auch immer).

Laut GPL wird das verlangt. Aber bezogen auch das Szenario wäre das
unnötige "Verwaltungsarbeit". Also genau das, was ich kritisiere.

> > Ich tue also insgesamt sogar *mehr* für die Community, und habe
> > weniger Aufwand damit. Ein Vorteil für alle. Aber nicht LGPL-Konform.
> 
> Was ist daran nicht LGPL-Konform?

Hast du doch festgestellt. Dass ich dem Kunden die Quellen der geänderten
Lib nicht direkt zur Verfügung gestellt habe, sie auch nicht wirklich
veröffentlich habe, sondern stattdessen nur dem ursprünglichen Autor
zurückgegeben habe.

Was aber in dem Szenario zumindest *meiner* moralischen Vorstellung von
solidarischem Verhalten sogar mehr als Genüge tut. Weil ich die
Änderungen demjenigen gegeben habe, der was damit anfangen kann (dem
Autor) und nicht demjenigen, den sie gar nicht interessieren (dem
Kunden).

Die LGPL würde aber letzteres von mir verlangen, ersteres nicht. Daher
versagt dieses komplexe Regelwerk in diesem Fall. Denn es gibt eine
für alle Seiten einfachere und bessere Lösung. Bei einer BSD-Lib sähe
das Szenario also besser aus als bei einer LGPL-Lib.

> Ich glaub, ein Vorteil der GPL ist, dass man wohl
> selten einen Anwalt braucht, weil die FSF paar Mal durchgeklagt hat, so
> dass der gegnerische Anwalt von einer Klage eher absieht, weil kaum
> Aussicht auf Erfolg. Eine eigene Lizenz kriegt man als Laie sicherlich
> nicht wasserdicht. 

Da ist was dran.

> Ein Nebeneffekt ist IMHO auch, dass sich bei BSD-style "kommerzielle
> Branches" entwickeln können, was langfristig vermutlich auch nicht
> unbedingt von Vorteil ist.

Ja, richtig. Aber dafür werden viele kurzfristige positive Entwicklungen
aufgegeben bzw. demotiviert, und diese sind IMHO für ein freies
Software-Projekt ebenfalls wichtig.

> War Apache StrongHold nicht so ein Beispiel?
> Gibt's das noch?

Kenn ich nicht.

> Natürlich ist eine BSD-style für einen Hersteller einfacher, weil er
> eben nix "zurückgeben muss". Aber weiss nicht, ob mich das als
> Entwickler interessiert. Wenn jemand meine Lib einsetzen will, soll er
> es tun, wenn nicht halt nicht, auch egal. Ich hab doch nix davon, wenn
> in irgendeinem embedded TV meine Software läuft, wenn ich nichtmal
> Verbesserungen oder Fixes zurückkriege.

Wenn von den vielen Firmen auch nur ein Bruchteil dir Verbesserungen
zurückgibt, hast du mehr gewonnen, als wenn alle Firmen seine Lib
vermeiden, weil sie durch die komplexe Lizenz abgeschreckt werden.

> Ich hab nie verstanden, warum so viele der Meinung sind, man müsse
> OpenSource "verbreiten" und Leute "bekehren".

Hobby-/Freizeit-Programmierer sollte man schon "bekehren". Aber nicht
unbedingt zu freier Software, sondern dazu, überhaupt ihre Werke zu
veröffentlichen.

Das Umfeld, in dem man "aufwächst" (Programmieren lernt), trägt doch
einiges dazu bei. Meiner Erfahrung nach sind Menschen, die nur unter
Windows entwickelt haben, vielleicht noch mit ner illegalen Kopie
von VB, VC++ oder Delphi, eher nicht bereit, ihre Sachen zu
veröffentlichen. Schon allein aus Angst, sich zu "verraten" (dass
sie z.B. VC++ illegal nutzen). Selbst wenn sie dann viel Geld ausgegeben
haben, sinkt die Motivation erst Recht, der internationalen Gemeinschaft
etwas zu schenken, und sei es nur ein praktisches privates Programm.

Wer hingegen ständig Hilfe und Unterstützung bekam, wer *zum
Programmieren* selbst freie Software einsetzt, der ist auch eher
bereit, seine eigenen Werke zu veröffentlichen. Und sei es nur aus
Dankbarkeit (ich habe etwas bekommen, kann diesem nichts dafür
geben, also gebe stattdessen der Gemeinschaft etwas zurück).

> Wozu? Ich denke, bei
> GNU/Linux Distries sieht man, dass das nur dazu führt, dass viele
> komische Anforderungen zu Nachteilen führen, Multimedia und
> Plug-and-play-mounting z.B..

Ja, bei End-Usern gebe ich dir recht. Da sollten einzig und allein
Benutzbarkeit etc. eine Rolle spielen. Das tut es aber leider nicht.
Sonst wäre Ubuntu viel stärker verbreitet. Und wir hätten viel mehr
Apples als Windosen. Daher finde ich schon, dass eine gewisse Lobby
nicht verkehrt ist, um diesen störenden Machteinflüssen einen Gegenpol
zu bieten.

Man kann es natürlich auch übertreiben. :-)

> Das nun noch eine Million Laien mehr Mist in
> irgendwelche PHP Foren in die Welt blasen (was es vor 10 Jahren so nicht
> gab!), kann ich auch nicht als Vorteil sehen.

Das hat mit Informations-Überflutung zu tun, und hat auch einige
Vorteile. Ich finde eher, dass hier die Menschen falsch an das Internet
herangeführt werden. Früher musste man sich sehr viel technisches Wissen
aneignen, und die soziale Kompetenz hat man sich parallel dazu gleich
mit erworben (z.B. seine Infos zu verifizieren, bevor man sie
veröffentlicht, keine Flames anzufangen/fortzuführen, u.s.w.)

Heutzutage ist diese technische Hürde weg. Das ist eigentlich gut. Aber
fehlen den Neulingen auch die sozialen Kompetenzen, die im weltweiten
Netz nunmal besonders entwickelt werden müssen, weil dort höhere
Anforderungen an den Einzelnen gestellt werden als im kleinen Famlien-
und Freundeskreis.


Viele Grüße,

    Volker

-- 
Volker Grabsch
---<<(())>>---
Administrator
NotJustHosting GbR