Rocky Linux zegt vanwege paywall RHEL-broncode via andere methodes te verkrijgen

RHEL-vervanger Rocky Linux heeft meer informatie gedeeld over zijn strategie nu Red Hat zijn Enterprise Linux-distro beperkt beschikbaar heeft gemaakt. De ontwikkelaar zegt methodes te hebben gevonden om de RHEL-paywall te omzeilen en toch de broncode te bemachtigen.

Het team van Rocky Linux zegt nu meerdere methodes te gaan gebruiken om de broncode van RHEL bij elkaar te krijgen. Als voorbeeld noemt RL dat het ubi-containerimages kan gebruiken die gebaseerd zijn op RHEL en via meerdere bronnen verkrijgbaar zijn. Volgens Rocky Linux kunnen de broncodes van Red Hat hiermee 'betrouwbaar' en 'ongehinderd' verkregen worden.

Een andere methode die de distro zegt te gebruiken, zijn 'openbare cloudinstanties' met een pay-per-usemodel. Daarmee moet het mogelijk zijn om RHEL-images in de cloud te draaien en op die manier aan de broncodes te komen. In tegenstelling tot de eerstgenoemde optie kan dit proces tevens geautomatiseerd worden.

Red Hat zei vorige week dat het RHEL niet meer algemeen beschikbaar maakt, maar alleen verkoopt aan Red Hat Enterprise-klanten. De reden daarvoor is dat andere ontwikkelaars RHEL vaak gebruiken als basis voor eigen distro's die zij vervolgens met winst doorverkopen. Het Rocky Linux-team is van mening dat deze maatregel 'in strijd is met de geest en het doel van open source'. Daarom zegt het bedrijf dat het de RHEL-binaries en source rpm's via deze twee methodes op een 'legitieme manier' kan verkrijgen 'zonder onze toewijding aan opensourcesoftware in gevaar te brengen of in te stemmen met beperkingen die onze rechten belemmeren'.

Het project voor Rocky Linux werd in 2021 opgezet uit onvrede over de koers van Red Hat. Dat stopte eind 2020 met rebuilds van Red Hat Enterprise Linux en ging zich alleen nog op CentOS Stream richten. Naast RL zijn er nog andere distro's, zoals AlmaLinux, die gebruikmaken van RHEL.

Reacties (138)

[Amanoo]

Was niet het punt van open source licenties zoals op Linux dat je juist de broncode bij dit soort dingen openbaar moet maken? Je mag geld vragen voor services met je product, maar ik dacht dat er wel regels waren over het distribueren van jouw afgeleide broncode.

[Stetsed]

Dus dit is de vraag die we niet zo goed op kunnen antwoorden, het argument van de FOSS community is dat volgens de GPL je geen restricties mag zetten op redistributie, maar red har argumenteert dat je de versie die je krijgt well mag redistribute maar je krijgt dan alleen niet de nieuwe versie. Zeer legaal grijs

[UPPERKEES]

Dit zegt Red Hat niet. De code blijft beschikbaar voor de gebruikers. Red Hat doet effectief niets dat GPL niet toestaat. Het argument van Red Hat is dat distributies zoals Rocky/Alma alleen de source pakken en that's it. Ze helpen niet mee met het fixen van bugs. Ze zijn letterlijk een bug-for-bug copy van RHEL, het is geen fork. Zo werkt open-source niet, het is geven en nemen. Als Rocky/Alma nou support zou toevoegen voor een extra architecture of dat ze zouden helpen met het fixen van bugs, dan sure. Maar dat is niet het geval. Men wilt RHEL, maar niet betalen voor het werk dat Red Hat levert. En als je kijkt hoeveel Red Hat teruggeeft aan de community, is het geen goede trend dat op die manier geld wordt weggesnoept. Red Hat is de #2 kernel contributer, de grootste voor GNOME, grote speler in systemd, pipewire, SELinux, etc. Het schaad juist open-source als men niet contribute, of dat nou code, documentatie, monetaire contributie of vertaling is. Dat maakt niet uit. Maar wat Rocky/Alma doen is geen van allen.

Wil je Red Hat? Dan kan je CentOS Stream gebruiken of forken. Daar kan men gewoon contributen en bugs fixen samen met Red Hat. Zo werkt open-source en zo behoud je ook dat de zakenwereld betrokken blijft. Anders wordt het straks weer een hobby. Daar heeft niemand wat aan als open-source een waardig alternatief moet blijven.

[BvdW1978]

Red Hat kan niet besluiten om gebruiksbeperkingen op te leggen aan code die zij zelf voorzien van de GPL danwel doorleveren met GPL. Red Hat is niet blij met hoe Rocky/Alma hun software gebruiken. Dat zal allemaal best, maar het is niet verboden om GPL-software te gebruiken en dat is precies wat Alma en Rocky doen. Het is evenmin verboden om GPL-code door te leveren aan derden. Dat weet Red Hat als geen ander. Er bestaat geen enkele verplichting om iets bij te dragen aan de code die via de GPL wordt verspreid.

De "zakenwereld" blijft prima betrokken want Red Hat verdient zijn geld aan de services en support om de code heen. De code is niet het product hier. Wie zijn ERP-stack wil voorzien van een FIPS-gecertificeerde onderlaag, komt al snel bij partijen als Red Hat uit en niet bij Alma of Rocky. Dat blijft gewoon zo, en daar komt ook helemaal niemand aan.

Hier zit gewoon een of ander blauw pak van IBM aan de knoppen dat probeert om een paar procent extra winst uit een dochteronderneming te knijpen zonder dat ecosysteem te begrijpen.

[Cergorach]

Red Hat kan niet besluiten om gebruiksbeperkingen op te leggen aan code die zij zelf voorzien van de GPL danwel doorleveren met GPL. Red Hat is niet blij met hoe Rocky/Alma hun software gebruiken. Dat zal allemaal best, maar het is niet verboden om GPL-software te gebruiken en dat is precies wat Alma en Rocky doen. Het is evenmin verboden om GPL-code door te leveren aan derden. Dat weet Red Hat als geen ander. Er bestaat geen enkele verplichting om iets bij te dragen aan de code die via de GPL wordt verspreid.

Echter kan Red Hat/IBM ook besluiten dat als je GPL code van hun distribueert (voor wat voor reden dan ook), dat ze je niet langer als klant willen hebben. GPL stelt dat je de source code beschikbaar moet stellen aan de gebruikers van die software. Wat RH doet, er staat nergens dat je recht heb om user te worden. User worden kan prima achter een paywall staan, de GPL FAQ gaat daar dan ook specifiek op in. En als bedrijf heeft RH het recht om jou geen klant te maken of je klant zijn te ontzeggen. Dit gaat natuurlijk wel tegen de intentie in van de GPL, maar zeer zeker niet tegen de regels van de GPL...

Wat ik verwacht is dat RH met dergelijke acties minder klanten zal krijgen en dus averechts gaat werken tov. wat ze eigenlijk willen. Sure, ik zie na de CentOS shenanigans meer grote bedrijven overstappen op RH. Maar veel kleintjes juist absoluut niet, waar denk je dat al dat personeel uiteindelijk vandaan komt? MS heeft dat ook gezien met hun Windows product, die wilde in de eerste instantie al die piracy en grijze keys ook de kop in drukken, maar daar zijn ze eigenlijk van teruggekomen omdat al die windows gebruikers dat ook doen op hun werk, welke wel (over het algemeen) de volle mep betalen voor al de MS producten...

Ik moest 'laatst' wat testen op CentOS versie X, wat niet meer te krijgen was en de RH versie op de kop tikken zonder daar direct de hoofdprijs voor te betalen was een heleboel hoepels door springen. Nadat die was verlopen zou je weer door al die hoepels moeten springen. Dit koste veel te veel tijd, wat mij als sporadische 'gebruiker' geen fan maakte van RH. Terwijl ik juist van mening ben dat een gratis versie zonder Enterprise support niet thuis hoort in een Enterprise omgeving en zou juist die Enterprise support sterk adviseren (RH). Maar met deze shenanigans zou ik kijken of een andere partij die ook Enterprise support levert op Linux distributies wellicht niet een betere keuze zou zijn. Niet omdat ik op m'n pikkie ben getrapt door deze RH/IBM actie, maar juist omdat de continuïteit van Linux servers in gevaar komt bij leverancier issues. Zoals we al hebben gezien bij de CentOS shenanigans...

Open source 'gratis' is leuk als individu, maar zodra je professioneel/zakelijk met iets aan de slag gaat en het is complex en het is essentieel voor je organisatie, dan kan je beter support er op hebben zitten zodat issues gefixt kunnen worden en experts naar kunnen kijken. Veel organisaties hebben gewoon niet structureel personeel in huis wiens primaire taak dat is. Dus dat huur je dan in bij een Red Hat, Ubuntu, SUSE, OpenLogic, etc.

Bron:
https://www.gnu.org/licenses/gpl-3.0.en.html
https://www.gnu.org/licen...RequireSourcePostedPublic

[Blokker_1999]

RH kan niet zomaar de GPL ammenderen. Als zij software onder GPL uitbrengen, hebben zij die licentie ook gewoon te respecteren. Software onder andere licenties, of software die door RH ontwikkeld is, en waar geen community bijdragen aan geleverd zijn, daar kan RH over beslissen wat er met de licentie moet gebeuren, maar alles wat onder GPL achtige licenties valt staat de gebruiker van de software vrij om opnieuw te distribueren.

De GPL stelt gewoon dat je de software onder deze licentie, en de broncode, gewoon opnieuw mag verspreiden. Dat staat letterlijk in die licentie. Daar kan RH niet zomaar beperkingen aan stellen. Andere licenties? Mogelijks wel, maar GPL? Absoluut niet.

[Cergorach]

RH kan niet zomaar de GPL ammenderen.

Wijs me aan waar ze dat doen.

Wat RH doet is dat ze software verkopen, wat mag. En alleen aan hun klanten de source code leveren, wat mag. Ze kiezen er onder bepaalde omstandigheden voor om je niet langer als klant te hebben, wat los staat van de GPL, wat los van de GPL ook gewoon mag.

Je zou toch weten in de IT dat als A werkt en B werkt, dat dit niet betekend dat per definitie A+B werkt!

RH zegt dan ook niet dat het herdistribueren van 'hun' code onder GPL niet mag, maar dat als je dat wel doet je niet langer klant bent. Als je geen klant bent van RH is deze niet langer verplicht om source code te leveren aan de niet klant. Dat dit het effect heeft dat mensen geen RH code distribueren is een heel ander verhaal.

