Man muss dem KUNDEN auf ANFRAGE den Quellcode zur Verfügung stellen. Das heißt für SUSE (Enterprise), dass die Businesspartner den Quellcode bekommen können, wenn sie wollen. Was die damit weiter machen, ist deren Sache.
Es gibt in der GPL keine Pflicht, den Quellcode der ALLGEMEINHEIT zur Verfügung zu stellen, schon gar nicht unentgeltlich.
"Man muss dem KUNDEN auf ANFRAGE den Quellcode zur Verfügung stellen." OK, aber ein Kunde dürfte doch -wenn er wollte- den erhaltenen Quellcode seinerseits weitergeben oder veröffentlichen. Ist das nicht so?
1. Zum einen der Supportvertrag, der für diesen Fall entsprechende Regelungen enthalten kann, z.B. die sofortige Terminierung.
2. Zum anderen müssen die Sourcen in jedem Fall debranded sein, dürfen also auch nach der Verwendung und Verwertung in anderen kommerziellen Produkten kein Suse-Branding mehr enthalten.
Ich glaube, ich habe es missverständlich geschrieben. Es geht um die Quellcode-Pakete. Anders ergibt es keinen Sinn, denn nur mit dem Quellcode allein müsste Opensuse immer noch selbst die Paketdefinitionen schreiben bzw. pflegen.
Und zwar dann, wenn man diese z.B. zum Download anbietet.
Und genau das macht Suse mit SLES und SLED (einfach anch SLES oder SLED und Evaluation suchen).
Du erhältst nach einer Registrierung vollen Zugriff auf die SLES- bzw. SLED-Binaries und -Sourcen plus Updates für 60 Tage (natürlich ebenfalls samt Sourcen), da der Testzeitrahmen für diese sog. Evaluationsversionen auf 60 Tage festgelegt wurde.
Wenn Du nach 60 Tagen weiterhin Updates haben möchtest, so müsstest Du dann eines der SLES- oder SLED-Angebote kaufen.
Deine Testversion läuft allerdings weiter, dann aber - nach 60 Tagen - ohne weitere Updates.
Das ist die kommerzielle Struktur, in die SLES und SLED eingebettet wurden. Bei RHEL ist das nicht viel anders.
So etwas wie CentOS ist das natürlich nicht.
Nichtsdestotrotz kann ich an dem Suse-Vorgehen im Hinblick auf SLES und SLED nichts Verwerfliches oder GPL-Verletzendes entdecken.
Zitat: "... dass Opensuse künftig auf einen Großteil des Quellcodes für Suse Linux Enterprise zugreifen kann"
Ich dachte immer, man muss den gesamten Quellcode seiner Distribution offenlegen. Oder wie war das?
Man muss dem KUNDEN auf ANFRAGE den Quellcode zur Verfügung stellen.
Das heißt für SUSE (Enterprise), dass die Businesspartner den Quellcode bekommen können, wenn sie wollen. Was die damit weiter machen, ist deren Sache.
Es gibt in der GPL keine Pflicht, den Quellcode der ALLGEMEINHEIT zur Verfügung zu stellen, schon gar nicht unentgeltlich.
"Man muss dem KUNDEN auf ANFRAGE den Quellcode zur Verfügung stellen." OK, aber ein Kunde dürfte doch -wenn er wollte- den erhaltenen Quellcode seinerseits weitergeben oder veröffentlichen. Ist das nicht so?
Doch.
Dabei muss aber zweierlei beachtet werden:
1. Zum einen der Supportvertrag, der für diesen Fall entsprechende Regelungen enthalten kann, z.B. die sofortige Terminierung.
2. Zum anderen müssen die Sourcen in jedem Fall debranded sein, dürfen also auch nach der Verwendung und Verwertung in anderen kommerziellen Produkten kein Suse-Branding mehr enthalten.
Falls die Erpressung aus Punkt 1 wirklich GPL-konform ist, sehe ich das aber als zu schließendes Schlupfloch an.
Ich glaube, ich habe es missverständlich geschrieben. Es geht um die Quellcode-Pakete. Anders ergibt es keinen Sinn, denn nur mit dem Quellcode allein müsste Opensuse immer noch selbst die Paketdefinitionen schreiben bzw. pflegen.
Richtig.
Und zwar dann, wenn man diese z.B. zum Download anbietet.
Und genau das macht Suse mit SLES und SLED (einfach anch SLES oder SLED und Evaluation suchen).
Du erhältst nach einer Registrierung vollen Zugriff auf die SLES- bzw. SLED-Binaries und -Sourcen plus Updates für 60 Tage (natürlich ebenfalls samt Sourcen), da der Testzeitrahmen für diese sog. Evaluationsversionen auf 60 Tage festgelegt wurde.
Wenn Du nach 60 Tagen weiterhin Updates haben möchtest, so müsstest Du dann eines der SLES- oder SLED-Angebote kaufen.
Deine Testversion läuft allerdings weiter, dann aber - nach 60 Tagen - ohne weitere Updates.
Das ist die kommerzielle Struktur, in die SLES und SLED eingebettet wurden. Bei RHEL ist das nicht viel anders.
So etwas wie CentOS ist das natürlich nicht.
Nichtsdestotrotz kann ich an dem Suse-Vorgehen im Hinblick auf SLES und SLED nichts Verwerfliches oder GPL-Verletzendes entdecken.