Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > de.comp.os.unix.linux.misc > #131801 > unrolled thread
| Started by | Marco Moock <mo01@posteo.de> |
|---|---|
| First post | 2023-06-22 12:00 +0200 |
| Last post | 2023-07-01 12:42 +0200 |
| Articles | 20 on this page of 108 — 17 participants |
Back to article view | Back to de.comp.os.unix.linux.misc
RHEL: Kein öffentlich verfügbarer Quellcode mehr Marco Moock <mo01@posteo.de> - 2023-06-22 12:00 +0200
Re: RHEL: Kein öffentlichverfügbarer Quellcode mehr Eike Rathke <erack+nutznetz.p@posteo.de> - 2023-06-22 20:32 +0000
Re: RHEL: Kein öffentlichverfügbarer Quellcode mehr Marco Moock <mo01@posteo.de> - 2023-06-23 09:15 +0200
Re: RHEL: Kein öffentlichverfügbarer Quellcode mehr Christian Garbs <mitch@cgarbs.de> - 2023-06-23 08:18 +0000
Re: RHEL: Kein öffentlichverfügbarer Quellcode mehr Marco Moock <mo01@posteo.de> - 2023-06-23 11:48 +0200
Re: RHEL: Kein öffentlichverfügbarer Quellcode mehr "Peter J. Holzer" <hjp-usenet3@hjp.at> - 2023-06-23 13:11 +0200
Re: RHEL: Kein öffentlichverfügbarer Quellcode mehr Ralph Angenendt <dein.name@strg-alt-entf.org> - 2023-06-23 11:21 +0000
Re: RHEL: Kein öffentlichverfügbarer Quellcode mehr Christian Garbs <mitch@cgarbs.de> - 2023-06-23 15:44 +0000
Re: RHEL: Kein öffentlichverfügbarer Quellcode mehr "Peter J. Holzer" <hjp-usenet3@hjp.at> - 2023-06-23 18:10 +0200
Re: RHEL: Kein öffentlichverfügbarer Quellcode mehr Ralph Angenendt <dein.name@strg-alt-entf.org> - 2023-06-23 10:04 +0000
Re: RHEL: Kein öffentlichverfügbarer Quellcode mehr Marco Moock <mo01@posteo.de> - 2023-06-23 12:22 +0200
Re: RHEL: Kein öffentlichverfügbarer Quellcode mehr Ralph Angenendt <dein.name@strg-alt-entf.org> - 2023-06-23 11:18 +0000
Re: RHEL: Kein öffentlichverfügbarer Quellcode mehr Marco Moock <mo01@posteo.de> - 2023-06-23 17:32 +0200
Re: RHEL: Kein öffentlichverfügbarer Quellcode mehr "Walter H." <Walter.H-Nntp@mathemainzel.info> - 2023-06-24 13:05 +0200
Re: RHEL: Kein öffentlichverfügbarer Quellcode mehr "Peter J. Holzer" <hjp-usenet3@hjp.at> - 2023-06-24 13:45 +0200
Re: RHEL: Kein öffentlichverfügbarer Quellcode mehr "Walter H." <Walter.H-Nntp@mathemainzel.info> - 2023-06-24 14:19 +0200
Re: RHEL: Kein öffentlichverfügbarer Quellcode mehr "Peter J. Holzer" <hjp-usenet3@hjp.at> - 2023-06-24 14:45 +0200
Re: RHEL: Kein öffentlichverfügbarer Quellcode mehr "Walter H." <Walter.H-Nntp@mathemainzel.info> - 2023-06-24 15:40 +0200
Re: RHEL: Kein öffentlichverfügbarer Quellcode mehr Hergen Lehmann <hlehmann.expires.12-22@snafu.de> - 2023-06-24 15:39 +0200
Re: RHEL: Kein öffentlichverfügbarer Quellcode mehr "Peter J. Holzer" <hjp-usenet3@hjp.at> - 2023-06-24 20:32 +0200
Re: RHEL: Kein öffentlichverfügbarer Quellcode mehr "Walter H." <Walter.H-Nntp@mathemainzel.info> - 2023-06-25 21:21 +0200
Re: RHEL: Kein öffentlichverfügbarer Quellcode mehr "Peter J. Holzer" <hjp-usenet3@hjp.at> - 2023-06-25 22:58 +0200
Re: RHEL: Kein öffentlichverfügbarer Quellcode mehr Ralph Angenendt <dein.name@strg-alt-entf.org> - 2023-06-26 09:37 +0000
Re: RHEL: Kein öffentlichverfügbarer Quellcode mehr Ulli Horlacher <framstag@rus.uni-stuttgart.de> - 2023-06-26 09:47 +0000
Re: RHEL: Kein öffentlichverfügbarer Quellcode mehr Ralph Angenendt <dein.name@strg-alt-entf.org> - 2023-06-26 10:15 +0000
Re: RHEL: Kein öffentlichverfügbarer Quellcode mehr Ulli Horlacher <framstag@rus.uni-stuttgart.de> - 2023-06-26 10:38 +0000
Re: RHEL: Kein öffentlichverfügbarer Quellcode mehr "Peter J. Holzer" <hjp-usenet3@hjp.at> - 2023-06-26 12:50 +0200
Re: RHEL: Kein öffentlichverfügbarer Quellcode mehr Ulli Horlacher <framstag@rus.uni-stuttgart.de> - 2023-06-26 11:15 +0000
Re: RHEL: Kein öffentlichverfügbarer Quellcode mehr Marco Moock <mo01@posteo.de> - 2023-06-26 13:39 +0200
Re: RHEL: Kein öffentlichverfügbarer Quellcode mehr Ulli Horlacher <framstag@rus.uni-stuttgart.de> - 2023-06-26 20:12 +0000
Re: RHEL: Kein öffentlichverfügbarer Quellcode mehr "Peter J. Holzer" <hjp-usenet3@hjp.at> - 2023-06-26 13:43 +0200
Re: RHEL: Kein öffentlichverfügbarer Quellcode mehr Arno Welzel <usenet@arnowelzel.de> - 2023-07-01 16:10 +0200
Re: RHEL: Kein öffentlichverfügbarer Quellcode mehr "Peter J. Holzer" <hjp-usenet3@hjp.at> - 2023-07-01 16:41 +0200
Re: RHEL: Kein öffentlichverfügbarer Quellcode mehr Arno Welzel <usenet@arnowelzel.de> - 2023-07-01 17:07 +0200
Re: RHEL: Kein öffentlichverfügbarer Quellcode mehr "Peter J. Holzer" <hjp-usenet3@hjp.at> - 2023-07-01 17:37 +0200
Re: RHEL: Kein öffentlichverfügbarer Quellcode mehr Arno Welzel <usenet@arnowelzel.de> - 2023-07-03 02:43 +0200
Re: RHEL: Kein öffentlichverfügbarer Quellcode mehr "Peter J. Holzer" <hjp-usenet3@hjp.at> - 2023-07-03 12:35 +0200
Re: RHEL: Kein öffentlichverfügbarer Quellcode mehr Arno Welzel <usenet@arnowelzel.de> - 2023-07-03 15:53 +0200
Re: RHEL: Kein öffentlichverfügbarer Quellcode mehr "Peter J. Holzer" <hjp-usenet3@hjp.at> - 2023-07-03 16:39 +0200
Re: RHEL: Kein öffentlichverfügbarer Quellcode mehr Gerald E¡scher <Spamer@fahr-zur-Hoelle.org> - 2023-07-03 15:47 +0000
Re: RHEL: Kein öffentlichverfügbarer Quellcode mehr Arno Welzel <usenet@arnowelzel.de> - 2023-07-04 08:22 +0200
Re: RHEL: Kein öffentlichverfügbarer Quellcode mehr Marco Moock <mo01@posteo.de> - 2023-07-01 21:37 +0200
Re: RHEL: Kein öffentlichverfügbarer Quellcode mehr Ulli Horlacher <framstag@rus.uni-stuttgart.de> - 2023-07-01 16:47 +0000
Re: RHEL: Kein öffentlichverfügbarer Quellcode mehr "Peter J. Holzer" <hjp-usenet3@hjp.at> - 2023-07-01 21:31 +0200
Re: RHEL: Kein öffentlichverfügbarer Quellcode mehr Ulli Horlacher <framstag@rus.uni-stuttgart.de> - 2023-07-01 16:42 +0000
Re: RHEL: Kein öffentlichverfügbarer Quellcode mehr Arno Welzel <usenet@arnowelzel.de> - 2023-07-03 02:46 +0200
Re: RHEL: Kein öffentlichverfügbarer Quellcode mehr Marco Moock <mo01@posteo.de> - 2023-06-26 13:18 +0200
Re: RHEL: Kein öffentlichverfügbarer Quellcode mehr Marco Moock <mo01@posteo.de> - 2023-06-26 13:16 +0200
Re: RHEL: Kein öffentlichverfügbarer Quellcode mehr Ralph Angenendt <dein.name@strg-alt-entf.org> - 2023-06-26 09:22 +0000
Re: RHEL: Kein öffentlichverfügbarer Quellcode mehr Ralph Angenendt <dein.name@strg-alt-entf.org> - 2023-06-26 09:26 +0000
Re: RHEL: Kein öffentlichverfügbarer Quellcode mehr Marco Moock <mo01@posteo.de> - 2023-06-26 13:41 +0200
Re: RHEL: Kein öffentlichverfügbarer Quellcode mehr Ralph Angenendt <dein.name@strg-alt-entf.org> - 2023-06-26 12:35 +0000
Re: RHEL: Kein öffentlichverfügbarer Quellcode mehr Marco Moock <mo01@posteo.de> - 2023-06-26 14:57 +0200
Re: RHEL: Kein öffentlichverfügbarer Quellcode mehr "Peter J. Holzer" <hjp-usenet3@hjp.at> - 2023-06-23 13:49 +0200
Re: RHEL: Kein öffentlichverfügbarer Quellcode mehr Marco Moock <mo01@posteo.de> - 2023-06-23 17:32 +0200
Re: RHEL: Kein öffentlichverfügbarer Quellcode mehr "Peter J. Holzer" <hjp-usenet3@hjp.at> - 2023-06-23 17:46 +0200
Re: RHEL: Kein öffentlichverfügbarer Quellcode mehr Eike Rathke <erack+nutznetz.p@posteo.de> - 2023-06-23 12:09 +0000
Re: RHEL: Kein öffentlichverfügbarer Quellcode mehr Hermann Riemann <nospam.ng@hermann-riemann.de> - 2023-06-23 14:51 +0200
Re: RHEL: Kein öffentlich verfügbarer Quellcode mehr "Andreas M. Kirchwitz" <amk@spamfence.net> - 2023-06-24 10:44 +0000
Re: RHEL: Kein öffentlich verfügbarer Quellcode mehr Marco Moock <mo01@posteo.de> - 2023-06-24 13:01 +0200
Re: RHEL: Kein öffentlich verfügbarer Quellcode mehr "Peter J. Holzer" <hjp-usenet3@hjp.at> - 2023-06-24 13:43 +0200
Re: RHEL: Kein öffentlich verfügbarer Quellcode mehr "Andreas M. Kirchwitz" <amk@spamfence.net> - 2023-06-24 13:28 +0000
Re: RHEL: Kein öffentlich verfügbarer Quellcode mehr Marco Moock <mo01@posteo.de> - 2023-06-24 18:28 +0200
Re: RHEL: Kein öffentlich verfügbarer Quellcode mehr "Peter J. Holzer" <hjp-usenet3@hjp.at> - 2023-06-24 20:40 +0200
Re: RHEL: Kein öffentlich verfügbarer Quellcode mehr Marc Haber <mh+usenetspam1118@zugschl.us> - 2023-06-25 12:57 +0200
Re: RHEL: Kein öffentlich verfügbarer Quellcode mehr "Peter J. Holzer" <hjp-usenet3@hjp.at> - 2023-06-25 13:59 +0200
Re: RHEL: Kein öffentlich verfügbarer Quellcode mehr Stefan Möding <Jun2023.5.kill-9@spamgourmet.com> - 2023-06-25 14:12 +0200
Re: RHEL: Kein öffentlich verfügbarer Quellcode mehr Marc Haber <mh+usenetspam1118@zugschl.us> - 2023-06-25 17:01 +0200
Re: RHEL: Kein öffentlich verfügbarer Quellcode mehr "Andreas M. Kirchwitz" <amk@spamfence.net> - 2023-06-24 13:01 +0000
Re: RHEL: Kein öffentlich verfügbarer Quellcode mehr Marco Moock <mo01@posteo.de> - 2023-06-24 18:31 +0200
Re: RHEL: Kein öffentlich verfügbarer Quellcode mehr Gerald E¡scher <Spamer@fahr-zur-Hoelle.org> - 2023-06-24 17:10 +0000
Re: RHEL: Kein öffentlich verfügbarer Quellcode mehr Marco Moock <mo01@posteo.de> - 2023-06-24 19:53 +0200
Re: RHEL: Kein öffentlich verfügbarer Quellcode mehr "Andreas M. Kirchwitz" <amk@spamfence.net> - 2023-06-24 21:23 +0000
Re: RHEL: Kein öffentlich verfügbarer Quellcode mehr "Peter J. Holzer" <hjp-usenet3@hjp.at> - 2023-06-24 20:47 +0200
Re: RHEL: Kein öffentlich verfügbarer Quellcode mehr Gerald E¡scher <Spamer@fahr-zur-Hoelle.org> - 2023-06-24 20:37 +0000
Re: RHEL: Kein öffentlich verfügbarer Quellcode mehr Marco Moock <mo01@posteo.de> - 2023-06-24 22:49 +0200
Re: RHEL: Kein öffentlich verfügbarer Quellcode mehr "Peter J. Holzer" <hjp-usenet3@hjp.at> - 2023-06-24 22:51 +0200
Re: RHEL: Kein öffentlich verfügbarer Quellcode mehr Marco Moock <mo01@posteo.de> - 2023-06-25 13:04 +0200
Re: RHEL: Kein öffentlich verfügbarer Quellcode mehr "Peter J. Holzer" <hjp-usenet3@hjp.at> - 2023-06-25 14:01 +0200
Re: RHEL: Kein öffentlich verfügbarer Quellcode mehr Gerald E¡scher <Spamer@fahr-zur-Hoelle.org> - 2023-06-25 14:43 +0000
Re: RHEL: Kein öffentlich verfügbarer Quellcode mehr Ralph Angenendt <dein.name@strg-alt-entf.org> - 2023-06-26 10:17 +0000
Re: RHEL: Kein öffentlich verfügbarer Quellcode mehr "Peter J. Holzer" <hjp-usenet3@hjp.at> - 2023-06-26 12:56 +0200
Re: RHEL: Kein öffentlich verfügbarer Quellcode mehr Ralph Angenendt <dein.name@strg-alt-entf.org> - 2023-06-26 12:31 +0000
Re: RHEL: Kein öffentlich verfügbarer Quellcode mehr Marco Moock <mo01@posteo.de> - 2023-06-26 13:46 +0200
Re: RHEL: Kein öffentlich verfügbarer Quellcode mehr Ralph Angenendt <dein.name@strg-alt-entf.org> - 2023-06-26 12:35 +0000
Re: RHEL: Kein öffentlich verfügbarer Quellcode mehr Marco Moock <mo01@posteo.de> - 2023-06-26 14:59 +0200
Re: RHEL: Kein öffentlich verfügbarer Quellcode mehr "Peter J. Holzer" <hjp-usenet3@hjp.at> - 2023-06-26 15:45 +0200
Re: RHEL: Kein öffentlich verfügbarer Quellcode mehr Thomas Hochstein <thh@thh.name> - 2023-06-26 19:53 +0200
Re: RHEL: Kein öffentlich verfügbarer Quellcode mehr Ralph Angenendt <dein.name@strg-alt-entf.org> - 2023-06-26 09:57 +0000
Re: RHEL: Kein öffentlich verfügbarer Quellcode mehr Ralph Angenendt <dein.name@strg-alt-entf.org> - 2023-06-26 09:53 +0000
Re: RHEL: Kein öffentlich verfügbarer Quellcode mehr Ralph Angenendt <dein.name@strg-alt-entf.org> - 2023-06-26 10:12 +0000
Re: RHEL: Kein öffentlich verfügbarer Quellcode mehr Ulli Horlacher <framstag@rus.uni-stuttgart.de> - 2023-06-26 10:35 +0000
Re: RHEL: Kein öffentlich verfügbarer Quellcode mehr Ralph Angenendt <dein.name@strg-alt-entf.org> - 2023-06-26 10:46 +0000
Re: RHEL: Kein öffentlich verfügbarer Quellcode mehr Marco Moock <mo01@posteo.de> - 2023-06-26 13:50 +0200
Re: RHEL: Kein öffentlich verfügbarer Quellcode mehr Marco Moock <mo01@posteo.de> - 2023-06-26 13:49 +0200
Re: RHEL: Kein öffentlich verfügbarer Quellcode mehr Ralph Angenendt <dein.name@strg-alt-entf.org> - 2023-06-26 12:37 +0000
Re: RHEL: Kein öffentlich verfügbarer Quellcode mehr Marco Moock <mo01@posteo.de> - 2023-06-26 14:58 +0200
Re: RHEL: Kein öffentlich verfügbarer Quellcode mehr "Andreas M. Kirchwitz" <amk@spamfence.net> - 2023-06-27 21:09 +0000
Re: RHEL: Kein öffentlich verfügbarer Quellcode mehr "Peter J. Holzer" <hjp-usenet3@hjp.at> - 2023-06-27 23:38 +0200
Re: RHEL: Kein öffentlich verfügbarer Quellcode mehr Sieghard Schicktanz <Sieghard.Schicktanz@SchS.de> - 2023-06-28 23:02 +0200
Re: RHEL: Kein öffentlich verfügbarer Quellcode mehr Gerald E¡scher <Spamer@fahr-zur-Hoelle.org> - 2023-06-29 18:05 +0000
Re: RHEL: Kein öffentlich verfügbarer Quellcode mehr "Andreas M. Kirchwitz" <amk@spamfence.net> - 2023-06-30 07:42 +0000
Re: RHEL: Kein öffentlich verfügbarer Quellcode mehr "Peter J. Holzer" <hjp-usenet3@hjp.at> - 2023-06-30 15:55 +0200
Re: RHEL: Kein öffentlich verfügbarer Quellcode mehr Gerald E¡scher <Spamer@fahr-zur-Hoelle.org> - 2023-06-30 17:13 +0000
Re: RHEL: Kein öffentlich verfügbarer Quellcode mehr Ulli Horlacher <framstag@rus.uni-stuttgart.de> - 2023-06-30 19:56 +0000
Re: RHEL: Kein öffentlich verfügbarer Quellcode mehr "Andreas M. Kirchwitz" <amk@spamfence.net> - 2023-07-01 09:40 +0000
Re: RHEL: Kein öffentlich verfügbarer Quellcode mehr Frank Miller <miller@posteo.ee> - 2023-07-01 01:24 +0200
Re: RHEL: Kein öffentlich verfügbarer Quellcode mehr "Peter J. Holzer" <hjp-usenet3@hjp.at> - 2023-07-01 12:42 +0200
Page 4 of 6 — ← Prev page 1 2 3 [4] 5 6 Next page →
| From | "Peter J. Holzer" <hjp-usenet3@hjp.at> |
|---|---|
| Date | 2023-06-24 13:43 +0200 |
| Message-ID | <slrnu9dlmp.u3t8.hjp-usenet3@trintignant.hjp.at> |
| In reply to | #131950 |
On 2023-06-24 11:01, Marco Moock <mo01@posteo.de> wrote:
> Am 24.06.2023 um 10:44:39 Uhr schrieb Andreas M. Kirchwitz:
>> Marco Moock <mo01@posteo.de> wrote:
>> >|CentOS Stream will now be the sole repository for public
>> >RHEL-related |source code releases. For Red Hat customers and
>> >partners, source code |will remain available via the Red Hat
>> >Customer Portal.
>> >
>> > Denkt ihr, dass das das Ende von Rocky Linux & Co. wird?
>> > Eine RHEL-Lizenz würde ausreichen, um an den Code zu kommen.
>>
>> Das Dilemma ist weniger, grundsätzlich irgendwie an den Source Code
>> zu kommen, sondern der wichtige Punkt ist, unter welchen vertraglichen
>> bzw. rechtlichen Rahmenbedingungen dieser Zugriff erfolgt.
>
> Je nach Lizenz kann RedHat das einschränken, oder eben nicht. Bei der
> GPL geht es z.B. nicht.
Das wird durchaus spannend. Ich könnte mir vorstellen, dass da einige
Open-Source-Entwickler gerade hektisch mit ihren Anwälten telefonieren.
>> > Warum macht RedHat das?
>>
>> IBM (Red Hat) möchte - aus deren Perspektive durchaus verständlich -
>> gern unter Kontrolle haben, was Nutzer von RHEL damit anstellen.
>> Clones wie früher z.B. CentOS und heute Alma und Rocky entziehen
>> sich nicht nur IBMs Kontrolle, sondern bieten vielmehr größere
>> Freiheiten und weniger Unwägbarkeiten bei der Nutzung.
>
> Was gibt es denn da mehr an Freiheit?
> Es gibt keinen Support vom Hersteller.
> Mit RHEL kann man das gleiche machen wie mit Rocky Linux.
> Ich wüsste da von keinen Einschränkungen, außer halt der, dass man für
> RHEL die Lizenz braucht.
Das kann schon eine Einschränkung sein, je nachdem, wie die Lizenzen
verwaltet werden. Wenn man für jede VM erstmal eine neue Lizenz kaufen
muss, ist das ein spürbarer Verwaltungsoverhead. Zugang zu Support kann
ein weiterer Grund sein. (Mein letzter Stand bezüglich Lizenzen (viele
Jahre her) war, dass man mit jeder Server-Lizenz eine gewisse Anzahl
(5?) VM-Lizenzen mitbekommen hat. Da wir damals noch recht wenig VMs
hatten, waren Test-VMs also kein Problem. Mal schnell alte Hardware für
einen Test einrichten ging aber nicht ...)
>> > Wollen die wen vergraulen oder befürchten die mit Rocky Linux
>> > Konkurrenz, die es zu stören gilt?
>>
>> IBM guckt wie die meisten großen Firmen primär auf die Zahlen,
>> und da ist jeder z.B. CentOS-, Alma- oder Rocky-Nutzer ein
>> entgangener zahlender Kunde.
Ob das nicht eher auf Oracle Linux abzielt als auf Alma und Rocky?
> Milchmädchenrechnung. Jemand hat ggf. daheim CentOS eingesetzt, weil es
> kostenlos war. Wird der jetzt wegen nem PC daheim RHEL kaufen?
Nope, aber eine Firma, die Oracle Linux einsetzt, wird vielleicht RHEL
kaufen. Oder zumindest wird es für Oracle teurer, Oracle Linux zu
maintainen, wenn sie nicht direkt auf RHEL zugreifen können.
>> Wer bei der Einstellung von CentOS den Schuss nicht gehört hat,
>> dem ist nicht zu helfen.
Was spricht eigentlich gegen CentOS Stream?
>> Alma und Rocky waren bereits damals bloß Notlösungen, um die Zeit
>> etwas zu verlängern, in der man sich klar werden musste, ob man sich
>> in Zukunft Red Hat bzw. IBM unterordnen möchte, oder ob man zur
>> Konkurrenz wechselt.
>
> Ich habe mit RHEL-basiertem Kram außer im Geschäft noch nie zu tun
> gehabt.
>
> Da haben wir aber mittlerweile RHEL-Lizenzen.
> Für mich war das aber irgendwie privat nie interessant.
>
Ich hatte privat Red Hat Linux, bevor es Red Hat Enterprise Linux gab.
Der Split von Red Hat Linux in Red Hat Enterprise Linux und Fedora war
aber aus meiner Sicht ziemlich holprig und ich bin dann auf Debian
umgestiegen. Einige Rechner (insbesondere das Notebook) laufen unter
Ubuntu, hauptsächlich, weil sie mit Ubuntu geliefert wurden und die
Unterschiede eine Neuinstallation nicht gerechtfertigt haben. @Work
haben wir mittlerweile im Server-Bereich nur mehr Ubuntu. Die letzten
RHEL/Oracle-VMs sind wir glücklicherweise los.
hp
[toc] | [prev] | [next] | [standalone]
| From | "Andreas M. Kirchwitz" <amk@spamfence.net> |
|---|---|
| Date | 2023-06-24 13:28 +0000 |
| Message-ID | <slrnu9drs1.7dt.amk@msgid.krell.zikzak.de> |
| In reply to | #131959 |
Peter J. Holzer <hjp-usenet3@hjp.at> wrote: >>> Wer bei der Einstellung von CentOS den Schuss nicht gehört hat, >>> dem ist nicht zu helfen. > > Was spricht eigentlich gegen CentOS Stream? CentOS Stream erhält keine vollständigen Security Patches oder Bug Fixes, und es hat auch keinen Anspruch, immer in sich "rund" zu laufen, sondern es ist eben eine Entwicklungsplattform für zukünftige RHEL-Veröffentlichungen. Dies ist das genaue Gegenteil von dem, warum jemand RHEL, CentOS, Alma, Rocky usw. einsetzt. :-) Grüße, Andreas
[toc] | [prev] | [next] | [standalone]
| From | Marco Moock <mo01@posteo.de> |
|---|---|
| Date | 2023-06-24 18:28 +0200 |
| Message-ID | <u775jo$5den$2@dont-email.me> |
| In reply to | #131959 |
Am 24.06.2023 um 13:43:21 Uhr schrieb Peter J. Holzer: > On 2023-06-24 11:01, Marco Moock <mo01@posteo.de> wrote: > > Am 24.06.2023 um 10:44:39 Uhr schrieb Andreas M. Kirchwitz: > >> Marco Moock <mo01@posteo.de> wrote: > >> >|CentOS Stream will now be the sole repository for public > >> >RHEL-related |source code releases. For Red Hat customers and > >> >partners, source code |will remain available via the Red Hat > >> >Customer Portal. > >> > > >> > Denkt ihr, dass das das Ende von Rocky Linux & Co. wird? > >> > Eine RHEL-Lizenz würde ausreichen, um an den Code zu kommen. > >> > >> Das Dilemma ist weniger, grundsätzlich irgendwie an den Source Code > >> zu kommen, sondern der wichtige Punkt ist, unter welchen > >> vertraglichen bzw. rechtlichen Rahmenbedingungen dieser Zugriff > >> erfolgt. > > > > Je nach Lizenz kann RedHat das einschränken, oder eben nicht. Bei > > der GPL geht es z.B. nicht. > > Das wird durchaus spannend. Ich könnte mir vorstellen, dass da einige > Open-Source-Entwickler gerade hektisch mit ihren Anwälten > telefonieren. Es gibt ja grundsätzlich 2 Typen von Lizenzen: Restriktiv, d.h. Weitergabe nur unter gleicher Lizenz Nicht-Restriktiv: Veröffentlichung unter anderer Lizenz möglich Von beidem gibt es eigentlich haufenweise. > >> > Warum macht RedHat das? > >> > >> IBM (Red Hat) möchte - aus deren Perspektive durchaus verständlich > >> - gern unter Kontrolle haben, was Nutzer von RHEL damit anstellen. > >> Clones wie früher z.B. CentOS und heute Alma und Rocky entziehen > >> sich nicht nur IBMs Kontrolle, sondern bieten vielmehr größere > >> Freiheiten und weniger Unwägbarkeiten bei der Nutzung. > > > > Was gibt es denn da mehr an Freiheit? > > Es gibt keinen Support vom Hersteller. > > Mit RHEL kann man das gleiche machen wie mit Rocky Linux. > > Ich wüsste da von keinen Einschränkungen, außer halt der, dass man > > für RHEL die Lizenz braucht. > > Das kann schon eine Einschränkung sein, je nachdem, wie die Lizenzen > verwaltet werden. Wenn man für jede VM erstmal eine neue Lizenz kaufen > muss, ist das ein spürbarer Verwaltungsoverhead. Es gibt auch Pauschallizenen, habe wir z.B. an der Uni. > >> > Wollen die wen vergraulen oder befürchten die mit Rocky Linux > >> > Konkurrenz, die es zu stören gilt? > >> > >> IBM guckt wie die meisten großen Firmen primär auf die Zahlen, > >> und da ist jeder z.B. CentOS-, Alma- oder Rocky-Nutzer ein > >> entgangener zahlender Kunde. > > Ob das nicht eher auf Oracle Linux abzielt als auf Alma und Rocky? > > > Milchmädchenrechnung. Jemand hat ggf. daheim CentOS eingesetzt, > > weil es kostenlos war. Wird der jetzt wegen nem PC daheim RHEL > > kaufen? > > Nope, aber eine Firma, die Oracle Linux einsetzt, wird vielleicht RHEL > kaufen. Oder zumindest wird es für Oracle teurer, Oracle Linux zu > maintainen, wenn sie nicht direkt auf RHEL zugreifen können. Mal gespannt, ob die jetzt wieder Solaris auspacken. > >> Wer bei der Einstellung von CentOS den Schuss nicht gehört hat, > >> dem ist nicht zu helfen. > > Was spricht eigentlich gegen CentOS Stream? Ständige Änderungen, ist halt nicht RHEL Version X. > >> Alma und Rocky waren bereits damals bloß Notlösungen, um die Zeit > >> etwas zu verlängern, in der man sich klar werden musste, ob man > >> sich in Zukunft Red Hat bzw. IBM unterordnen möchte, oder ob man > >> zur Konkurrenz wechselt. > > > > Ich habe mit RHEL-basiertem Kram außer im Geschäft noch nie zu tun > > gehabt. > > > > Da haben wir aber mittlerweile RHEL-Lizenzen. > > Für mich war das aber irgendwie privat nie interessant. > > > > Ich hatte privat Red Hat Linux, bevor es Red Hat Enterprise Linux gab. > Der Split von Red Hat Linux in Red Hat Enterprise Linux und Fedora war > aber aus meiner Sicht ziemlich holprig und ich bin dann auf Debian > umgestiegen. Einige Rechner (insbesondere das Notebook) laufen unter > Ubuntu, hauptsächlich, weil sie mit Ubuntu geliefert wurden und die > Unterschiede eine Neuinstallation nicht gerechtfertigt haben. @Work > haben wir mittlerweile im Server-Bereich nur mehr Ubuntu. Die letzten > RHEL/Oracle-VMs sind wir glücklicherweise los. Von Ubuntu bin ich weggegangen.
[toc] | [prev] | [next] | [standalone]
| From | "Peter J. Holzer" <hjp-usenet3@hjp.at> |
|---|---|
| Date | 2023-06-24 20:40 +0200 |
| Message-ID | <slrnu9ee5q.v9he.hjp-usenet3@trintignant.hjp.at> |
| In reply to | #131993 |
On 2023-06-24 16:28, Marco Moock <mo01@posteo.de> wrote:
> Am 24.06.2023 um 13:43:21 Uhr schrieb Peter J. Holzer:
>> On 2023-06-24 11:01, Marco Moock <mo01@posteo.de> wrote:
>> > Je nach Lizenz kann RedHat das einschränken, oder eben nicht. Bei
>> > der GPL geht es z.B. nicht.
>>
>> Das wird durchaus spannend. Ich könnte mir vorstellen, dass da einige
>> Open-Source-Entwickler gerade hektisch mit ihren Anwälten
>> telefonieren.
>
> Es gibt ja grundsätzlich 2 Typen von Lizenzen:
> Restriktiv, d.h. Weitergabe nur unter gleicher Lizenz
> Nicht-Restriktiv: Veröffentlichung unter anderer Lizenz möglich
>
> Von beidem gibt es eigentlich haufenweise.
Wissen wir. Es war aber konkret von der GPL die Rede. Die anderen können
wir in diesem Thread ignorieren.
>> >> Clones wie früher z.B. CentOS und heute Alma und Rocky entziehen
>> >> sich nicht nur IBMs Kontrolle, sondern bieten vielmehr größere
>> >> Freiheiten und weniger Unwägbarkeiten bei der Nutzung.
>> >
>> > Was gibt es denn da mehr an Freiheit?
>> > Es gibt keinen Support vom Hersteller.
>> > Mit RHEL kann man das gleiche machen wie mit Rocky Linux.
>> > Ich wüsste da von keinen Einschränkungen, außer halt der, dass man
>> > für RHEL die Lizenz braucht.
>>
>> Das kann schon eine Einschränkung sein, je nachdem, wie die Lizenzen
>> verwaltet werden. Wenn man für jede VM erstmal eine neue Lizenz kaufen
>> muss, ist das ein spürbarer Verwaltungsoverhead.
>
> Es gibt auch Pauschallizenen, habe wir z.B. an der Uni.
Klar, wenn man groß genug ist, dass sich das auszahlt (oder Redhat aus
Marketing-Gründen ein großzügiges Angebot stellt). Ist halt bei den
meisten nicht der Fall.
Hmm, das waren jetzt zwei Aussagen von Dir im gleichen Posting, die mich
daran zweifeln lassen, ob Du den Unterschied zwischen "einige" und
"alle" kennst.
hp
[toc] | [prev] | [next] | [standalone]
| From | Marc Haber <mh+usenetspam1118@zugschl.us> |
|---|---|
| Date | 2023-06-25 12:57 +0200 |
| Message-ID | <u796j3$2l1s9$1@news1.tnib.de> |
| In reply to | #131959 |
"Peter J. Holzer" <hjp-usenet3@hjp.at> wrote: >Das kann schon eine Einschränkung sein, je nachdem, wie die Lizenzen >verwaltet werden. Wenn man für jede VM erstmal eine neue Lizenz kaufen >muss, ist das ein spürbarer Verwaltungsoverhead. Zugang zu Support kann >ein weiterer Grund sein. (Mein letzter Stand bezüglich Lizenzen (viele >Jahre her) war, dass man mit jeder Server-Lizenz eine gewisse Anzahl >(5?) VM-Lizenzen mitbekommen hat. Da wir damals noch recht wenig VMs >hatten, waren Test-VMs also kein Problem. Mal schnell alte Hardware für >einen Test einrichten ging aber nicht ...) Du weißt aber schon wie so ein Satellite-Server funktioniert? (Vorausgesetzt dass es den noch gibt - meine letzten Erfahrungen damit sind acht Jahre her). Grüße Marc -- -------------------------------------- !! No courtesy copies, please !! ----- Marc Haber | " Questions are the | Mailadresse im Header Mannheim, Germany | Beginning of Wisdom " | Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834
[toc] | [prev] | [next] | [standalone]
| From | "Peter J. Holzer" <hjp-usenet3@hjp.at> |
|---|---|
| Date | 2023-06-25 13:59 +0200 |
| Message-ID | <slrnu9gb0f.12obc.hjp-usenet3@trintignant.hjp.at> |
| In reply to | #132073 |
On 2023-06-25 10:57, Marc Haber <mh+usenetspam1118@zugschl.us> wrote:
> "Peter J. Holzer" <hjp-usenet3@hjp.at> wrote:
>>Das kann schon eine Einschränkung sein, je nachdem, wie die Lizenzen
>>verwaltet werden. Wenn man für jede VM erstmal eine neue Lizenz kaufen
>>muss, ist das ein spürbarer Verwaltungsoverhead. Zugang zu Support kann
>>ein weiterer Grund sein. (Mein letzter Stand bezüglich Lizenzen (viele
>>Jahre her) war, dass man mit jeder Server-Lizenz eine gewisse Anzahl
>>(5?) VM-Lizenzen mitbekommen hat. Da wir damals noch recht wenig VMs
>>hatten, waren Test-VMs also kein Problem. Mal schnell alte Hardware für
>>einen Test einrichten ging aber nicht ...)
>
> Du weißt aber schon wie so ein Satellite-Server funktioniert?
Nein, dafür waren wir zu klein.
Ich bin mir aber sicher, dass auch in dem Fall die Lizenzen überprüft
werden.
hp
[toc] | [prev] | [next] | [standalone]
| From | Stefan Möding <Jun2023.5.kill-9@spamgourmet.com> |
|---|---|
| Date | 2023-06-25 14:12 +0200 |
| Message-ID | <m2o7l3agg0.fsf@athena.moeding.net> |
| In reply to | #132078 |
"Peter J. Holzer" <hjp-usenet3@hjp.at> writes: > Ich bin mir aber sicher, dass auch in dem Fall die Lizenzen überprüft > werden. Da hat aber nicht jede VM eine eigene Lizenz. Mit der Virtual Datacenter Lizenz ist z.B. eine komplette Virtualisierungsumgebung (VMware, ...) abgedeckt und man kann eine unbegrenzte Anzahl VMs darin laufen lassen. -- Stefan
[toc] | [prev] | [next] | [standalone]
| From | Marc Haber <mh+usenetspam1118@zugschl.us> |
|---|---|
| Date | 2023-06-25 17:01 +0200 |
| Message-ID | <u79krf$2lvro$1@news1.tnib.de> |
| In reply to | #132078 |
"Peter J. Holzer" <hjp-usenet3@hjp.at> wrote: >On 2023-06-25 10:57, Marc Haber <mh+usenetspam1118@zugschl.us> wrote: >> "Peter J. Holzer" <hjp-usenet3@hjp.at> wrote: >>>Das kann schon eine Einschränkung sein, je nachdem, wie die Lizenzen >>>verwaltet werden. Wenn man für jede VM erstmal eine neue Lizenz kaufen >>>muss, ist das ein spürbarer Verwaltungsoverhead. Zugang zu Support kann >>>ein weiterer Grund sein. (Mein letzter Stand bezüglich Lizenzen (viele >>>Jahre her) war, dass man mit jeder Server-Lizenz eine gewisse Anzahl >>>(5?) VM-Lizenzen mitbekommen hat. Da wir damals noch recht wenig VMs >>>hatten, waren Test-VMs also kein Problem. Mal schnell alte Hardware für >>>einen Test einrichten ging aber nicht ...) >> >> Du weißt aber schon wie so ein Satellite-Server funktioniert? > >Nein, dafür waren wir zu klein. > >Ich bin mir aber sicher, dass auch in dem Fall die Lizenzen überprüft >werden. Vor allen Dingen werden sie automatisch angemeldet. Grüße Marc -- -------------------------------------- !! No courtesy copies, please !! ----- Marc Haber | " Questions are the | Mailadresse im Header Mannheim, Germany | Beginning of Wisdom " | Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834
[toc] | [prev] | [next] | [standalone]
| From | "Andreas M. Kirchwitz" <amk@spamfence.net> |
|---|---|
| Date | 2023-06-24 13:01 +0000 |
| Message-ID | <slrnu9dq91.7dt.amk@msgid.krell.zikzak.de> |
| In reply to | #131950 |
Marco Moock <mo01@posteo.de> wrote: >> Das Dilemma ist weniger, grundsätzlich irgendwie an den Source Code >> zu kommen, sondern der wichtige Punkt ist, unter welchen vertraglichen >> bzw. rechtlichen Rahmenbedingungen dieser Zugriff erfolgt. > > Je nach Lizenz kann RedHat das einschränken, oder eben nicht. Bei der > GPL geht es z.B. nicht. Quatsch, die GPL stellt zwar ein paar Bedingungen, aber natürlich kann IBM/RedHat noch ganz viel dranklatschen, und das tun sie auch, wäre ja sonst ein ziemlich dämliches Geschäftsmodell, wenn sie ihr Produkt ohne Einschränkungen einfach so jedem in die Hand drücken. >> IBM (Red Hat) möchte - aus deren Perspektive durchaus verständlich - >> gern unter Kontrolle haben, was Nutzer von RHEL damit anstellen. >> Clones wie früher z.B. CentOS und heute Alma und Rocky entziehen >> sich nicht nur IBMs Kontrolle, sondern bieten vielmehr größere >> Freiheiten und weniger Unwägbarkeiten bei der Nutzung. > > Was gibt es denn da mehr an Freiheit? CentOS & Co. haben eine entscheidende Zwischenschicht gebildet, die einen losgelöst hat von direkten Auflagen seitens Red Hat. > Es gibt keinen Support vom Hersteller. In vielen Szenarien wird der im Alltag so direkt nicht benötigt, sondern das macht man primär zur Absicherung, dass man das Recht hat, auch gegenüber dem Hersteller Anforderungen zu stellen, während beispielsweise bei CentOS oder gar Debian es überhaupt niemanden gibt, der im Zweifelsfall greifbar ist, und das gilt im Geschäftsleben häufig als Deal Breaker. Wer tatsächlich viel RHEL-Support benötigt, kauft sich sowieso extra Consultants dort ein. > Mit RHEL kann man das gleiche machen wie mit Rocky Linux. Nein. (Das soll keine Wertung sein, sondern nur aussagen, dass es mitnichten das gleiche ist.) > Ich wüsste da von keinen Einschränkungen, außer halt der, dass man für > RHEL die Lizenz braucht. Dann solltest Du vielleicht mal die Vertragsbedingungen lesen. :-) >> IBM guckt wie die meisten großen Firmen primär auf die Zahlen, >> und da ist jeder z.B. CentOS-, Alma- oder Rocky-Nutzer ein >> entgangener zahlender Kunde. > > Milchmädchenrechnung. Jemand hat ggf. daheim CentOS eingesetzt, weil es > kostenlos war. Wird der jetzt wegen nem PC daheim RHEL kaufen? > Eher nicht. Ja, das ist aber genau die Sichtweise von IBM - so einer hätte sowieso kein RHEL gekauft, also warum soll man eigene Ressourcen opfern, damit sich Leute mit CentOS, Alma oder Rocky durchschnorren? Hier und jetzt ist es wirtschaftlich eine nachvollziehbare Entscheidung, alle Ressourcen abzubauen, die RHEL-Clones zugute kommen und dadurch vielleicht noch ein paar Leute direkt an RHEL binden zu können. Jeder Wechsler zu RHEL ist ein Gewinn. Wer hingegen nicht zu RHEL wechselt, ist kein unmittelbarer Verlust und daher unwichtig für die Rechnung. Grüße, Andreas
[toc] | [prev] | [next] | [standalone]
| From | Marco Moock <mo01@posteo.de> |
|---|---|
| Date | 2023-06-24 18:31 +0200 |
| Message-ID | <u775p6$5den$3@dont-email.me> |
| In reply to | #131973 |
Am 24.06.2023 um 13:01:21 Uhr schrieb Andreas M. Kirchwitz: > Marco Moock <mo01@posteo.de> wrote: > > >> Das Dilemma ist weniger, grundsätzlich irgendwie an den Source Code > >> zu kommen, sondern der wichtige Punkt ist, unter welchen > >> vertraglichen bzw. rechtlichen Rahmenbedingungen dieser Zugriff > >> erfolgt. > > > > Je nach Lizenz kann RedHat das einschränken, oder eben nicht. Bei > > der GPL geht es z.B. nicht. > > Quatsch, die GPL stellt zwar ein paar Bedingungen, aber natürlich > kann IBM/RedHat noch ganz viel dranklatschen, und das tun sie auch, > wäre ja sonst ein ziemlich dämliches Geschäftsmodell, wenn sie ihr > Produkt ohne Einschränkungen einfach so jedem in die Hand drücken. Das wäre ein Verstoß gegen die GPL. GPL bedeutet, dass jeder die Rechte hat, der die Software in der Hand hat. Das gilt natürlich nur für die Sachen, die unter der GPL stehen. Wenn RedHat weitere Sachen ausliefert, gilt das natürlich nicht für diese. > > Es gibt keinen Support vom Hersteller. > > In vielen Szenarien wird der im Alltag so direkt nicht benötigt, > sondern das macht man primär zur Absicherung, dass man das Recht > hat, auch gegenüber dem Hersteller Anforderungen zu stellen, > während beispielsweise bei CentOS oder gar Debian es überhaupt > niemanden gibt, der im Zweifelsfall greifbar ist, und das gilt > im Geschäftsleben häufig als Deal Breaker. Was auch verständlich ist. Nur wer das bisher brauchte, hatte ja RHEL, für den ändert sich ja nix.
[toc] | [prev] | [next] | [standalone]
| From | Gerald E¡scher <Spamer@fahr-zur-Hoelle.org> |
|---|---|
| Date | 2023-06-24 17:10 +0000 |
| Message-ID | <168762660976.24414.18226106887509315674.XPN@ID-37099.user.uni-berlin.de> |
| In reply to | #131994 |
Marco Moock schrieb am 24/6/2023 18:31: > Am 24.06.2023 um 13:01:21 Uhr schrieb Andreas M. Kirchwitz: > >> Marco Moock <mo01@posteo.de> wrote: >> >> > Je nach Lizenz kann RedHat das einschränken, oder eben nicht. Bei >> > der GPL geht es z.B. nicht. >> >> Quatsch, die GPL stellt zwar ein paar Bedingungen, aber natürlich >> kann IBM/RedHat noch ganz viel dranklatschen, und das tun sie auch, >> wäre ja sonst ein ziemlich dämliches Geschäftsmodell, wenn sie ihr >> Produkt ohne Einschränkungen einfach so jedem in die Hand drücken. > > Das wäre ein Verstoß gegen die GPL. RedHat kann unabhängig von der GPL in die Verträge mit seine Kunden hinein schreiben, was sie wollen. Meines Wissens steht da drin, dass die Kunden aus den RHEL-Sourcen keine Distribution bauen dürfen, mit der sie in Konkurrenz zu RedHat treten. > GPL bedeutet, dass jeder die Rechte > hat, der die Software in der Hand hat. Das gilt selbstverständlich auch für RedHat-Kunden. Nach der GPL nimmt denen niemand das Recht, aus den RHEL-Sourcen RHEL zu klonen und zu veröffentlichen. RedHat wird ihnen anschließend allerdings den Vertrag kündigen und sie hätten keinen Zugang mehr zu Aktualisierungen der Sourcen. -- Gerald
[toc] | [prev] | [next] | [standalone]
| From | Marco Moock <mo01@posteo.de> |
|---|---|
| Date | 2023-06-24 19:53 +0200 |
| Message-ID | <u77aig$5udt$1@dont-email.me> |
| In reply to | #131997 |
Am 24.06.2023 um 17:10:10 Uhr schrieb Gerald E¡scher: > Marco Moock schrieb am 24/6/2023 18:31: > > > Am 24.06.2023 um 13:01:21 Uhr schrieb Andreas M. Kirchwitz: > > > >> Marco Moock <mo01@posteo.de> wrote: > >> > >> > Je nach Lizenz kann RedHat das einschränken, oder eben nicht. Bei > >> > der GPL geht es z.B. nicht. > >> > >> Quatsch, die GPL stellt zwar ein paar Bedingungen, aber natürlich > >> kann IBM/RedHat noch ganz viel dranklatschen, und das tun sie auch, > >> wäre ja sonst ein ziemlich dämliches Geschäftsmodell, wenn sie ihr > >> Produkt ohne Einschränkungen einfach so jedem in die Hand drücken. > >> > > > > Das wäre ein Verstoß gegen die GPL. > > RedHat kann unabhängig von der GPL in die Verträge mit seine Kunden > hinein schreiben, was sie wollen. Meines Wissens steht da drin, dass > die Kunden aus den RHEL-Sourcen keine Distribution bauen dürfen, mit > der sie in Konkurrenz zu RedHat treten. Wäre aber ein Verstoß gegen die GPL. Wie RedHat das vor Gericht durchsetzen will, ist mir unklar. > > GPL bedeutet, dass jeder die Rechte > > hat, der die Software in der Hand hat. > > Das gilt selbstverständlich auch für RedHat-Kunden. Nach der GPL nimmt > denen niemand das Recht, aus den RHEL-Sourcen RHEL zu klonen und zu > veröffentlichen. > RedHat wird ihnen anschließend allerdings den Vertrag kündigen und sie > hätten keinen Zugang mehr zu Aktualisierungen der Sourcen. Dazu müssten die aber auch den Kunden finden, der das tut. Mit etwas Verschleierung sollte das machbar sein.
[toc] | [prev] | [next] | [standalone]
| From | "Andreas M. Kirchwitz" <amk@spamfence.net> |
|---|---|
| Date | 2023-06-24 21:23 +0000 |
| Message-ID | <slrnu9enlt.ogp.amk@msgid.krell.zikzak.de> |
| In reply to | #131999 |
Marco Moock <mo01@posteo.de> wrote: > Wäre aber ein Verstoß gegen die GPL. Wie RedHat das vor Gericht > durchsetzen will, ist mir unklar. Du hast das Problem nicht verstanden. IBM (Red Hat) muss nichts durchsetzen, sondern sie werfen den Kunden einfach raus. Es ist nun umgekehrt der Kunde, der etwas durchsetzen müsste, aber der wäre kein Kunde (gewesen), wenn er nicht Anspruch und Zugang für Patches usw. bräuchte, also wird er alle Kröten schlucken, solange sie ihn nicht tangieren, und die wenigsten bauen ja schließlich einen RHEL-Clone. >> RedHat wird ihnen anschließend allerdings den Vertrag kündigen und sie >> hätten keinen Zugang mehr zu Aktualisierungen der Sourcen. > > Dazu müssten die aber auch den Kunden finden, der das tut. Mit etwas > Verschleierung sollte das machbar sein. IBM (Red Hat) hat Kontrolle über alle Zugriffe, und es ist nicht notwendig, ein raffiniertes Leak zu finden, sondern sie müssen den Zugang nur hinreichend umständlich gestalten und immer wieder neue Steine in den Weg legen, dass am Ende keiner mehr Lust hat, daraus noch eine Clone-Distribution zu erstellen. Wer nach der Einstellung von CentOS nicht begonnen hat, sich entweder IBM unterzuordnen oder auf eine ganz andere Linux-Welt wie z.B. Debian umzusteigen, dem ist nicht mehr zu helfen. Alma und Rocky sind prima Übergangslösungen, und vermutlich wird es sie noch viele Jahre geben, weil manche Leute den Ehrgeiz haben, solche Firmen wie IBM auszutricksen, aber RHEL-Clones sind inzwischen eine unkluge Wahl, wenn man einfach seine Ruhe haben will. Es ist belanglos, ob RHEL und GPL vereinbar sind, darüber wird schon seit Jahren (auch vor IBM) diskutiert, doch das geht am Kern der Sache vorbei. GPL hin oder her, Du kannst IBM nicht zwingen, Geschäfte mit Dir zu machen. Und wenn IBM am Ende vor Gericht unterliegt und das gesamte RHEL-Geschäftsmodell für illegal erklärt wird, dann steht es IBM frei, einfach alles zu beenden, aus die Maus, die bestehende Verträge bedient man noch bis zu ihrem kündbaren Ende, und das war's dann für alle. Du kannst nicht gewinnen. Grüße, Andreas
[toc] | [prev] | [next] | [standalone]
| From | "Peter J. Holzer" <hjp-usenet3@hjp.at> |
|---|---|
| Date | 2023-06-24 20:47 +0200 |
| Message-ID | <slrnu9eehp.v9he.hjp-usenet3@trintignant.hjp.at> |
| In reply to | #131997 |
On 2023-06-24 17:10, Gerald E¡scher <Spamer@fahr-zur-Hoelle.org> wrote:
> Marco Moock schrieb am 24/6/2023 18:31:
>> Am 24.06.2023 um 13:01:21 Uhr schrieb Andreas M. Kirchwitz:
>>> Marco Moock <mo01@posteo.de> wrote:
>>>
>>> > Je nach Lizenz kann RedHat das einschränken, oder eben nicht. Bei
>>> > der GPL geht es z.B. nicht.
>>>
>>> Quatsch, die GPL stellt zwar ein paar Bedingungen, aber natürlich
>>> kann IBM/RedHat noch ganz viel dranklatschen, und das tun sie auch,
>>> wäre ja sonst ein ziemlich dämliches Geschäftsmodell, wenn sie ihr
>>> Produkt ohne Einschränkungen einfach so jedem in die Hand drücken.
>>
>> Das wäre ein Verstoß gegen die GPL.
>
> RedHat kann unabhängig von der GPL in die Verträge mit seine Kunden
> hinein schreiben, was sie wollen.
Können sie, aber wenn das darauf hinausläuft, dass der Kunde Software,
die eigentlich unter GPL stehen müsste, nicht zu den Bedingungen der GPL
bekommt, dann verliert Redhat selbst das Recht auf diese Software.
> Meines Wissens steht da drin, dass die Kunden aus den RHEL-Sourcen
> keine Distribution bauen dürfen, mit der sie in Konkurrenz zu RedHat
> treten.
Was möglicherweise ok ist, da eine Redhat-Distribution auch einen Haufen
Nicht-GPL-Software enthält, für den sie eine solche Einschränkung machen
können. Für GPL-Software wäre das IMHO unzulässig, aber eine
Distribution, die nur aus den GPL-Teilen von RHEL besteht, wäre keine
Konkurrenz.
hp
[toc] | [prev] | [next] | [standalone]
| From | Gerald E¡scher <Spamer@fahr-zur-Hoelle.org> |
|---|---|
| Date | 2023-06-24 20:37 +0000 |
| Message-ID | <168763902735.24414.5163789876030945141.XPN@ID-37099.user.uni-berlin.de> |
| In reply to | #132003 |
Peter J. Holzer schrieb am 24/6/2023 20:47: > On 2023-06-24 17:10, Gerald E¡scher <Spamer@fahr-zur-Hoelle.org> wrote: >> Marco Moock schrieb am 24/6/2023 18:31: >>> >>> Das wäre ein Verstoß gegen die GPL. >> >> RedHat kann unabhängig von der GPL in die Verträge mit seine Kunden >> hinein schreiben, was sie wollen. > > Können sie, aber wenn das darauf hinausläuft, dass der Kunde Software, > die eigentlich unter GPL stehen müsste, Ich ergänze obige Aussage um "im Rahmen der rechtlichen Möglichkeiten". Sie dürfen auch nicht hinein schreiben, dass RHEL-Kunden ihnen ihren Erstgeborenen überlassen müssen ;-) >> Meines Wissens steht da drin, dass die Kunden aus den RHEL-Sourcen >> keine Distribution bauen dürfen, mit der sie in Konkurrenz zu RedHat >> treten. > > Was möglicherweise ok ist, da eine Redhat-Distribution auch einen Haufen > Nicht-GPL-Software enthält, für den sie eine solche Einschränkung machen > können. Für GPL-Software wäre das IMHO unzulässig, Nein, wieso? Ein Kunde, der unter der GPL lizensierte RHEL-Sourcen mit Stand heute bekommt, darf ja damit laut GPL verfahren, auch einen RHEL-Klon bauen und veröffentlichen. RedHat wird diesem Kunden allerdings mindestens den Vertrag kündigen, und er wird kein Updates mehr erhalten. In der GPL steht nicht drin, dass man ein Recht auf Updates hat. -- Gerald
[toc] | [prev] | [next] | [standalone]
| From | Marco Moock <mo01@posteo.de> |
|---|---|
| Date | 2023-06-24 22:49 +0200 |
| Message-ID | <u77kte$6s0g$4@dont-email.me> |
| In reply to | #132015 |
Am 24.06.2023 um 20:37:07 Uhr schrieb Gerald E¡scher: > Peter J. Holzer schrieb am 24/6/2023 20:47: > > > On 2023-06-24 17:10, Gerald E¡scher <Spamer@fahr-zur-Hoelle.org> > > wrote: > >> Marco Moock schrieb am 24/6/2023 18:31: > >>> > >>> Das wäre ein Verstoß gegen die GPL. > >> > >> RedHat kann unabhängig von der GPL in die Verträge mit seine Kunden > >> hinein schreiben, was sie wollen. > > > > Können sie, aber wenn das darauf hinausläuft, dass der Kunde > > Software, die eigentlich unter GPL stehen müsste, > > Ich ergänze obige Aussage um "im Rahmen der rechtlichen > Möglichkeiten". Sie dürfen auch nicht hinein schreiben, dass > RHEL-Kunden ihnen ihren Erstgeborenen überlassen müssen ;-) > > >> Meines Wissens steht da drin, dass die Kunden aus den RHEL-Sourcen > >> keine Distribution bauen dürfen, mit der sie in Konkurrenz zu > >> RedHat treten. > > > > Was möglicherweise ok ist, da eine Redhat-Distribution auch einen > > Haufen Nicht-GPL-Software enthält, für den sie eine solche > > Einschränkung machen können. Für GPL-Software wäre das IMHO > > unzulässig, > > Nein, wieso? Ein Kunde, der unter der GPL lizensierte RHEL-Sourcen mit > Stand heute bekommt, darf ja damit laut GPL verfahren, auch einen > RHEL-Klon bauen und veröffentlichen. Da es in RHEL aber auch Software unter anderen, weniger restriktiven Lizenzen gibt, wird das kein RHEL-Klon werden. > RedHat wird diesem Kunden allerdings mindestens den Vertrag kündigen, > und er wird kein Updates mehr erhalten. In der GPL steht nicht drin, > dass man ein Recht auf Updates hat. Das stimmt auch wieder.
[toc] | [prev] | [next] | [standalone]
| From | "Peter J. Holzer" <hjp-usenet3@hjp.at> |
|---|---|
| Date | 2023-06-24 22:51 +0200 |
| Message-ID | <slrnu9elr9.100ac.hjp-usenet3@trintignant.hjp.at> |
| In reply to | #132015 |
On 2023-06-24 20:37, Gerald E¡scher <Spamer@fahr-zur-Hoelle.org> wrote:
> Peter J. Holzer schrieb am 24/6/2023 20:47:
>> On 2023-06-24 17:10, Gerald E¡scher <Spamer@fahr-zur-Hoelle.org> wrote:
>>> Meines Wissens steht da drin, dass die Kunden aus den RHEL-Sourcen
>>> keine Distribution bauen dürfen, mit der sie in Konkurrenz zu RedHat
>>> treten.
>>
>> Was möglicherweise ok ist, da eine Redhat-Distribution auch einen Haufen
>> Nicht-GPL-Software enthält, für den sie eine solche Einschränkung machen
>> können. Für GPL-Software wäre das IMHO unzulässig,
>
> Nein, wieso? Ein Kunde, der unter der GPL lizensierte RHEL-Sourcen mit
> Stand heute bekommt, darf ja damit laut GPL verfahren, auch einen
> RHEL-Klon bauen und veröffentlichen.
Wenn der Vertrag eine Konkurrenzausschlussklausel beinhaltet (was meines
Wissens bei "Partnern" der Fall ist, nicht bei "Kunden"), dann darf er
das laut Vertrag eben nicht. Darum geht es IMHO in dieser Diskussion:
Dass Redhat über einen Vertrag Rechte einschränkt, die die GPL
garantiert.
hp
[toc] | [prev] | [next] | [standalone]
| From | Marco Moock <mo01@posteo.de> |
|---|---|
| Date | 2023-06-25 13:04 +0200 |
| Message-ID | <u79709$f2vt$4@dont-email.me> |
| In reply to | #132019 |
Am 24.06.2023 um 22:51:53 Uhr schrieb Peter J. Holzer: > Wenn der Vertrag eine Konkurrenzausschlussklausel beinhaltet (was > meines Wissens bei "Partnern" der Fall ist, nicht bei "Kunden"), dann > darf er das laut Vertrag eben nicht. Darum geht es IMHO in dieser > Diskussion: Dass Redhat über einen Vertrag Rechte einschränkt, die > die GPL garantiert. Dann könnte man dagegen aber klagen. Die Autoren der GPL-Programme würden das mindestens mal versuchen. Ich vermute daher, dass sowas eher nicht passieren wird. Ich traue IBM zu, das dann eher zu erschweren, z.B. durch Captchas.
[toc] | [prev] | [next] | [standalone]
| From | "Peter J. Holzer" <hjp-usenet3@hjp.at> |
|---|---|
| Date | 2023-06-25 14:01 +0200 |
| Message-ID | <slrnu9gb50.12obc.hjp-usenet3@trintignant.hjp.at> |
| In reply to | #132076 |
On 2023-06-25 11:04, Marco Moock <mo01@posteo.de> wrote:
> Am 24.06.2023 um 22:51:53 Uhr schrieb Peter J. Holzer:
>> Wenn der Vertrag eine Konkurrenzausschlussklausel beinhaltet (was
>> meines Wissens bei "Partnern" der Fall ist, nicht bei "Kunden"), dann
>> darf er das laut Vertrag eben nicht. Darum geht es IMHO in dieser
>> Diskussion: Dass Redhat über einen Vertrag Rechte einschränkt, die
>> die GPL garantiert.
>
> Dann könnte man dagegen aber klagen. Die Autoren der GPL-Programme
> würden das mindestens mal versuchen.
Was glaubst Du warum ich in einem Posting in diesem Thread bereits die
Vermutung geäußert habe, dass einige Open-Source-Entwickler bereits mit
ihren Anwälten telefonieren würden?
hp
[toc] | [prev] | [next] | [standalone]
| From | Gerald E¡scher <Spamer@fahr-zur-Hoelle.org> |
|---|---|
| Date | 2023-06-25 14:43 +0000 |
| Message-ID | <168770419402.24414.15429949720702918835.XPN@ID-37099.user.uni-berlin.de> |
| In reply to | #132019 |
Peter J. Holzer schrieb am 24/6/2023 22:51: > On 2023-06-24 20:37, Gerald E¡scher <Spamer@fahr-zur-Hoelle.org> wrote: >> Peter J. Holzer schrieb am 24/6/2023 20:47: >>> On 2023-06-24 17:10, Gerald E¡scher <Spamer@fahr-zur-Hoelle.org> wrote: >>>> Meines Wissens steht da drin, dass die Kunden aus den RHEL-Sourcen >>>> keine Distribution bauen dürfen, mit der sie in Konkurrenz zu RedHat >>>> treten. >>> >>> Was möglicherweise ok ist, da eine Redhat-Distribution auch einen Haufen >>> Nicht-GPL-Software enthält, für den sie eine solche Einschränkung machen >>> können. Für GPL-Software wäre das IMHO unzulässig, >> >> Nein, wieso? Ein Kunde, der unter der GPL lizensierte RHEL-Sourcen mit >> Stand heute bekommt, darf ja damit laut GPL verfahren, auch einen >> RHEL-Klon bauen und veröffentlichen. > > Wenn der Vertrag eine Konkurrenzausschlussklausel beinhaltet (was meines > Wissens bei "Partnern" der Fall ist, nicht bei "Kunden"), dann darf er > das laut Vertrag eben nicht. Sehe ich nicht so. Der Kunde/Partner darf ja einen Klon bauen und veröffentlichen, RedHat kann ihn deswegen nicht klagen. Er wird allerdings von RedHat keine weiteren Binaries und Sourcen von RHEL erhalten, was aber keinen Verstoß gegen die GPL darstellt. -- Gerald
[toc] | [prev] | [next] | [standalone]
Page 4 of 6 — ← Prev page 1 2 3 [4] 5 6 Next page →
Back to top | Article view | de.comp.os.unix.linux.misc
csiph-web