De vraag gaat wezen of een rechter dit ook zo gaat zien, ik ben geen jurist (jij trouwens ook niet), dus die zou dat wel eens anders kunnen interpreteren, je weet het niet.

Jij ziet de GPL niet los van RH klant zijn, wat dat wel is (imho).

[Xander2]

Jij ziet de GPL niet los van RH klant zijn, wat dat wel is (imho).

Het is een leuk truukje, maar dan zal RH toch echt alle gratis toegang moeten blokkeren, want die zijn geen klant. En dan ben je expliciet toevoegingen aan GPL aan het hanteren, wat niet mag.

En dan nog, diegenen buiten RH waarvan RH GPL contributies accepteert mag je geen toegang weigeren tot RH contributies tot diezelfde programmatuur.

Dit is een proefballonnetje wat RH wel eens heel duur kan komen te staan.

[Cergorach]

Het is een leuk truukje, maar dan zal RH toch echt alle gratis toegang moeten blokkeren, want die zijn geen klant. En dan ben je expliciet toevoegingen aan GPL aan het hanteren, wat niet mag.

Die gratis Dev accounts zijn imho vrij vreselijk in gebruik, maar je wordt wel doodleuk een gebruiker die eerst toestemt met voorwaarden (die voor de dev accounts nog niet zijn aangepast). Die devs accounts zijn wel degelijk 'klant', maar een gratis klant. En ook die toegang kunnen ze je weer ontzeggen. Je kan voor zover ik weet niet zonder account RH downloaden van een legale bron.

Ik ben met je eens dat het een proefballonnetje is, maar ik denk dat je ook onderschat hoe groot de kans is dat RH/IBM wel eens gelijk kan krijgen in een rechtszaak en dan is de open source gemeenschap veel verder van huis. Ik verwacht namelijk dat de kans dat RH/IBM gelijk krijgt wel eens 60%+ kan zijn.

En ben ook van mening dat ook al krijgt RH/IBM gelijk, ze alsnog wel eens behoorlijk wat schade zouden kunnen ondervinden. Het ligt er een beetje aan hoe RH beheerders en beslissers bij grote organisaties die primair RH gebruiken dit interpreteren. Ze kunnen dit zien als een bedreiging voor business-continuity (en dan alsnog beslissen dat ze het risico nemen) of als gewoon een feit van het huidige Linux landschap...

Gasten/organisaties die voorheen CentOS gebruikte en nu Rocky Linux, AlmaLinux en Navy Linux hebben geen invloed daarop, want voorheen betaalde ze ook niet voor RH. Linux developers etc. zijn een heel ander verhaal en dit zijn ook de partijen die mogelijk een claim hebben richting RH...

[BvdW1978]

Als beslisser in zo'n omgeving zie ik dit gedrag als een majeur risico inderdaad.

[Xander2]

Ik ben met je eens dat het een proefballonnetje is, maar ik denk dat je ook onderschat hoe groot de kans is dat RH/IBM wel eens gelijk kan krijgen in een rechtszaak en dan is de open source gemeenschap veel verder van huis. Ik verwacht namelijk dat de kans dat RH/IBM gelijk krijgt wel eens 60%+ kan zijn.

Ik heb geen idee wat betreft de kansen mbt een rechtszaak.

Wat IBM niet begrijpt is dat de situatie volstrekt andersom is, de beperkte distributie werd oogluikend toegestaan omdat via een omweg de code beschikbaar was.

Haal je dat weg, zal RH alle contributies en afhankelijkheden moeten napluizen en simpelweg gezeik krijgen met zo'n beetje elke developer.

Gebruikers zullen in dat geval, als ze verstandig zijn, hard weg lopen.

[jimshatt]

Zoals ik het zie krijg je twee contracten onder je neus geduwd waarbij je volgens het eerste contract bepaalde dingen mag waar je volgens het tweede contract dat niet mag (reden tot ontbinding tweede contract).

Op die manier kun je dus altijd de GPL volledig omzeilen door te distribueren met een GPL licentie plus een anti-GPL overeenkomst ("Ik ga ermee akkoord dat alles wat in de GPL staat ongeldig is").

Het lijkt erop dat clausule 7 van de GPLv2 dit toestaat:

7. If, as a consequence of a court judgment or allegation of patent infringement or for any other reason (not limited to patent issues), conditions are imposed on you (whether by court order, agreement or otherwise) that contradict the conditions of this License, they do not excuse you from the conditions of this License. If you cannot distribute so as to satisfy simultaneously your obligations under this License and any other pertinent obligations, then as a consequence you may not distribute the Program at all.

[Xander2]

Dat kan dus niet, op het moment dat je GPL code aanpast of deelt verandert de licentie niet, die blijft GPL.

Alleen als je volledig eigenaar bent van de code kun je de licentie veranderen.

[jimshatt]

De code krijg je inderdaad nog steeds onder de GPL. Maar daarnaast moet je een losstaande overeenkomst sluiten, om überhaupt in het bezit van het product en bijbehorende broncode te komen, waarin je belooft dat je niet verder zult distribueren.

Als in de GPL zou staan dat je naast de GPL geen enkele andere voorwaarden mag stellen dan zou dit niet mogen, maar clausule 7 staat dat expliciet toe. Waarschijnlijk om te voorkomen dat mensen in overtreding gaan en dan naar de GPL wijzen die zei dat het toch mocht.

Ik denk overigens ook dat je gelijk zou hebben als je puur en alleen extra voorwaarden voor ontvangst krijgt. Dat voelt gelijk aan het veranderen van de licentie wat niet mag als je geen eigenaar bent. Maar omdat die voorwaarden voor een of ander bullshit lidmaatschap is mag het waarschijnlijk wel. Het blijft een dick move die hopelijk niet onbestraft blijft.

[Xander2]

Als in de GPL zou staan dat je naast de GPL geen enkele andere voorwaarden mag stellen dan zou dit niet mogen, maar clausule 7 staat dat expliciet toe. Waarschijnlijk om te voorkomen dat mensen in overtreding gaan en dan naar de GPL wijzen die zei dat het toch mocht.

Ik denk dat we het anders lezen, vanuit het oogpunt van RH mogen ze niet distribueren volgens clausule 7 wanneer ze conflicterende additionele licentie eisen stellen, dat staat er klip en klaar. Dat is exact waarom GPL als viraal bestempeld wordt.

Een GPL met additionele voorwaarden is dus niet geldig en mag als zodanig niet worden gedistribueerd, dat ligt niet bij de gebruiker.

[jimshatt]

We lezen het inderdaad anders. Ik lees namelijk dat de *klanten* van RH niet mogen distribueren volgens clausule 7 omdat RH conflicterende additionele eisen stelt. IANAL dus ik weet het ook niet zeker.

[BvdW1978]

Laten we de rechtszaken maar eens afwachten. IBM/RH is niet de eigenaar/rechthebbende van alle code in RHEL, dus ik ben heel benieuwd hoe dit uitpakt.

Maar open source 'gratis' is ook in zakelijk/professioneel verband zeker wel interessant. Lang niet alles is altijd even essentieel voor een organisatie namelijk, en daar passen de Rocky's en de Alma's prima in aan de onderkant van een spectrum waar RH zich blijkbaar te goed voor voelt.

[divvid]

Maar open source 'gratis' is ook in zakelijk/professioneel verband zeker wel interessant. Lang niet alles is altijd even essentieel voor een organisatie namelijk

Daar kwam Oracle ook achter na een exorbitante prijsverhoging. De stofkam door alle databases bleek dat 80% door PostgreSQL vervangen kon worden: gevolg voor Oracle, minder contracten en slechts marginaal meer werk voor de DBs

[kodak]

Regels gaan ook om de achterliggende bedoeling van bestaan. Je lijkt het genoemde argument waarom GPL het delen belangrijk maakt te negeren om te klagen over blauwe pakken. Het teruggeven en samenwerken is juist een heel belangrijk onderdeel van een community vormen, om evenwicht proberen te houden in inzet en gebruik. Je kan dus net zo goed stellen dat deze Rocky/Alma de blauwe pakken zijn waar je over klaagt, of je eigen mening daaronder valt: wel zelf de extra winst van nemen door meer te nemen en minder tot niets terug te geven, maar de echt bijdragende gemeenschap dan gaan verwijten alsof die uit zijn op meer winst.

[JackBol]

Ik zie dit argument een paar keer voorbij komen.

GPL heeft geen enkele verplichting dat je moet contributen. De licentie is zelfs extreem duidelijk dat de source gedistribueerd wordt as-is.

En dat is ook niet de geest van de licentie anders had het er wel ingestaan.

[kodak]

dat is ook niet de geest van de licentie anders had het er wel ingestaan.

GPL is als licentie een compromis voor de bedoelingen. Dat kan niet anders, omdat er in de praktijk genoeg situaties zijn dat expliciet eisen stellen niet kunnen. Er valt namelijk moeilijk te oordelen wat genoeg bijdragen/opbrengen is naast het publiek maken. Eisen om aan de distributor bij te dragen zijn weggewoven omdat de distributors mogelijk niet meer kan bestaan, niet omdat het onwenselijk is dat er samenwerking of evenwicht in geven en nemen is.

De vrijheid om bij te dragen gaat niet alleen om de vrijheid, of alleen het bijdragen, of alleen die woorden in een geldelijke of eigen motiverende 'winstgevende' manier voor alleen de afnemers, of alleen de distributors. Het doel is dat geven en nemen er is zodat iedereen dat samen doet.

Naar mijn mening lijken geen van deze partijen GPL toe te passen om, als gemeenschap, samen te werken. Ze lijken meer uit op resultaten om samenwerking te beperken. Omdat ze ook andere behoeftes hebben en ze de vrijheid bedoeld om samen te werken gebruiken als vrijheid om dat zo min mogelijk te doen.

[Reactie gewijzigd door kodak op 22 juli 2024 16:49]

[JackBol]

Duik eens in de historie van GPL en je zult zien dat de intentie is om het mogelijk maken je eigen systeem te verbeteren. Daarvoor heb je toegang tot de source nodig.

Ik zou het top vinden als een quote van Richard Stallman weet te linken die specifiek ingaat op de quid-pro-quo mbt contributie.

[kodak]

Ik ga al een tijd mee, GPL is veel breder dan dat.

[JackBol]

GPL is veel breder dan dat.

Nogal vaag statement.
De GPL 3.0 staat letterlijk online.

Eerste alinea:

General Public License is intended to guarantee your freedom to share and change all versions of a program--to make sure it remains free software for all its users

