Red Hat 'blijft zich inspannen voor opensourcesoftware' ondanks RHEL-paywall

Red Hat blijft zich inspannen voor opensourcesoftware, maar gaat de plannen rondom beperkte beschikbaarheid van RHEL niet intrekken. Dat zegt het bedrijf in een eerste reactie op de ophef die ontstond na vorige week, toen bleek dat Red Hat zijn Enterprise Linux achter een paywall wil zetten.

Mike McGrath, de vicepresident van Core Platforms Engineering bij Red Hat, schrijft in een blogpost dat het bedrijf zich wil blijven inzetten voor opensourcesoftware en -licenties als GPL. Red Hat Enterprise Linux, of RHEL, blijft volgens hem onder zo'n licentie beschikbaar. Tegelijk verandert het bedrijf niet van mening en blijft RHEL voortaan achter een paywall staan. Dat is volgens McGrath nodig, omdat andere ontwikkelaars RHEL vaak gebruiken als basis voor eigen distro's die zij vervolgens met winst doorverkopen. Het zijn juist die mensen, zegt hij, die het meest boos zijn op de paywall. "Deze vraag naar RHEL-code is oneerlijk", zegt McGrath. "Wij moeten mensen betalen voor al het werk dat ze doen."

McGrath noemt het ook 'categorisch onwaar' dat RHEL nu closedsourcesoftware zou zijn. "Er is een verschil tussen de binary en de broncoderepository van CentOS Stream", zegt hij. In die laatste worden RHEL-releases openbaar gemaakt 'waar iedereen het kan zien'. CentOS Stream is sinds 2020 geen rebuild van RHEL meer, maar de enige repo die is gebaseerd op RHEL.

Er is een verschil tussen distro's die eigen architectuur en compile flags toevoegen aan RHEL en distro's die enkel RHEL pakken, dat herverpakken en doorverkopen, zegt McGrath. Dat laatste noemt hij 'een serieuze bedreiging voor open source en opensourcebedrijven'. McGrath waarschuwt dat dergelijke praktijken 'de opensourcewereld terugwerpen naar dat van de hobbyisten en hackers'.

De blogpost is een reactie op een eerdere aankondiging van Red Hat. Het bedrijf zei vorige week dat het RHEL niet meer algemeen beschikbaar maakt, maar alleen verkoopt aan Red Hat Enterprise-klanten. Daarmee is CentOS Stream nog de enige beschikbare RHEL-repo. Dat heeft grote gevolgen voor alternatieve distro's zoals Rocky Linux of AlmaLinux, die allemaal gebruikmaken van RHEL en die zichzelf ook presenteren als alternatieven voor CentOS en RHEL. Rocky Linux zei eerder al dat het denkt dat de beslissing geen grote gevolgen heeft voor de toekomst van het besturingssysteem. Rocky Linux zegt dat het weliswaar niet meer geautomatiseerd kan werken, maar dat het een langetermijnstrategie opstelt die rekening houdt met de beperkte beschikbaarheid.

Reacties (138)

[Stetsed]

Dus ik denk dat dit een interessante situatie gaat zijn omdat technisch gezien volgens de GPL, een license die veel wordt gebruikt in de linux community mag je geen restricties op leggen op de redistributie van de source code, wat red hat hier probeert te doen door te zeggen “Als je de packages deelt om een nieuwe distro te maken cancellen we je abbo” dus hoe ze dit gaan doen zal zeker interessant zijn.

Hiernaast boren ze zich zelf zo hard de grond in, red hat is juist een van de bedrijven die in goed zicht stond van de linux community omdat het zo open was en zoveel terug leverende aan open source, en dan doen ze die waardoor ze all die goede will die ze verzameld hebben weg gooien.

Het gaat interessant zijn.

[Reactie gewijzigd door Stetsed op 23 juli 2024 09:32]

[zaphod_b]

Klopt niet helemaal. Check de video van Jeff Geerling, hierboven al genoemd.

Linux valt onder de GPL, daar moet RH zich dus aan houden. Dat betekent dat ze aanpassingen aan code *altijd* moeten vrijgeven. Maar… ze mogen daar wel geld voor vragen. Die ‘regel’ was ooit ingevoerd zodat je bijvoorbeeld wel geld kon vragen voor een CD met een distro erop, iets dat in de jaren 90 veel werd gedaan. Ik heb zelf ooit nog eens SUSE op CD gekocht. Je zou kunnen stellen dat ook het online beschikbaar maken kosten met zich meebrengt, van opslag en dataverkeer. Daar mag RH een vergoeding voor vragen. Of het netjes is, dat is vers twee.

Het is allemaal vrij subtiel en het wordt interessant als er een rechtszaak uit voort zou komen. Jeff Geerling legt het heel netjes en exact uit in zijn video, aanrader. En Jeff heeft gewoon gelijk: dit is een hele achterlijke actie van RH.

Persoonlijk hoop ik dat veel professionele partijen nu over zullen stappen naar wat anders, zoals Debian Linux. Ik ben nooit een RedHat fan geweest, maar dat komt vooral door mijn forse afkeer van RPM, de packagemanager from hell IMHO.
Als er een bedrijf opstaat dat op Enterprise niveau support kan leveren voor Debian, dan denk ik dat dat wel eens een goed alternatief kan worden.

[Bulkzooi]

Dus ik denk dat dit een interessante situatie gaat zijn omdat technisch gezien volgens de GPL, een license die veel wordt gebruikt in de linux community mag je geen restricties op leggen op de redistributie van de source code

Het gaat interessant zijn.

Klopt niet helemaal.
Linux valt onder de GPL, daar moet RH zich dus aan houden. Dat betekent dat ze aanpassingen aan code *altijd* moeten vrijgeven.

Nee, de source code moet vrij beschikbaar en toegankelijk zijn. Dus enkel beschikbaar stellen via Cent Stream is een ongeoorloofde limitatie.

Er zijn al cases geweest waarbij de sources ernstig vertraagd gepubliceerd werden en waarbij er een .tarball gereleased werd met daarin een organisatorische chaos. Ook zijn er gevallen bekent waarbij de source-code enkele minuten online was en daarna verdween.

De source verstoppen achter een paywall (MIT licensed toevallig?) breekt alles wat de GPL vertegenwoordigd. Maar ja, de GPL is dan ook net het Wilde Westen.

Is dit het einde van Open Source Software? Of enkel een tikje van IBM richting Oracle? Voer voor de advocaten of voor de filosofen?

Either way, de software community at large is in gevaar. En dat komt door de wetten.

@Arnoud Engelfriet wat denk jij?

[Reactie gewijzigd door Bulkzooi op 23 juli 2024 09:32]

[Arnoud Engelfriet]

"de source code moet vrij beschikbaar en toegankelijk zijn" Als we juridisch gaan lezen, staat er in de GPL dat de broncode meegeleverd moet worden met de objectcode. Ik mag dus enkel jou de tarball mailen als ik enkel jou de software geef. Als een ander dan komt vragen om de broncode, hoef ik niets te doen. Maar ik mag jou niet beletten die software aan hem te geven.

Als ik de broncode niet meelever, moet ik een 'written offer' meegeven met mijn binary dat een ieder deze drie jaar lang mag komen opeisen bij mij. (Ik ga even uit van GPLv2 want Linux kernel.)

Er is geen regel dat je dingen moet publiceren of gratis/ongehinderd online moet zetten. Dus het mag, enterprise users tegen betaling binaries geven en alleen die users toegang geven tot de (GPL) broncode. Wat niet mag is die enterprise users verbieden de broncode verder te verspreiden. Maar als geen van die users daar zin in heeft, dan heb je dus een de facto closed ecosysteem voor GPL software.

[GekkePrutser]

Wat niet mag is die enterprise users verbieden de broncode verder te verspreiden. Maar als geen van die users daar zin in heeft, dan heb je dus een de facto closed ecosysteem voor GPL software.

Maar dit doet RedHat dus wel, ze verbieden die enterprise gebruikers om de source code publiek te maken, op straffe van het intrekken van hun licentie.

Trouwens: RedHat biedt ook 16 gratis developer licenties aan, aan particulieren. Die krijgen dus de gecompileerde binaries, als ik het verhaal goed begrijp mogen ze die dus ook de source code niet weigeren?

[Reactie gewijzigd door GekkePrutser op 23 juli 2024 09:32]

[dmantione]

Let wel dat "niet mogen verbieden" bij de GPL een redelijk letale constructie is: Bij overtreding verlies je permanent al je rechten op de GPL-software, voor een Linuxdistributeur zou dat een curatorbezoek opleveren. Nu is het gebruikelijk dat een overtreder vergiffenis kan krijgen, maar niet vanzelf. De FSF sloot dan altijd expliciet contracten af waarin de betreffende partij dan beterschap moest beloven.

[dmantione]

Waar mijn inziens het probleem zit, is dat contractueel beperkingen worden opgelegd aan klanten die toegang tot het broncodeportaal hebben, dat wat ze daar downloaden niet verder mogen verspreiden. Dat is in strijd met het beginsel van de vrijheid of de dood voor het programma, zoals beschreven in de GPL. Red Hat is vrij om contracten af te sluiten wat ze willen, maar het kan leiden tot een schending van de GPL. Of dat werkelijk zo is, hangt af van de handhaving en interpretatie van de specifieke tekst. Zeker is, dat wat hier gebeurt niet de bedoeling is van de GPL. Je mag geld vragen voor distributie, maar degene die het programma ontvangt mag niet beperkt zijn het programma weer verder te verspreiden.

