Ich bim im Netz auf einige Kommentare zu diesem Thema gestoßen, hab allerdings den Auslöser der Aufregung verpasst. Worum geht es überhaupt? Mitbekomen habe ich, dass CentOS eingestellt wurde, deswegen sind andere kostenlose RedHat Klone entstanden, die auf dem selben Quellcode basieren. Diese Alternativen will RedHat verhindern, indem es die Quelltexte nur Kunden mit Wartungsvertrag bereit stellt und diese vertraglich dazu verpflichtet, die Quelltexte nicht weiter zu geben. Stimmt das? Die Quelltexte stehen aber unter GPL. Die GPL untersagt ausdrücklich die Einschränkung der zugesicherten Kopier- und Nutzungsrechte. Ergo bricht RedHat die GPL. Habe ich das so richtig verstanden?
Oliver S. schrieb: > Nein Sei bitte so nett und erkläre es mir oder verweise auf eine Webseite wo ich es nachlesen kann.
Stefan F. schrieb: > oder verweise auf eine Webseite wo > ich es nachlesen kann. lwn hat etwas dazu https://lwn.net/Articles/936405/#Comments und https://lwn.net/Articles/935592/
Stefan F. schrieb: > Die Quelltexte stehen aber unter GPL. Die GPL untersagt ausdrücklich die > Einschränkung der zugesicherten Kopier- und Nutzungsrechte. Ergo bricht > RedHat die GPL. Ist wohl komplizierter: https://sfconservancy.org/blog/2023/jun/23/rhel-gpl-analysis/
Das sind ja auch wieder nur Kommentare zu dem Vorgang. Was mir fehlt, ist der Vorgang der gerade überall kommentiert wird. Offenbar ist das hier so ein Fall, wo die Bezeichnung "Rechtsverdreher" passt.
Stefan F. schrieb: > Was mir fehlt, > ist der Vorgang der gerade überall kommentiert wird. https://www.redhat.com/en/blog/furthering-evolution-centos-stream https://www.redhat.com/en/blog/red-hats-commitment-open-source-response-gitcentosorg-changes
So wie ich das lese, verpflichtet die GPL nur dazu, den Quellcode jenen Leuten rebuild-fähig zur Verfügung zu stellen, denen man die Binaries zur Verfügung stellt. Ist beispielsweise Rocky Linux Kunde von Red Hat, können sie auf der bisherigen Basis weiter machen, weil eine Einschränkung der Weitergabe durch Rocky Linux nicht zulässig ist. Ist Rocky Linux aber kein Kunde (oder nicht mehr), wird der Zugang zu rebuild-fähigem Code weit schwieriger und das Ergebnis ähnelt dann vmtl mehr einer eigenen Distro als einer Red Hat Kopie. Inwieweit man das moralisch gut heisst, ist eine andere Frage. Die GPL ist aber ein Rechtsdokument, kein Glaubensartikel.
:
Bearbeitet durch User
Stefan F. schrieb: > Worum geht es überhaupt? So habe ich das verstanden: Red Hat stellte bisher allen den Quellcode in einer Form zur Verfügung, der Rebuilds einfach machte. Nun tun sie das nur den eigenen Kunden gegenüber.
(prx) A. K. schrieb: > Ist beispielsweise Rocky Linux Kunde von Red Hat, können sie auf der > bisherigen Basis weiter machen, weil eine Einschränkung der Weitergabe > durch Rocky Linux nicht zulässig ist. Andererseits behält RedHat sich vor, eben wegen der Weitergabe der Quelltexte, den Vertrag zu beenden und das Aschließen neuer Verträge abzulehnen. Allerdings veröffentlichen sie ihre Quelltexte weiterhin in Git, bevor daraus ein Release wird. Soweit ich verstanden habe genügt das, die GPL zu erfüllen. Es wird nun sehr Mühsam, aus den ganzen losen Quelltexten eine installierbare Distribution zu machen. Einfach alles 1:1 übernehmen und ein anderen Namen drauf zu stempeln, geht wohl nicht mehr.
Stefan F. schrieb: > Andererseits behält RedHat sich vor, eben wegen der Weitergabe der > Quelltexte, den Vertrag zu beenden und das Aschließen neuer Verträge > abzulehnen. Und da wirds dann eben "Legalese". Man muss sich Leuten bedienen, die das Studium dieser Fremdprache durchgezogen und damit reichlich Praxis gewonnen haben. Und wird trotzdem feststellen, dass 2 dieser Leute mit 3 Ansichten kommen. > Es wird nun sehr Mühsam, aus den ganzen losen Quelltexten eine > installierbare Distribution zu machen. Einfach alles 1:1 übernehmen und > ein anderen Namen drauf zu stempeln, geht wohl nicht mehr. Yep. Der Quellcode von des nunmehr rolling CentOS steht weiterhin zur Verfügung, das geht nicht anders. Aber die Releases von RHEL sind darin nicht mehr 1:1 identifizierbar.
:
Bearbeitet durch User
Ich frage mich, wie kleine Autoren von Linux Paketen künftig RedHat supporten sollen. Wenn RedHat mangels CentOS (oder anderer Klone) für Hobbyautoren nicht mehr zugänglich ist, dann werden sich einige von RedHat zurück ziehen. In Folge dessen könnte unter Umständen auch RedHat für Anwender weniger attraktiv werden, als es jetzt ist. Ende der 90er liebte ich Sun Spark Rechner mit Solaris wegen ihrer guten Performance und Stabilität. Aber ich hasste sie auch, weil man mit vielen OSS Programmen im Fehlerfall ohne Support da stand. Da haben die Autoren oft gesagt: Wenn mein Programm auf deinem Solaris läuft: schön. Wenn nicht: Pech gehabt. Helfen kann ich dir nicht.
Stefan F. schrieb: > In Folge dessen könnte unter Umständen auch RedHat für Anwender weniger > attraktiv werden, als es jetzt ist. Wobei ich nicht den Eindruck habe, dass das RedHat-Universum in privaten Kreisen in Europa von allzu grosser Bedeutung ist, Fedora inklusive. Auch CentOS sah ich eher als Business-Lösung für Sparsame. Mir schien auch schon bisher, dass sich der private und kleinkommerzielle Bereich eher im Debian- und Arch-Universum bewegte, Derivate wie Ubuntu etc eingeschlossen. In letztere Zeit haben wir uns trotz langjähriger strategischer Orientierung des Hauses auf Red Hat in einigen Lösungen für das Debian-Universum entschieden. Wenn etwas nicht in Red Hat enthalten ist, hat man auf diesem Weg schon jetzt weniger Arbeit.
:
Bearbeitet durch User
(prx) A. K. schrieb: > Auch CentOS sah ich eher als Business-Lösung für Sparsame. Darum gehts wohl. https://www.heise.de/meinung/Kommentar-Erst-verteufeln-dann-selber-so-machen-Red-Hats-idiotischer-Murks-9204529.html Oliver
Oliver S. schrieb: > (prx) A. K. schrieb: >> Auch CentOS sah ich eher als Business-Lösung für Sparsame. > > Darum gehts wohl. Die Lizenzen von RHEL auf zentralen Virtualisierungs-Host sind verglichen mit Windows Datacenter bisher harmlos. Verteilt auf viele Aussenstellen wär das deutlicher spürbar, also war dort bisher CentOS die Wahl. Bei nicht produktionskritischem Kram gibt es aber keinen Grund, dort künftig RHEL einzusetzen. Es gibt genug Alternativen. Kommerzielle Lösungen, durchaus auch in produktionskritischen Bereichen, findet man heute oft auf Ubuntu-Grundlage, ausschliesslich oder als Option. Wobei Ubuntu ja neuerdings auch auf deutlich Geld aus ist, will man mehr als 5 Jahre ohne Upgrade haben. Die bisherige Billigvarante für Einzelfälle wurde unlängst gestrichen.
:
Bearbeitet durch User
Stefan F. schrieb: > Ich frage mich, wie kleine Autoren von Linux Paketen künftig RedHat > supporten sollen. Gar nicht. > Wenn RedHat mangels CentOS (oder anderer Klone) für Hobbyautoren nicht > mehr zugänglich ist, dann werden sich einige von RedHat zurück ziehen. Na und? Es gibt doch genug Alternativen. > In Folge dessen könnte unter Umständen auch RedHat für Anwender weniger > attraktiv werden, als es jetzt ist. Na und? Es gibt doch genug Alternativen. > Ende der 90er liebte ich Sun Spark Rechner mit Solaris wegen ihrer guten > Performance und Stabilität. Aber ich hasste sie auch, weil man mit > vielen OSS Programmen im Fehlerfall ohne Support da stand. Da haben die > Autoren oft gesagt: Wenn mein Programm auf deinem Solaris läuft: schön. > Wenn nicht: Pech gehabt. Helfen kann ich dir nicht. Naja, das meiste hat ja funktioniert, solange es nicht allzu systemnah war.
(prx) A. K. schrieb: > So wie ich das lese, verpflichtet die GPL nur dazu, den Quellcode jenen > Leuten rebuild-fähig zur Verfügung zu stellen, denen man die Binaries > zur Verfügung stellt. Meinem Verständnis nach muss man den Quellcode jedem zur Verfügung stellen, der das Binary hat, egal woher. Das fand ich zwar immer etwas seltsam, aber so ist es wohl. (prx) A. K. schrieb: > Auch CentOS sah ich eher als Business-Lösung für Sparsame. Es scheint im Business-Bereich recht verbreitet zu sein, obwohl da Ubuntu auch inzwischen sehr häufig anzutreffen ist.
Rolf M. schrieb: > Meinem Verständnis nach muss man den Quellcode jedem zur Verfügung > stellen, der das Binary hat, egal woher. Das fand ich zwar immer etwas > seltsam, aber so ist es wohl. Das lese ich anders. Abschnitt 6 der GPLv3 verlangt, dass derjenige, der Binaries zur Verfügung stellt, ebenso auch den Source zur Verfügung stellen muss. Wenn du also die Binaries nicht von Red Hat erhalten hast, sondern von einem Dritten, ist dieser Dritte in der Pflicht.
:
Bearbeitet durch User
Rolf M. schrieb: > Meinem Verständnis nach muss man den Quellcode jedem zur Verfügung > stellen, der das Binary hat, egal woher. Das fand ich zwar immer etwas > seltsam, aber so ist es wohl. Nein. Wenn unter GPL stehendes verbreitet wird, muss der Verbreitende demjenigen, dem er das zugänglich macht, auch den Quellcode zugänglich machen. RedHat macht das Material aber halt nicht allen zugänglich, sondern nur seinen Kunden, die über Zusatzvereinbarungen daran gehindert werden sollen, das weiterzuverbreiten. Das ist so ein wenig, wie in der Grundschule: Gib mir einen Keks, dann erzähle ich dir einen Witz, den ich gehört habe. Aber wenn du den weitererzählst, dann bin ich sauer und rede nicht mehr mit dir. Letztendlich ist es gut, dass eine Firma wie RedHat diesen Mist mal durchexerzieren will, weil das eine Auseinandersetzung auf rechtsstaatlich festem Terrain wird und die Sache danach - wie auch immer es ausgeht - klar ist. Viel schlimmer sind doch die ganzen chinesischen Firmen, die still und heimlich klauen und nicht zur Rechenschaft gezogen werden können.
(prx) A. K. schrieb: > Das lese ich anders. Abschnitt 6 der GPLv3 verlangt, dass derjenige, der > Binaries zur Verfügung stellt, ebenso auch den Source zur Verfügung > stellen muss. Wenn du also die Binaries nicht von Red Hat erhalten hast, > sondern von einem Dritten, ist dieser Dritte in der Pflicht. Genau so ist es auch mir bekannt und spiegelt auch die gelebte Realität wieder. Bedeutet im konkreten: - Man kann GPL Sourcecode für sich selbst beliebig modifizieren, keine Veöffentlichung notwendig - Man kann GPL Sourcecode für einen Kunden / Projekt beliebig modifizieren, keine Veröffentlichung notwendig, lediglich der Kunde muss den modifizierten Sourcecode erhalten
:
Bearbeitet durch User
Rolf M. schrieb: >> Auch CentOS sah ich eher als Business-Lösung für Sparsame. > > Es scheint im Business-Bereich recht verbreitet zu sein, obwohl da > Ubuntu auch inzwischen sehr häufig anzutreffen ist. Wo gab es sonst 10 Jahre Security-Support ohne Versionsupgrade, und das für lau? Bei Ubuntu und Debian sind es nur 5 Jahre. Es gibt etliche Business-Lösungen, bei denen solche Stabilität viel Zeit und Geld erspart. Innerhalb einer Version ändert(e) sich das Verhalten nur in Ausnahmefällen. Ein Versionsupgrade solcher Lösungen kann einen ziemlichen Aufwand darstellen. Nicht so sehr die eigentliche Arbeit, sondern Terminbürokratie im Produktionsbereich und Support-Kosten beim Lieferanten. Es verletzt das Prinzip Never Change A Running System.
:
Bearbeitet durch User
(prx) A. K. schrieb: > Das lese ich anders. Abschnitt 6 der GPLv3 verlangt, dass derjenige, der > Binaries zur Verfügung stellt, ebenso auch den Source zur Verfügung > stellen muss. Ja, aber nicht nur demjenigen, dem er das Binary höchstpersönlich gegeben hat, sondern jedem, der das Binary hat. Also: Wen du jemandem das Binary gibst, und der gibt es mir, dann kann ich von dir den Sourcecode einfordern. "… accompanied by a written offer, valid for at least three years and valid for as long as you offer spare parts or customer support for that product model, to give anyone who possesses the object code …" Michael H. schrieb: > - Man kann GPL Sourcecode für einen Kunden / Projekt beliebig > modifizieren, keine Veröffentlichung notwendig, lediglich der Kunde muss > den modifizierten Sourcecode erhalten … sofern er auch der einzige ist, der Binary hat.
Rolf M. schrieb: > "… accompanied by a written offer, valid for at least three years and > valid for as long as you offer spare parts or customer support for that > product model, to give anyone who possesses the object code …" Das bezieht sich ausschliesslich auf jenen Abschnitt 6b in dem es steht: "Convey the object code in, or embodied in, a physical product..." Damit sind, wie auch in 6a, beispielsweise auf sowas wie Edge-Router gemeint, bei denen es in der Vergangenheit schon Streit gegeben hat. Bei Red Hat dürfte 6d relevant sein.
:
Bearbeitet durch User
(prx) A. K. schrieb: > Das bezieht sich ausschliesslich auf jenen Abschnitt 6b in dem es steht: > "Convey the object code in, or embodied in, a physical product..." "… including a physical distribution medium", also z.B. ein USB-Stick oder eine CD-ROM. > Das bezieht sich, wie auch 6a, beispielsweise auf sowas wie Edge-Router. Ich kann mir nicht vorstellen, dass es auf das beschränkt ist. Denn sonst dürfte man das Programm gar nicht auf eben so Dingen wie USB-Sticks weitergeben, denn es gibt neben dieser Variante nur noch "access from a designated place", also das Ablegen auf einem Server und "using peer-to-peer transmission", also sowas wie BitTorrent.
:
Bearbeitet durch User
Rolf M. schrieb: > "… including a physical distribution medium", also z.B. ein USB-Stick > oder eine CD-ROM. 6a: Du kriegt irgendeinem Gerät oder fassbares Medium mit Source. 6b: Du kriegst irgendein Gerät oder fassbares Medium ohne Source, kannst den aber ohne zusätzliche Kosten holen. Und das darf dann auch derjenige, der das Gerät/Medium mittlerweile besitzt.
Rolf M. schrieb: > Ich kann mir nicht vorstellen, dass es auf das beschränkt ist. Anfassbare Distro-CD/DVDs sind etwas aus der Mode gekommen. Ohne Gerät und ohne solches vom Anbieter gelieferte Medium sind weder 6a noch 6b relevant. Downloads von Distro-ISOs sind davon dem Wortsinm nach nicht erfasst.
:
Bearbeitet durch User
Rolf M. schrieb: > sonst dürfte man das Programm gar nicht auf eben so Dingen wie > USB-Sticks weitergeben Ein Red Hat Kunde kann dir einen USB-Stick mit allem Source in die Hand drücken (6a) und riskiert damit keinen Ärger mit der GPL, aber mit Red Hat (*). Ohne darauf befindlichem Source hingegen (6b) verletzt er die GPL, weil er dem Empfänger den Zugang zum Source nicht gewährleisten kann. *: Und genau da wird es spannend, wie Sönke schon schrieb. Ob Red Hat den Vertrag kündigen oder Verlängerungen ablehnen darf (hab es nicht gelesen, aber so in die Richtung wird es wohl gehen), weil der Kunde ein Recht gemäss der GPL beansprucht. Deshalb auch oben mein Verweis auf Legalese. Das können letztlich nur Richter entscheiden.
:
Bearbeitet durch User
Wie Rocky&Co das angehen wollen, weiss ich nicht. Aber sollte der Quellcode in git vollständig und frei verfügbar sein, fehlt im Grunde nur die Assoziierung zwischen einer RHEL-Version und den exakten git-Links. Es muss also kein Source weiter gegeben werden, sondern nur Meta-Information.
:
Bearbeitet durch User
(prx) A. K. schrieb: > 6b: Du kriegst irgendein Gerät oder fassbares Medium ohne Source, kannst > den aber ohne zusätzliche Kosten holen. Und das darf dann auch > derjenige, der das Gerät/Medium mittlerweile besitzt. Oder eben auch irgendein anderer, der irgendwie an das Binary gekommen ist. Das muss nicht zwingend auf dem Original-Medium (oder überhaupt einem physischen Medium) sein ("anyone who possesses the object code"). (prx) A. K. schrieb: > Anfassbare Distro-CD/DVDs sind etwas aus der Mode gekommen. Ohne Gerät > und ohne solches vom Anbieter gelieferte Medium sind weder 6a noch 6b > relevant. Downloads von Distro-ISOs sind davon dem Wortsinm nach nicht > erfasst. Mir ging es um diese Aussage, die in dieser Allgemeinheit eben nicht ganz korrekt ist: (prx) A. K. schrieb: > So wie ich das lese, verpflichtet die GPL nur dazu, den Quellcode jenen > Leuten rebuild-fähig zur Verfügung zu stellen, denen man die Binaries > zur Verfügung stellt. Es scheint tatsächlich, dass man bei der Download-Option (6d) nur denen auf die Sourcen Zugriff geben muss, die auch Zugriff auf die Binaries haben ("offer equivalent access to the Corresponding Source"), während man bei der "written offer" (6b) jedem, der das Binary hat, auch die Quellen geben muss. Diese Unterscheidung finde ich seltsam.
:
Bearbeitet durch User
Sönke P. schrieb: > Nein. Wenn unter GPL stehendes verbreitet wird, muss der Verbreitende > demjenigen, dem er das zugänglich macht, auch den Quellcode zugänglich > machen. Korrekt. > RedHat macht das Material aber halt nicht allen zugänglich, sondern nur > seinen Kunden, die über Zusatzvereinbarungen daran gehindert werden > sollen, das weiterzuverbreiten. Inkorrekt, derartige Zusatzvereinbarungen läßt die GPL nicht zu. Jedoch gilt auch für RedHat der Grundsatz der Vertragsfreiheit. Also können sie einfach den Vertrag mit Kunden beenden, die den Code weitergeben.
Könnte ich in meinen Projekten eine COPYING Datei neben der GPL Lizenz anlegen, und da was in die Richtung rein schreiben:
1 | This code is licensed under the GPL, and I (Daniel Abrecht) grant a GPL license for the code I am the copyright holder of to everyone, except for: |
2 | * Red Hat, Inc. |
3 | * Anyone intending to grant the license to them. |
4 | |
5 | This is because I believe they currently do not follow the intent behind the GPL license. |
6 | |
7 | A copy of the GPL license can be found in the LICENSE file. |
Daniel A. schrieb: > Könnte ich in meinen Projekten eine COPYING Datei neben der GPL Lizenz > anlegen, und da was in die Richtung rein schreiben: Wenn du der Rechteinhaber bist, kannst du komplett eigene Lizenzen erstellen und deinen Code auch unter verschiedenen Lizenzen bereitstellen. Ich würde eher Abstand davon halten eine solche Datei zu erstellen und das Ganze trotzdem unter GPL laufen zu lassen, das geht vermutlich eher in die Hose, theoretisch könnte ja jemand einen Fork von deinem Code erstellen ohne diese Klausel, weil die Lizenz selbst ja nicht geändert wird und eine weitere Person könnte diesen Fork dann an Red Hat weiter lizenzieren, ich würde da eher das Ganze in eine eigene an die GPL angelehnte Lizenz einbauen. So das es direkt als nicht änderbare Lizenz definiert ist. Die Zusatzdatei wäre ja eine Änderung der GPL und somit würdest du behaupten es wäre GPL, was es ja eindeutig nicht ist. Wobei sich die Frage stellt, wenn dein Code offen verfügbar ist und jemand sich (vermeintlich) nicht an die GPL hält, wie willst du es dann verhindern, dass das nicht ebenso mit deiner eigenen Lizenz(-Erweiterung) geschieht?
Rolf M. schrieb: > Es scheint tatsächlich, dass man bei der Download-Option (6d) nur denen > auf die Sourcen Zugriff geben muss, die auch Zugriff auf die Binaries > haben ("offer equivalent access to the Corresponding Source"), während > man bei der "written offer" (6b) jedem, der das Binary hat, auch die > Quellen geben muss. Diese Unterscheidung finde ich seltsam. Nicht jedem, der das Binary hat, sondern nur dem, der das Binary und die "Written Offer" hat. Das ist also quasi eine Berechtigungsurkunde für den Quellcode. Nach 6c lässt sich die "Written Offer" noch im nichtkommerziellen, gelegentlichen Rahmen kopieren und zusammen mit dem Binary weitergeben.
Marc X. schrieb: > Wenn du der Rechteinhaber bist, kannst du komplett eigene Lizenzen > erstellen und deinen Code auch unter verschiedenen Lizenzen > bereitstellen. Das ist bei meinen Projekten in der Regel der Fall. Aber da liegt wohl auch das Problem mit meiner Idee, dann könnte ich Nähmilch keine Änderungen von anderen annehmen, denn deren Code wäre ja unter der GPL, und die geben die Lizenz ja weiterhin an jeden, damit würde das Copyleft greifen, und wenn ich den Code einfach so von jedem Download lasse, könnte ich da nichts mehr dagegen machen... Marc X. schrieb: > Ich würde eher Abstand davon halten eine solche Datei zu > erstellen und das Ganze trotzdem unter GPL laufen zu lassen, das geht > vermutlich eher in die Hose, theoretisch könnte ja jemand einen Fork von > deinem Code erstellen ohne diese Klausel, weil die Lizenz selbst ja > nicht geändert wird und eine weitere Person könnte diesen Fork dann an > Red Hat weiter lizenzieren, Ja, das Problem gäbe es natürlich. > ich würde da eher das Ganze in eine eigene an die GPL angelehnte Lizenz einbauen. So das es direkt als nicht > änderbare Lizenz definiert ist. Die Zusatzdatei wäre ja eine Änderung > der GPL und somit würdest du behaupten es wäre GPL, was es ja eindeutig > nicht ist. Das hingegen ist nicht der Fall. Es ist üblich, in der COPYING Datei klarzustellen, welche Dateien unter welchen Lizenzen stehen. Und hier mache ich ja nichts anderes als das. Ich füge ja keine Bedingung der GPL hinzu, ich gebe die Lizenz nur nicht an jeden, nämlich nicht an RedHat. Allen anderen gebe ich den Code unter der Lizenz, unverändert. Mehr ist dahinter nicht. Wenn RedHat auch eine Lizenz haben will, können sie ja fragen, ob ich ihnen eine gebe. Aber eben, die anderen Probleme mit der Idee sind trotzdem da...
Beitrag #7450336 wurde vom Autor gelöscht.
Rolf M. schrieb: > Diese Unterscheidung finde ich seltsam. Wenn man 6b als Absatz für physikalische Geräte versteht, dann passt es. Dann stellt es sicher, dass bei sowas wie einer Weitergabe der Binaries im ROM des Gerätes der neue Besitzer auch Zugang zum Source hat. https://www.gnu.org/licenses/gpl-faq.html#WhatDoesWrittenOfferValid
:
Bearbeitet durch User
Thorsten M. schrieb: > Nicht jedem, der das Binary hat, sondern nur dem, der das Binary und die > "Written Offer" hat. Hmm, stimmt, wer die "written offer" nicht hat, hat ja eigentlich gar keine Basis, um den Quellcode zu verlangen. Ich finde es aber in der Lizenz etwas missverständlich formuliert, weil sie sich ausdrücklich auf alle, die das Binary haben, bezieht, ohne eine weitere Einschränkung zu nennen. > Nach 6c lässt sich die "Written Offer" noch im > nichtkommerziellen, gelegentlichen Rahmen kopieren und zusammen mit dem > Binary weitergeben. Ah, jetzt verstehe ich, wie 6c gemeint ist. Das war mir bisher nicht so richtig klar. Wobei ich mich da frage, was denn in dem Kontext "gelegentlich" und "nichtkommerziell" genau bedeutet. https://www.gnu.org/licenses/gpl-faq.html#RedistributedBinariesGetSource bezieht sich wohl genau darauf. Deshalb steht da "my friend".
Ein T. schrieb: > gilt auch für RedHat der Grundsatz der Vertragsfreiheit. Also können sie > einfach den Vertrag mit Kunden beenden, die den Code weitergeben. Kündigung eines laufenden Vertrages aufgrund einer Handlung, die per GPL zulässig ist, wäre härterer Tobak und ein grösseres Risiko für Red Hat, als Nichtverlängerung eines abgelaufenen Vertrages. Man muss wohl im Recht jenseits der GPL suchen, inwieweit eine solche Massnahme von Red Hat nur auf der Basis einer unerwünschten Weitergabe rechtlich angemessen ist. Man mag der Ansicht sein, dass Red Hats Schema dem Geist der GPL zuwider handelt, aber solche Geister können schwer zu fassen sein. Da wird man mit Paragraphen allein nicht weiter kommen. Sondern benötigt Richter, die das im jeweilige Rechtssystem entscheiden.
:
Bearbeitet durch User
(prx) A. K. schrieb: > Wie Rocky&Co das angehen wollen, weiss ich nicht. Ein hier beschriebenes Schema: Eine Cloud-Maschine mit der aktuellen Version mieten und den Code rausziehen. Um das zu verhindern, müsste Red Hat (IBM) sich mit Lizenzierung und Vertriebsmodellen solcher Cloud-Hoster näher beschäftigen. https://rockylinux.org/news/keeping-open-source-open/
:
Bearbeitet durch User
Stefan F. schrieb: > (prx) A. K. schrieb: >> Ist beispielsweise Rocky Linux Kunde von Red Hat, können sie auf der >> bisherigen Basis weiter machen, weil eine Einschränkung der Weitergabe >> durch Rocky Linux nicht zulässig ist. > > Andererseits behält RedHat sich vor, eben wegen der Weitergabe der > Quelltexte, den Vertrag zu beenden und das Aschließen neuer Verträge > abzulehnen. > Und? Steht in der GPL daß es verboten ist?
Jens B. schrieb: > Und? Steht in der GPL daß es verboten ist? Genau das ist die Frage. Ist eine Drohung mit Nichtverlängerung des Vertragsverhältnisses aufgrund Weitergabe eine Einschränkung der GPL im Sinne von "You may not impose any further restrictions on the exercise of the rights granted or affirmed under this License."? Oder ist das einfache Vertragsfreiheit?
:
Bearbeitet durch User
(prx) A. K. schrieb: > Ein T. schrieb: >> gilt auch für RedHat der Grundsatz der Vertragsfreiheit. Also können sie >> einfach den Vertrag mit Kunden beenden, die den Code weitergeben. > > Kündigung eines laufenden Vertrages aufgrund einer Handlung, die per GPL > zulässig ist, wäre härterer Tobak und ein grösseres Risiko für Red Hat, > als Nichtverlängerung eines abgelaufenen Vertrages. Auf die Gefahr hin, mich zu wiederholen: Na und? Es gibt genug Alternativen. > Man muss wohl im Recht jenseits der GPL suchen, inwieweit eine solche > Massnahme von Red Hat nur auf der Basis einer unerwünschten Weitergabe > rechtlich angemessen ist. "Angemessen" ist keine Rechtskategorie, die Frage ist vielmehr, ob es rechtlich zulässig ist oder nicht. Aber ich glaube, das ist auch nicht wichtig, denn... > Man mag der Ansicht sein, dass Red Hats Schema > dem Geist der GPL zuwider handelt, aber solche Geister können schwer zu > fassen sein. Da wird man mit Paragraphen allein nicht weiter kommen. > Sondern benötigt Richter, die das im jeweilige Rechtssystem entscheiden. ...ich rechne damit, daß sich das Thema von alleine lösen wird. Vermutlich wird kein Projekt mehr RPM-Pakete zur Bereicherung von RedHat erstellen (okay, einige hartnäckige RedHat-Fans wie Pulp vielleicht...), und dann sind zwei Szenarien denkbar: entweder RedHat wird von der Community ganz langsam ausgehungert, oder sie leisten etwas für ihr Geld und bauen ihre eigenen Pakete. So oder so könnte diese Aktion dazu führen, daß RedHat in der Community endlich marginalisiert wird, und das wäre jedenfalls nach meinem persönlichen Dafürhalten ohnehin längst überfällig. :-)
Stefan F. schrieb: > Wo ist Percy? Er würde uns vermutlich darauf hinweisen, kein Fachmann für Lizenz- und / oder us-amerikanisches Recht zu sein... Aber, wie gesagt: die Community wird wohl auf ihre eigene Weise damit umgehen, keine Sorge.
Beitrag #7450467 wurde vom Autor gelöscht.
(prx) A. K. schrieb im Beitrag #7450467: > Ein T. schrieb: >> Es gibt genug Alternativen. > > Für Linux-Quellcode schon. Bei dem, was Red Hat anbietet, nämlich > Enterprise-Support Dafür gibt es auch genug Alternativen -- große wie Canonical und SuSE oder kleinere wie -- zum Beispiel -- in D die Credativ. Der Unterschied bei den kleineren ist nur, daß die keine eigene Distribution haben, sondern solche supporten, die andere entwickeln... etwa Debian. Das spielt im Linuxumfeld allerdings eine untergeordnete Rolle, die "Enterprise-Distributoren" bauen ja auch fast ausschließlich auf fremdem Code auf. Eine eigene Distribution bietet dann, strategisch betrachtet, keinen großen Vorteil. > für eine langfristig stabile Plattform "Langfristig stabil" ist ein Euphemismus... und im Enterpriseumfeld sehe ich, wie die alten Dogmen (etwa "never change a running sysem") langsam verschwinden und immer seltener versucht wird, veraltete Software bis zum geht-nicht-mehr auszuwringen. Sicherlich tragen auch moderne Prozesse wie Test-Driven-Development, CI / CD und Automatisierung dazu bei, daß Change nicht mehr überall als Das Ganz Große Grauen (tm) gesehen wird. > Und SUSE als althergebrachte Alternative dazu ist fein > raus. Ein CentOS-Pendant für SLES ist mir nicht bekannt, weshalb SUSE > schon dort ist, wo Red Hat überhaupt erst hin will. Ja, das ist eine von mehreren Alternativen und an der Stelle merkt man natürlich auch, woher die Unternehmen kommen. Nach der Übernahme der SuSE durch Novell wurde SuSE Linux mit dem SLES konsequent auf die Bedürfnisse von Unternehmen ausgerichtet -- die SuSE brachte dabei das Linux mit, und Novell seine Erfahrungen im Unternehmensumfeld. Diese hätte zwar IBM, aber ein Jährchen nach der Übernahme wird davon vermutlich noch nicht sehr viel in die Produkte von RedHat eingeflossen sein, insbesondere auch nicht weil IBM ja mit AIX noch ein Konkurrenzprodukt im Hause hat. Andererseits sehe ich im Bereich unserer Kunden aus der Finanzbranche, die als besonders konservativ und unbeweglich gilt, in den letzten zehn Jahren immer mehr Bewegung. Da sehe ich immer öfter Debian und PostgreSQL (oder EnterpriseDB) anstelle von AIX und RedHat. Und auch wenn sich RedHat im Laufe der Jahre durchaus um die OSS-Community verdient gemacht hat, werde ich ihre Konzentration von Marktmacht und ihre Spaltpilz-Aktionen (think GCC 2.96, Gnome vs. KDE, Podman vs. Docker, Mono... und so weiter, und so fort) sicherlich nicht vermissen.
RedHat stellt den Kunden weiterhin den kompletten Sourcecode zur Verfügung. Und RedHat stellt der Öffentlichkeit auch den kompletten Sourcecode zur Verfügung. Nur nicht mehr in einer Form, die es per Knopfdruck erlaubt RHEL binärkompatibel nachzubauen. Dafür ist nun erheblich mehr Aufwand notwendig. Es ist aber immer noch möglich. Desweiteren behält sich RH vor die Geschäftsbeziehung mit Kunden zu beenden, die den "One-Klick-Sourcecode" weiterverbreiten. Das ist natürlich eine unredliche Ausnutzung von Freier Software, aber das ist mit ziemlicher Sicherheit gerade noch so legal. Legitim ist es aber natürlich nicht.
Ein T. schrieb: > ...ich rechne damit, daß sich das Thema von alleine lösen wird. > Vermutlich wird kein Projekt mehr RPM-Pakete zur Bereicherung von RedHat > erstellen (okay, einige hartnäckige RedHat-Fans wie Pulp vielleicht...), > und dann sind zwei Szenarien denkbar: entweder RedHat wird von der > Community ganz langsam ausgehungert, oder sie leisten etwas für ihr Geld > und bauen ihre eigenen Pakete. So oder so könnte diese Aktion dazu > führen, daß RedHat in der Community endlich marginalisiert wird, und das > wäre jedenfalls nach meinem persönlichen Dafürhalten ohnehin längst > überfällig. :-) Ziemlicher Unsinn. RedHat (und auch der IBM-Mutterkonzern) ist einer der größten Einzelkontributoren in Linux und anderer freier Software. Sie hier so darzustellen, als würden sie nur die Kirschen von der Freie-Software-Torte essen, ist schlichtweg falsch. RedHat wird es nicht die Bohne jucken, wenn irgendwelche Entwickler keine RPM-Pakete mehr zur Verfügung stellen. RedHat verwendet auch heute keine vom Upstream zur Verfügung gestellten Pakete. RedHat ist und bleibt ein wichtiger Bestandteil der Community, auch wenn sie seit mittlerweile Jahrzehnten unredliche Geschäftspraktiken führen. Technisch sind sie wichtig für die Community und für Freie Software insgesamt.
(prx) A. K. schrieb: >> Und? Steht in der GPL daß es verboten ist? > > Genau das ist die Frage. Ist eine Drohung mit Nichtverlängerung des > Vertragsverhältnisses aufgrund Weitergabe eine Einschränkung der GPL im > Sinne von "You may not impose any further restrictions on the exercise > of the rights granted or affirmed under this License."? Oder ist das > einfache Vertragsfreiheit? Die Frage ist nicht relevant, weil RedHat weiterhin den vollen Sourcecode öffentlich bereitstellt. Nur nicht mehr in einer Form, die es per Knopfdruck erlaubt eine binärkompatible eigene Variante nachzubauen. Das ist zwar weiterhin möglich, nur mit erheblich mehr Aufwand.
Jens B. schrieb: >> Andererseits behält RedHat sich vor, eben wegen der Weitergabe der >> Quelltexte, den Vertrag zu beenden und das Aschließen neuer Verträge >> abzulehnen. > Und? Steht in der GPL daß es verboten ist? Ja, das steht in der GPL: >You may not impose any further restrictions on the recipients' >exercise of the rights granted herein. Wenn RedHat also die GPL-Rechte nur unter der Bedingung der Beendigung aller Vertragsverhältnisse bereitstellen würde, wäre das ziemlich sicher ein Lizenzbruch gegenüber Upstream. Spielt hier aber keine Rolle, weil RedHat den vollen GPL-SourceCode weiterhin öffentlich bereitstellt.
MaWin O. schrieb: > Spielt hier aber keine Rolle, weil RedHat den vollen GPL-SourceCode > weiterhin öffentlich bereitstellt. Es geht in der GPL um exakt jenen Stand der Sourcen, wie er ausgelieferten Binaries entspricht. Auch wenn die Sourcen alle öffentlich sind, fehlt nun die Information, welcher Stand wozu gehört. Und damit ist eine Kernforderung nicht mehr erfüllt, dass man die Binaries selbst erzeugen und eigene Modifikationen anbringen kann.
:
Bearbeitet durch User
Daniel A. schrieb: > Könnte ich in meinen Projekten eine COPYING Datei neben der GPL Lizenz > anlegen, und da was in die Richtung rein schreiben:This code is licensed > under the GPL, and I (Daniel Abrecht) grant a GPL license for the code I > am the copyright holder of to everyone, except for: > * Red Hat, Inc. > * Anyone intending to grant the license to them. Selbstverständlich kannst du das tun. Du hättest damit halt eine eigene proprietäre Lizenz geschaffen. Dann wäre dein Code inkompatibel zur GPL und würde wahrscheinlich auch von Distributionen wie Debian als unfreie Software angesehen werden. In der Praxis würde wohl niemand etwas von einer solchen Software ableiten wollen, weil diese Einschränkung ja wie ein Krebs wuchern würde.
(prx) A. K. schrieb: > Es geht in der GPL um exakt jenen Stand der Sourcen, wie er > ausgelieferten Binaries entspricht. Auch wenn die Sourcen alle > öffentlich sind, fehlt nun die Information, welcher Stand wozu gehört. Nein, diese Information wird den Kunden bereitgestellt. > Und damit ist eine Kernforderung nicht mehr erfüllt, dass man die > Binaries selbst erzeugen und eigene Modifikationen anbringen kann. Warum sollte das so sein? Der vollständige Sourcecode ist vorhanden. Warum solltest du als Nicht-Kunde ein Recht haben die exakte RHEL-Binary nachbauen zu können? Die GPL räumt dir ein solches Recht gar nicht ein. Du kannst dir den Sourcecode für jedes Binary herunterladen. Die Information, welche dieser Sourcecodes in welcher Kombination in welche RHEL geflossen ist, ist nicht von der GPL gedeckt.
Daniel A. schrieb: > Könnte ich in meinen Projekten eine COPYING Datei neben der GPL Lizenz > anlegen, und da was in die Richtung rein schreiben: Mit ausschliesslich eigenem Code kannst du machen was du willst. Kombinierst du jedoch deinen Code mit Code unter der GPL in einer Form, wie sie in der GPLv3 entsprechend aufgeführt ist, verletzt du damit die GPL.
MaWin O. schrieb: > RedHat (und auch der IBM-Mutterkonzern) ist einer der größten > Einzelkontributoren in Linux und anderer freier Software. > Sie hier so darzustellen, als würden sie nur die Kirschen von der > Freie-Software-Torte essen, ist schlichtweg falsch. So ein Quatsch. Nichts davon hatte ich bestritten. > RedHat wird es nicht die Bohne jucken, wenn irgendwelche Entwickler > keine RPM-Pakete mehr zur Verfügung stellen. RedHat verwendet auch > heute keine vom Upstream zur Verfügung gestellten Pakete. Da ging es aber gar nicht um Software, die ohnehin in RHEL enthalten ist, sondern um jene Projekte, die nicht enthalten sind und die bisher CentOS oder Rocky als kompatible Build- und Testplattform nutzen konnten. Wie sollen die das in Zukunft machen? Du darfst ausnahmsweise gerne auch mal ein bisschen mitdenken. Wenn Du Dir ein bisschen Mühe gibst, schaffst Du das ganz bestimmt. Danke. > RedHat ist und bleibt ein wichtiger Bestandteil der Community, auch wenn > sie seit mittlerweile Jahrzehnten unredliche Geschäftspraktiken führen. > Technisch sind sie wichtig für die Community und für Freie Software > insgesamt. Das sehe ich nicht, wird sich aber zeigen.
Ein T. schrieb: > Du darfst ausnahmsweise gerne auch mal ein bisschen mitdenken. Wenn Du > Dir ein bisschen Mühe gibst, schaffst Du das ganz bestimmt. Danke. In diesem Stil diskutiere ich nicht.
MaWin O. schrieb: > Warum solltest du als Nicht-Kunde ein Recht haben die exakte RHEL-Binary > nachbauen zu können? Weil das so in GPLv3 Abschnitt 6 drinsteht. Die Weitergabe der Binaries von Kunde zu Nichtkunde muss so erfolgen, dass der Empfänger - der ja nicht notwendigerweise Kunde von Red Hat ist - dies kann.
MaWin O. schrieb: > Warum solltest du als Nicht-Kunde ein Recht haben die exakte RHEL-Binary > nachbauen zu können? Die GPL räumt dir ein solches Recht gar nicht ein. Das Binary muss nicht Byte für Byte gleich sein, aber die Sourcen müssen exakt übereinstimmen. Aus der GPL: The “Corresponding Source” for a work in object code form means all the source code needed to generate, install, and (for an executable work) run the object code and to modify the work, including scripts to control those activities. > Du kannst dir den Sourcecode für jedes Binary herunterladen. Die > Information, welche dieser Sourcecodes in welcher Kombination in welche > RHEL geflossen ist, ist nicht von der GPL gedeckt. Doch, genau das ist es. Selbstverständlich is ist der "corresponding source" nicht einfach irgendein Quellcode, sondern exakt der, der verwendet wurde, um das Binary zu bauen.
:
Bearbeitet durch User
Beitrag #7450551 wurde vom Autor gelöscht.
(prx) A. K. schrieb: >> Warum solltest du als Nicht-Kunde ein Recht haben die exakte RHEL-Binary >> nachbauen zu können? > > Weil das so in GPLv3 Abschnitt 6 drinsteht. Die Weitergabe der Binaries > von Kunde zu Nichtkunde muss so erfolgen, dass der Empfänger - der ja > nicht notwendigerweise Kunde von Red Hat ist - dies kann. Nein, das steht dort nicht. Der Bauprozess von RHEL fällt überhaupt gar nicht unter die GPL-Bedingungen des Upstream-Codes. Was die Lizenz des Upstream-Codes fordert ist die vollständige Veröffentlichung ebenjenes (modifizierten) Quellcodes. RHEL-Metainformationen fallen da nicht darunter. Da hat RedHat selbstverständlich eigene Rechte dran und sie können damit tun was sie wollen. Paketierung ist kein abgeleitetes Werk. Wenn in deinem Auto Freie Software ist, dann ist es völlig Upstream-lizenzkonform, wenn der Hersteller dir die Sourcen von allen jemals ausgelieferten Modellen bereitstellt. Er muss dir nicht sagen welche dieser Versionen jetzt exakt zu deinem Modell passt und er muss dich auch keine weitere Hilfestellung liefern wie du das Projekt bauen kannst. Es muss lediglich prinzipiell buildfähig sein. Zur tatsächlichen Buildfähigkeit ist dann noch ein weiter weg, bei dem der Hersteller dir nicht helfen muss.
MaWin O. schrieb: > Nein, das steht dort nicht. Rolf hat das in der aktualisierten Fassung seines Beitrags näher ausgeführt.
:
Bearbeitet durch User
Rolf M. schrieb: > Das Binary muss nicht Byte für Byte gleich sein, aber die Sourcen müssen > exakt übereinstimmen. Ist ja auch vorhanden. > Aus der GPL: > The “Corresponding Source” for a work in object code form means all the > source code needed to generate, install, and (for an executable work) > run the object code and to modify the work, including scripts to control > those activities. Wird alles geliefert. Was nicht geliefert wird, sind die Scripte und Metadaten um RHEL zu bauen. Aber das ist ja auch gar nicht notwendig. Die Lizenz ist befriedigt, wenn du dir das Einzelprogramm auf deinem nicht-RHEL bauen und installieren kannst. Rolf M. schrieb: >> Du kannst dir den Sourcecode für jedes Binary herunterladen. Die >> Information, welche dieser Sourcecodes in welcher Kombination in welche >> RHEL geflossen ist, ist nicht von der GPL gedeckt. > > Doch, genau das ist es. Selbstverständlich is ist der "corresponding > source" nicht einfach irgendein Quellcode, sondern exakt der, der > verwendet wurde, um das Binary zu bauen. Der "corresponding source" ist vorhanden. Öffentlich und für jede Version. Was nicht mehr öffentlich vorhanden ist, ist die einfache Zuordnung Binary zu Source. Das ist aber auch gar nicht notwendig zu veröffentlichen.
MaWin O. schrieb: > In diesem Stil diskutiere ich nicht. Diesen "Stil" hatte ich extra von Dir übernommen: MaWin O. schrieb: > Ziemlicher Unsinn.
MaWin O. schrieb: > Das ist aber auch gar nicht notwendig zu veröffentlichen. Es reicht nicht aus, jemandem an Stelle des exakten Sandkorns einen Sandkasten zu zeigen. Möge er doch selber suchen.
:
Bearbeitet durch User
MaWin O. schrieb: > Was nicht mehr öffentlich vorhanden ist, ist die einfache Zuordnung > Binary zu Source. Eben, aber die ist zwingend erforderlich, denn wie soll ich aus den Sourcen das Binary bauen, wenn ich nicht weiß, welche ich nehmen soll? > Das ist aber auch gar nicht notwendig zu veröffentlichen. Dass das notwendig ist, steht ausdrücklich in der GPL: If the place to copy the object code is a network server, the Corresponding Source may be on a different server (operated by you or a third party) that supports equivalent copying facilities, provided you maintain clear directions next to the object code saying where to find the Corresponding Source.
(prx) A. K. schrieb: > Es reicht nicht aus, jemandem auf Anfrage nach dem exakten Sandkorn > einen Sandkasten zu zeigen. Möge er doch selber suchen. Doch, das reicht eben aus. Mit der GPL2 muss man nicht einmal in der Lage sein die Software überhaupt betreiben zu können ("Tivoization"). So sind halt die Bedingungen und RedHat nutzt das knallhart aus. Das geht ganz klar gegen den Gedanken hinter Freier Software, ist aber vollkommen legal. Ein T. schrieb: > Diesen "Stil" hatte ich extra von Dir übernommen: Ich habe Unsinn als Unsinn bezeichnet. Du hast mich persönlich beleidigt. Merkst du den Unterschied? Aber ich kann deine Frage auch gerne beantworten: Ein T. schrieb: > Wie sollen die das in Zukunft machen? Mit RHEL. Es gibt eine kostenlose Entwicklerlizenz für alle interessierten Entwickler. Und die gab es auch schon vorher. Die ist genau für diesen Zweck gedacht. Und darüber hinaus erlaubt sie dir sogar die Systeme im Produktiveinsatz zu nutzen. Lediglich die Anzahl der Systeme ist beschränkt.
Rolf M. schrieb: > If the place to copy the object code is a network server, the > Corresponding Source may be on a different server (operated by you or a > third party) that supports equivalent copying facilities, provided you > maintain clear directions next to the object code saying where to find > the Corresponding Source. RedHat liefert jedem, denen sie das Binary liefern, ebenjene Information. Das heißt aber nicht, dass sie diese Information veröffentlichen müssen.
MaWin O. schrieb: > Das heißt aber nicht, dass sie diese Information veröffentlichen müssen. Korrekt, das müssen sie gegenüber Dritten nicht. Wohl aber der Kunde gegenüber einem Dritten, wenn er ihm er die Binaries überreicht. Aber da sind wir nun bei "we agree to disagree" angekommen. Du meinst, der Sandkasten reiche aus. Andere meinen, er reiche nicht aus.
:
Bearbeitet durch User
(prx) A. K. schrieb: > Korrekt, das müssen sie gegenüber Dritten nicht. Wohl aber der Kunde > gegenüber einem Dritten, dem er die Binaries überreicht. Aber da sind > wir nun bei "we agree to disagree" angekommen. Du meinst, der Sandkasten > reicht. Jeder andere meint, er reicht nicht. Wenn ich ein Binary foobar-1.2.3 von einem RH-Kunden bekomme, dann ist es mit öffentlichen Ressourcen möglich anhand der Versionsnummer die Source dazu zu bekommen. Da gibt es überhaupt gar keine Hürden. Der Kunde kann ganz einfach auf die Datei im öffentlichen Repo zeigen. Fertig. Lizenz erfüllt. Was nicht so einfach öffentlich verfügbar ist, ist in welche RHEL diese Binary eingebaut ist und in welchen Kombinationen die Paketversionen dort verwendet werden. Das ist aber auch nicht von der GPL gefordert. Deine Sandkastenanalogie ist schlicht falsch.
(prx) A. K. schrieb: > da sind wir nun bei "we agree to disagree" angekommen ... und drehen uns im Kreis.
:
Bearbeitet durch User
(prx) A. K. schrieb: > ... und drehen uns im Kreis. Ja gut. Aus diesem Kreis kannst du dich nur selbst befreien.
MaWin O. schrieb: > Wenn ich ein Binary foobar-1.2.3 von einem RH-Kunden bekomme, dann ist > es mit öffentlichen Ressourcen möglich anhand der Versionsnummer die > Source dazu zu bekommen. Da gibt es überhaupt gar keine Hürden. Der > Kunde kann ganz einfach auf die Datei im öffentlichen Repo zeigen. > Fertig. Lizenz erfüllt. Der Kunde hat aber auch das Recht, das Binary uneingeschränkt weiterzugeben, geschenkt oder auch gegen Geld, und er hat das Recht (und auch die Pflicht), dann ebenfalls die Sourcen verfügbar zu machen. Wenn aber RedHat die Ausübung dieses Rechts als Anlass nimmt, das Vertragsverhältnis zu kündigen (*), könnte man das schon als unzulässige Einschränkung sehen. Ob es das ist, werden aber wohl Juristen entscheiden müssen. * Nach dem Motto: Klar darfst du die Sourcen frei und ohne jegliche Einschränkungen weitergeben, aber denn werden wir mit sofortiger Wirkung alle Geschäftsbeziehungen zu dir einstellen.
:
Bearbeitet durch User
Rolf M. schrieb: > Der Kunde hat aber auch das Recht, das Binary uneingeschränkt > weiterzugeben, geschenkt oder auch gegen Geld, und er hat das Recht (und > auch die Pflicht), dann ebenfalls die Sourcen verfügbar zu machen. Wenn > aber RedHat die Ausübung dieses Rechts als Anlass nimmt, das > Vertragsverhältnis zu kündigen Nein. RedHat schränkt das Recht die Software ansich weiterzugeben nicht ein. Sie schränken nur die Weitergabe von ihren eigenen RHEL-Buildscripten und Buildmetainformationen für RHEL ein. Die RHEL-Scripte und Informationen sind nicht und waren nie von der Upstream-GPL gedeckt. Sie sind unter RH-Copyright mit eigener Lizenz und ebenjener Einschränkung. Sie wollen nicht das Weiterverbreiten der Software verhindern, die sie selbst nicht entwickelt haben. Sie wollen die einfache Weiterverbreitbarkeit ihres eigenen Teils einschränken. Wie ich schon mehrfach schrieb: Ich finde dieses Vorgehen unredlich und es widerspricht dem Gedanken hinter Freier Software grundsätzlich. Aber ich sehe hier beim besten Willen keinen Lizenzverstoß. Und einen solchen Lizenzverstoß von einem Unternehmen wie RedHat/IBM anzunehmen, ist schon extrem naiv. Die machen das nicht, ohne es vorher von Anwälten prüfen zu lassen.
MaWin O. schrieb: > Legitim ist es aber natürlich nicht. Natürlich ist es legitim. Dass alle Welt immer glaubt "GPL" wäre die heilsbringende Lizenz für jegliche Freiheit ist eh schon an Witz nicht mehr zu überbieten.
Michael H. schrieb: > Dass alle Welt immer glaubt "GPL" wäre die heilsbringende Lizenz für > jegliche Freiheit ist eh schon an Witz nicht mehr zu überbieten. Der Begriff "Freiheit" kam im Thread bisher ausschliesslich in Form von "Vertragsfreiheit" vor. Den hast erst du eingebracht, um Stunk zu provozieren.
:
Bearbeitet durch User
Hallo zusammen ich habe das erst jetzt durch diesen Thread mitbekommen, dass CentOS eingestellt werden soll. Das ist natürlich schlecht. Man erlaube mir folgende kleine Zwischenfrage: ich betreibe mehrere Server mit CentOS 7, auf denen kommerzielle Software läuft, die CentOS als Anforderung hat. Gut, 7 bekommt noch Updates, aber irgendwann ist Schluss. Was bedeutet das für mich als Admin? oder wird nur CentOS eingestellt und CentOS Stream gibts weiterhin? Das ist mir im Moment noch ein wenig undurchsichtig.
Michael H. schrieb: >> Legitim ist es aber natürlich nicht. > Natürlich ist es legitim. Das ist individuelle Ansichtssache. Wenn RedHat/IBM GPL-Software von mir kostenlos nimmt, damit ein eigenes stark eingeschränktes kommerzielles Produkt baut, was vom Wortlaut meiner Lizenz zulässig ist, dann finde ich das nicht legitim. Eben weil der Gedanke hinter der GPL ist, dass Freiheit zur Weiterverbreitung nicht eingeschränkt werden soll. Das Gesamtprodukt ist in diesem Fall aber eingeschränkt. (Die GPL ist da eben nicht perfekt. Insbesondere in der Version 2.) Wenn ich keinen Wert auf diese Freiheiten gelegt hätte, hätte ich eine andere Lizenz gewählt. Das ist meine ganz persönliche Einschätzung basierend auf den tatsächlichen Fakten, die RedHat/IBM schafft. Ich bin aber auch dagegen die GPL weiter zu verkomplizieren, um solch ein Verhalten zu verhindern. Selbst die GPL 3 geht mir schon zu weit und ich verwende sie so gut wie nie. > Dass alle Welt immer glaubt "GPL" wäre die heilsbringende Lizenz für > jegliche Freiheit ist eh schon an Witz nicht mehr zu überbieten. Niemand behauptet, dass die GPL "jegliche Freiheit" bringt.
Tobias P. schrieb: > ich betreibe mehrere Server mit CentOS 7, Wie viele? Wenn es nur eine Handvoll sind, dann kannst du die mit RHEL-Developer-Lizenz betreiben. > auf denen kommerzielle > Software läuft, die CentOS als Anforderung hat. Das ist dann das Problem des Anbieters dieser Software. > Gut, 7 bekommt noch Updates, aber irgendwann ist Schluss. Was bedeutet > das für mich als Admin? oder wird nur CentOS eingestellt und CentOS > Stream gibts weiterhin? Gibts weiterhin, soweit ich das verstanden habe.
Tobias P. schrieb: > Gut, 7 bekommt noch Updates, aber irgendwann ist Schluss. Und zwar RHEL7 folgend in einem Jahr. > oder wird nur CentOS eingestellt und CentOS > Stream gibts weiterhin? Ebendies.
Tobias P. schrieb: > auf denen kommerzielle > Software läuft, die CentOS als Anforderung hat. Die Anbieter dieser Software wird sich sicherlich bereits Gedanken über die Zukunft gemacht haben.
MaWin O. schrieb: > Und einen solchen Lizenzverstoß von einem Unternehmen wie RedHat/IBM > anzunehmen, ist schon extrem naiv. RedHat wurden in der Vergangenheit auch schon Verstöße gegen die GPL nachgewiesen. Es wäre also nicht so ungewöhnlich.
Rolf M. schrieb: > RedHat wurden in der Vergangenheit auch schon Verstöße gegen die GPL > nachgewiesen. Es wäre also nicht so ungewöhnlich. Links?
MaWin O. schrieb: > Links? Wurde oben schon genannt: https://sfconservancy.org/blog/2023/jun/23/rhel-gpl-analysis/
Rolf M. schrieb: > Wurde oben schon genannt: Ach. Mehr kommt da also nicht. Na dann bin ich ja beruhigt. Ich sehe nicht, was diese zwei Fälle mit dem aktuellen Fall zu tun haben sollen. Das sind völlig andere Situationen und es sind vor allem Einzelfälle mit einzelnen Kunden. Hier im Thread geht es ja aber um eine Grundsatzänderung, die den Tod für RedHat bedeuten würde, wenn sie nicht rechtskonform wäre.
Ihr muesst euch garnicht so verrenken. Redhat muss dem nicht-Kunden garnichts geben. Wenn ein RH-Kunde ein Binary an einen nicht-RH-Kunden weitergibt, dann tut er das unter den Bedingungen der GPL und muss seinerseits die Sourcen dem nicht-RH-Kunden zur verfuegung stellen. Tut er das nicht, verletzt er die GPL, nicht Redhat.
Lukey S. schrieb: > Ihr muesst euch garnicht so verrenken. Redhat muss dem nicht-Kunden > garnichts geben. > Wenn ein RH-Kunde ein Binary an einen nicht-RH-Kunden weitergibt, dann > tut er das unter den Bedingungen der GPL und muss seinerseits die > Sourcen dem nicht-RH-Kunden zur verfuegung stellen. Tut er das nicht, > verletzt er die GPL, nicht Redhat. Du darfst halt nicht vergessen, dass RedHat selbst Lizenznehmer ist und sich somit an die Upstream-Lizenzen zu halten hat, wenn RedHat die Binaries an seine Kunden gibt. Wenn RedHat die Sourcen nur unter der Bedingung, dass der Kunde sie nicht weitergibt oder den Vertrag verliert an den Kunden geben würde, dann wäre das ziemlich eindeutig nicht legal. Das tun sie aber nicht. Sie veröffentlichen alle Upstream-relevanten Quellen (mit Lizenznehmercharacter für RH) öffentlich.
MaWin O. schrieb: > Ein T. schrieb: >> Diesen "Stil" hatte ich extra von Dir übernommen: > > Ich habe Unsinn als Unsinn bezeichnet. Du hast mich persönlich > beleidigt. Merkst du den Unterschied? Dafür, daß Du hier gerne wie die Axt im Walde auftrittst, reagierst Du auf Gegenwind aber ganz schön empfindlich. Zudem hab ich Dich nicht beleidigt, Du willst das nur so darstellen. Merkst du den Unterschied? > Ein T. schrieb: >> Wie sollen die das in Zukunft machen? > > Mit RHEL. > Es gibt eine kostenlose Entwicklerlizenz für alle interessierten > Entwickler. Und die gab es auch schon vorher. Die gibt es aber nicht für Projekte, sondern lediglich für individuelle Entwickler, die mitunter gar keine Lust haben, sich einen RedHat-Account anzulegen und eine Lizenz für OpenSource-Software zu pflegen. Und wie das Ganze in modernen Zeiten stattfinden soll, Stichwort: Containerisierung, das steht nochmal auf einem ganz anderen Blatt... Die meisten OpenSource-Projekte, die ich persönlich kenne, sind personell ohnehin schon unterbesetzt (oder meinetwegen auch überambitioniert). Das fangen sie üblicherweise durch ein besonders hohes Engagement einzelner Mitwirkender aus, mal mehr und mal weniger erfolgreich. Ich kann nur für mich sprechen, aber mein Gedankengang ist: "Ich brauche RedHat nicht, und sie gehen mir seit Jahrzehnten auf den Keks. Warum sollte ich jetzt auch noch Arbeit investieren und ihnen meine Daten geben? Damit sie besser von meiner Arbeit schmarot^Wprofitieren können? Never. Ever." Außer Daniel in diesem Thread habe ich ähnliche Positionen auch schon von anderen Leuten gelesen, die in der Community mitwirken. Wie auch immer: RedHat stößt nicht nur die Community und renommierte Leute wie Theo Ts'o (Rocky Linux) vor den Kopf, sondern legt sich auch mit dem einen oder anderen Branchenriesen wie Oracle (Oracle Linux) und AMD (Alma Linux) an. Wie zulässig RedHats Schritt ist, wird daher wohl früher oder später auch gerichtlich überprüft werden. Das wird spannend.
Ein T. schrieb: > Dafür, daß Du hier gerne wie die Axt im Walde auftrittst, reagierst Du > auf Gegenwind aber ganz schön empfindlich. Hättest du ein Beispiel, wo ich Personen beleidige? > die mitunter gar keine Lust haben Tja. Persönliches Pech, würde ich sagen. > Damit sie besser von meiner Arbeit > schmarot^Wprofitieren können Voll die Schmarot^WProfiteure, die 5% des Kernels entwickeln. https://lwn.net/Articles/936113/ Wie viel zahlst du bei einem Kernelupdate an RedHat? > früher oder später auch gerichtlich überprüft werden. Das wird spannend. Eigentlich nicht.
MaWin O. schrieb: > Ein T. schrieb: >> Dafür, daß Du hier gerne wie die Axt im Walde auftrittst, reagierst Du >> auf Gegenwind aber ganz schön empfindlich. > > Hättest du ein Beispiel, wo ich Personen beleidige? Jetzt soll ich wieder etwas belegen, das ich niemals gesagt habe. Ist das nicht langweilig, immer nur Deine eigenen Strohpuppen anzuzicken? >> die mitunter gar keine Lust haben > > Tja. Persönliches Pech, würde ich sagen. Tja, aber wohl das von RedHat. Wenn Leute wie Jeff Geerling keine Umgebung mehr haben, um ihre Ansible-Rollen zu entwickeln, dann werden seine Rollen eben zukünftig kein RedHat mehr unterstützen. Das läuft dann ziemlich dumm für RedHat, denn RHEL hat ja vergleichen mit Distributionen wie Debian und seinen Derivaten einen ziemlich überschaubaren Umfang. Wenn solche Dritten jetzt ihre Unterstützung für RHEL einstellen, weil ihnen die Entwicklungs- und Testplattformen entzogen werden, wird RHEL bald sehr alt, sehr klein, und sehr, sehr häßlich aussehen. Tja. Genau diese Diskussionen -- die Du geflissentlich als "ziemlichen Unsinn" abtust -- finden gerade vielfach in der Community statt. Die meisten der Teilnehmer fühlen sich vor den Kopf gestoßen, über den Tisch gezogen, und betrogen. Ein nicht nur mir bekannter Entwickler sagt "endlich hab ich die richtigen Argumente, um unsere Enterprise-Leute vom Upgrade auf Ubuntu zu überzeugen", und ähnliche Ausführungen lese ich auch von anderen. Offenbar bekommst so Du überhaupt gar nichts davon mit, was gerade in der internen Kommunikation verschiedener OpenSource-Projekte stattfindet. Aber trotzdem gibst Du hier den Lauten... meine Güte. >> Damit sie besser von meiner Arbeit >> schmarot^Wprofitieren können > > Voll die Schmarot^WProfiteure, die 5% des Kernels entwickeln. > https://lwn.net/Articles/936113/ Und wenn es 90% wären: würde es ihnen dann das Recht geben, die Lizenzen anderer Softwareprojekte zu verletzen? > Wie viel zahlst du bei einem Kernelupdate an RedHat? Meine Güte... Wenn Du ernstgenommen werden möchtest, mußt Du Dir solchen Kinderkram wirklich abgewöhnen. So wird das nix. >> früher oder später auch gerichtlich überprüft werden. Das wird spannend. > > Eigentlich nicht. Das sehen wir ja dann, hm?
Jetzt sind Oracle die "Guten", LOL: https://www.oracle.com/news/announcement/blog/keep-linux-open-and-free-2023-07-10/
Daniel A. schrieb: > Jetzt sind Oracle die "Guten", LOL Ja echt, aber so ein Kommentar war von Oracle zu erwarten.
Jetzt muss Oracle nur noch die Lizenzierung der Oracle Database von "völlig gaga" auf "gerade noch akzeptabel" umstellen. Dann fange ich vielleicht an, den Laden wieder auf die Rechnung zu nehmen.
(prx) A. K. schrieb: > Jetzt muss Oracle nur noch die Lizenzierung der Oracle Database von > "völlig gaga" auf "gerade noch akzeptabel" umstellen. Meinst du dass Oracle sich pro CPU Kern bezahlen lässt. Aber das muss doch sein, schließlich macht jeder CPU Kern den Leuten viel Arbeit, die erledigt werden muss. Oder nicht?
Stefan F. schrieb: > Meinst du dass Oracle sich pro CPU Kern bezahlen lässt. Aber das muss > doch sein, schließlich macht jeder CPU Kern den Leuten viel Arbeit, die > erledigt werden muss. Oder nicht? Ach. Hast du nun herausgefunden, dass Lizenzkosten generell nicht darauf basieren, wie viel menschliche Arbeit entsteht?
Stefan F. schrieb: > Meinst du dass Oracle sich pro CPU Kern bezahlen lässt. Machen andere auch. Aber andere beziehen sich auf den Server, wo es drauf läuft. Oracle zählt auch alle anderen Server-Cores des Hauses mit. Ob die was mit Oracle zu tun haben, oder nicht. Wurde mir zumindest so vermittelt.
:
Bearbeitet durch User
(prx) A. K. schrieb: > Oracle zählt auch alle anderen Server-Cores des Hauses mit. > Ob die was mit Oracle zu tun haben, oder nicht. Wurde mir zumindest so > vermittelt. Soweit ich weiß betrifft das virtuelle Maschinen. Wenn der Host 64 Kerne hat, musst du für alle Kerne zahlen, auch wenn die VM der DB auf 2 Kerne beschränkt ist.
Stefan F. schrieb: > Soweit ich weiß betrifft das virtuelle Maschinen. Bei 100% VMs... > Wenn der Host 64 Kerne > hat, musst du für alle Kerne zahlen, auch wenn die VM der DB auf 2 Kerne > beschränkt ist. Und zwar nicht nur von dem einen VM-Host, sondern auch von allen anderen VM-Hosts. Wenn die des Lastausgleichs und der Verfügbarkeit halber einen HA-Cluster bilden (*), dann zahlst zu für aberhunderte bis tausende von Cores, obwohl bloss 2 davon Oracle machen. Was einen für uns wichtigen Software-Anbieter dazu zwang, auf PostgreSQL umzusteigen. Wäre sonst unbezahlbar gewesen. *: Angeblich zählen sogar weitere Cluster mit, die exakt nichts damit zu tun haben. Die einfach nur da sind. Ich hatte grosse Schwierigkeiten, das zu glauben und bekam den Eindruck, dass Oracle sich nicht für Neukunden interessiert, sondern die bestehenden Kunden solange aussaugen will, bis der letzte tot oder migriert ist.
:
Bearbeitet durch User
(prx) A. K. schrieb: > Was einen für uns wichtigen > Software-Anbieter dazu zwang, auf PostgreSQL umzusteigen. Wäre sonst > unbezahlbar gewesen. PostgreSQL ist für die meisten Anwendungsfälle eh die bessere Datenbank, also alles gut.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.