Wat Red Hat doet staat er letterlijk in dat het mag:

You may charge any price or no price for each copy that you convey

Het enige wat ze verplicht zijn het het leveren van de source aan iedereen die de code van hun koopt.

For example, if you distribute copies of such a program, whether gratis or for a fee, you must pass on to the recipients the same freedoms that you received. You must make sure that they, too, receive or can get the source code. And you must show them these terms so they know their rights.

Nu graag 1 quote uit de GPL van jouw dat de GPL "breder is dan dat". En waarin staat dat contributie aan de community een expliciete of impliciete voorwaarde is.

[kodak]

@JackBol je stelt zelf dat al meerdere keren argumenten gegeven zijn waarom het breder is dan slechts de GPL tekst. In plaats van op genoemde argumenten in te gaan trek je het in twijfel door die argumenten te negeren, je te beperken tot de GPL tekst, je eigen interpretatie gericht op alleen het delen te kiezen en dan zelfs zonder onderbouwing een ander te beschuldigen de geschiedenis niet kent. Dat laatste vind ik nogal ongepast. Dan weet je kennelijk dat er geschiedenis is, maar negeer je die door je te beperken tot selectieve text uit de licenties.

Op geen enkele wijze is een verplichting om te delen te negeren, maar dat is de discussie niet. Iemand beschuldigt een ander iets te doen wat we niet afgesproken hebben: niet delen. Maar doet dat beschuldigen op selectieve eigen onderbouwing: door het niet eens te zijn met winst/bedrijfsbelang. Ook suggestief beschuldigen van te veel leunen op vrijwillige bijdrage is langs gekomen. Als iemand zich de vrijheid gunt om anderen te beschuldigen van gebruik van die vrijheid, maar zichzelf geen beperkingen op legt alsof de eigen vrijheid belangrijker is, dan lijkt mij de term vrijheid niet gezien te worden om te willen samenwerken, maar om te beschuldigen. Zo lees ik vrijheid zoals in de GPL staat niet, zo lees ik de faq van GPL niet, zo lees ik de geschiedenis van GPL en opensource niet. Dit soort moddergooien is ongepast en het zij begonnen, ongeacht van rhel, de distributies die zich afzetten of tweakers, ook. Ik zie liever dat men zo volwassen is niet met moddergooien te gooien, niet de eigen stokpaardjes belangrijk probeert te maken, maar samen werkt. Want het klinkt mij niet als gezond model van software ontwikkeling, verspreiding en gebruik als het vooral om de eigen stokpaardjes gaat, om gebruik te maken van recht op vrijheid dat bedoeld is om samen te werken.

[Reactie gewijzigd door kodak op 22 juli 2024 16:49]

[kaas-schaaf]

Je kan prima complient zijn met de audits en regelgeving (intern of extern, bijvoorbeeld voor bepaalde FIPS specificaties) waarvoor RHEL gebruikt word zonder RHEL te gebruiken. Dit vergt echter investering in de eigen kennis en tooling terwijl er ook geld naar IBM geschoven kan worden. Het eerste zou voor een bedrijf dat die dit soort keuringen wil hebben wellicht een betere keuze zijn maar dat gaat er bij bepaalde groepen helaas niet in.

[eth0]

Maar Rocky en Alma gebruikte daarvoor niet de RHEL sources maar de debranded source. waar Redhat al het extra werk voor hun deed. dat doen ze niet meer.

en Red Hat blijft de source van hun packages leveren, alleen die zijn wel Red Hat branded, maar wel volgens GPL.

[kodak]

Regels gaan ook om de achterliggende bedoeling van bestaan. Je lijkt het genoemde argument waarom GPL het delen belangrijk maakt te negeren om te klagen over blauwe pakken.

Het teruggeven en samenwerken is juist een heel belangrijk onderdeel van een community vormen, om evenwicht proberen te houden in inzet en gebruik. Je kan dus net zo goed stellen dat deze Rocky/Alma de blauwe pakken zijn waar je over klaagt, of je eigen mening daar zelfs onder valt: wel zelf de extra winst van nemen door meer te nemen te verdedigen, en minder tot niets interesseren in terug te geven. Om vervolgens de echt bijdragende gemeenschap dan te verwijten alsof die uit zijn op meer winst die ze al misliepen door het nemen nemen nemen.

[BvdW1978]

Laten we vooral even de volgorde recht houden dan. Red Hat is hier de partij die samenwerking en open delen plotseling is gaan belemmeren. Eerst met de overname en effectieve castratie van CentOS als RHEL-workalike, en nu opnieuw. De GPL veroorzaakt en beoogt dat de code zelf niet het product wordt. Dat lukt heel goed tot dusver. Rocky en Alma zoeken de weg terug die Red Hat eerder al probeerde af te snijden, en waar het nu (en opnieuw midden in een release-cyclus!) een stap verder in gaat. Rocky heeft zich alweer herpakt, en dat kan ook dankzij de GPL. Mijn voorspelling: Red Hat valt hier in het eigen zwaard maar gaat het "lek" waar ze tegen strijden desondanks helemaal nooit gedicht krijgen.

IBM acteert hier op de manier die we van IBM gewend zijn. Dat is ook niet verrassend want cultureel zo bepaald binnen een gigantisch bedrijf dat al al meer dan een eeuw bestaat: zie ook de manier waarop ze AIX in de markt positioneren. Dat is hun goed recht natuurlijk, maar het zegt veel over de cultuur waarbinnen de knopentellers in de traditionele blauwe pakken dus de GPL en FOSS in het algemeen niet begrijpen.

Red Hat is verder ook niet hetzelfde als Microsoft Windows, Oracle Solaris of IBM AIX. Red Hat wikt en beschikt hier niet over de code onder een product dat het zelf gemaakt heeft. RHEL is in overgrote meerderheid een bij elkaar geleende verzameling die zijn waarde ontleent aan het werk van anderen. Geweeklaag over "rebuilders" is niet alleen potsierlijk, men bevuilt hiermee het eigen nest.

Red Hat levert hier nu bovendien voor de tweede keer een streek tegen de community waaruit ze zelf zijn ontstaan en gegroeid, en waaraan tot op de dag van vandaag hun hele bestaansrecht op drijft. Dat is destructief, te kwader trouw en de timing en manier waarop is een enterprise-bedrijf onwaardig. Op de plekken waar ik invloed heb op leverancierskeuze, en dat zijn er best een paar, zal ik niet langer Red Hat zonder meer goedkeuren als optie voor de shortlist. Simpelweg omdat men zich een onbetrouwbare partji heeft getoond.

Ik schreef het ook al elders. Deze reflex van Red Hat (IBM) past niet bij de GPL. Willen ze op deze manier verder, dan zouden ze er verstandig aan doen om Linux als fundament te laten vallen en om te schakelen naar bijvoorbeeld FreeBSD. Die licentie en community staan dit gedrag namelijk wel probleemloos toe, maar blijkbaar geeft de GPL toch ook een heleboel voordelen.

[kodak]

Het past ook niet bij GPL om alleen maar naar rhel te wijzen alsof die nergens op reageren wat mede een gevolg is van wat een deel van de community al een tijd deed: nemen, niet geven. Rhel is daarbij onderdeel van de community, dus ook op die manier is het onredelijk om alleen naar hun te wijzen als we zien dat een groep als Rocky wel neemt maar zich dan tegen samenwerken verzet door die af te schilderen als boosdoener zonder aan zelfreflectie te doen. En dat zien we ook in deze discussie weer: vooral opzettelijk lelijke termen naar redhad slingeren, inspelen op geldelijke winst is slecht wij zijn goed, wij waarderen de community wel want we zetten ons af tegen een deel van de community enz. Dan lijkt het meer te gaan om een eigen community, niet een grote samenwerking.

[BvdW1978]

De hele geven/nemen-discussie is op zichzelf niet relevant en wat je over Rocky beweert is bovendien feitelijk onwaar maar daar gaat het niet om. De overgrote groep die profiteert van de GPL neemt alleen. Daar is het hele verhaal in de jaren '80 om begonnen: dat zijn gebruikers. Die zijn even zo gerechtigd om GPL-software door te geven aan hun buurman en dat gebeurt ook. Dat die zich groeperen en die doorgifte structureren is hun goed recht, en ziedaar: CentOS, Rocky, Alma en nog veel meer distributies.

De enige partij die deze verhouding nu, na decennia van geldelijke winst, scheef trekt is Red Hat (IBM). Niemand anders. En er is werkelijk niets mis met geldelijke winst en die komt ook helemaal nergens in gevaar of staat zelfs ter discussie, maar dit gedrag van Red Hat is simpelweg hypocriet en te kwader trouw ten aanzien van de community waar ze zelf van bestaan.

[kodak]

Je lijkt opzettelijk alle argumenten die je niet uitkomen te negeren zonder onderbouwing, om door te kunnen gaan met eenzijdig klagen. Daarbij ben je ook selectief in wegwimpelen, want eerst stellen dat geven/nemen niet belangrijk is om vervolgens te klagen over niet geven en klagen over geldelijk nemen is nogal scheef.

[BvdW1978]

Ik "klaag" over "niet geven" omdat het niet opwerpen van belemmeringen daarbij de verplichting is waar Red Hat groot mee is geworden en die ze vanaf dag 1 kennen. Ze werpen nu willens en wetens wel zo'n beperking op en proberen dat recht te praten met een hele sliert aan juridisch "ja maar hunnie". Dat is hypocriet en daar wijs ik op. Of ze juridisch nu wel of niet in hun recht staan: Red Hat is wat mij betreft helemaal af nu.

[kodak]

Nogmaals, de vrijheid om als community samen te werken is meer dan verplichtingen. Ja maar wij hebben al decennia lang gegeven (en dan weer weglaten wat rhel gegeven heeft) is niet waar een community om gaat, want dat draagt net zo min bij aan de huidige situatie nu samen te werken. Het af zijn lijkt zo vooral op zij bij rhel en winst zijn fout en wij die klagen, ontevreden zijn en nu hoe dan ook willen nemen en afzetten zijn goed. En wat is het af zijn dan? Hoe dan ook die code willen nemen om hoe dan ook ook van het rhel werk te genieten lijkt namelijk te bewijzen wat ik al stelde: het nemen komt vooral goed uit om er zelf voordeel bij te hebben en selectief de eigen houding te belonen.

[BvdW1978]