[laurxp]

Nee, de source code moet vrij beschikbaar en toegankelijk zijn.

Maar dat is het ook - voor klanten van Red Hat.

De GPL zegt dat een ieder die van jou de binaries ontvangt, gratis of tegen kostprijs ook de broncode bij mag opvragen. Je krijgt de binaries alleen als je Red Hat betaalt (dit is expliciet in de GPL toegestaan), en Red Hat heeft nul verplichtingen om de broncode beschikbaar te maken aan derden. Op dat vlak doen ze dus niks verkeerd.

Het enige dat hier wellicht problematisch is, is dat ze in de voorwaarden van de subscription zeggen dat ze je subscription annuleren als jij als klant de broncode verder verspreid. Het is niet zwart/wit., maar dit is wellicht in strijd met de GPL.

[Bulkzooi]

Maar dat is het ook - voor klanten van Red Hat.

General Public License

Lol, waar Bill Gates de GPL als virus ervaart, daar ervaar ik de licentie als een filosofische rem. In het geval van software, een spirituele rem zelfs.

anyway, het subscription model koppelen aan de GPL heeft geen enkele zin, zonder de SaaS-loophole goed in overweging te nemen inclusief effecten die in de geopolitiek de laatste 10 - 20 - 30 - 40 jaar waargenomen zijn. Denk vooral aan exponentialiteit en verfijningen in heuristics.

Da's het mooie van data-wetenschap: het is de meest liquide wetenschap van alle informatie wetenschappen.

@Arnoud Engelfriet yes, GPL v2 en de busybox case zijn wel DE referentie. Tiviozation en de SaaS-loophole zijn andere beschreven elementen van de storyline. En die draait idd om objectcode, compilers en nu dus compiler flags.

Deze zaak kan net zo goed een een-tweetje tussen Oracle en IBM zijn, als onderdeel van een lange termijn visie.

[Reactie gewijzigd door Bulkzooi op 23 juli 2024 09:32]

[GekkePrutser]

Lol, waar Bill Gates de GPL als virus ervaart, daar ervaar ik de licentie als een filosofische rem. In het geval van software, een spirituele rem zelfs.

Dat was Ballmer en ging specifiek over de GPLv3, niet de GPLv2.

Overigens houdt Apple zich ook ver van GPLv3. Ze hebben om die reden bijvoorbeeld bash vervangen door zsh op macOS.

[Bulkzooi]

Dat was Ballmer en ging specifiek over de GPLv3, niet de GPLv2.

Overigens houdt Apple zich ook ver van GPLv3. Ze hebben om die reden bijvoorbeeld bash vervangen door zsh op macOS.

ow ja, het is Libre BillyBoy & Viral Steve.

https://arstechnica.com/i...l-which-we-disagree-with/

Toch wel meer dan frappant dat al die partijtjes die een paar decennia zich hard hebben gemaakt voor software ideology allemaal vastgelopen zijn... in een ORM mapper of zo.

Maar je kan idd niet stellen dat alle sporen naar Redmond en Santa Clara leiden. Qua faciliteren niet, maar ook de coverups niet. lol, fakenews geschreven met een balpen lijkt me dan ook een factor 80 miljard maal minder schadelijk dan de digitale variant.

[Reactie gewijzigd door Bulkzooi op 23 juli 2024 09:32]

[thomvh]

Is dat niet wat Ubuntu van Canonical een beetje is?

[zaphod_b]

Een beetje wel, alleen is Ubuntu een afgeleide van Debian, maar echt wel wat anders ondertussen. Debian lijkt me voor servertoepassingen veel stabieler…

[thomvh]

Wij kiezen toch voor Ubuntu juist om die support optie... Omdat Debian die geheel mist.

[pennywiser]

Support is een commercieel verdienmodel. Debian is geen bedrijf maar een non-profit instelling. En inderdaad stabieler dan Ubuntu .

Waarom overigens die support afnemen, wordt dit opgelegd door klanten, of missen jullie zelf de kennis? En heb je ook echt iets aan die support optie? Of zit je bijna altijd nog steeds zelf te Googlen naar oplossingen?

[Reactie gewijzigd door pennywiser op 23 juli 2024 09:32]

[thomvh]

Voornamelijk klant vraag. Zijn een klein bedrijfje met best veel kennis in huis voor het formaat. Maar klanten wilden toch dat we die extra stok achter de deur hebben in geval van nood.

[Terr-E]

Wij draaien bij ons al meer dan 10 jaar Ubuntu Server voor vrijwel alle toepassingen, en ik zou me geen stabieler OS kunnen wensen. Ik zie geen enkel punt waarop Debian een verbetering zou zijn aangaande stabiliteit, dus misschien dat het in het verre verleden zo was dat Debian daadwerkelijk stabieler was dan Ubuntu, maar anno 2023 is het verschil nihil. (en ja, we hebben in het verleden ook Debian gedraaid)

En wat betreft de opmerkingen van @zaphod_b en @thomvh hierboven; Er zijn zat bedrijven (met name grote multinationals en overheden) die een verplichting hebben (van bovenaf opgelegd vanuit de industrie of naar beneden contractueel afgesproken met afnemers) tot support van de leverancier van door hen gebruikte software, dus die zullen sowieso een distro moeten gebruiken die first party support levert (e.g. RedHat, Suse, Ubuntu, Oracle) en dan valt Debian meteen al buiten de boot, hoe goed de distro ook is.

[Stetsed]

Ik praat ook niet over het geld er voor vragen, ik praat over het consequenties aan hangen voor distributie. Dat is waar het heel legaal grijs wordt. Omdat ze eigenlijk zeggen “Als je dit gebruikt in nog een distro stoppen we je abbo” wat eigenlijk de license breekt in spirit omdat de gebruiker eigenlijk dezelfde rechten krijgt als red hat dus ze mogen het redistrubten maar wat je dan zou kunnne argumenteren “We stoppen je niet om het te redistrbuteren we geven je alleen niet de nieuwere versie”

[Reactie gewijzigd door Stetsed op 23 juli 2024 09:32]

[zaphod_b]

Check, dat klopt inderdaad. Want stel dat je netjes betaald om het te downloaden, dan mag je dat vervolgens absoluut herdistribueren. De code valt immers *altijd* onder de GPL.

[Hydranet]

Niet alle software die binnen RHEL gebruikt word valt onder GPL er zitten ook een heel op andere licenties tussen die minder restrictief zijn als GPL.

[lenwar]

Het is allemaal vrij subtiel en het wordt interessant als er een rechtszaak uit voort zou komen

Nou ja, subtiel... Hij praat wel heel erg in een moraalriddertoontje vind ik
Op een gegeven moment verliest hij bij mij wel een vracht geloofwaardigheid wanneer hij klaagt over het feit dat hij een week moet spenderen om z'n spullenboel om te zetten naar de gratis (!!) Red Had Developer-zaken (op 4m30), in plaats van iets productiefs te doen (zoals het opnemen van filmpjes. #sarcasme)

En Jeff heeft gewoon gelijk: dit is een hele achterlijke actie van RH.

Dit ben ik helemaal met je eens overigens!! Ik vind het ook maar een rare actie van Red Hat/IBM

Aan de andere kant snap ik hem ook wel een beetje: Zij steken heel veel tijd/energie (en dus geld) in hun product (een gebalanceerde Linux distro, die zij commercieel ondersteunen), en dan komt er een derde distro die een kopietje maakt, een 'search and replace' doet met Red Hat ---> Alma, en klaar. (uiteraard kort door de bocht)

[GekkePrutser]

en dan komt er een derde distro die een kopietje maakt, een 'search and replace' doet met Red Hat ---> Alma, en klaar. (uiteraard kort door de bocht)

Vergeet alleen niet waarom die distro er gekomen is. Juist doordat redhat zelf stopte met de echte CentOS.

[Superstoned]

Nou ja, maar dat had precies hetzelfde probleem he. Wat de GPL betreft hoeft RH alleen maar naar de repo's met originele source te verwijzen. Ze hoeven echt niet kant en klaar alles samengevat te hebben voor andere commerciele bedrijven die geld willen verdienen aan het kopieren van RHEL. Voor klanten maken ze dan de source RPM's beschikbaar - onder de voorwaarde dat die dat niet distribueren. De klanten mogen de SOURCE wel distribueren - de tarballs, de github repo's etc, dus ik denk niet dat de GPL hier geschonden wordt.

[deadinspace]

Nou ja, subtiel... Hij praat wel heel erg in een moraalriddertoontje vind ik

Volgens mij bedoelt zaphod_b dat het juridisch vrij subtiel is of wat Red Hat precies doet nu wel of niet legaal is. Niet dat Jeff subtiel is.

[Reactie gewijzigd door deadinspace op 23 juli 2024 09:32]

[Hydranet]

Niemand heeft de video nog gelinkt dus bij deze.
https://www.youtube.com/watch?v=kF5pyVUQBH8

**Edit: Kennelijk dus wel maar het kan geen kwaad om 'm nog een keer te delen**

[Reactie gewijzigd door Hydranet op 23 juli 2024 09:32]

[cobis taba]

Ik heb mijn twijfels of je geld mag vragen, omdat de tekst specifiek gaat over "the physical act of transferring a copy". Daar mag je een vergoeding voor vragen, maar is een download een physical act?

