RHEL kopieren und dann auch noch versuchen, Red Hat die eigenen Kunden abspenstig zu machen: Da zieht selbst Red Hat die Notbremse. Ist das auch im Geiste der GPL o.k.? Ja, das ist es, da die RHEL-Kernel-Patches weiterhin nach Upstream wandern. Es gibt da aber viel schlimmere Textpassagen in den RHEL-Supportverträgen.
Das ist aber unglücklich formuliert. Die GPL verlangt nicht, daß Red Hats Änderungen am Kernel "nach Upstream wandern", sondern gibt nur vor, in welcher Form diese Änderungen zu veröffentlichen sind.
Das meinte ich nicht. In den Kommentaren zum oben verlinkten LWN-Artikel wurde das, was ich oben angesprochen habe, schon diskutiert.
Es geht um solche "RHEL"-Paragraphen:
"Distributing the Software or any portion of the Subscription Services to a third party or using any of the Subscription Services for the benefit of a third party is a material breach of the Agreement even though the open source license applicable to individual software packages may give you the right to distribute those packages."
und
"Any unauthorized use of the Subscription Services is a material breach of the Agreement, such as (a) only purchasing or renewing Subscription Services based on some, but not all, of the total number of Units of Red Hat Software or other Red Hat Product that you deploy, install, use or execute [...] [!!!] For the purposes of this paragraph (for example, in calculating the total number of Units of Software), Software would include versions or copies that have the Red Hat trademark(s) and/or logo file(s) removed. [!!!]" [Die Ausrufezeichen sind von mir.]
Erinnerst Du Dich noch, wie Shuttleworth RHEL mit dem Begriff "quasiproprietär" (oder so ähnlich) umschrieben hat? Das ist nicht so meilenweit daneben. Allerdings ist es hier nicht einfach zu entscheiden, ob die Bedingungen für die RHEL Subscription Services durch die GPL gewährte Rechte tatsächlich auch verletzen oder nicht. Jedenfalls ist das IMO hart an der Grenze.
> Ist das auch im Geiste der GPL o.k.? > Ja, das ist es, da die RHEL-Kernel-Patches weiterhin nach Upstream wandern.
Nur darauf bezog ich mich in meinem Kommentar.
Deinen Ausführungen zu den Wartungs- und Supportverträgen kann ich so nicht folgen. RHEL ist quelloffen. Du kannst mit den veröffentlichten src.rpm Paketen tun, was deren Lizenzbestimmungen erlauben. Ggf. mußt Du bei der Verwendung darüberhinaus noch Markenrechte beachten - das beschränkt sich aber nicht nur für Open Source Software von Red Hat. Gehst Du Wartungsverträge mit Red Hat ein, so haben die ihre eigenen Spielregeln, Du nimmst dabei gewöhnlich kostenpflichtige Leistungen in Anspruch, die weit über das reine Zusammenstellen und Verfügbarmachen von OSS hinausgehen.
Allerdings ist es hier nicht einfach zu entscheiden, ob die Bedingungen für die RHEL Subscription Services durch die GPL gewährte Rechte tatsächlich auch verletzen oder nicht. Jedenfalls ist das IMO hart an der Grenze.
Die Redhat Lizenzverträge sind mit an Sicherheit grenzender Wahrscheinlichkeit GPL-konform. Ich glaube das aus zwei Gründen:
1) Redhat ist ein sehr guter "Bürger" der freien Software Community, wenn man als Vergleich Novell, Oracle oder Google heranzieht. Die Leute bei Redhat werden nicht blöd sein und durch Lizenzverletzungen ihren Bonus bei der Community verlieren wollen.
2) Die FSF hätter DER führenden kommerziellen Distribution schon die Rute ins Fenster gestellt, hätte Redhat die GPL auch nur im geringsten verletzt, schließlich hält die FSF die Copyrights für viele der zentralen Distributionsbestandteile.
Du sagst ja wohl nicht, dass Du diese Bestimmungen ganz toll findest?
Da steht doch defacto: Solange man die Red Hat Subscription Services benutzt, solange darf man RHEL-GPL-Pakete nicht weiterverteilen. Was ist die GPL denn noch wert, wenn man gezwungen wird, die durch sie gewährten Rechte durch eine Subskription "freiwillig" aufzugeben? Nichts.
Die durch die GPL gewährten Rechte kann man also nur dann in Anspruch nehmen, wenn man die Subskription kündigt. Krass.
Es heißt in der GPL ausdrücklich:
§6. Jedesmal, wenn Sie das Programm (oder ein auf dem Programm basierendes Werk) weitergeben, erhält der Empfänger automatisch vom ursprünglichen Lizenzgeber die Lizenz, das Programm entsprechend den hier festgelegten Bestimmungen zu vervielfältigen, zu verbreiten und zu verändern. [!!!] Sie dürfen keine weiteren Einschränkungen der Durchsetzung der hierin zugestandenen Rechte des Empfängers vornehmen. [!!!] Sie sind nicht dafür verantwortlich, die Einhaltung dieser Lizenz durch Dritte durchzusetzen. http://www.gnu.de/documents/gpl-2.0.de.html
Ich weiß nicht, ob da Oracle und Novell anders handeln, vermutlich nicht. SLES ist ja auch nicht gerade für "Offenheit" bekannt. Ich habe natürlich auch nicht vergessen, dass Red Hat die Sourcen sowieso für jedermann zum Download bereit stellt. Das ändert aber nichts an den oben zitierten, gültigen Bestimmungen für RHEL-Kunden.
Habe ich irgendwo einen "Denkfehler" gemacht? Ich glaube nicht.
Hmm, der Vertrag hats in sich, für Laien kaum so lesbar, wie es sein sollte. ;) Ich versuchs dennoch, danke für die Quellenangabe, deshalb der Nachtrag zum ersten Paragrafen: (and this Appendix is not intended to interfere with your rights under those individual licenses
Die Weitergabe der Software (der Zusammenstellung!) oder der Subskriptionsdienste an Dritte (also Nicht RH-Kunden/Partner...) oder die Nutzung dieser zum Profitt/Nutzen von Dritten ist ein Verstoss gegen den Nutzungsvertrsg. (soll verhindern, dass sich jemand die Pakete klaubt und anderen 1:1 zur Verfügung stellt, die keine Subskription bei RH haben).
Und jetzt wirds interessant: ... "auch wenn die Lizenz der einzelnen Softwarepakete dieses Recht zur Weitergabe gib" - Der Nachtrag ist etwas gummig aber daraus würde ich ableiten: Die Rechte, die euch die Lizenzen der EINZELNEN OSS produkte erteilt wurden, sind davon nicht tangiert. - Das verstehe ich: Die von RH über Subskription zu verfügung gestellten binär. und sourcepakete können nur von Kunden verwendet werden. - Diejenigen aber, die RH als SRPMS auf öffentlichen Servern hat, um der GPL nachzukommen, sind für jedermann frei verwendbar (und sind ja gleiche wie diese über das RHN) - Damit erfüllt RH die GPL wieder. Es geht RH primär um die binärpakete und da dürfen sie machen wie sie wollen, da sagt die GPL nichts dazu, nur über den Umgang mit Sourcen.
Auch der letzte mit Ausrufezeichen vom Vorposter hervorgehobene Abschnitt macht Sinn, sofern man den Abschnitt davor mitliest (!): Er bezieht sich auf den Fall, dass man Subskriptionsdienste, RH Supportleistungen an Dritte weitergibt (und damit selber ein Geschäft auf Kosten von RH macht) oder für mehr Maschinen verwendet , als man subskribiert hat - dann kann man nicht einfach bei den SRPMS von RH (und nur bei denen) einfach deren Logos und Co. entfernen und sagt *ätsch, nun hab ich halt einfach eure Logos entfernt um Copyright nicht zu verletzen, ihr könnt mich jetzt, aber Support hätte ich bittschön trotzdem*
Alles in allem ein nicht allzu leichter Vertrag, aber er hält sich IMO an die GPL-Pflichten und beschneidet nicht die Rechte auch wenn man richtiger RH-Kunde ist - aber er schränkt die Drittnutzung soweit wie Möglich ein, damit anderen nicht einfach ein Geschäft auf dem Buckel von RH machen (können). Oracle baut deswegen geschickt darum herum. - Weil das Engineering meist bei RH geschieht, kann Oracle dieses sparen und dann günstigere Subscription machen. Ob die Qualität und der Tiefgang bei RH und Oracle-Ingenieuren gleich ist, bezweifle ich aber.
Den Gebrauch von mrepo oder etwa eines eines Spacewalk-Servers (nicht RH Satelite) sehe ich nicht verboten, aber bei einem RH Satelite bekommst du Support (wenn dir das Wert ist), bei der OSS-Variante Spacewalk eben nicht. Bedienst du damit (mit original RH-Paketen) mehr als subskribiert oder Dritte (der Kumpel mit dem CentOS Server, dem ein RHEL zu teuer ist), ist das nicht mehr i.O.
Meine Ausführungen oben waren etwas lang, prinzipiell wollte ich damit sagen: Der Kontext ist manchmal unentbehrlich für das korrekte Verständns, dann reichen eininige lose herausgepickter Passagen nicht mehr.
Die GPL redet von "Software" und meint den Sourcecode. Red Hat spricht im Hinblick auf seine Subscription Services von "Software" und meint die Binaries.
Die Herstellerbinaries samt RHEL-Logos und -Branding sind proprietär und unterliegen nicht der GPL. In diesem genau bezeichneten Sinne ist RHEL proprietäre Software.
Ein einfaches Debranding der Binaries genügt nicht. Wer RHEL nachbauen möchte, muss zwingend über den freiwillig zur Verfügung gestellten Sourcecode gehen.
Jetzt stelle man sich nur einmal vor, Red Hat würde nicht freiwillig die Sourcen auch Nichtkunden zur Verfügung stellen.
Was hätten wir dann? Immer noch ein "freies" System natürlich.
Folgendes muss man natürlich dabei bedenken: Meines Wissens veröffentlichen weder Oracle noch Novell die Sourcen der Updates ihrer Enterpriseprodukte für jedermann, etwas, was Red Hat immer macht.
Bei Novell landet allerdings SLES-Software (u.a. der Kernel) in den openSUSE Buildservice-Repos, Projekte wie openSUSE 11.1 Evergreen können dann darauf zugreifen und diese verwenden. Fast jedes Teil-Repo des Buildservice beherbergt zudem zu openSUSE 11.1 kompatible SLES 11-Software samt Sourcen.
Am "Geschlossensten" scheint deshalb Oracles Linux zu sein, ausgerechnet die einzige Firma der "großen Drei" (gemessen an der Konzerngröße), die kein eigenes Linux entwickelt.
"Die GPL redet von "Software" und meint den Sourcecode. Red Hat spricht im Hinblick auf seine Subscription Services von "Software" und meint die Binaries."
Ja, im wesentlichen passt das.
"Meines Wissens veröffentlichen weder Oracle noch Novell die Sourcen der Updates ihrer Enterpriseprodukte für jedermann, etwas, was Red Hat immer macht."
Das hat keine 2 Minuten gedauert, die Sourcen bei Oracle zu finden:
Support geht's halt doch: Geld verdienen
Und weil das so toll geht, sieht sich Red Hat gezwungen, Konkurrenten zu behindern? Aha.
Würdest du das auch schreiben, wenn Oracle, Apple oder Microsoft so etwas getan hätten? Nein, wohl eher nicht...
RHEL kopieren und dann auch noch versuchen, Red Hat die eigenen Kunden abspenstig zu machen:
Da zieht selbst Red Hat die Notbremse.
Ist das auch im Geiste der GPL o.k.?
Ja, das ist es, da die RHEL-Kernel-Patches weiterhin nach Upstream wandern.
Es gibt da aber viel schlimmere Textpassagen in den RHEL-Supportverträgen.
Ein kleines Beispiel? (sofern du was im Kopf/zur Hand hast)
Das ist aber unglücklich formuliert. Die GPL verlangt nicht, daß Red Hats Änderungen am Kernel "nach Upstream wandern", sondern gibt nur vor, in welcher Form diese Änderungen zu veröffentlichen sind.
Das meinte ich nicht.
In den Kommentaren zum oben verlinkten LWN-Artikel wurde das, was ich oben angesprochen habe, schon diskutiert.
Es geht um solche "RHEL"-Paragraphen:
"Distributing the Software or any portion of the Subscription Services to a third party or using any of the Subscription Services for the benefit of a third party is a material breach of the Agreement even though the open source license applicable to individual software packages may give you the right to distribute those packages."
und
"Any unauthorized use of the Subscription Services is a material breach of the Agreement, such as (a) only purchasing or renewing Subscription Services based on some, but not all, of the total number of Units of Red Hat Software or other Red Hat Product that you deploy, install, use or execute [...]
[!!!]
For the purposes of this paragraph (for example, in calculating the total number of Units of Software), Software would include versions or copies that have the Red Hat trademark(s) and/or logo file(s) removed.
[!!!]"
[Die Ausrufezeichen sind von mir.]
Siehe http://www.redhat.com/licenses/rhel_us_appendix1.pdf
Erinnerst Du Dich noch, wie Shuttleworth RHEL mit dem Begriff "quasiproprietär" (oder so ähnlich) umschrieben hat?
Das ist nicht so meilenweit daneben.
Allerdings ist es hier nicht einfach zu entscheiden, ob die Bedingungen für die RHEL Subscription Services durch die GPL gewährte Rechte tatsächlich auch verletzen oder nicht. Jedenfalls ist das IMO hart an der Grenze.
Du schriebst:
> Ist das auch im Geiste der GPL o.k.?
> Ja, das ist es, da die RHEL-Kernel-Patches weiterhin nach Upstream wandern.
Nur darauf bezog ich mich in meinem Kommentar.
Deinen Ausführungen zu den Wartungs- und Supportverträgen kann ich so nicht folgen. RHEL ist quelloffen. Du kannst mit den veröffentlichten src.rpm Paketen tun, was deren Lizenzbestimmungen erlauben. Ggf. mußt Du bei der Verwendung darüberhinaus noch Markenrechte beachten - das beschränkt sich aber nicht nur für Open Source Software von Red Hat. Gehst Du Wartungsverträge mit Red Hat ein, so haben die ihre eigenen Spielregeln, Du nimmst dabei gewöhnlich kostenpflichtige Leistungen in Anspruch, die weit über das reine Zusammenstellen und Verfügbarmachen von OSS hinausgehen.
Allerdings ist es hier nicht einfach zu entscheiden, ob die Bedingungen für die RHEL Subscription Services durch die GPL gewährte Rechte tatsächlich auch verletzen oder nicht. Jedenfalls ist das IMO hart an der Grenze.
Die Redhat Lizenzverträge sind mit an Sicherheit grenzender Wahrscheinlichkeit GPL-konform.
Ich glaube das aus zwei Gründen:
1) Redhat ist ein sehr guter "Bürger" der freien Software Community, wenn man als Vergleich Novell, Oracle oder Google heranzieht. Die Leute bei Redhat werden nicht blöd sein und durch Lizenzverletzungen ihren Bonus bei der Community verlieren wollen.
2) Die FSF hätter DER führenden kommerziellen Distribution schon die Rute ins Fenster gestellt, hätte Redhat die GPL auch nur im geringsten verletzt, schließlich hält die FSF die Copyrights für viele der zentralen Distributionsbestandteile.
Du sagst ja wohl nicht, dass Du diese Bestimmungen ganz toll findest?
Da steht doch defacto:
Solange man die Red Hat Subscription Services benutzt, solange darf man RHEL-GPL-Pakete nicht weiterverteilen.
Was ist die GPL denn noch wert, wenn man gezwungen wird, die durch sie gewährten Rechte durch eine Subskription "freiwillig" aufzugeben?
Nichts.
Die durch die GPL gewährten Rechte kann man also nur dann in Anspruch nehmen, wenn man die Subskription kündigt.
Krass.
Es heißt in der GPL ausdrücklich:
§6. Jedesmal, wenn Sie das Programm (oder ein auf dem Programm basierendes Werk) weitergeben, erhält der Empfänger automatisch vom ursprünglichen Lizenzgeber die Lizenz, das Programm entsprechend den hier festgelegten Bestimmungen zu vervielfältigen, zu verbreiten und zu verändern.
[!!!]
Sie dürfen keine weiteren Einschränkungen der Durchsetzung der hierin zugestandenen Rechte des Empfängers vornehmen.
[!!!]
Sie sind nicht dafür verantwortlich, die Einhaltung dieser Lizenz durch Dritte durchzusetzen.
http://www.gnu.de/documents/gpl-2.0.de.html
Ich weiß nicht, ob da Oracle und Novell anders handeln, vermutlich nicht. SLES ist ja auch nicht gerade für "Offenheit" bekannt.
Ich habe natürlich auch nicht vergessen, dass Red Hat die Sourcen sowieso für jedermann zum Download bereit stellt. Das ändert aber nichts an den oben zitierten, gültigen Bestimmungen für RHEL-Kunden.
Habe ich irgendwo einen "Denkfehler" gemacht? Ich glaube nicht.
Hmm, der Vertrag hats in sich, für Laien kaum so lesbar, wie es sein sollte. ;)
Ich versuchs dennoch, danke für die Quellenangabe, deshalb der Nachtrag zum ersten Paragrafen: (and this Appendix is not intended to interfere with your rights under those individual licenses
Die Weitergabe der Software (der Zusammenstellung!) oder der Subskriptionsdienste an Dritte (also Nicht RH-Kunden/Partner...) oder die Nutzung dieser zum Profitt/Nutzen von Dritten ist ein Verstoss gegen den Nutzungsvertrsg. (soll verhindern, dass sich jemand die Pakete klaubt und anderen 1:1 zur Verfügung stellt, die keine Subskription bei RH haben).
Und jetzt wirds interessant: ... "auch wenn die Lizenz der einzelnen Softwarepakete dieses Recht zur Weitergabe gib" - Der Nachtrag ist etwas gummig aber daraus würde ich ableiten: Die Rechte, die euch die Lizenzen der EINZELNEN OSS produkte erteilt wurden, sind davon nicht tangiert. - Das verstehe ich: Die von RH über Subskription zu verfügung gestellten binär. und sourcepakete können nur von Kunden verwendet werden. - Diejenigen aber, die RH als SRPMS auf öffentlichen Servern hat, um der GPL nachzukommen, sind für jedermann frei verwendbar (und sind ja gleiche wie diese über das RHN) - Damit erfüllt RH die GPL wieder. Es geht RH primär um die binärpakete und da dürfen sie machen wie sie wollen, da sagt die GPL nichts dazu, nur über den Umgang mit Sourcen.
Auch der letzte mit Ausrufezeichen vom Vorposter hervorgehobene Abschnitt macht Sinn, sofern man den Abschnitt davor mitliest (!): Er bezieht sich auf den Fall, dass man Subskriptionsdienste, RH Supportleistungen an Dritte weitergibt (und damit selber ein Geschäft auf Kosten von RH macht) oder für mehr Maschinen verwendet , als man subskribiert hat - dann kann man nicht einfach bei den SRPMS von RH (und nur bei denen) einfach deren Logos und Co. entfernen und sagt *ätsch, nun hab ich halt einfach eure Logos entfernt um Copyright nicht zu verletzen, ihr könnt mich jetzt, aber Support hätte ich bittschön trotzdem*
Alles in allem ein nicht allzu leichter Vertrag, aber er hält sich IMO an die GPL-Pflichten und beschneidet nicht die Rechte auch wenn man richtiger RH-Kunde ist - aber er schränkt die Drittnutzung soweit wie Möglich ein, damit anderen nicht einfach ein Geschäft auf dem Buckel von RH machen (können). Oracle baut deswegen geschickt darum herum. - Weil das Engineering meist bei RH geschieht, kann Oracle dieses sparen und dann günstigere Subscription machen. Ob die Qualität und der Tiefgang bei RH und Oracle-Ingenieuren gleich ist, bezweifle ich aber.
Also ist es nicht rechtens, zB per mrepo sich sein eigenes Repository zu bauen und mehr Maschinen mit Updates versorgt, als man RH Subskriptionen hat?
Genau, so jedenfalls verstehe ich den passus.
Den Gebrauch von mrepo oder etwa eines eines Spacewalk-Servers (nicht RH Satelite) sehe ich nicht verboten, aber bei einem RH Satelite bekommst du Support (wenn dir das Wert ist), bei der OSS-Variante Spacewalk eben nicht. Bedienst du damit (mit original RH-Paketen) mehr als subskribiert oder Dritte (der Kumpel mit dem CentOS Server, dem ein RHEL zu teuer ist), ist das nicht mehr i.O.
Meine Ausführungen oben waren etwas lang, prinzipiell wollte ich damit sagen: Der Kontext ist manchmal unentbehrlich für das korrekte Verständns, dann reichen eininige lose herausgepickter Passagen nicht mehr.
Also, ich fasse (hoffentlich korrekt) zusammen:
Die GPL redet von "Software" und meint den Sourcecode.
Red Hat spricht im Hinblick auf seine Subscription Services von "Software" und meint die Binaries.
Die Herstellerbinaries samt RHEL-Logos und -Branding sind proprietär und unterliegen nicht der GPL.
In diesem genau bezeichneten Sinne ist RHEL proprietäre Software.
Ein einfaches Debranding der Binaries genügt nicht.
Wer RHEL nachbauen möchte, muss zwingend über den freiwillig zur Verfügung gestellten Sourcecode gehen.
Jetzt stelle man sich nur einmal vor, Red Hat würde nicht freiwillig die Sourcen auch Nichtkunden zur Verfügung stellen.
Was hätten wir dann?
Immer noch ein "freies" System natürlich.
Folgendes muss man natürlich dabei bedenken:
Meines Wissens veröffentlichen weder Oracle noch Novell die Sourcen der Updates ihrer Enterpriseprodukte für jedermann, etwas, was Red Hat immer macht.
Bei Novell landet allerdings SLES-Software (u.a. der Kernel) in den openSUSE Buildservice-Repos, Projekte wie openSUSE 11.1 Evergreen können dann darauf zugreifen und diese verwenden. Fast jedes Teil-Repo des Buildservice beherbergt zudem zu openSUSE 11.1 kompatible SLES 11-Software samt Sourcen.
Am "Geschlossensten" scheint deshalb Oracles Linux zu sein, ausgerechnet die einzige Firma der "großen Drei" (gemessen an der Konzerngröße), die kein eigenes Linux entwickelt.
"Die GPL redet von "Software" und meint den Sourcecode.
Red Hat spricht im Hinblick auf seine Subscription Services von "Software" und meint die Binaries."
Ja, im wesentlichen passt das.
"Meines Wissens veröffentlichen weder Oracle noch Novell die Sourcen der Updates ihrer Enterpriseprodukte für jedermann, etwas, was Red Hat immer macht."
Das hat keine 2 Minuten gedauert, die Sourcen bei Oracle zu finden:
> http://oss.oracle.com/el5/
> http://oss.oracle.com/el5/SRPMS-updates/?C=M;O=D