Als Red Hat meer zou doen dan alleen verplichtingen navolgen, hadden ze CentOS niet de nek om gedraaid en nu ook deze streek niet geleverd. Red Hat is volgens de GPL verplicht de broncode te leveren van alles wat het onder die licentie verspreidt en daarbij mag het conform die licentie geen gebruiksbeperkingen opwerpen. Dat doet het nu wel. Misschien niet volgens de letter van de wet, dat gaan rechtszaken nog wel uitwijzen, maar zeker wel volgens de geest van de GPL en "de community".

Geldelijke winst is zeker niet vies. Red Hat maakt al jaren uitstekend winst en dat is prima. Het gedraagt zich sinds de IBM-overname echter meer en meer als een hypocriete speler die bruggen verbrandt omwille van winst op de korte termijn. Dat is prima voor een bedrijf, maar IBM toont glashelder aan niet te begrijpen waar Red Hat het eigen bestaansrecht vandaan haalt. Dat is kortzichtig, maar ook dat is zeker voor IBM geen nieuw gedrag. Spijtig wel, dat er voor decennia aan opgebouwde goodwill wordt weggegooid voor een paar procent winst op de korte termijn... en ja, dat is blauwe-pakken-gedrag waar ik wat van vind inderdaad. IBM sloopt alles wat het niet begrijpt, en FOSS begrijpt het absoluut niet.