[laurxp]

Ja, waarom niet?

Daarnaast zegt de volgende zin "you may at your option offer warranty protection in exchange for a fee", en je betaalt vooral voor RHEL omdat ze support bieden.

[cobis taba]

Dat tweede stuk lees ik als "je mag een optie bieden", maar niet als "je mag dit als enige optie bieden". Kortom:
- Je moet het gratis aanbieden
- Je mag een vergoeding vragen voor de "the physical act of transferring a copy"
- Je mag een garantie als service bieden en daar een vergoeding voor vragen.

Mijn lezing is dan echter dat:
- Je voor "the physical act of transferring a copy" sowieso alleen eenmalig een vergoeding kan vragen. Het gaat immers specifiek om de transfer, een specifieke handeling en geen doorlopende actie.
- Een download is een digital transfer, niet een physical act lijkt me.

Alle juridische bronnen die ik zo snel kan vinden gaan bij een physical act echt uit van een fysieke handeling, in de echte wereld, waarbij iets van A naar B verplaatst wordt. Iets dat je kunt aanraken, bv. op DVD of USB-stick, of...

Ik kan het daar mis hebben, vandaar dat ik het twijfel noem. Maar mijn hunch is toch dat dit niet de bedoeling is van de regels.

[Superstoned]

De vraag is ook wat de 'source' is hier. RH kan toch gewoon naar het Github repo of naar KDE, GNOME, de kernel repo's etc verwijzen? Daar kun je de broncode vinden. De rest mag je dan zelf doen. Lijkt me volledig legit, om eerlijk te zijn. De concurrentie voor RHEL werkt alleen maar omdat ze geheel automatisch alles kunnen herbouwen. Op deze manier moeten ze opeens echt werk doen om geld te verdienen. Lekker voor ze.

[laurxp]

Distributies hebben praktisch altijd patches bovenop de upstream source code, de code van de Github repo van KDE/etc is dus niet 100% wat er daadwerkelijk draait.

Daarnaast voegen distro's ook een heleboel eigen dingen toe, de upstream code is bij lange na niet genoeg om een werkend OS te maken.

[Superstoned]

Ja, ik simplificeer een beetje. Maar er zit een flink gat tussen de code beschikbaar maken en het bouwen van een kopie een kwestie van 1 bash script maken. Dat eerste moet natuurlijk, dat 2e niet. En daar zijn ze dus mee gestopt, dat is alles. En dat is, mijns inziens, hun goed recht. De code is open, voor het werk mag je betalen - als bedrijf, voor individuen of kleine bedrijfjes is het natuurlijk nog steeds gratis...

[laurxp]

Over dát stuk bestaat geen enkele twijfel, dit is al decennia de norm.

[zaphod_b]

Kijk eens naar de laatste release van Debian zou ik zeggen. Dat is een stuk verbeterd. En in een enterprise omgeving (of edu) wil je vooral stabiliteit en niet per se bleading edge.

[deadinspace]

Debian is net zo goed verschrikkelijk om te gebruiken. Lekker versies van packages en libraries van 8 jaar oud gebruiken

Debian released elke 2 jaar een nieuwe stable. Dus bij release van een nieuwe versie is de software in de vorige versie ongeveer 2½ jaar oud. Dit is vergelijkbaar met Ubuntu LTS (ook elke 2 jaar).

RHEL daarentegen released ongeveer elke 3-4 jaar. Tussen RHEL 7 en 8 zat zelfs 5 jaar, daarmee is RHEL gemiddeld duidelijk ouder dan Debian. (En het is bij RHEL niet zeldzaam een oudere versie tegen te komen bij bedrijven. Leuk, RHEL 6 met software uit 2010!)

Het is een fabel dat Debian gelijk staat aan oude software. Ja, vergeleken met een cutting edge rolling release distributie wel, maar vergeleken met normale OSsen met stabiele releases is het meer een middenmoot.

[TD-er]

Die goede naam stond al in de schaduw nadat ze CentOS eigenlijk de nek om hadden gedraaid.

[Cergorach]

Dus ik denk dat dit een interessante situatie gaat zijn omdat technisch gezien volgens de GPL, een license die veel wordt gebruikt in de linux community mag je geen restricties op leggen op de redistributie van de source code, wat red hat hier probeert te doen door te zeggen “Als je de packages deelt om een nieuwe distro te maken cancellen we je license” dus hoe ze dit gaan doen zal zeker interessant zijn.

Volgens mij zeggen ze niet, we cancellen je license, maar je abo wordt beëindigd, waardoor je daarna dus geen toegang meer hebt tot de source code.

Vragen die ik heb zijn:
- Wat kost toegang tot die software/sourcecode?
- Hoe denkt men te kunnen achterhalen dat X source code heeft gedistribueerd? Zijn ze van plan signatures toe te voegen/verbergen in de sourcecode/license?

[DDX]

De toegang kost niets :

https://developers.redhat...-red-hat-enterprise-linux

Maar ook die heeft weer beperkingen waarvoor je het mag gebruiken, dus je zal alle lettertjes moeten doornemen.

[Cergorach]

Dat zijn ten eerste de voorwaarden van 5 februari 2021, dus van 2,4 jaar geleden. En als het gratis is, is dat dus niet de 'paywall' waar RH het over heeft.

[Nieleken]

Die voorwaarden gelden nog steeds. Die "paywall" bestaat er vooral voor commerciële bedrijven, die betalen voor Red Hat support

[jeffrey4413]

Jeff geerling heeft een goeie video hierover gemaakt en ook een blog post die het lezen en het kijken wel waard is:
https://www.jeffgeerling....-red-hat-enterprise-linux
https://youtu.be/kF5pyVUQBH8

[Keeper of the Keys]

Nog een goede overview van Learn Linux TV:

https://www.youtube.com/watch?v=fqfyM7zE6KM

[nzbee]

Dank voor deze link.
Voor degenen die achtergrond missen, raad ik aan de video vanaf het begin te kijken. Voor degenen die geinteresseerd zijn in de recente ontwikkelingen, raad ik aan om op 7:46 te beginnen (gebookmarkt onder de video).

Ik vraag mezelf af of ik me voor de kop moet slaan omdat ik nu Rocky Linux gebruik. Had ik niet beter moeten weten na het CentOS debacle?

En ik ben ervan overtuigd dat AlmaLinux en Rocky hun best gaan doen om hun distributies bij te houden, maar ik ga niet meer wachten tot Red Hat de volgende streek levert. Ik stap over op... Debian waarschijnlijk.

[WhatsappHack]

Ze blijven ons wel lekker naaien daar bij RedHat. Eerst die stunt met CentOS 7/8 en nu alles dat in dat gat gesprongen is en veel processen nu op over zijn proberen de nek om te draaien.

“Het zijn juist die mensen, zegt hij, die het meest boos zijn op de paywall.”

Press X to doubt. Het zijn juist opensource communities en gebruikers van de volledige FOSS-varianten die pissig zijn op deze achterlijke fratsen en de enorme onbetrouwbaarheid die het bedrijf nu voor de zoveelste keer uitstraalt.

[wimdebok]

Ik was weer blij met de Rocky na het gedoe rond CentOs maar inmiddels denk ik dat het tijd wordt voor een switch naar Debian. Ik snap dit niet, door deze alternatieve varianten wordt het woord van Red Hat (incl RPM) wijd verpspreid en heeft het bijgedragen aan de populariteit. En kan je bijvoorbeeld de toon zetten in Linux land, waren het niet twee redhat ontwikkelaar die voor de systemd hebben gezorgd? Ben er gekomen doordat bedrijven het veel gebruiken en het een prettig systeem vind of inmiddels aan gewend ben. De handel van Red Hat zit in de betaalde ondersteuning en het oerwoud van certificaten. Een ander systeem went ook zo weer, Debian is zeker geen straf en is ook mooi.

[Htbaa]

Sinds een paar jaar ben ik over op CentOS 8 en dat is vrij snel AlmaLinux geworden na het cancellen van CentOS 8. Daarvoor zat ik altijd bij Ubuntu wat me altijd goed is bevallen (al had ik daar ook wel bij identieke installaties dat op de ene server na een reboot Apache bijv. niet automatisch in de lucht kwam, of dat bijv. ClamAV niet geherstart kon worden zonder een reboot...). De reden dat ik toen over ben gegaan is vanwege de lange support. Iedere 4-5 jaar een server moeten migreren was ik wel een beetje klaar mee. Ondertussen enorm veel spijt dat ik op 2 Ubuntu servers na alles op AlmaLinux heb draaien. I.c.m. Ubuntu ESM/Pro (eerste 5 licenties gratis) heb je ook die 10 jaar ondersteuning voor een server.

Los van dat een migratie naar een andere server de nodige tijd en gedoe kost, moet ik ook mijn installatie + configuratiescripts weer gaan afstemmen op Ubuntu (of Debian). Zo blijf je bezig :-).

[wimdebok]

Het hangt er natuurlijk vanaf hoeveel servers je hebt maar kan me voorstellen dat het een klus is, Centos/Rocky is toch een hele andere smaak dan Ubuntu. Ja, dan kan ik me voorstellen dat je baalt. Aan de andere kant moet je denken, het is ook goed om je systemen weer goed te leren kennen.

Even terug van Centos7 naar Rocky overgegaan. Nadat Rocky beschikbaar kwam bij de serverboer (transip) overgegaan, ook altijd wel leuk werk op een of andere manier

