Abo
  1. Foren
  2. Kommentare
  3. Politik/Recht
  4. Alle Kommentare zum Artikel
  5. › Linux: Mit Ignoranz gegen die GPL

Umdenken auch bei Kernel-Entwicklern erforderlich

  1. Thema

Neues Thema Ansicht wechseln


  1. Umdenken auch bei Kernel-Entwicklern erforderlich

    Autor: irisquelle 20.03.18 - 04:55

    Ich halte eine aggressive Durchsetzung der GPL für kontraproduktiv. Letztlich wird der Ruf der ganzen Open-Source Entwicklercommunity beschädigt, wenn es sich Einzelne zur Lebensaufgabe machen, andere wegen Linzenzverstößen mit Prozessen zu überziehen. Hier allein auf die "Dummheit" der Hersteller und Vertriebsorganisationen hinzuweisen, reicht nicht aus. Es gibt ja konkrete kommerzielle Gründe, weshalb etwa die Hersteller von Geräten, die den Linux-Kernel einsetzen, ihre Erweiterungen nicht offenlegen können. Daher sollten sich die GPL-Verfechter darüber klar werden, dass man nicht beides haben kann: die massenhafte kommerzielle Verbreitung des Linux-Kernels lässt sich schwerlich damit vereinbaren, wenn jeder Hersteller gezwungen wird seine Geschäftsgeheimnisse zu offenbaren.

    Eher schon kann ich mir eine Partitionierung des Linux-Kernels in zwei unterschiedlich lizensierte Bereiche vorstellen. Zum einen einen echten "Kern", wo hardware-übergreifende Funktionen realisiert wird (also Scheduler, Memory Management, Netzwerkstack usw.), der weiterhin unter der GPL lizensiert ist. Und einen "Randbereich", wo Hersteller etwa Hardware-nahe Features wie Treiber umsetzen und vor der zwangsweisen Offenlegung ihres geistigen Eigentums geschützt sind. Eine weitere Alternative sind Karenzfristen, während derer die Hersteller ihren Code zurückhalten dürfen. Nach fünf Jahren dürfte es für den Hersteller eines Android-Geräts weniger schmerzhaft sein, wenn die programmierten Treiber zum Allgemeingut werden. Noch besser wäre es, wenn der Linux-Kernel perspektivisch die GPL aufgibt und zu einer liberaleren Lizenz wechselt. Übergangsweise ist auch eine Dual-Lizensierung denkbar, bei der Verwender des Linux-Kernels sich ggf. für eine alternative Lizenz entscheiden könnten. Das kann auch gegen Lizenzgebühren erfolgen, die dann per Verteilungsschlüssel an die Kernel-Programmierer ausgeschüttet werden.

  2. Re: Umdenken auch bei Kernel-Entwicklern erforderlich

    Autor: wilima 20.03.18 - 06:33

    Ich hoffe, du machst Witze! Eine Lizenz ist eine Lizenz ist eine Lizenz! Wenn ein Hersteller Geschäftsgeheimnisse hat, muss er eben ein eigenes Betriebssystem entwickeln oder könnte z. B. ein kommerzielles lizensieren.

    Die massenhafte Verbreitung des Linux-Kernels wurde überhaupt erst durch die GPL ermöglicht! Denn jeder Hersteller, der eine Erweiterung benötigt, muss diese öffentlich machen. Dadurch entwickelt sich der Kernel weiter und wird für mehr Leute interessant, die dann wieder eine Erweiterung benötigen und diese öffentlich machen müssen ...

    Alles andere ist kommerzielles Ausbeuten der Kernel-Entwickler, die genau deshalb zu ihrem Schutz unter der GPL entwickeln.

  3. Re: Umdenken auch bei Kernel-Entwicklern erforderlich

    Autor: irisquelle 20.03.18 - 08:27

    Ausgebeutet werden viele Kernel-Entwickler schon jetzt. Ich sehe jedenfalls nicht, dass die vielen Freizeit-Programmierer auch nur eine geringfügige wirtschaftliche Entschädigung für ihre Beiträge erhalten würden. Und andere Software ist beispielsweise BSD, MIT oder Apache-lizensiert und trotzdem erfolgreich. Meine These ist, dass Linux trotz, aber nicht wegen der GPL erfolgreich ist.

    Man sollte das Thema Lizensierung grundsätzlich ideologiefrei betrachten. Vor allem sollten die Protagonisten der Community regelmäßig überprüfen, inwiefern die GPL noch zweckmäßig ist. Es kann ja sein, dass die GPL in den Anfangsjahren von Linux die richtige Wahl war. Inzwischen wäre aber eine Dual-Lizensierung in vielen Fällen zeitgemäßer.

    Als Beispiel einmal ein fiktives Szenario: ein SaaS-Anbieter passt GPL-lizensierte Software für seine Zwecke an. Dann setzt er diese Software ohne Veröffentlichung des Quellcodes in seiner Cloud ein. Das ist zwar auch eine Lizenzverletzung, lässt sich aber praktisch nicht nachweisen.

    Demgegenüber müssen Hersteller von Hardware mit Linux-basierter Firmware oder Programmierer von installierter Software mit GPL-lizensierten Komponenten ihre Firmware/Software offen legen - allein weil der Nachweis einer Lizenzverletzung ungleich einfacher ist. Diese Unterscheidung ist nicht nur unfair - vor allem zeigt es, wie die GPL aus der Zeit gefallen ist. Der Gedanke der Offenlegung des Quelltextes ergibt im Zeitalter von Cloud-basierten Diensten immer weniger Sinn.

  4. Re: Umdenken auch bei Kernel-Entwicklern erforderlich

    Autor: a user 20.03.18 - 13:35

    irisquelle schrieb:
    --------------------------------------------------------------------------------
    > Ich halte eine aggressive Durchsetzung der GPL für kontraproduktiv.
    > Letztlich wird der Ruf der ganzen Open-Source Entwicklercommunity
    > beschädigt, wenn es sich Einzelne zur Lebensaufgabe machen, andere wegen
    > Linzenzverstößen mit Prozessen zu überziehen. Hier allein auf die
    > "Dummheit" der Hersteller und Vertriebsorganisationen hinzuweisen, reicht
    > nicht aus.

    Doch!
    > Es gibt ja konkrete kommerzielle Gründe, weshalb etwa die
    > Hersteller von Geräten, die den Linux-Kernel einsetzen, ihre Erweiterungen
    > nicht offenlegen können.
    Nein gibt es nicht. Ich abreite in einer Firma die sich genau damit schwer tut und es ist EINZIG UND ALLEINE UNSERER DUMMHEIT und FAULHEIT geschuldet. Denn es wurde nicht einmal einn erstnhafter Versuch unternommen dem Folge zu leisten.

    Es sieht nämlich so aus:
    A : "Was kostet uns das?"
    B: "Nix. Aber du musst da paar Kleinigkeiten erfüllen. Und zwar..."
    A: "Ah ne, dann lassen wir das. Zu aufwändig und wer weiß was da schief gehen kann."
    > Daher sollten sich die GPL-Verfechter darüber klar
    > werden, dass man nicht beides haben kann: die massenhafte kommerzielle
    > Verbreitung des Linux-Kernels lässt sich schwerlich damit vereinbaren, wenn
    > jeder Hersteller gezwungen wird seine Geschäftsgeheimnisse zu offenbaren.
    Darüber sind sich die GPL Verfechter im Klaren. Denn wenn du dich einmal mit der GPL beschäftigt hättest, dann wüstest du, dass sie das gar nicht zum Ziel hat. Das Ziel ist mithilfe guter Software über diese Lizenz Software frei für alle zu erzwingen.
    Was du mit unserem Zeug machst, musst du allen frei zugänglich machen. Das hat mit Nichten das Ziel diese Software weit zu verbreiten.

    Andersurm wird ein Schuh draus: man versucht die Verbreitung, weil es gute und freie Software ist dazu zu nutzen, damit immer mehr Software frei wird.

  5. Re: Umdenken auch bei Kernel-Entwicklern erforderlich

    Autor: Thaodan 20.03.18 - 21:16

    irisquelle schrieb:
    --------------------------------------------------------------------------------

    > Als Beispiel einmal ein fiktives Szenario: ein SaaS-Anbieter passt
    > GPL-lizensierte Software für seine Zwecke an. Dann setzt er diese Software
    > ohne Veröffentlichung des Quellcodes in seiner Cloud ein. Das ist zwar auch
    > eine Lizenzverletzung, lässt sich aber praktisch nicht nachweisen.
    Nein wäre es nicht, nur bei AGPL.

    Wahrung der Menschenrechte oder Freie fahrt am Wochenende.
    -- Georg Schramm

  6. Re: Umdenken auch bei Kernel-Entwicklern erforderlich

    Autor: Silberfan 29.03.18 - 09:42

    irisquelle schrieb:
    --------------------------------------------------------------------------------
    > Ich halte eine aggressive Durchsetzung der GPL für kontraproduktiv.
    > Letztlich wird der Ruf der ganzen Open-Source Entwicklercommunity
    > beschädigt, wenn es sich Einzelne zur Lebensaufgabe machen, andere wegen
    > Linzenzverstößen mit Prozessen zu überziehen. Hier allein auf die
    > "Dummheit" der Hersteller und Vertriebsorganisationen hinzuweisen, reicht
    > nicht aus. Es gibt ja konkrete kommerzielle Gründe, weshalb etwa die
    > Hersteller von Geräten, die den Linux-Kernel einsetzen, ihre Erweiterungen
    > nicht offenlegen können. Daher sollten sich die GPL-Verfechter darüber klar
    > werden, dass man nicht beides haben kann: die massenhafte kommerzielle
    > Verbreitung des Linux-Kernels lässt sich schwerlich damit vereinbaren, wenn
    > jeder Hersteller gezwungen wird seine Geschäftsgeheimnisse zu offenbaren.

    Die Schwierigkeit liegt im Risiko des Betreibers. Wenn er nun also kein Geld für Software Zahlen muss,dann ist es auch klar das er kein Geld verlangen kann und darf beim Kunden. Ebenso muss der Quellcode Offengelegt werden. Es reicht im allgemeinen aus die Ansprech-Adressen der Hardware korrekt aufzulisten und eine entsprechende Dokumentation dazu mitzugeben. die meisten Hersteller scheuen aber die Kosten die dabei entstehen. Wobei die Kostenpflichtige Closed Version im Vergleich zur Open Source teurer wäre. Man muss aber auch aus Firmensicht selbst entscheiden. Will man kosten in der Software Welt einsparen dann muss ich auch die Folgen die dadurch entstehen können mit in Betracht ziehen(Offenlegung des Quellcodes ,saubere Dokumentation ,etc.) . Oder ich betreibe Closed Source und kann so keine Umsatzzahlen oder geringere generieren und muss Möglicherweise auch den Support zur Software ( Treiber ,etc. ) dann auch noch Übernehmen.


    > Eher schon kann ich mir eine Partitionierung des Linux-Kernels in zwei
    > unterschiedlich lizensierte Bereiche vorstellen. Zum einen einen echten
    > "Kern", wo hardware-übergreifende Funktionen realisiert wird (also
    > Scheduler, Memory Management, Netzwerkstack usw.), der weiterhin unter der
    > GPL lizensiert ist. Und einen "Randbereich", wo Hersteller etwa
    > Hardware-nahe Features wie Treiber umsetzen und vor der zwangsweisen
    > Offenlegung ihres geistigen Eigentums geschützt sind. Eine weitere
    > Alternative sind Karenzfristen, während derer die Hersteller ihren Code
    > zurückhalten dürfen. Nach fünf Jahren dürfte es für den Hersteller eines
    > Android-Geräts weniger schmerzhaft sein, wenn die programmierten Treiber
    > zum Allgemeingut werden. Noch besser wäre es, wenn der Linux-Kernel
    > perspektivisch die GPL aufgibt und zu einer liberaleren Lizenz wechselt.
    > Übergangsweise ist auch eine Dual-Lizensierung denkbar, bei der Verwender
    > des Linux-Kernels sich ggf. für eine alternative Lizenz entscheiden
    > könnten. Das kann auch gegen Lizenzgebühren erfolgen, die dann per
    > Verteilungsschlüssel an die Kernel-Programmierer ausgeschüttet werden.

    Die Problematik gestaltet sich in 2 ebenen. Kostenpflichtig und kostenfrei. nimmt man kostenpflichtig will keiner was damit zu tun haben. Kostenfrei nutzt somit jeder. Es gibt zig andere Methoden und Möglichkeiten die Kosten der Softwareentwicklung wieder einzuspielen. Man muss nicht stur auf die eine oder andere Möglichkeit sein Geschäftsmodell setzten. Man kann auch z.B. durch Zusatz Modulen oder extras die es so gibt auch einen weiteren Zweig für Finanzielles einsetzten.
    Beispiel: jemand hat Grafikkarte X in Benutzung ,zockt aber nicht ,brauch als das geblubber für die Treiber im Gaming Bereich nicht. Ihm reichen Standard Treiber ,also zahlt er nix. Jemand anderes Zockt gerne und brauch den Kram. Also einmalig sich registrieren, 5¤ im Jahr für den Treiber Kram Bezahlen lassen, fertig. Wenn das z.B. 500.000 Leute das machen so könnte man mit dem Geld Locker 2 Programmierer ( evtl. mehr) finanzieren die Bugs oder Probleme beheben und diese dann Zeitnah auch fixen.
    Einfacher Dargestellt, für Standard zahlt man nix. Für Extras sollte man einen kleinen Betrag hinlegen. Das Denkbar Schlechtestes Beispiel im Kostenpflichtigen Bereich wäre Crossover von Cedega das schon 50-60¤ Pro Jahr Verlangt. Würden die z.B. auf 5¤ runter gehen , würden auch viel mehr Leute Ihre Software nutzten.

  7. Re: Umdenken auch bei Kernel-Entwicklern erforderlich

    Autor: Hello_World 03.04.18 - 17:32

    Es ist wenig sinnvoll, darüber zu diskutieren, ob der Kernel mit einer liberaleren Lizenz besser dran wäre, da es ohnehin nicht dazu kommen wird. Tausende Leute haben mittlerweile daran mitgearbeitet. Einige dürften sich schlicht weigern, ihren Code unter eine andere Lizenz zu stellen, andere sind unauffindbar oder tot.

    Zudem ist ohnehin zweifelhaft, ob es wirklich besser und technisch machbar wäre. Wäre der AMD-Grafiktreiber heute Open Source, wenn die GPL nicht wäre? Wie sieht es mit den Android-Features aus, die in den Mainline-Kernel gemerged wurden? Ich glaube nicht, dass der Kernel heute so weit wäre, wie er ist, wenn er unter einer liberaleren Lizenz gestanden hätte.
    Ganz zu schweigen davon, dass das auch ein stabiles Kernel-ABI nötig machen würde, was die Weiterentwicklung erschwert.