Wat je zegt over "nemen" is verder ieders goed recht. Je doet net alsof dat iets is waar iemand zich voor zou moeten schamen. Dat is niet zo en ik weiger dat ook te doen, evenmin als Rocky, Alma, Oracle of Amazon dat zouden moeten doen (ook die laatste twee zijn "rebuilders" met hun eigen EL-distro's). De GPL moedigt expliciet juist het "nemen" aan door de andere kant te verplichten tot geven zonder gebruiksbeperkingen. Niemand wordt gedwongen zijn producten onder de GPL uit te brengen. Dat doet Red Hat in voorkomende gevallen helemaal zelf en dat is soms sympathiek, maar daar nu op terugkomen wanneer mensen er dingen mee doen die je niet fijn vindt, is hypocriet.

Lees anders ook even het blog en de Twitter-feed van Jeff Geerling hierover. Die verwoordt het misschien wat samenhangender dan ik hier in deze comments.

[Stetsed]

Ik moet je effe serieus vragen of je nu een grap uit zit te trekken of dat je serieus bent. Als je serieus bent moet je eens even kijken naar wie de developers van rocky Linux zijn, het zijn all vaak notable leden van de linux development community. Die all veel terug leveren. En hoe is de adoptie van linux vergroten niet een toelevering. Het hele punt van red hat was dat ze niet de software verkopen, ze verkopen de support die er bij komt dat was naar mijn visie wat ze vroeger deden. Nou dat is dus verandert dat kan je zeker zien.

P.S: CentOS stream als alternatief geven is bullshit want dat is rolling release dus net zoals Arch of SUSE tumbleweed dat draai je gewoon niet op servers.

[Hydranet]

CentOS Stream is geen rolling release want die werken gewoon met major versies, van je hebt nu Centos Stream 8 and CentOS Stream 9.

[appollonius333]

Ik moet hier toch even op inhaken. CentOS Stream is wel degelijk een rolling release (Bron: https://wiki.centos.org/M...erprise%20Linux%20(RHEL).) Dat er meerdere CentOS Stream versies zijn heeft hier niks mee te maken. Aangezien Voor CentOS 8 ook nog steeds support geleverd wordt.

CentOS Stream heeft namelijk ook niet dezelfde stabiliteit als een RHEL. Daarom zie je dat bedrijven/ enterprises/ overheden ook weinig doen met CentOS Stream. Omdat het simpelweg niet stabiel is. Wat RHEL, Rocky Linux en Alma Linux wel zijn.

EDIT: Waarom wordt mijn reactie en die van de persoon hieronder als 'irrelevant' beschouwd. Is toch juist on-topic?

[Reactie gewijzigd door appollonius333 op 22 juli 2024 16:49]

[Hydranet]

Leuk dat daar staat dat CentOS Stream rolling release is maar rolling release zijn distributies zoals Arch, Gentoo,Tumbleweed, Manjaro, etc. Fedora is ook geen rolling release, want rolling release distributies doen niet aan major/minor versie nummers daarom heet het rolling. Maar dat CentOS Stream niet gelijk is aan RHEL ben ik met je eens daarom wil ik het ook niet op mijn vpsen draaien.

[Reactie gewijzigd door Hydranet op 22 juli 2024 16:49]

[BvdW1978]

CentOS Stream is wel degelijk rolling. Ze releasen het nota bene zelf zo:

Uit hun eigen release announcement:

CentOS Stream is a rolling-release Linux distro that exists as a
midstream between the upstream development in Fedora Linux and the
downstream development for Red Hat Enterprise Linux (RHEL). It is a
cleared-path to contributing into future minor releases of RHEL while
interacting with Red Hat and other open source developers. This pairs
nicely with the existing contribution path in Fedora for future major
releases of RHEL.

Er zijn nu dus twee streams. Eentje die in het EL8-spoor blijft, en eentje op 9. Daarbinnen zijn ze gewoon rolling.

[Hydranet]

Echte rolling houden geen versies bij zoals Arch, Gentoo en Tumbleweed, er is dus geen Arch Linux 8 of 9 of Gentoo maar alleen Arch of Gentoo. Maar maakt verder niet uit, alleen al omdat CentOS Stream up Stream van RHEL is wil ik het niet op mijn vpsen gebruiken.

[Reactie gewijzigd door Hydranet op 22 juli 2024 16:49]

[UPPERKEES]

CentOS Stream is absoluut niet hetzelfde als Arch of Tumbleweed. Het is rolling release binnen de major release van RHEL. Er is dus niet zoiets als CentOS Stream 8.5, je hebt gewoon major versie 8. Je kan het zeg maar zien zoals Debian waar je optioneel de security repository aan kan zetten. Zet je die security repository aan dan heb je minder updates wanneer er een point release uitkomt, want die updates kreeg je al tussendoor. Zowel met of zonder die security repo draai je gewoon binnen de major release. Met security repository enabled heb je een semi rolling release binnen de major release. Semi, want bij een point release krijg je meer dan alleen security updates.

Met CentOS krijg je exact hetzelfde wat RHEL krijgt, alleen eerder. De hoeveelheid testing dat Red Hat doet is voorbeeldig. Zelf draai ik al bijna 10 jaar Fedora, nooit issues. En dat is near-bleeding edge software. In CentOS Stream is het nog steeds erg conservatief, met goede QA pipelines. Is het iets voor iedereen, nee. Maar het is absoluut niet onbruikbaar zoals veel claimen.

Red Hat grootste fout was het zo slecht uitleggen van CentOS Stream. Wil de community iets beters? Fork dan CentOS Stream, net zoals Ubuntu dat doet met Debian. Dan voeg je tenminste nog wat toe. Want contribution is dan wél mogelijk.

[Reactie gewijzigd door UPPERKEES op 22 juli 2024 16:49]

[divvid]

Wellicht off topic: is CentOS 9 nou echt zoveel instabieler dan een Alma of Rocky? Zijn er mensen die serieus CentOS stream op servers draaien, en over welke stabiliteit of instabiliteit hebben we het in de praktijk? (Serieuze vraag)

Voor veel onderzoeksinstellingen is er geen of weinig geld voor licenties en was CentOS een prima keuze. Vaak boeit het niet of nauwelijks als er enige downtime is, maar echte cijfers over downtime door bugs per jaar op CentOS stream kan ik nergens vinden

Wij zitten nu serieus met die keuze. Vanaf CentOS7 switchen naar debian, rocky of alma? Vanaf scratch moeten we toch al opbouwen

[Reactie gewijzigd door divvid op 22 juli 2024 16:49]

[UPPERKEES]

Ligt aan je definitie van stabiliteit. Want daar lijkt nogal eens verwarring over te bestaan. Sommige mensen noemen Debian stabiel en Fedora niet omdat het nieuwere software heeft. De definitie van stabiel is dat je APIs and ABIs niet veranderen tijdens de release en je dus software kan updaten zonder dat dingen stukgaan.

Maar sommige zien stable als iets dat geen bugs heeft. Mijn ervaring is dat Debian bijvoorbeeld meer onstabiel is in dat opzicht, omdat de software niet meer maintained wordt, omdat upstream die versies niet meer actief ondersteund. Dus fixes zijn soms mogelijk door cherry picks van upstream. Maar actieve support heeft het niet meer. Dat maakt zoiets als RHEL ook zo bijzonder, wat tot wel 10 jaar support kan krijgen. Dat is ook iets wat erg duur is, en waar Alma/Rocky niks aan bijdraagt.

Dus TL;DR, ja CentOS is gewoon stabiel, APIs en ABIs breken niet. En updates worden goed getest en als er iets stuk is, zal Red Hat dat fixen op basis van hoeveel impact het heeft.

[Reactie gewijzigd door UPPERKEES op 22 juli 2024 16:49]

[tvdijen]

Ik merk niets van instabiliteit.. Gewoon wat je van CentOS gewend bent.
Wellicht heeft het met het gebruik te maken.. Ik beperk me tot het gebruik van database-software (MariaDB/MongoDB) en het draaien van PHP/Java webapplicaties.

[s0ulmaster]

Ik werk veelal met RHEL, maar ook daar zie ik inconsistentie door API/ABI wijzigingen. Ze doen graag dingen uit noeuwe kernels backporten en een update van RH 8.4 naar 8.6 was dus voor ons niet zonder slag of stoot. Gelukkig waren de aanpassingen aan onze drivers minimaal dit keer, maar ik zie de update naar 8.8 nog wel weer het een en ander stuk gaan.

@UPPERKEES ik werk te weinig met centos maar ik kan me nirt vooratellen dat als RHEL al dingen stuk weet te maken, dat centos dat wellicht nog meer doet!

[UPPERKEES]

RHEL heeft geen API/ABI wijzigingen tijdens een major release. Ken geen enkele distro die dat wel heeft, tenzij het rolling release is.

[s0ulmaster]

Kunnen ze wel verkondigen, maar ik heb toch echt eertehands ervaringen, dat ze, voornamelijk door hun backporten, toch echt wel breaking changes maken

Edit: en ik denk dat je ipv major, minor bedoeld?

[Reactie gewijzigd door s0ulmaster op 22 juli 2024 16:49]

[Hydranet]

Ze voegen wel wat toe aan een het opensource echosysteem, namelijk.

Couple of examples:

We provide live images of Workstation (gnome), KDE, XFCE, MATE, and now Cinnamon for 9
raspberry pi support by way of a custom kernel and images done by SIG/AltArch
We built our own build system for 9 and are working on version 2 of it, it’s open source
We built our own tool sets, it’s open source.

Those are just some examples. We also have devs who work with red hat folks on EPEL/Fedora Project related work and maintenance, which ultimately benefits the entire community. We’ve also reported several bugs to red hat’s bugzilla.

bron: https://forums.rockylinux...lled-rocky-linux/10378/99

[Guru Evi]

Dat kunnen ze toch gewoon doen op CentOS? De grootste aantrek was een kopie van RHEL zonder te betalen voor RHEL, eenmaal je custom kernels, Cinnamon etc wilt, dan kun je evengoed onderweg met CentOS of Fedora.

[Hydranet]

Het punt van een RHEL clone is juist om zoveel mogelijk gelijk te zijn aan RHEL en niet upstream van RHEL te zitten.

[Guru Evi]

Maar een RHEL kloon heeft geen Cinnamon of RPi versies, de verklaring van Rocky raakt dus kant noch wal voor de mogelijkheid om een RPM-gebaseerde Linux te maken met Cinnamon zonder de RHEL distributie.

De RHEL distributie is precies bedoeld voor bedrijven die meer stabiel dan CentOS willen zijn, custom kernels en Cinnamon komt er niet bij kijken.

Rocky kan nog steeds een ‘meer stabiele’ CentOS maken, ze kunnen echter niet langer afkijken van RHEL en een identiek product verkopen.

[Hydranet]

De meeste mensen(en bedrijven) die Rocky of Alma gebruiken, gebruiken die omdat het RHEL clones zijn en omdat ze geen technical support nodig hebben van Redhat. Ik dus ook en zou het erg jammer vind als dat weg zou gaan want ik draai juist een RHEL clone op mijn eigen vpsen om ook een beetje bij te blijven in de RHEL omgeving en omdat ik gewend ben om er mee te werken.

[Guru Evi]

Dan maakt het niet dik uit wat je draait, CentOS of een Alma/Rocky die hun eigen ideeën hebben van stabieler te zijn dan Stream zijn dicht genoeg bij RHEL dat je ze qua kennis nodig niet kunt uitmaken.

De enige reden dat je een RHEL kloon nodig hebt is dat er andere software bovenop zit die een Enterprise Linux vereisen.

Dat is meestal in bedrijven, hardware of software zoals nVIDIA Enterprise drivers of VMWare of Dell gaan Rocky/CentOS/SuSE/Debian niet ondersteunen en RHEL maakt het een beetje makkelijker vanwege de afhankelijkheden die bekend zijn. Dat wilt niet zeggen dat het niet mogelijk is (wij draaien nVIDIA enterprise op Proxmox) maar het is een beetje meer werk en een beetje minder documentatie. Documentatie waar je anders iemand voor kan bellen of kan verkrijgen. En in zulke omgeving maakt de 120-700 euro voor een RHEL licentie niet uit jaarlijks.

[Hydranet]

Ik draai ook een RHEL clone op mijn vpsen vanwege selinux omdat geen enkele distributie dat zo goed voor elkaar heeft als RHEL, heb laatst nog selinux zitten testen op Debian en dan loop je tegen van alles aan wat op RHEL verder wel goed geregeld is. Ik weet nog niet hoe het gaat aflopen met Rocky en Alma maar om eerlijk te zijn sta ik niet om te springen om CentOS Stream op mijn vps te draaien vooral omdat ik op veel plekken lees dat Stream niet even betrouwbaar is. En dan lees ik op andere plekken weer dat wat er in CentOS Stream zit al getest zit en in de volgende update of minor release van RHEL komt. Dus ik ga het allemaal even rustig afwachten voordat ik een beslissing maak wat ik met mijn vpsen ga doen.

[Reactie gewijzigd door Hydranet op 22 juli 2024 16:49]

[Guru Evi]

Voor tuin en keukengebruik (en klein bedrijf zelfs) krijg je van RHEL nog steeds 16 gratis licenties voor RHEL met alle toeters en bellen. Je hebt inderdaad gelijk dat bepaalde configuraties standaard beter zijn in RHEL, en dat is waar je uiteindelijk als bedrijf soms wilt voor betalen. 100 licenties waar alles al afgewerkt is goedkoper dan een SysAdmin.

En het is mogelijk dat Alma/Rocky dat ook kan doen, maar het kost allemaal tijd en geld, Proxmox is ook gratis maar enterprise repos zitten achter een paywall, echter daar zeggen we al jaren niets over.

[Hydranet]

Ja daar heb ik aan gedacht om de personal developer subscription te aan gebruiken maar ik heb er eigenlijk geen vertrouwen in dat Red Hat op gegeven daar ook geld voor gaat vragen. Ik heb ook mijn grote vraag tekens er bij hoe lang Rocky/Alma het gaat volhouden, want ik verwacht dat dit niet het laatste wat Red Hat probeert om ze dwars te zitten.

Ik denk dat het verschil met Proxmox is dat die het al vanaf het begin zo gedaan hebben en dat Red Hat pas sinds de laatste jaren met zulke wijzigingen aan komt. Eerst CentOS -> Stream en nu dat over de sources, alleen ik volg Proxmox nog niet zo lang omdat ik het pas sinds 2 jaar gebruik of zo.

[BvdW1978]

Zullen we de gebruiker zelf laten bepalen wat "evengoed" is of niet? Dat is nu net waar de GPL om gaat.

[Azbest]

Het argument van Red Hat is dat distributies zoals Rocky/Alma alleen de source pakken en that's it.

Mwoah, uiteindelijk hebben ze daar ook gebruikers. Dat komt RHEL ergens wel ten goede. Kan me niet voorstellen dat Alma en Rocky geen bugs vinden.

[GertMenkel]

GPL staat 100% toe om de sources opnieuw aan te bieden zonder enige bijdrages of toevoegingen. Je moet de nodige copyrightzaken uitzoeken (je mag niet doen alsof je Red Hat bent) maar er is helemaal niks verboden aan het opnieuw aanbieden van Red Hat packages. Sterker nog, je mag de code pakken, er een prijskaartje op plakken, en daarna zelf verkopen.

Nu is het wel zo dat niet alle packages onder GPLv3 aan worden geboden. Apache 2 en MIT staan toe dat je alleen de copyright notice verspreid maar niet de sources, bijvoorbeeld.

Daarnaast gelden de GPL-rechten alleen voor klanten. Als Red Hat besluit om geen software meer te leveren aan Rocky, heeft Rocky geen recht meer op de GPL-broncode vanaf dat punt. Er is onder GPL absoluut geen verplichting om alles maar openbaar ergens te uploaden. Ethisch gezien kun je het oneens zijn met Alma/Rocky/etc., maar licentietechnisch gezien is wat Alma doet helemaal niet verboden als het aankomt op GPL-code.

Overigens zijn veel mensen achter Rocky wel degelijk actief in de open source-wereld.

[syl765]

Het argument van Red Hat is dat distributies zoals Rocky/Alma alleen de source pakken en that's it. Ze helpen niet mee met het fixen van bugs.

En hier maakt RedHat in mijn ogen toch een inschattings fout. Misschien helpen ze niet actief mee in het fixen van de bugs. Wat men wel vergeet is dat je door deze distro's wel op veel meer platformen komt te draaien, je komt op heel veel andere configuraties te draaien en je vind daarmee veel meer bugs die dus gefixed kunnen worden. Misschien wel die kritieke bug die je nu dus kunt fixen voor 1 van je betaalde klanten hier tegen aan loopt.

[GekkePrutser]

Het is helemaal niet de inschatting die RedHat maakt. Dat bugfixen is alleen maar een excuus. Alleen het PR verhaaltje. Net zoals de discussie rondom CentOS Stream destijds.

Waar het ze om gaat is dat ze niet willen dat 'hun' OS gratis beschikbaar is.

[Reactie gewijzigd door GekkePrutser op 22 juli 2024 16:49]

[Polderviking]

Als je in het open source landschap zit en je je vervolgens stoort aan wie er hoe van je werk profiteert heb je het volgens mij gewoon niet begrepen.

Verder denk ik niet dat het paywallen van rhel goed is voor 't marktaandeel van rhel en dus op termijn de positie van rhel in het bedrijfsleven.
Maar als ze dat de nek om willen draaien moeten ze dat vooral zelf weten. Er zijn zat alternatieven.

[Reactie gewijzigd door Polderviking op 22 juli 2024 16:49]

[GekkePrutser]

Ze zijn letterlijk een bug-for-bug copy van RHEL, het is geen fork. Zo werkt open-source niet, het is geven en nemen.

Zo werkt open-source wel. Het is fijn als mensen meehelpen met bugs maar alleen nemen is ook ok. Je kan niet je eigen regeltjes gaan bedenken. Nouja, dat kan wel maar dan moet je zelf al je software bouwen, zoals Microsoft doet.

En redhat helpt ook niet mee met bugfixes van alle packages die ze distribueren.

[Reactie gewijzigd door GekkePrutser op 22 juli 2024 16:49]

[UPPERKEES]

Hele comment lezen. Rocky/Alma doet geen enkele bijdrage, want dat is niet mogelijk als je bug-for-bug copy maakt. En Red Hat is een powerhouse in de open source wereld, tuurlijk raken ze niet elke package aan. Maar het zijn absoluut de grootmacht met commits in kernel, GNOME, systemd, etc.

[swhnld]

Alles hangt samen met de gebruikte licenties in de software. Zelfs binnen GPL heb je al verschillende versies. En daarbuiten is nog een wereld aan licenties.
Meest vervelende is als er conflicterende licenties zijn voor hetzelfde stuk software. Een paar jaar terug was er een bepaalde plugin voor betaalsoftware in centraal Europa in omloop die dat had. De ene licentie was dat je de software gewoon mocht gebruiken, de andere dat je integratie sourcecode moest openbaren.
Toen maar de ontwikkelaar aangeschreven en uitleg gevraagd en ontvangen en die goed bewaard.
Om die betaal methode te gebruiken was deze software integreren immers de verplichte oplossing. En toestemming om het te gebruiken zonder de eigen broncode te publiceren was wat onze klant wilde en daarmee ook kreeg.

[bzuidgeest]

Voor zover ik het begrijp gebruiken ze de clausule die zegt dat je geld mag vragen om de kosten te dekken voor distribute.
In het verleden betekende dat je geld vraagt voor de cd waarop je de code perst. Cd maken is namelijk niet gratis een post ook niet.
Redhat past dit nu toe op digitale distributie. Kost stroom en internet bandbreedte en dat is ook niet gratis.

Het lijkt mij een dubieuze lezing van de gpl maar voor wat ik lees niet tegen de regels strikt genomen.

[jorisvergeerTBA]

Je moet het openbaar maken aan je klanten en gebruikers. En deze gebruikers mogen distribueren met dezelfde rechten en plichten.

Je bent niet verplicht alles aan het hele universum open te geven.

[BvdW1978]

Heeft Red Hat dan wel het recht om beperkingen op te leggen aan de klant die zijn rechten krachtens de GPL uitoefent?

[Guru Evi]

Niet op de broncode, wel op de verpakking (de configuratiebestanden, de precieze versies). De broncode en zelfs de RPMs voor de hele RHEL distributie is beschikbaar openbaar op git.centos.org. Wat niet beschikbaar is de broncode van het verpakkingsproces en documentatie dat RHEL gebruikt, dat is enkel beschikbaar voor klanten en is niet GPL.

Als voorbeeld, als jij Linux opzet voor een bedrijf, hoef je de bestanden in /etc/ niet terug online te zetten. Als systeembeheerder zijn er veel dingen die je soms zelfs niet documenteert.

[Reactie gewijzigd door Guru Evi op 22 juli 2024 16:49]

[BvdW1978]

Zover ik weet had CentOS en hebben Rocky en Alma juist hierom hun eigen buildstraten en zit daar dan ook niet het euvel.

Als gebruiker van een Linuxdistributie heb ik sowieso alle vrijheid om te doen en laten wat ik ermee wil. De GPL wordt pas relevant wanneer ik de gelicentieerde software ga doorleveren aan derden. In dat geval ben ik verplicht er ook de broncode bij te doen inclusief mijn wijzigingen aan die code. De configuratie kan daar inderdaad buiten blijven.

[Reactie gewijzigd door BvdW1978 op 22 juli 2024 16:49]

[Guru Evi]

En dat is precies het punt, Rocky/Alma neemt alles van de RHEL distributie over, het grootste verschil is oa. SELinux en SCAP configuraties die ‘uit de doos’ werken met RHEL waar CentOS Stream of Fedora … moeilijk kunnen zijn (en de reden dat een groot aantal mensen gewoon SELinux uitschakelen).

Vooral de SCAP configuraties zijn niet ‘gratis’ beschikbaar (ik heb zelf een account en inspraak by CIS profiles, kost de organisatie waar ik werk een aardig duitje), echter Rocky neemt ze gewoon over en verandert RH naar RL en klaar is Kees terwijl je bij CIS de developers (mensen met een redhat.com e-mail) echt dagelijks aan die profielen werken, vragen beantwoorden en de kleinste veranderingen overleggen met mensen op die forums. Natuurlijk kan Rocky ook een zetel krijgen bij al die organisaties voor hun eigen distributie, maar opnieuw, dit kost geld, zakken geld, maar het is geen deel van de GPL.

Je hebt bij Proxmox ook al jaren een enterprise repo waar je enkel als betalende klant bijkunnen en je mag die ook niet zomaar verspreiden. En Ubuntu en SuSE heeft ook al een tijdje aparte repos voor de Pro/betaalde versie. Het enige verschil tussen RHEL en Ubuntu Pro of Proxmox is dat (net zoals het Reddit drama) een paar luide mensen die achter specifieke projecten zitten niet kunnen verstaan dat dingen geld kosten en omdat je vroeger misbruik kon maken (of er was tenminste een gedoogbeleid) van bepaalde functies, je niet kunt verwachten dit oneindig mogelijk is.

Wat nog steeds mogelijk is om naar git.centos.org, dezelfde versies van de software die een RHEL distributie gebruikt compileren en die distributie her-verspreiden. Echter, dat is voor veel mensen niet waar RHEL waarde brengt en dus voor Rocky/Alma geen meerwaarde over gewoon CentOS of Fedora te gebruiken (de meeste packages zijn 1-2 versienummers verschillend van wat er in RHEL zit) de meerwaarde zit grotendeels in oa. het redhat-rpm-config package waar uiteindelijk geen GPL licentie aanhangt alhoewel dev/beta versies nog steeds in Fedora/CentOS zitten.

[Reactie gewijzigd door Guru Evi op 22 juli 2024 16:49]

[BvdW1978]

redhat-rpm-config heeft GPL+ in zijn spec file..

Maar goed, ik ben er wel klaar mee eigenlijk. Niemand heeft Red Hat ergens toe gedwongen toen ze onder GPL software gingen bouwen en distribueren. Het zijn volwassen mensen die zelf de consequenties van hun daden moeten overzien.

Geef je software uit onder de GPL, dan moet je hier gewoon niet over blijven doorgaan. Het is wat het is: gratis en vrij te gebruiken zodra je eenmaal legaal een exemplaar hebt verkregen, alsook vrij te verspreiden daarna. Juist hier zijn ze groot mee geworden.

[The Zep Man]

Was niet het punt van open source licenties zoals op Linux dat je juist de broncode bij dit soort dingen openbaar moet maken?

Je moet met bijvoorbeeld iets als GPL broncode beschikbaar stellen aan degenen aan wie je software (binaries) beschikbaar stelt, zonder verdere restricties op te leggen. Als Red Hat enkel binaries levert aan klanten, moeten ze enkel broncode beschikbaar stellen aan klanten.

In de praktijk brengen de meeste (ook commerciele) opensourceontwikkelaars hun broncode uit voor iedereen omdat het simpelweg makkelijker is (ook voor bijvoorbeeld crowdsourcing van bugfixes), maar dit wordt niet afgedwongen door licenties.

[Reactie gewijzigd door The Zep Man op 22 juli 2024 16:49]

[BvdW1978]

Punt is dat ik als klant van Red Hat vervolgens het recht heb om de verkregen broncode alsook de binaries vrij te verspreiden. Daar doorkruisen dan wel weer wat merkenrechtelijke zaken het verhaal. Krijg je dus situaties zoals destijds Debian dat de Firefox-browser herverpakte als Iceweasel met eigen branding om de handelsmerken van Mozilla te omzeilen. Red Hat behoudt zich nu het recht voor om, wanneer ik mijn rechten vanuit de GPL uitoefen, de klantrelatie eenzijdig te staken.

[The Zep Man]

Punt is dat ik als klant van Red Hat vervolgens het recht heb om de verkregen broncode alsook de binaries vrij te verspreiden. Daar doorkruisen dan wel weer wat merkenrechtelijke zaken het verhaal.

Alleen als jij wijzigingen daaraan maakt. Anders stuur jij nog steeds Red Hat's product door. Je mag je alleen niet voordoen als Red Hat (identiteitsfraude). Dat moet Red Hat maar accepteren, gezien die hun merknaam aan een FOSS-product gekoppeld hebben.

Als je wel wijzigingen maakt, dan mag je niet meer claimen dat het van Red Hat is, en moet je waarschijnlijk ook de naam wijzigen. Dat heeft nog steeds geen impact op je overige rechten.

Red Hat behoudt zich nu het recht voor om, wanneer ik mijn rechten vanuit de GPL uitoefen, de klantrelatie eenzijdig te staken.

De discussie is dus of dat mag, gezien de voorwaarden van bijvoorbeeld de GPL. Zie ook mijn andere reactie. Dat zal in een rechtszaal uitgevochten moeten worden.

[Reactie gewijzigd door The Zep Man op 22 juli 2024 16:49]

[Guru Evi]

Alle broncode van RHEL is beschikbaar in Fedora en CentOS. Wat RH specifiek doet is bepaalde versies van de boel verpakken en op een CD (ISO) zetten en support verkopen. Daarvoor mag je dus wel geld vragen.

Wat oa. Rocky Linux doet is afkijken welke pakketjes ze samenstellen, configuratiebestanden en alle andere zaken dat RedHat een RHEL maakt, ze lopen awk/sed RedHat met Rocky en dan ‘verkopen’ ze dit door aan mensen die er niet voor willen betalen.

Het is niet echt legaal grijs, het is legaal wit en zwart. Jij moet ook je configuratiebestanden en samenstelling van je systeem niet online zetten enkel omdat je Linux gebruikt. De bron blijft beschikbaar, de speciale saus die RH gebruikt voor een klant moeten ze niet vrijgeven (alhoewel ze dit wel in beperkte mate blijven doen). RHEL doet bepaalde dingen voor bedrijven waar zelfs upstream niet happig mee is (vb. Fedora wil nu al omschakelen naar Wayland terwijl het nog niet compleet is en we nog jaren nodig zullen hebben om X11 te verplaatsen)

[Brent]

Nee, dat is net het verschil tussen open source en free software. En niet alles wat Red Hat bundelt is free. Spul onder een Apache licentie hoeft niet gedeeld te worden bijv., en Red Hat zal die loophole wss gebruiken.

De vraag is waarom deze CentOS forkers niet Debian LTS gaan versterken. Dan heb je geen commerciële entiteit die de grond onder je voeten vandaan kan trekken.

[Zezura]

Ik heb Red Hat nog nooit geprobeerd of mee te maken gehad. Ik draai zelf eigenlijk alleen maar Debian. Ik begon ooit met Ubuntu, maar ik gebruik nu tegenwoordig puur Debian (& Raspi OS ).

Zijn er mensen die ik het kort, de grootste verschillen kunnen uitleggen tussen Debian en Red Hat?

[HJR]

Hier zijn al genoeg antwoorden op te vinden. RHEL staat voor Enterprise Linux.
In een enterprise gaat over schaalbaarheid, lange termijn support en tooling eromheen om de boel te kunnen managen.
Het is dus een totaal andere usecase dan jouw twee debian doosjes die je makkelijk met de hand kunt managen en patchen.
Als je 2000+ VMs hebt die je elke week wilt patchen, dan wil je tooling om dit te kunnen doen.
Redhat is zo’n beetje de enige die naast Linux ook de tooling levert om dit alles op grote schaal te kunnen doen.

[c-nan]

Red Hat is natuurlijk veel meer dan alleen RHEL, het OS. Het is een ecosysteem. Veel Enterprise gebruikt:
- RHEL als OS
- Red Hat Satellite voor distributie van software
- Red Hat IdM voor authenticatie en autorisatie
- Tegenwoordig ook Red Hat OpenShift voor containerisatie

Wil je Debian als OS? Dan zal je ook geen gebruik maken van Satellite, IdM en OpenShift. De genoemde producten zijn allemaal gebaseerd op opensource software. Dus dan krijg je Debian, Foreman, Katello, FreeIPA, Kubernetes. Als Enterprise wil je support op je producten en het liefst breng je dat onder bij 1 partij.

[beerse]

Ooit, in den beginne was er linux, gnu en nog wat tools die bij elkaar geraapt zijn. In die tijd waren er al snel een paar verschillende groepen. Zowel Debian als ook RedHat waren er al snel. Zij hebben ongeveer alles vanaf de grond af aan opgebouwd en alles bij elkaar verzameld.

De achtergrond van Debian was toen al en is nu volgens mij nog steeds: Wij zijn open, we gebruiken open en daar kan en mag iedereen op aanhaken of het zelf doen als ze het beter weten.

De achtergrond van RedHat was volgens mij toen ook al een beetje en is steeds meer: Wij zorgen er voor dat het gaat werken en dat er ook ondersteuning is en nog veel meer zaken die grote en/of commerciële organisaties wensen. Daar laten we ze dan netjes voor betalen. Wel respecteren we de opensource gedachte en zullen voor zover nodig de sources beschikbaar stellen. ook respecteren we andere licenties ook als die niet aansluiten op opensource.

Technisch is het grootste verschil de gebruikte tools voor pakketten, installaties en dergelijke: Debian == apt, dpkg, aptitude en dergelijke. RedHat is rpm en omstreken. ER zijn nog veel meer detail verschillen maar er zijn gelukkig veel meer overeenkomsten.

[Ozzie]

Enterprise support is het grootste verschil. Grote bedrijven en/of overheidsinstellingen willen gewoon bij een partij kunnen aankloppen voor hun software. Zodat het gegarandeerd werkt met de configuratie die zo'n partij wil en zodat er een leverancier is die jarenlang support kan leveren en security updates aanbied.

[ArcticWolf]

Ook begonnen met Debian, maar uiteindelijk overgestapt naar Arch en nooit meer terug gekeken naar Debian
RedHat ooit weleens geprobeerd, maar vond het niks.. maar te lang geleden om de verschillen te herinneren.

[Marve79]

Redhat begint op Oracle te lijken. Tijd voor een boycot.

[Ozzie]

Tja RedHat levert wel een heel goed product en commit heel veel in diverse open source projecten. Bijvoorbeeld de op een na grootste contributer in Kubernetes.

[EXX]

Ironisch is dat Oracle hier ook bij betrokken is vanwege Oracle Linux, dat ook de RHEL sources als basis heeft, maar veel meer gewicht in de schaal kan gooien tegen Red Hat. Uitgerekend Oracle, dat zelf ook niet zo een geweldige reputatie heeft.

[The Zep Man]

De ontwikkelaar zegt methodes te hebben gevonden om de RHEL-paywall te omzeilen en toch de broncode te bemachtigen.

Het lijkt mij makkelijk. Ze moeten een RHEL-klant vinden als sponsor. Immers moet Red Hat broncode onder FOSS-licenties beschikbaar stellen aan klanten, en mogen die dat weer doorgeven aan anderen.

[Stetsed]

Het is onder de license agreements van red hat dat je de source code niet mag redistributeren of je license tot RHEL wordt afgehaakt, dit is waar het dus zeer legaal grijs wordt want technisch gezien stoppen je niet van de het redistribute, maar geven je dan alleen niet de nieuwe versie.

[The Zep Man]

Het is onder de license agreements van red hat dat je de source code niet mag redistributeren of je license tot RHEL wordt afgehaakt,

Ik spreek natuurlijk over de delen die bijvoorbeeld vallen onder de GPL. Red Hat kan voor die delen op hun kop gaan staan, maar de GPL gaat boven alles dat zij erbovenop gooien en ermee in conflict is. In een rechtszaak zou RH's gedrag geen standhouden.

Verder is het natuurlijk de vraag hoe Red Hat erachter komt wie broncode herdistribueert, en of ze echt daarop durven te handelen. Vaak zijn dat soort clausules meer blaf dan bijt.

[Reactie gewijzigd door The Zep Man op 22 juli 2024 16:49]

[- peter -]

Daar is dus de discussie wat over. Of contracten boven de GPL gaan. In de zin van, mogen ze je je contract ontbinden als je tegen hun zin in distribueert.

[Reactie gewijzigd door - peter - op 22 juli 2024 16:49]

[The Zep Man]

GPL:

4. You may not copy, modify, sublicense, or distribute the Program except as expressly provided under this License. Any attempt otherwise to copy, modify, sublicense or distribute the Program is void, and will automatically terminate your rights under this License. However, parties who have received copies, or rights, from you under this License will not have their licenses terminated so long as such parties remain in full compliance.
(...)
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.

Het is uiteraard voer voor juristen, maar ik denk dat RH hier geen sterke casus heeft, zeker niet als je ook de tech-community in het harnas jaagt.

[Reactie gewijzigd door The Zep Man op 22 juli 2024 16:49]

[Anoniem: 454358]

zou die tech community ze zich ook maar iets interesseren? RH wil gewoon geld zien, en dat doen ze niet aan die gratis gebruikers, maar aan hun enterprise klanten.

[The Zep Man]

zou die tech community ze zich ook maar iets interesseren?

Het is die tech community die veel moeite doet om Red Hat's broncode te verkrijgen, voor een fractie van de kosten die Red Hat zelf maakt. Natuurlijk hoef je die niet te faciliteren, maar in de weg zitten werkt vaak averechts.

[Reactie gewijzigd door The Zep Man op 22 juli 2024 16:49]

[Stetsed]

Dit is niet de discussie, LICENSE gaat boven contract. De vraag is of de LICENSE well wordt gebroken, in spirit is dit zeker waar maar er is weinig precident op dit gebied en de enige manier om het uit te vinden is dat iemand of een group van mensen die GPL code developed die red hat gebruikt red hat aanklaagd.

[dmantione]

Beiden zijn geldig: Dus als jij verder verspreidt, mag Red Hat je account afsluiten. Het probleem is dat als ze dat daadwerkelijk doen, ze de GPL schenden en dat heeft nogal gevolgen: Ze verliezen al hun rechten op GPL-software en die kunnen ze niet automatisch terugkrijgen. Ze moeten dan de auteurs om vergiffenis vragen (en dat zijn er nogal niet wat). De kans dat Red Hat daadwerkelijk bijt, acht ik daarom nihil.

[i-chat]

dit is een zaak die lang gaat duren maar waar een partij als de FSF zeker iets mee moet.

[Transportman]

Maar wie gaat zijn account er voor opofferen? Als klant zit je niet op dat soort gezeik te wachten, als je als klant dan zo principieel bent ga je eerder naar een alternatief kijken dan je allerlei gezeik op de hals halen met Red Hat.

[Ozzie]

Ik zou niet weten waarom dat niet mag. RedHat mag toch zeker wel zelf bepalen wie ze wel en niet als klant willen. De licentie op de software die ze leveren veranderd daar niets aan.

[Hydranet]

Niet alle software in RHEL valt onder de GPL er zit ook software tussen die on der de BSD en MIT licenses vallen. Dus strict genomen zouden ze de bron van die software niet hoeven vrij geven, ben benieuwd of ze die kaart nog gaan spelen.

dnf repoquery --repo appstream --repo baseos --repo crb --info|grep ^Lic|sort -u

[BvdW1978]

Dat hoeven ze inderdaad niet, maar die kaart gaat ze nog aardig in hun achterste bijten wanneer ook klanten die sources niet meer krijgen.

[justinkb]

Ik zou graag zien dat het tot een rechtszaak komt, zodat we eindelijk jurisprudentie over deze kwestie krijgen. Ik kan de GPL niet anders interpreteren dan dat Red Hat de GPL overtreedt door niet GPL-compatibele restricties op te leggen op het verder verspreiden van de open source broncode. En als ze de GPL overtreden, is de licentie niet meer geldig en plegen ze dus auteursrechtovertredingen

[Reactie gewijzigd door justinkb op 22 juli 2024 16:49]

[devices]

Welke restricties worden er dan opgelegd? Je bent vrij om de broncode te verspreiden. Het enige wat nadrukkelijk niet mag is herdistribueren onder de Red Hat naam, maar dat mag bijvoorbeeld bij Firefox ook niet..

[justinkb]

Het probleem is dat Red Hat in hun RHEL licentieovereenkomsten met hun klanten heeft opgenomen dat hun account gesloten wordt als de klant deze sources verder verspreidt

[devices]

Dat gaat over de klantrelatie, maar je had het in je eerste comment over restricties op het verspreiden van GPL broncode.

[justinkb]

Volgens de GPL mogen er geen restricties opgelegd worden voor het verder verspreiden van broncode. Dit valt grofweg onder deze uitleg https://www.gnu.org/licen...n.html#DoesTheGPLAllowNDA

[L0g0ff]

Door deze beweging van redhat zou ik niet snel voor alma en/of rocky kiezen als enterprise distro.

Het kan zijn dat ze er nu omheen bewegen maar als redhat hier echt geen zin meer in heeft dan is het wachten op een hoop gedoe in de toekomst.

Kies dan bijvoorbeeld voor een debian waar je weet dat de (politiek) betrouwbaarheid van de distro wel op orde is.

[mmjjb]

Alma & Rocky zijn ook geen enterprise distro's. Als je dat wou ging je zowizo al naar RedHat. Het probleem is dat een groot deel van de gebruikers wel bijdraagt maar niet enterprise is, wat nu dus potentieel afgesloten wordt.

[L0g0ff]

Zowel centos als rhel hebben enterprise in hun naam (in de "e"). Dat heeft een een reden

Omdat redhat behoorlijk stabiel is maar best wel aan de prijs zag je dat heel veel vendoren hun (enterprise) appliances op centos bouwde. Je had dat de betrouwbaarheid van de rhel distributie maar geforkt en onderhouden door de community.

Dit werkte jaren lang prima totdat redhat besloot centos over te nemen en er een rolling release distro van te maken.

Als je een (enterprise) applicance hebt draaien dan wil je geen rolling release. Je wilt dan stabiele versies zodat niet na een update ineens heel je applicatie in elkaar zakt.

Onder andere alma en rocky sprongen in dat gat. Er was dus ineens weer een rhel fork met een betrouwbare fundering en onderhouden door een community. Je zag dus dat heel veel vendoren hun centos distro ombouwde naar alma of rocky.

Maar na dit nieuws zie je dat redhat hier helemaal geen zin meer in heeft. Dit gaat een kat en muis spel worden waar ik persoonlijk als ik zo'n appllicance zou moeten onderhouden helemaal geen zin in zou hebben. Je kiest niet voor niets voor een betrouwbare stabiele fundering. Maar dan moet je niet het idee hebben dat elk moment de stoelpoten onder je distro uitgezaagd kunnen worden.

Vandaar mijn vorige opmerking dat ik dan eerder voor debian zou kiezen. Dat heeft namelijk bewezen al jarenlang wel stabiel en betrouwbaar te zijn.

[SillieWous]

Andersom exact hetzelfde. Een groot deel zijn zeker enterprise gebruikers die niet willen betalen. Sterker nog, ik denk dat velen zelfs een enkele RHEL licentie aanschaffen, om op die manier ook nog support te krijgen.

[BvdW1978]

Wat is er precies op tegen om niet te willen betalen voor software waarvoor dat ook niet verplicht is? Die ene licentie RHELhangt bovendien aan dat ene exemplaar. Daarmee support krijgen op je hele winkel gaat je echt niet lukken in de praktijk.

Er zijn genoeg bedrijven die een heleboel CentOS/Rocky/Alma in de winkel hebben staan en daarbij inschatten dat de eigen beheerclub afdoende support is. Daarnaast draait een plukje missiekritische infra, waar je dan wel SUSE of RHEL tegenkomt voor de vendor-support. SAP vereist dat bijvoorbeeld. Je appliatiestack wordt simpelweg niet ondersteund of gecertificeerd wanneer je niet de juiste OS-versies eronder hebt draaien. Dat doe je dan ook gewoon. Maar waarom zou je dat ook zo doen voor een webservertje met het lunchmenu van je kantine erop?

[SillieWous]

Omdat je dan niet alleen niet bijdraagt aan het ecosysteem, maar zelfs afbreuk er aan doet door de mensen die er aan werken niet te betalen.

En dan kun je wel een verhaal gaan ophangen dat het mag. Maar als de enige reden is dat het gratis is, ben je wmb niet ethisch bezig als bedrijf. Voor het minuscule deel dat wel op een andere manier bij draagt is het een ander verhaal.

[BvdW1978]

Supportcontracten en omliggende diensten betalen de mensen van Red Hat. Als gebruiker van GPL-software ben je tot helemaal *NIETS* verplicht en het is al helemaal niet onethisch. Die lees ik al vaker hier, alsof ik me moet schamen als ik niets bijdraag of niet op zijn minst financieel iemand compenseer. Dat is echt de grootst mogelijke onzin die tot dusver voorbij is gekomen. Als deze vorm van gebruik zo'n groot probleem was, had Red Hat destijds een BSD moeten forken en onder die licentie de boel moeten sluiten en Microsoftje moeten gaan spelen. Dan hadden ze alleen nog geen deuk in een pakje boter geslagen natuurlijk. In plaats daarvan zijn ze groot geworden op de GPL en nu ze zijn overgenomen door een nog veel grotere jongen, beginnen ze streken te krijgen... hypocriet is het, en ik ga me geen seconde verontschuldigen voor welke vorm van gebruik van GPL-software dan ook.

[SillieWous]

Ok

[Stetsed]

Hoewel ik het fijn vindt dat rocky kan blijven bestaan wordt dit gewoon een cat en mouse spell, Red hat wordt meer restrictief en rocky vindr er dan een nieuwe methode voor en zo door en zo door.

[DeBierVampier]

U bedoelt misschien 'kat en muis spel'?

[DrPoncho]

Of Red Cat game?

[beerse]

Als je bedenkt dat je met `cat` de inhoud van een bestand laat zien is dat best wel open: RedCat, de listing van RedHat

[Stetsed]

Sorry je hebt gelijk, mix een beetje Engelse met Nederlands mijn excuses.

[Rob Coops]

Oh boy, dit is zo'n geweldige discussie waar je de popcorn bij moet pakken en dan even dit stukje van de GPL licentie in het achterhoofd houden:

4. Conveying Verbatim Copies.
You may convey verbatim copies of the Program's source code as you receive it, in any medium, provided that you conspicuously and appropriately publish on each copy an appropriate copyright notice; keep intact all notices stating that this License and any non-permissive terms added in accord with section 7 apply to the code; keep intact all notices of the absence of any warranty; and give all recipients a copy of this License along with the Program.

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.

Met andere worden RedHat mag gewoon welke prijs dan ook vragen voor hun software. Er is geen twijfel geen discussie nodig RedHat doet gewoon dat geen dat de GPL licentie toestaat. Nus is het een soort van ongeschreven regel dat je geen geld vraagt voor de sources maar dat is niet relevant het mag wel.
Daar naast moet je je heel erg af vragen of de partijen die klagen echt een punt hebben. Alles wat zij doen is de code compileren en de software onder een andere naam uitbrengen, er wordt voor de rest niets extra's mee gedaan (op wat cosmetische aanpassingen na misschien). Dat een bedrijf als RedHat waar vele duizenden mensen werken zegt goh, leuk dat je dat doet en zo maar deze mensen werken hier niet voor niets is niet zo heel erg gek natuurlijk.

Dat er heel erg veel distro's zijn die helemaal geen geld rekenen is ook niet zo gek omdat de meeste distro's nu eenmaal in essentie uit de hand gelopen hobby projecten zijn veel al van een flinke groep mensen in wisselende samenstelling. Voor zulke distro's is geld verdienen met de hobby geen optie omdat men moeilijk fatsoenlijke betrouwbare support kan leveren want iedereen die aan de distro werkt doet dat in de vrije tijd en kan morgen zo maar stoppen zonder dat er noodzakelijkerwijs een vervanger gevonden kan worden want geen inkomsten en dus is het geluk hebben als een ander het werk over kan en wil nemen zo niet is het niet geheel ongewoon dat een distro sterft omdat een of twee van de drijvende krachten achter de distro simpel weg niet meer genoeg tijd heeft.
Met RedHat koop je als een bedrijf de zekerheid dat de distro blijft bestaan en dat er altijd iemand is die support kan leveren als je tegen een probleem aanloopt en dat is voor veel bedrijven erg belangrijk. Deze bedrijven vinden het echt niet erg als de source code niet langer beschikbaar is zonder te betalen ze betalen toch voor de support dus de sources zijn in hun ogen gewoon gratis en er veranderd niets dus de userbase van RedHat zal hier echt niet van wakker liggen.

De mensen die roepen het is tegen de geest van open source die moeten toch de GPL licentie maar eens lezen want open source is niet gratis per definitie. De sources moeten gedeeld worden met de gebruikers van de software en dat is precies wat RedHat doet. Al is het misschien niet geheel zo als veel mensen dat graag zouden zien de klanten van RedHat hebben er echt geen moeite mee en dat is de enige groep die RedHat tevreden wil houden.

[Vorlayn]

Als beheerder van +/- 350 AlmaLinux-vms bij 1 van mijn klanten zojuist in samenspraak met de klant besloten maar over te gaan op Ubuntu Server LTS. Wordt een redelijk herschrijfklusje van de SaltStack om de uitrol aan te passen maar dit gaat nog een flink staartje krijgen (verwacht ik) en daar zitten EL-gebruikers niet op te wachten. Dit is na de plotselinge stop van CentOS 8 de tweede plaagactie vanuit RedHat, we hebben hier geen zin om de volgende af te wachten.

Gezien RedHat ook, zonder betaling, de software van vele duizenden niet- RH developers gebruikt in hun OS vind ik hun stelling nogal...apart, maar hey, hun bedrijf hun beslissing.

[Bulkzooi]

Decoy.. De hete brei betreft natuurlijk Oracle.

Leuk hoor zo'n nieuw Linux desktopje, één van de duizenden, maar het bedrijf met €50 miljard omzet waar dezelfde problematiek op van toepassing is, is natuurlijk relevanter.

[Reactie gewijzigd door Bulkzooi op 22 juli 2024 16:49]

[nzbee]

één van de duizenden

Niet een van de duizenden, maar eentje uit een zeer kleine groep van RHEL klonen, samen met AlmaLinux en Oracle Linux. En ze zitten alledrie in hetzelfde schuitje, waarbij Oracle natuurlijk wel de partij is die er een leger advocaten tegenaan kan gooien...

[Bulkzooi]

Niet een van de duizenden, maar eentje uit een zeer kleine groep van RHEL klonen, samen met AlmaLinux en Oracle Linux. En ze zitten alledrie in hetzelfde schuitje, waarbij Oracle natuurlijk wel de partij is die er een leger advocaten tegenaan kan gooien...

Mijn punt is niet het clonen van RHEL, hoewel ik me bewust ben van de RHEL history, maar dat Oracle geen nietszeggend Linux desktopje zoals AlmaLinux is.

Tech historie is hartstikke leuk, maar de discussies worden dus gestuurd richting de 4th Wave Linux Desktop, waarvan er duizenden, zo niet miljoenen, zijn. Oracle is een database giant.

Vandaar, decoy. En dat leger advocaten is niet nodig; die piekten juist voordat dit naar buiten kwam en die gaan deze zaak rustig in den minne settlen als het stof is opgetrokken. En daarna hervatten de advo's het golven.

[Reactie gewijzigd door Bulkzooi op 22 juli 2024 16:49]

[nzbee]

maar de discussies worden dus gestuurd richting de 4th Wave Linux Desktop

Vergeef mijn onwetendheid, maar de link die je legt tussen "desktop" en RHEL(-klonen) snap ik niet.

[fastedje]

Inderdaad RHEL is een prima server distro, maar als desktop blijft het altijd behelpen.

[WhatsappHack]

AlmaLinux wordt vooral gebruikt op servers en is daar intussen behoorlijk populair, een groeiend deel van de shared hosting industrie gaat of is er ook op over en zodra CentOS 7 geheel EOL is zullen er waarschijnlijk nog veel meer volgen. Dat of Rocky. Het is apart om het dan weg te zetten als irrelevant desktop OS, of all things.

[z1rconium]

Of Rocky, die hadden net een support contract met NASA getekend.

Uiteindelijk is dit voor heel het eco-systeem slecht. EL werd voor veel zaken gebruikt - dat zit nu achter een account want niet iedereen wil (Debian/Ubuntu hebben dat immers ook niet), dus zal er minder vanuit community worden bijgedragen en er zullen zeker enterprises markt onderzoek gaan doen naar alternatieven, dit kost RH meer dan het gaat opleveren in de longterm.

Leesvoer aanrader.

[BvdW1978]

Vergeet Amazon niet. Amazon Linux is ook een "rebuilder".