Heb wel besloten mocht dit, het besluit van IBM over Red Hat, gevolgen hebben voor Rocky (en varianten) dan ga deze Linux smaak achter me laten. Vind het een stijlloze vertoning, eerst dat geintje met Centos en nu dit. Ik denk dat de mensen bij IBM vergeten zijn waar Red Hat vandaan komt.

Edit: draai overigen Rocky ook op de desktop, iets anders, geweldig systeem dat Linux en prachtige toepassing. Even reclame maken.

[Reactie gewijzigd door wimdebok op 23 juli 2024 09:32]

[Htbaa]

Gelukkig ben ik nog steeds bekend met Ubuntu dus de transitie valt dan mee. Het is alleen wel zo dat ik de configuratiebestanden héél goed moet nalopen. Waar ik bij EL vaak zag dat het grotendeels standaard configuraties zijn was dat bij Ubuntu vaak niet het geval. Zolang je je eigen configuraties in losse bestanden hebt staan die weer worden ingelezen is het goed te overzien. Maar er zijn altijd wel wat pijnpunten die je moet oplossen.

Voor nu wacht ik nog even af of en hoe dit opgelost wordt. Maar net als jou bepaalt dit wel wat ik in de toekomst met EL ga doen.

Linux op de desktop heb ik inmiddels al heel lang niet meer gedraaid. Wisselde altijd af tussen Linux en Windows :-). Inmiddels over op de Mac. Heb nog wel een oude Asus EeePC met Ubuntu liggen (met ik denk 20.04), maar die gebruik ik niet meer (met Windows toen al niet vooruit te branden, met Ubuntu gaat het maar het booten is zo traag ondanks de SSD). Wellicht dat ik mijn oude PC (i7, 32GB RAM) nog 's ga inzetten als Linux bak. Maar heb al een Intel NUC met Proxmox met de nodige containers draaien die deze rol vervult.

[CH4OS]

RedHat boort zich met deze actie zo enorm de grond in, er is best een boel commotie ontstaan door deze actie en heel veel systeembeheerders zijn op zijn zachtst gezegd niet echt te spreken hierover. Reden hiervoor is dat een boel open source software dat normaliter gratis aangeboden wordt, voor betaald moet worden in RHEL. Op die manier lijkt RedHat geld te willen gaan verdienen over de ruggen van ontwikkelaars / maintainers van packages, die zijzelf gratis aanbieden.

Ik begrijp heel goed dat open source niet per se gratis hoeft te zijn, maar de manier waarop Red Hat dit nu doet, verdiend verre van een schoonheidsprijs.

[swhnld]

Toen IBM (Ik Betaal Meer) het bedrijf Red Hat kocht zat het al in de pijplijn dat ze die investering terug zouden willen gaan verdienen.
Eerst gingen ze vervolgens CentOS de nek omdraaien als stabiele versie, en nu de pay-wall dat mensen gaan betalen voor het onderhoud en de support die er achter zit.

En dan kun je als systeembeheerder die steeds gratis meegelift heeft niet blij zijn, maar dan moet je als diezelfde systeembeheerder ook in de spiegel kijken en bedenken wat je bedrijf echt nodig heeft en wat dat waard is.
Uiteindelijk betaal je ergens mee voor iets wat je wil. In dit geval als je gratis bedrijfssoftware wil zul je over moeten naar een andere distributie en daar tijd in moeten steken om al je servers over te zetten. Wil je enterprise kwaliteit support zul je een contract moeten sluiten. Wil de werkgever niet betalen en krijg je ook de tijd er niet voor, dan moet je gaan solliciteren. En dat klinkt hard, maar zo kijkt je werkgever er ook naar. net als IBM/RedHat winst wil maken, wil het bedrijf wat de software gebruikt dat ook.
Dus schakel om naar een Debian of OpenSuse met je servers als je een gratis distributie wil blijven gebruiken. Of kijk eens goed welk betaalde alternatieven er zijn en vergelijk RHEL met Suse, Ubuntu of een van de kleinere professioneel ondersteunde distributies, en overweeg of je op een van die partijen over wil stappen.

Daarnaast kies je voor de gratis versie, denk ook na of en wat je kunt bijdragen om het gratis te houden. Besteed een halve dag per week met vragen beantwoorden op een support forum (een win voor beide want je leert er zelf ook van naast dat je anderen helpt), of biedt een download omgeving om te helpen een distributie te verspreiden en de bandbreedte kosten voor de distributie beheerders te verminderen, of help ergens mee ontwikkelen aan een stukje software, of doe met regelmaat een financiële donatie aan de organisatie achter de software.

[CH4OS]

Het gaat niet om het betalen voor de subscription door klanten van Red Hat of support van hen. Maar wat het effect is door Red Hat. Derden ontwikkelen een security patch voor een package die zij beheren en geven die in principe gratis uit, want package heeft een GPL licentie en is open source.

Red Hat maintained een repo voor RHEL based distributies. Daar komt deze patch in. Maar vooraleer deze patch daadwerkelijk wordt uitgerold naar de klanten, heeft de klant een subscription nodig bij Red Hat. Terwijl Red Hat zelf geen seconde werk besteed heeft aan het maken van de patch, maar wel over de rug van de maker van die patch geld verdiend.

[swhnld]

Nee, Red Hat doet wel degelijk werk, want het verwerken van die patch betekend ook dat ze vervolgens dit mee nemen in hun regressie testen en security om die patch vervolgens veilig te laten samen werken met alle andere componenten in de RHEL distributie alsmede backwards compatibility.

En dat basis pakket waar de patch voor gemaakt is, kan door elke andere distributie ook gebruikt worden, waar die distributie nu door Red hat de regressie testen en security testen en al het andere werk laten doen om het vervolgens in hun eigen distributie te gebruiken.

En wil je als basis pakket niet dat dit gebeurt, dan moet je je eigen open source licentie aanpassen. Er zijn gewoon licenties die stellen dat de software alleen hergebruikt mag worden als het eindproduct de source code ook volledig publiek publiceert. Zou Red Hat dat dan alsnog gebruiken komt de source code van RHEL volledig open source, en hoeven de distributies die daar gebruik van maken alleen het zelf nog maar te compileren.

[CH4OS]

Ware het niet dat de code die zij ook gratis ophalen en herdistribueren in veel gevallen via GPL gelicenseerd is. Die staat herdistributie toe en moedigt dat zelfs aan. Doordat Red Hat daar nu een paywall tussen zet (en zelfs zichzelf het recht geeft subscriptions te annuleren als je eea herdistribueert), zou dat nog best eens tegen het GPL principe kunnen zijn. Je kunt je zelfs afvragen wat de legaliteit ervan is.

Zoals ik net rakelings al zei: prima dat Red Hat geld vraagt voor werk dat zij verricht hebben, maar als een package 'bij de bron' al GPL is, moet je dat ten alle tijden kunnen en mogen verspreiden. Iets wat Red Hat nu dus tegenhoudt.

En dat basis pakket waar de patch voor gemaakt is, kan door elke andere distributie ook gebruikt worden, waar die distributie nu door Red hat de regressie testen en security testen en al het andere werk laten doen om het vervolgens in hun eigen distributie te gebruiken.

Nee, zover ik begrijp kan dit dus niet meer dus vanuit Red Hat's optiek, ook niet als je wel een subscription hebt.

En wil je als basis pakket niet dat dit gebeurt, dan moet je je eigen open source licentie aanpassen. Er zijn gewoon licenties die stellen dat de software alleen hergebruikt mag worden als het eindproduct de source code ook volledig publiek publiceert.

Dat doet o.a. GPL dus en laat veel ook beschikbaar zijn onder GPL. Dat is juist het hele punt. Bekijk voor meer diepgang de linkjes van jeffrey4413 in 'Red Hat 'blijft zich inspannen voor opensourcesoftware' ondanks RHEL-paywall' even.

[Reactie gewijzigd door CH4OS op 23 juli 2024 09:32]

[lenwar]

Dat is niet helemaal waar.
Red Hat backport patches. Binnen een major release, garanderen zij dat packages functioneel identiek blijven en verzorgen dus ook patches. Wanneer de upstream packages al lang niet meer geüpdatet worden.

Bijvoorbeeld:

RHEL 8 is gebaseerd op
Linux kernel versie: 4.18.0 - De Linux kernel project ondersteunt deze versie al jaren niet meer (4.16 en 4.19 wel als long term). Alle patches die uitkomen worden door Red Hat gebackport naar die versie
Samba versie: 4.9.1 - De Samba foundation ondersteund die versie al niet meer sinds november 2018. Red Hat patcht hem nog steeds.

Enzovoorts.

Als iets werkt op RHEL 8.0, dan werkt het gegarandeerd ook op RHEL8.9 (aldus Red Hat). Dat is de meerwaarde van Red Hat als commerciële Linux distro.
(( en dan even los van hoe succesvol ze daar in zijn. Dat is het product dat ze verkopen ))

[CH4OS]

Als zij dit ook met packages met GPL licentie doen, dan moet men het beschikbaarstellen, anders voldoet Red Hat niet aan de GPL.

[lenwar]

Dat doen ze ook netjes. Alleen achter een Paywall. En dit mag ook conform GPL

https://www.gnu.org/licenses/gpl-3.0.nl.html

You may charge any price or no price for each copy that you convey, and you may offer support or warranty protection for a fee.