Neues Thema Ansicht wechseln


Um zu kommentieren, loggen Sie sich bitte ein oder registrieren Sie sich. Zum Login

Stellenmarkt
  1. Lidl Digital, Leingarten
  2. Software AG, Darmstadt
  3. GSI Helmholtzzentrum für Schwerionenforschung GmbH, Darmstadt
  4. MediaNet GmbH Netzwerk- und Applikations-Service, Freiburg

Golem pur
  • Golem.de ohne Werbung nutzen

Anzeige
Top-Angebote
  1. 69€
  2. (u. a. Destiny 2 PS4 für 9,99€)
  3. 448,89€ inkl. Versand (Vergleichspreis 495€)
  4. 36,99€ + 5,99€ Versand oder versandkostenfrei bei Zahlung mit paydirekt (Vergleichspreis 69...


Haben wir etwas übersehen?

E-Mail an news@golem.de


Elektromobilität: Regierung bremst bei Anspruch auf private Ladesäulen
Elektromobilität
Regierung bremst bei Anspruch auf private Ladesäulen

Die Anschaffung eines Elektroautos scheitert häufig an der fehlenden Lademöglichkeit am heimischen Parkplatz. Doch die Bundesregierung will vorerst keinen eigenen Gesetzesentwurf für einen Anspruch von Wohnungseigentümern und Mietern vorlegen.
Ein Bericht von Friedhelm Greis

  1. ID Buzz und Crozz Volkswagen will Elektroautos in den USA bauen
  2. PFO Pininfarina plant Elektrosupersportwagen mit 400 km/h
  3. Einride Holzlaster T-Log fährt im Wald elektrisch und autonom

Russische Agenten angeklagt: Mit Bitcoin und CCleaner gegen Hillary Clinton
Russische Agenten angeklagt
Mit Bitcoin und CCleaner gegen Hillary Clinton

Die US-Justiz hat zwölf russische Agenten wegen des Hacks im US-Präsidentschaftswahlkampf angeklagt. Die Anklageschrift nennt viele technische Details und erhebt auch Vorwürfe gegen das Enthüllungsportal Wikileaks.

  1. Nach Gipfeltreffen Trump glaubt Putin mehr als US-Geheimdiensten
  2. US Space Force Planlos im Weltraum
  3. Gewalt US-Präsident Trump will Gespräch mit Spielebranche

KI in der Medizin: Keine Angst vor Dr. Future
KI in der Medizin
Keine Angst vor Dr. Future

Mit Hilfe künstlicher Intelligenz können schwer erkennbare Krankheiten früher diagnostiziert und behandelt werden, doch bei Patienten löst die Technik oft Unbehagen aus. Und das ist nicht das einzige Problem.
Ein Bericht von Tim Kröplin

  1. Künstliche Intelligenz Vages wagen
  2. KI Mit Machine Learning neue chemische Reaktionen herausfinden
  3. Elon Musk und Deepmind-Gründer Keine Maschine soll über menschliches Leben entscheiden

  1. Star Trek Discovery 2: Erster Trailer zeigt Raumschiff in Schwierigkeiten
    Star Trek Discovery 2
    Erster Trailer zeigt Raumschiff in Schwierigkeiten

    Oje, das schöne Schiff: Der erste Trailer der zweiten Staffel von Star Trek Discovery setzt auf Action und neue Bedrohungen. Auch das Raumschiff selbst kommt wohl nicht ganz unbeschadet aus dem neuen galaktischen Konflikt.

  2. Handelskrieg: Apple Watch und anderen Gadgets drohen Strafzölle
    Handelskrieg
    Apple Watch und anderen Gadgets drohen Strafzölle

    Die USA wollen offenbar beliebte Gadgets mit Strafzöllen belegen: Apple Watch und Lautsprecher von Sonos könnten in Nordamerika um 10 Prozent teurer werden. Dem iPhone drohen wegen eines Versprechens von US-Präsident Donald Trump gegenüber Tim Cook aber wohl keine Preisaufschläge.

  3. Spielebranche: Ex-Angestellter rechnet mit Valve ab
    Spielebranche
    Ex-Angestellter rechnet mit Valve ab

    In der Öffentlichkeit gilt Valve (Half-Life, Steam) als vorbildhafte Firma, die Wirklichkeit scheint nicht ganz so toll zu sein: Der ehemalige Angestellte Rich Geldreich schreibt seit einigen Tagen auf Twitter, wie es tatsächlich hinter den Kulissen aussieht.


  1. 13:24

  2. 12:44

  3. 11:42

  4. 09:48

  5. 18:05

  6. 17:46

  7. 17:31

  8. 17:15