Overigens is bijvoorbeeld Apache httpd niet GPL-gelicentiëerd, maar Apache License 2.0, die het ook toelaten:
https://www.apache.org/licenses/LICENSE-2.0

While redistributing the Work or Derivative Works thereof, You may choose to offer, and charge a fee for, acceptance of support, warranty, indemnity,

[dmantione]

De betaalmuur is het probleem niet. Het probleem is de taal dat klanten die toegang tot dat portaal hebben de broncode niet verder zouden mogen verspreiden. Het is dat wat op gespannen voet met de GPL staat.

[lenwar]

Op die manier...
Ik zit even te denken. De GPL is een copyright-licentie. Geen gebruikslicentie toch? Ik vind het maar een ingewikkelde. Ik stel voor dat we de advocaten van Oracle tegen de advocaten van IBM het laten uitvechten

[dmantione]

Het is een copyright-licentie inderdaad, maar het beginsel is "vrijheid of dood voor het programma". Als om wat voor reden dan ook een beperking van toepassing op je is, waardoor je de GPL niet kunt naleven, dat mag een contract, een patent of een wet, dan vervalt de licentie.

Dus stel: Ik teken een contract dat ik een GPL-programma niet verder ga verspreiden. Niets dat me tegenhoudt een dergelijk contract af te sluiten, de inhoud van contracten is vrij. Echter staat in de GPL dat zodra ik mijn handtekening daaronder zet, mijn rechten op het GPL-programma vervallen.

[Reactie gewijzigd door dmantione op 23 juli 2024 09:32]

[deadinspace]

De GPL is een copyright-licentie. Geen gebruikslicentie toch?

Correct.

Stel, we nemen de Linux kernel, deze valt onder de GPL 2.0. Red Hat mag deze niet verspreiden (want copyrightwetgeving) tenzij ze daar toestemming van de rechthebbenden voor hebben.

Een licentie regelt zo'n toestemming. Bij commerciele software koop je zo'n licentie, bij de GPL krijgt iedereen die licentie gratis mits ze zich aan de voorwaarden in de GPL houden. Wil je je niet aan die voorwaarden houden? Prima, maar dan heb je ook geen licentie om de software te verspreiden.

Één van de voorwaarden in de GPL is dat als je de software in kwestie verspreidt, je dit onder dezelfde licentie doet, onder de GPL dus. Mensen die de software van Red Hat ontvangen, krijgen dit dus onder de GPL, en hebben daarmee ook de rechten die de GPL geeft. Dit mag Red Hat niet inperken.

De letterlijke tekst uit de GPL (v2.0) is:

Each time you redistribute the Program (or any work based on the Program), the recipient automatically receives a license from the original licensor to copy, distribute or modify the Program subject to these terms and conditions. You may not impose any further restrictions on the recipients' exercise of the rights granted herein.

Als Red Hat mensen extra beperkingen oplegt dan voldoen ze dus niet aan de voorwaarden van de GPL, en hebben ze dus geen licentie om de software te verspreiden, en plegen ze dus copyright-inbreuk. Gebruik komt bij deze kwestie verder niet kijken.

De vraag is een klein beetje of wat ze doen daadwerkelijk valt onder "impose any further restrictions on the recipients' exercise of the rights granted herein". Dat is in het ergste geval aan een rechter om te beoordelen.

[anvil]

En er zijn genoeg dingen die hard stuk gaan of juist ineens wel werken bij overgang tussen minor versies. In de RHEL7 tijd sloopte een glibc ooit heel wat code.

[lenwar]

Zoals ik al schreef. Even los van hoe succesvol ze daar in zijn, maar dat is het product dat ze verkopen…

[Williams123]

Dat wordt misschien nog een probleem mijn mail server draait op almalinux. Heb dit past geleden overgezet van centos. Zou niet mooi wezen als het geen updates/security updates etc meer zou krijgen, omdat red hat eraan wilt verdienen.

en ja de ontwikkelaars etc krijgen die ook weer betaald door red hat?

Je zou als ontwikkelaar etc kunnen zetten dan doe we niets meer op RHEL voor hun alleen op andere platforms. geen idee of dat ze makkelijk gaat verder.

[IrBaboon79]

Migreren naar debian of Ubuntu Server LTS dan maar? mailservers zijn over het algemeen niet al te spannend immers

[Reactie gewijzigd door IrBaboon79 op 23 juli 2024 09:32]

[GekkePrutser]

Debian heeft niet zulke lange LTS en met Ubuntu zit je weer vast aan dat snap gedoe

[IrBaboon79]

Dat snap gedoe kan je gewoon zonder, ze proberen die meuk er wel steeds meer in te schuiven (vooral op de desktop versies) maar op de server (console/shell only) heb je er gelukkig geen last van en kan je die services gewoon uitzetten of de snapstore in je externe firewall zetten

[deadinspace]

Debian heeft niet zulke lange LTS

Debian heeft tegenwoordig LTS support, tot minstens 5 jaar na release. (Hierin zijn wel niet alle packages ondersteund, zie Using LTS).

Er is zelfs een los project voor Extended LTS, wat het tot tien jaar zou verhogen, maar dit is geen project van Debian zelf, en is nog beperkter in ondersteunde packages. Ik heb persoonlijk met beiden geen ervaring overigens.

Aan de andere kant, is iedere twee jaar een updateronde het einde van de wereld? Mijn ervaring met oa postfix en dovecot is dat die software weinig meer verandert en dat een Debian update relatief weinig voeten in aarde heeft.

[GekkePrutser]

Met Debian heb ik vervelende ervaringen met upgrades ja. Er gaat bijna altijd wel wat stuk.

Ubuntu doet dit beter met zijn do-release-upgrade die veel van tevoren checkt op problemen.

Van die nieuwe LTS wist ik niet. Vroeger ging het naar het security maintenance team (moest je je repo ook veranderen) maar die deed er nooit zo lang aan. Sinds die tijd gebruik ik het eigenlijk ook niet meer.

[Reactie gewijzigd door GekkePrutser op 23 juli 2024 09:32]

[deadinspace]

Met Debian heb ik vervelende ervaringen met upgrades ja. Er gaat bijna altijd wel wat stuk.

Serieus? Ik gebruik al meer dan 20 jaar Debian en kan me eigenlijk geen noemenswaardige problemen herinneren.

Wel volg ik altijd de Upgrade Release Notes die aangeeft wat je moet doen en waar je op moet letten.

Van die nieuwe LTS wist ik niet. Vroeger ging het naar het security maintenance team (moest je je repo ook veranderen) maar die deed er nooit zo lang aan.

Tegenwoordig doet het Debian security team support tot 1 jaar na de release van een nieuwe versie (doorgaans 3 jaar dus), en daarvoor volg je gewoon de main repos. Die LTS support neemt het daarna over, voor ongeveer 2 jaar (tot 5 jaar na release).

Voorzover ik begrijp hoef je daar ook je sources.list niet aan te passen (maar nogmaals: ik heb geen ervaring met de LTS).

[Hydranet]

Ik heb ook net kort geleden al mijn vpsen over gezet naar Rocky Linux 9, nu lijkt het er op dat Rocky Linux wel weer verder kan

https://rockylinux.org/news/brave-new-world-path-forward

En volgens mij heeft Alma Linux ook wel weer een manier gevonden.

https://almalinux.org/blog/impact-of-rhel-changes

Does this mean I won’t be getting security updates for my AlmaLinux OS Server?

No. In the immediate term, our plan is to pull from CentOS Stream updates and Oracle Linux updates to ensure security patches continue to be released. These updates will be carefully curated to ensure they are 1:1 compatible with RHEL, while not violating Red Hat’s licensing, and will be vetted and tested just like all of our other releases.

Maar we zien wel hoe het zich ontwikkeld, ik zit er eigenlijk niet op te wachten om mijn vpsen nu allemaal weer over te gaan zetten naar Debian en ik durf er niet op de te gokken dat ze ooit niet geld gaan vragen voor de developer subscriptie.

[_JGC_]

Bij RHEL betaal je voor een stabiel platform met "support". Stabiel in de vorm van een platform zonder al te grote veranderingen. RHEL steekt hier veel tijd en geld in, van het geld dat ze verdienen aan RHEL worden ontwikkelaars in loondienst betaald.

RHEL7 komt bijvoorbeeld met httpd-2.4.6. Die release is van juli 2013, 10 jaar oud inmiddels. In die 10 jaar is het 98x gepatcht. Bij elke security update die Apache uitbrengt voor hun webserver mogen zij die patch backporten naar een zwaar aangepaste Apache versie van 10 jaar oud en de garantie geven dat het ook daadwerkelijk blijft werken.
Ander voorbeeld is de kernel. RHEL7 komt met 3.10, RHEL8 met 4.18 en RHEL9 met 5.14. Geen van allen een upstream ondersteunde LTS kernel, maar Redhat ondersteunt het wel 10 jaar. Lekker bugfixes uit moderne kernels uitpluizen en fixen in oude code die intussen al meerdere malen compleet is herschreven.

Redhat steekt serieus veel tijd en geld in bovenstaande dingen, en vervolgens is er een "community" die gewoon geautomatiseerd je SRPMs ript, 's/Redhat/Rocky/g', 's/Redhat/Alma/g' of 's/Redhat/Oracle/g' erover en vervolgens kunnen de freeloaders gratis meeliften op het monnikenwerk van Redhat.

De GPL vereist dat je je klanten voorziet van de broncode en dat je patches teruggeeft. Betalende klanten kunnen gewoon de SRPMs downloaden, en patches worden in principe gewoon teruggegeven.

Overigens vraag ik me af wat de waarde van zo'n enterprise distributie is voor de meeste gebruikers. Ik zie het heel veel in combinatie met DirectAdmin gebruikt worden, waarbij dan alle software uit source gecompileerd wordt met custombuild. Weg support vanuit de distributie.

[Some12]

Even wat ophelderingen:
1. Red Hat is gratis voor elke organisatie met minder dan (ik geloof) dertien computers. (Of was het elf?)
Iedereen kan zo’n developper acount krijgen…;
2. CentOS stream blijft open voor iedereen om te kopieëren. Red Hat haar eigen repo gaat dicht voor derden zonder account;
3. Mensen die een account afnemen krijgen gewoon de source, a-la GPL;
4. Red Hat doet alle fixes eerst upstream;
5. Pineuten zijn de mensen die de service willen rebranden als hun eigen.

Nou is hier dus niets aan de hand. Het wordt echter een probleem wanneer derden zoiets gaan doen, zonder aanpassingen eerst upstream te maken. Kudo’s voor Red Hat, maar problematische uitvinding voor de toekomstige bedrijven die hiermee potentieel aan de haal gaan.

Tijd voor een GPLv4?

[lenwar]

Nou, ja. Precies dit.
Voor ongeveer 100% van de particulieren is er geen probleem. Zij kunnen gewoon RHEL gratis gebruiken (tot 16 (virtuele) machines, wat vermoedelijk wel voldoende zou moeten zijn voor privé/hobbygebruik). Het enige dat je dan niet hebt, is commerciële ondersteuning (nou is mijn professionele ervaring dat het niveau hiervan zeer variabel is #verwoordhetnetjes, andere discussie ) maar alleen self-service.

Voor kleine ontwikkelaars is het bovenstaande model is dus ook gewoon prima te doen. Als je daadwerkelijk je brood verdiend met producten voor Red Hat maken, dan zal je inderdaad een licentie moeten nemen. Dat zijn dan eenmaal je kosten. Net zoals iemand in de grafische industrie de facto een Adobe-licentie nodig heeft op de betreffende producten.

[laurxp]

Het is voor kleine ontwikkelaars vooral verschrikkelijk irritant. Als er een bug report komt en je vermoed dat het komt door een issue in een library, moet je ineens een developer account aanmaken en moeilijk gaan doen met licenties voordat je kan kijken welke code er nou precies in RHEL zit. Bij letterlijk iedere andere distro is de code gewoon vrij beschikbaar.

Als RHEL niet je primaire platform is, is het dan ook een heel stuk aantrekkelijker om een bug report direct als WONTFIX te sluiten. Waarom zou je al die moeiten doen?

[lenwar]

Dat is natuurlijk maar gewoon een eenmalig iets. Ik snap dat het minder handig is dan het niet te doen, maar het is niet zo dat je drie keer per week een developer license aan het maken bent..

[pennywiser]

Dat hoeft ook maar 1 x. Je hoeft niet telkens nieuwe accounts aan te maken. De subscriptie vernieuwen op OS niveau moet wel regelmatig, al hoeft dat ook maar 1x per jaar per installatie.

[lenwar]

Dat bedoel ik. Dat is dus in de praktijk geen probleem voor een ontwikkelaar.
Die zullen in de praktijk toch regelmatig verse installaties uitvoeren lijkt mij?

[pennywiser]

Lijkt mij wel inderdaad, of snapshots. Zojuist mijn dev subscriptie renewed, die was net een paar weken verlopen, en met subscription manager loopt alles meteen weer door op OS niveau. Zou die Geerling 100en machines hebben dat ie daar een week mee bezig is?

Je kan ook een Alma of Rocky migratie script ombouwen naar RHEL en dan met Ansible de subscriptie zelf even regelen. Lijkt me geen week werk.

[lenwar]

Dat idee had ik ook al.
Ik zeg niet dat ik hem ongelijk geef, maar het is, naar mijn mening, wel een beetje overdramatisch/moraalridderig hoe hij er over spreekt.

[dieterdem]

Als je software ontwikkelt om te verkopen en zeker wil zijn dat die vlot werkt op RHEL, heeft Red Hat hier ook een "partner subscription" voor: https://connect.redhat.co...its/partner-subscriptions . Je hoeft dus niet noodzakelijk de developer subscription te gebruiken en als ik de website goed lees, krijg je hier support bij.

[Keeper of the Keys]

1. Tot 16 vziw
2. CentOS Stream is niet te vergelijken met RHEL, rolling release vs. LTS.
3. Er wordt vermeld dat RH probeert te claimen dat je de source niet mag herdistribueren wat een overtreding is van de GPL.
4. -
5. Behalve misschien Oracle "wilde" CentOS/Alma/Rocky dat allemaal niet maar was dat de enige oplossing voor het hebben van een distro die binary compatible is met RHEL en dus software die specifiek voor RHEL is ontwikkelt te draaien zonder te veel gedoe (alien op Debian etc), dat alles is begonnen toen RHEL alleen nog source ter beschikking stelde en eiste dat binary redistribution zonder hun merken etc zou gebeuren.

GPLv4? Wat zou dat oplossen, Linux is nog steeds GPLv2 en GPLv3 is niet heel erg geaccepteerd.

[EXX]

Oracle doet 2 kernels leveren, de UEK en de RHEL compatible kernel. Het is dus niet puur rebranding.

Overigens, zou Oracle nu een probleem hebben zou het me niet verbazen dat Oracle een rechtzaak zou beginnen. Ik weet niet wie er diepere zakken heeft: RedHat/IBM of Oracle...

[DDX]

' Dat is volgens McGrath nodig, omdat andere ontwikkelaars RHEL vaak gebruiken als basis voor eigen distro's die zij vervolgens met winst doorverkopen.'

Maar welke partij verkoopt een distro dan voor winst ?

[Nieleken]

Rocky Linux is gemaakt door CiQ, die Rocky gratis aanbieden en dan support contracts verkopen. Heel gelijkaardig aan Red Hat dus, waarbij ze RHEL als een soort van "vreemde" upstream gebruiken (heel veel mensen die nu replies schrijven, begrijpen volgens mij niet hoe git.centos.org synchronisatie überhaupt werkte) waar ze niet aan terug contributen.

[rbr320]

Wat betreft punt 1, ook voor @Some12: Red Hat heeft het aantal licenties in zijn developer subscription inmiddels opgehoogd naar 240, wat behoorlijk veel is. Het vervelende aan zo'n developer subscription is echter dat je hem niet kunt vernieuwen, je moet hem elk jaar opnieuw aanvragen. Het verschil is subtiel maar het gevolg is dat je eens per jaar al je systemen opnieuw aan een licentie moet koppelen. Dat proces is uiteraard goed te automatiseren, maar het blijft irritant.

edit: zojuist even ingelogd in mijn Red Hat account en ik zie nu nog maar 16 entitlements, waar dit er gisteren nog 240 waren, iets wat Jeff Geerling ook vermeld in zijn video. Zou Red Hat hun beslissing om het aantal entitlements in de Developer Subscription op te hogen terug hebben gedraaid?
edit2: bleek om een bug in de website te gaan. De RD4I licentie blijft beperkt tot 16 entitlements.

[Reactie gewijzigd door rbr320 op 23 juli 2024 09:32]

[Hydranet]

1. Red Hat is gratis voor elke organisatie met minder dan (ik geloof) dertien computers. (Of was het elf?)
Iedereen kan zo’n developper acount krijgen…;

Ja dat kan maar Red Hat kan ook na een tijd zich gaan bedenken en ineens besluiten dat ze ook geld willen voor de developer subscriptie.

[Annihlator]

Dus als ik het goed begrijp, als ik in een homelab wil rommelen met RHEL zonder zelf te hoeven compilen, kan dat nadien nog steeds middels de CentOS Stream repo?

[Xander2]

GPLv4?

Je kunt geen additionele restricties aan GPL toevoegen via distributie.
Dit is een proefballonnetje en ik ben benieuwd hoe de FSF hierop gaat reageren.

Edit: het is ook heel simpel op te lossen als een kernelontwikkelaar zich affilieert met Rocky- of AlmaLinux.

[Reactie gewijzigd door Xander2 op 23 juli 2024 09:32]

[svennd]

Zoals ik het begrijp mag je de code die achter de paywall staat ook niet verder distribueren wat dus wel problematisch is voor Rocky/Alma en varianten...

[TD-er]

En ik vraag me serieus af hoe legaal dit is.

[lenwar]

https://www.gnu.org/licenses/gpl-3.0.nl.html

You may charge any price or no price for each copy that you convey, and you may offer support or warranty protection for a fee.

Sowieso mag Red Hat gewoon geld vragen voor hun 'product'. Zij mogen ook best voorwaarden stellen aan het gebruik van hun software. Zij zijn slechts verplicht de code beschikbaar te stellen.

[dmantione]

... zonder verdere beperkingen op te leggen:

"You may not impose any further restrictions on the exercise of the rights granted or affirmed under this License."

(sectie 10 in de GPL v3).

[lenwar]

Volgens mij betreft dit de afnemer.

RHEL is in dit geval het product. Niet de individuele packages waar RHEL uit bestaat. Volgens mij moet je die zinsnede zo lezen, dat bijvoorbeeld AlmaLinux geen geld mag vragen voor haar product.

Ik bedoel. Zelfs Oracle (de meesters in het uitbuiten zelf) geven 'Oracle Linux' (financieel) gratis weg en als er ook maar één bedrijf op de wereld is, die er geld voor had gevraagd omdat ze het kunnen had het wel Oracle geweest.

[dmantione]

Ik snap je antwoord niet. Wat het product is, is voor de GPL geheel niet relevant, de GPL spreekt enkel over een programma dat onder bepaalde voorwaarden verspreid mag worden. Geld daarvoor vragen is toestaan, ontvangers verbieden opnieuw te verspreiden is verboden.

En geld vragen voor Linuxdistributies is van alle tijden, in de goede oude tijd kocht je een pakket Slackware-CD's in de winkel.

[TD-er]

Probleem waar ik op doelde was dat zij restricties leggen op het verder verspreiden van de source code en dat is volgens mij niet toegestaan volgens de GPL.

[deadinspace]

Sowieso mag Red Hat gewoon geld vragen voor hun 'product'.

Dat mogen ze. Maar als ze GPL software van anderen verspreiden (zoals bijvoorbeeld de Linux kernel, Gnome, glibc, gcc), dan moeten ze ook de source code leveren, hoogstens tegen een kostendekkende betaling. Uit de GPLv2, sectie 3:

3. You may copy and distribute the Program (or a work based on it, under Section 2) in object code or executable form under the terms of Sections 1 and 2 above provided that you also do one of the following:

a) Accompany it with the complete corresponding machine-readable source code, which must be distributed under the terms of Sections 1 and 2 above on a medium customarily used for software interchange; or,
b) Accompany it with a written offer, valid for at least three years, to give any third party, for a charge no more than your cost of physically performing source distribution, a complete machine-readable copy of the corresponding source code, to be distributed under the terms of Sections 1 and 2 above on a medium customarily used for software interchange

Zij mogen ook best voorwaarden stellen aan het gebruik van hun software.

Dat mogen ze absoluut niet in het geval van andermans GPL software! Uit de GPLv2, sectie 6:

6. Each time you redistribute the Program (or any work based on the Program), the recipient automatically receives a license from the original licensor to copy, distribute or modify the Program subject to these terms and conditions. You may not impose any further restrictions on the recipients' exercise of the rights granted herein. You are not responsible for enforcing compliance by third parties to this License.

Wel mag Red Hat dit natuurlijk voor software waar zij de copyright op hebben. Ook mogen ze het voor software onder vrijere licenties (zoals BSD/MIT). Maar ze mogen het niet voor heel RHEL, want dat bestaat voor een significant deel uit andermans GPL software.

[Reactie gewijzigd door deadinspace op 23 juli 2024 09:32]

[lenwar]

Dat klopt uiteraard, maar Geldt dit ook als het om een nieuw product gaat, dat de gebruikte componenten overstijgt?

Zij leveren niet Red Hat GBLIC of zo. Zij leveren 'RHEL', wat 'slechts uit een aantal GPL-componenten' bestaat. (even gechargeerd, want het is volgens mij voor meer dan 90% uit GPL-compnenten, maar even voor de discussie). Zij leggen geen beperking op de gebruikte glibc, enz, enz, maar op RHEL.

Mag dat dan ook niet? Want hier gaat het denk ik een beetje scheef?

Ze bieden de individuele packages ook gewoon aan (zij het achter een paywall, maar ook gratis, alleen moet je ingelogd zijn). Zij stellen een beperking op RHEL, niet op GLIBC of de andere individuele packages.

[deadinspace]

Zij leveren niet Red Hat GBLIC of zo. Zij leveren 'RHEL', wat 'slechts uit een aantal GPL-componenten' bestaat.

Klopt, en daarom hangt het er ook van af wat ze exact doen. Ik heb geen RHEL developer license en dergelijke, dus ik ken hun exacte voorwaarden niet.

Stel, ze leveren aan klanten een systeem met een ongewijzigde glibc, een gepatchte kernel voor enterprise features, en een Red Hat Control Panel™ (los stuk software dat ze zelf geschreven hebben). Dan bieden ze klanten ook de source van deze drie aan. Op glibc en de kernel mogen ze geen verdere beperkingen leggen.

Voor het control panel mogen ze doen wat ze willen. In principe mogen ze die zelfs onder de GPL aanbieden EN extra beperkingen opleggen. De GPL kan hier niks tegen doen, want Red Hat mag als copyrighthouder sowieso die software verspreiden, daar hebben ze geen licentie voor nodig. Dat zou niet erg in de geest van Open Source zijn, maar goed.

Wat mogelijk wel heel relevant is, is dat ze van de kernel ook hun wijzigingen onder de GPL beschikbaar moeten stellen. Ik kan me voorstellen dat Red Hat wel het een en ander aan bestaande software aanpast om bepaalde enterprise features te bieden (Ksplice zou een voorbeeld van zoiets kunnen zijn).

Het lijkt er dus nogal van af te hangen wat hun voorwaarden precies zijn. Als dat is "Je mag van de RHEL sources niks verspreiden", dan breekt dat vrij duidelijk met de GPL. Als ze specifieker zijn dan is het juridisch gezien misschien wel OK.

Maar zelfs als ze juridisch binnen de lijntjes kleuren dan is het wel begrijpelijk dat mensen hier alsnog niet blij mee zijn. Het is de grenzen opzoeken van waar ze mee wegkomen. En voor velen voelt het alsof RH gaat van "samenwerken met de community" naar "alleen maar profiteren van het werk van anderen". Want Red Hat klaagt dat "andere ontwikkelaars RHEL vaak gebruiken als basis voor eigen distro", maar ondertussen gebruiken zij een gigantische berg software als basis voor hun distro. Da's ook wel een beetje het idee van Open Source.

[Verwijderd]

Dat is precies de hele reden waarom iedereen zo 'kwaad' is. Men is van mening dat dit tegen de GPL ingaat. Maar goed, begin maar eens een zaak tegen RedHat / IBM...
Dan kun je beter eieren voor je geld kiezen en van distro veranderen.

[Big Mama]

De reden dat veel mensen hier kwaad om zijn, is omdat Red Hat wel gebruik maakt van de inspanningen van de open source ontwikkelaars, maar de omgekeerde weg probeert te belemmeren.
Het sudo adagium is: "with great power comes great responsibility", en Red Hat lijkt sinds de overname door IBM meer te neigen naar "improve shareholder value", en lijkt zich minder aan te trekken van zijn roots.

[Verwijderd]

Ik reageer op de vraag 'En ik vraag me serieus af hoe legaal dit is.'

[jbhc]

Een in mijn ogen mooie tegenactie zou zijn om RHEL uit te sluiten in de GPL

[Reactie gewijzigd door jbhc op 23 juli 2024 09:32]

[foobar79]

Let wel, er is een verschil tussen het schenden van de GPL en de user agreement/paywall met Redhat (je RHEL licentie of je developer agreement)

In dit geval breek je dus het “contract” met Redhat en ze zeggen dan dat ze je niet langer als klant willen. Daarmee zullen ze de toegang tot de website/source ontnemen en die sources hoeven ze dan ook niet meer te geven omdat je geen klant meer bent.

[Verwijderd]

"McGrath waarschuwt dat dergelijke praktijken 'de opensourcewereld terugwerpen naar dat van de hobbyisten en hackers'."

Maar.. dat is toch precies waar het zich thuis voelt? Wat is daar mis mee? Moet per se alles door de kapitalistische geldmachine worden gemangeld?

[MneoreJ]

Het is een meer dan ironische quote, die me veel doet denken aan deze historische uitspraak:

Who can afford to do professional work for nothing? What hobbyist can put 3-man years into programming, finding all bugs, documenting his product and distributing it for free? The fact is, no one besides us has invested a lot of money in hobby software.

-- Bill Gates, "An Open Letter to Hobbyists", 1976

Dit was uiteraard lang voor MS zich bedreigd voelde door OSS en Linux omver probeerde te trekken en nog wat verder voor MS helemaal on board was met OSS en Linux omarmde.

[ari3]

Dit was uiteraard lang voor MS zich bedreigd voelde door OSS en Linux omver probeerde te trekken en nog wat verder voor MS helemaal on board was met OSS en Linux omarmde.

Nou laat dat omarmen maar weg. Ze ondersteunen schoorvoetend Linux in Azure, maar voor de reste werkt Microsoft open source en open koppelingen actief tegen. Ze publiceren de specificatie van (interne) Windows APIs nog steeds niet waardoor Wine actief tegengewerkt wordt. Ook kun je nog steeds geen terminal service profile in ActiveDirectory schrijven via LDAP waardoor bijvoorbeeld Java applicaties geen gebruikerprofile kunnen opvoeren/muteren in AD.

[MneoreJ]

Waar jij het over hebt is interoperabiliteit tussen Windows en de rest. Op dat punt is er door de jaren heen inderdaad verder weinig veranderd, en dat kan ook moeilijk anders, want dat Windows spullen alleen op Windows draaien is zo'n beetje het enige bestaansrecht van Windows. Lullig voor de rest van de wereld, maar niet iets waar simpel iets aan te doen is -- dat openen zou voor MS vooral duur worden en weinig opleveren, ten opzichte van inzetten op hun cloud diensten.

Qua Linux ondersteunen gaat MS echt wel een stuk verder dan schoorvoeten: WSL bakt Linux in Windows zelf, SQL Server is geport naar Linux, .NET target actief Linux en alle closed source stukken van .NET worden actief geopend. Een aantal jaar geleden was dat allemaal volstrekt ondenkbaar geweest.

[DDX]

Er is een verschil tussen distro's die eigen architectuur en compile flags toevoegen aan RHEL en distro's die enkel RHEL pakken, dat herverpakken en doorverkopen

Dat doorverkopen slaat op Oracle Linux ?

En die blogpost van Rocky Linux is wel erg onduidelijk.

While this decision does change the automation we use for building Rocky Linux, we have already created a short term mitigation and are developing the longer term strategy. There will be no disruption or change for any Rocky Linux users, collaborators, or partners.

Hoe lossen ze dit nu op, nemen ze 1 subscription en halen ze op die manier de sourcecode op ?

[Stetsed]

Dus dit zou niet kunnen omdat onder de nieuwe subscriber agreement van red hat mag je de source code niet redistrubteren voor het maken van een alternatieve linux distribution. Lees mijn andere comment over dit is combo met de GPL. Maar als dit blijft staan zouden ze niet met 1 license alle packages steeds kunnen blijven halen omdat die license zou be cancelled worden.

[DDX]

Als het volgens de subscriber agreement niet mag kunnen ze alma en rocky (en oracle?) daarop aanpakken.
License cancellen lijkt me lastig aangezien je moeilijk kan achterhalen welke licentie in gebruik is voor het downloaden van de sources...

[dmantione]

Ik denk dat de sleutel zit dat de "subscriber agreement" een los contract is dat gebruikers van Red Hat afsluiten, maar geen softwarelicentie is. Als je het "subscriber agreement" overtreedt heb je dus weliswaar contractbreuk met Red Hat, het zegt niets over de software die je in handen hebt, daar mag je op basis van de GPL immers mee doen wat je wilt, dus Red Hat kan verspreiding niet verhinderen.

Het enige wat Alma, Rocky e.d. dus nodig hebben is een "stiekeme" toevoer van broncode via een tussenpersoon.

[Hydranet]

Of ze lezen de changelogs uit van de src rpms zonder de source rpms werkelijk te gebruiken en vergelijken deze met CentOS stream src packages en op basis daarvan maken ze packages die dan wel weer gelijk is aan RHEL.

[zx9r_mario]

SCO ging destijds achter bedrijven aan die Linux gebruikte en werd uiteindelijk hun ondergang.

[Keeper of the Keys]

SCO is niet echt vergelijkbaar, die gingen achter alle Linux gebruikers aan en claimden copyright op delen van Linux wat ze niet hadden.

Hier zegt RH dat ze iemands toegang tot hun repo zullen ontnemen als ze de source verder verspreiden, dat is een inperking op het recht op redistribution in de GPL licentie en op zich zouden ze waarschijnlijk geen poot hebben om op te staan in de rechtbank maar zoals Jeff Geerling uitlegt in de video die @jeffrey4413 linkte zal IBM waarschijnlijk uitgaan van het feit dat ze een grotere juridische afdeling hebben dan de gemiddelde gebruiker.

RH gaat verder niet achter andere distros aan en probeert alleen de binary compatible versies van RHEL uit de wereld te helpen, als meer ontwikkelaars reageren zoals Jeff dan hebben ze zich waarschijnlijk meer geschaad dan geholpen zeker nu er zat LTS distributies zijn, de tijd waarin alleen RHEL minstens 5 jaar ondersteuning bood op hun distro is al heel lang voorbij.

[Polderviking]

Ik heb nog veel Centos 7, zat al te kijken naar Almalinux die ik links en rechts al aan het inzetten was.
Die lijken ook wel een plan aan het formuleren te zijn om dit te handelen, maar ik ga denk ik maar gewoon afscheid nemen van heel RHEL.

Eerst CentOS de nek om draaien en nu dit.
Dit wordt niet beter.

[DeCo]

Ik draai inmiddels CentOS Stream, na ook CentOS 7 gehad te hebben.. dat bevalt me nog steeds heel goed. Migratie was een eitje. Correct me if i'm wrong: op basis van dit artikel zie ik geen reden om over te stappen naar wat anders.

[Keeper of the Keys]

Voor zover ik altijd heb begrepen is Stream een rolling release, eigenlijk compleet het tegenovergestelde van een RHEL/LTS distro.

[rbr320]

Dat heb je dan verkeerd begrepen. Het enige verschil tussen CentOS Stream en de oude CentOS als downstream van RHEL is dat CentOS Stream iets eerder updates krijgt. Deze updates zijn dan al uitvoerig intern getest door Red Hat, maar zij hebben natuurlijk maar een eindige verzameling aan hard- en software combinaties waarop ze kunnen testen. Het kan dus in theorie voorkomen dat een update die via CentOS Stream "in het wild" is losgelaten toch problemen blijkt te geven in bepaalde configuraties, waarna Red Hat het probleem zal analyseren en met een andere/betere oplossing zal komen. Hun betalende klanten zijn dan hopelijk nog niet geraakt door deze nieuw geïntroduceerde problemen.

Ik denk dat het laatste zeer zelden voor zal komen, wat CentOS Stream wat mij betreft prima geschikt maakt voor gebruik in productie zoals voorheen met CentOS gebeurde. Maar daar denken veel mensen blijkbaar anders over.

Overigens denk ik dat vele anderen dit net zo verkeerd hebben begrepen als jij en dat daar de enorme commotie door is ontstaan toen Red Hat de wijzigingen aan CentOS aankondigde ongeveer een half jaar geleden. Dat is overigens begrijpelijk, de communicatie vanuit Red Hat/IBM was erg slecht, vooral voor een wijziging die zomaar zonder waarschuwing werd doorgevoerd. Destijds heb ik Red Hat verdedigd want ik vond het niet reëel dat mensen verwachtten dat iets als RHEL altijd maar gratis voor ze beschikbaar bleef. De huidige ontwikkelingen sta ik echter niet achter en ik ben benieuwd hoe dit verder gaat en of Red Hat/IBM nog terug gaat komen van deze beslissing.

[Reactie gewijzigd door rbr320 op 23 juli 2024 09:32]

[pennywiser]

Bedankt voor deze uitleg. Hier zocht ik naar. Heb je ergens ook wat documentatie die jouw beschrijving bevestigt? Geerling zegt bv ook dat het geen alternatief is: https://youtu.be/kF5pyVUQBH8?t=287

Het kan dus niet voorkomen dat je in Centos stream hogere package versies krijgt dan de RHEL, waar diezelfde Centos dan upstream van is? Want dat is wat ik ervan begrijp.

Hoe gaat Centos stream dan van downstream Rhel 9 naar 10 toe? Merk je daar iets van, of zodra Rhel 10 er is gaat Centos dan meteen mee?

Edit: Volgens mij snap ik het nu eindelijk. Er is een Centos Stream 8 en 9. Stream 8 is EOL in 2024 en 9 krijgt de volledige RHEL 9 support fase.

Centos Stream is de development branch van RHEL, Dus Stream 8 is dat van RHEL 8 en 9 van RHEL 9. Je krijgt updates en fixes dus wat eerder ipv later.

Imo kan je Centos Steam gewoon blijven gebruiken en ook voor productie zou ik dat ook wel aandurven. Wel asap naar 9 migreren. Het is dus GEEN echte rolling release.

[Reactie gewijzigd door pennywiser op 23 juli 2024 09:32]

[Polderviking]

Stream bestaat upstream van RHEL dus in dat opzicht ben je al overgestapt naar wat anders.

[Reactie gewijzigd door Polderviking op 23 juli 2024 09:32]

[Keeper of the Keys]

Als je organisatie OK is met een andere distro omgeving dan zijn Debian/Ubuntu Server ook prima oplossingen.

De enige reden waarom ik nog RHEL/RHEL compaitble distros gebruik is als ik een programma wil gebruiken dat alleen daar wordt ondersteund, en gelukkig zijn dat er steeds minder.

[Polderviking]

Ja ik ben niet getrouwd met RHEL verder. Debian based LTS releases werken ook prima. Wel een hoop werk.

[Reactie gewijzigd door Polderviking op 23 juli 2024 09:32]

[Cergorach]

Maar dat willen ze toch juist, jij betaald al niet, dat doe je ook niet als je wat anders gaat gebruiken.

[Polderviking]

Ja klaarblijkelijk willen ze hun userbase decimeren.

[lenwar]

Afhankelijk van je gebruik en hoeveel je nodig hebt, kan je gewoon gratis 16 RHEL machines gebruiken, hè?

[DDX]

Als ik dan blog artikel van almalinux lees :
https://almalinux.org/blog/impact-of-rhel-changes/

Does this mean I won’t be getting security updates for my AlmaLinux OS Server?
No. In the immediate term, our plan is to pull from CentOS Stream updates and Oracle Linux updates to ensure security patches continue to be released. These updates will be carefully curated to ensure they are 1:1 compatible with RHEL, while not violating Red Hat’s licensing, and will be vetted and tested just like all of our other releases.

Maar Oracle Linux gaat toch ook niet aan die sourcecode komen ?

[EXX]

Dat vraag ik me dus ook af. En wat Oracle in dat geval gaat doen.