SUSE gaat Red Hat Enterprise Linux forken na toegangsrestricties broncode

SUSE gaat Red Hat Enterprise Linux forken en zelf een RHEL-compatibele Linux-distributie ontwikkelen en onderhouden. Deze distributie moet vrij toegankelijk worden zonder beperkingen. Het bedrijf wil de komende jaren tien miljoen dollar in het project investeren.

SUSE zegt in een blogpost dat het 'is toegewijd' om samen met de opensourcegemeenschap een compatibel RHEL-alternatief te ontwikkelen voor RHEL- en CentOS-gebruikers. Het bedrijf gaat de momenteel daarvoor publiek beschikbare versie van RHEL forken en zelf doorontwikkelen. Het bedrijf wil die code bijdragen aan een opensourcestichting, die doorlopend en gratis toegang moet bieden tot de broncode van het project. SUSE meldt niet welke stichting dat betreft. Het softwarebedrijf blijft tegelijkertijd investeren in zijn andere distro's, zoals SUSE Linux Enterprise en openSUSE.

De zet van SUSE is een reactie op een eerdere aankondiging van Red Hat. Het bedrijf zei vorige maand dat het de RHEL-broncode niet meer algemeen openbaar beschikbaar maakt, maar alleen nog aanbiedt aan Red Hat Enterprise-klanten. Daarmee is CentOS Stream, de ontwikkelbranche van RHEL, nog de enige publiek beschikbare repository waar de broncode wordt gepubliceerd.

Verschillende alternatieve Linux-distributies maken gebruik van RHEL, zoals Rocky Linux en AlmaLinux. Hoewel zij de broncode kunnen bemachtigen met een Red Hat-licentie, wordt herdistributie onder die licentieovereenkomst beperkt. Rocky Linux zei eerder overigens al dat het denkt dat de beslissing geen grote gevolgen heeft voor de toekomst van het besturingssysteem. De makers van die distro zeggen de RHEL-broncode via andere methodes te kunnen verkrijgen.

Red Hat ontving na zijn aankondiging kritiek van meerdere partijen. Onder meer Oracle uitte kritiek op Red Hat. In een blogpost zei dat bedrijf eerder deze week dat Red Hat-moederbedrijf IBM hiermee de concurrentie probeert te elimineren. Het bedrijf zei toen dat de broncode van zijn eigen distro, Oracle Linux, vrij beschikbaar blijft. Red Hat zelf zei vorige maand dat het zich blijft inzetten voor opensourcesoftware, maar het bedrijf gaat het beleid niet veranderen.

Reacties (106)

[jj71]

Red Hat zelf zei vorige maand dat het zich blijft inzetten voor opensourcesoftware, maar het bedrijf gaat het beleid niet veranderen.

Dat kunnen ze wel zeggen, maar ze gedragen zich niet als een opensource vriendelijk bedrijf.

Het is irritant dat ze niet alleen source code maar ook documentatie van hun producten en vragen en antwoorden verstoppen achter paywalls. Daar heb ik als ontwikkelaar die voor klanten gebruik maakt van Red Hat producten zoals JBoss en OpenShift last van. We hebben bijvoorbeeld wel eens meegemaakt dat we last hadden van een bug. Daar was dan op de website van Red Hat wel iets over te vinden, maar daar mocht je alleen maar bij als je een enterprise account had...

Het verstoppen van source code en documentatie achter paywalls is lijnrecht tegen het idee van opensource in, dus wat mij betreft is Red Hat niet een bedrijf wat zich oprecht inzet voor opensource.

[moredruid]

Ik heb zo'n hekel aan dit soort reacties, FOSS ≠ gratis.

Als je als bedrijf (je schrijft "we", vandaar die aanname) geld verdient aan producten die op RedHat (en specifieke RedHat extra software) draaien dan mag RedHat toch wel van je verwachten dat je op z'n minst één licentie afneemt (ruwweg € 800/jaar) zodat jij je klanten goed kan ondersteunen.

RedHat heeft zich (zeker voor ze werden opgekocht door IBM) altijd als open source vriendelijk bedrijf gedragen. Ze staan al jaren in de top 10 linux kernel contributors; de laatste jaren is het wel minder maar dat komt vooral doordat andere bedrijven (eindelijk) zijn gaan bijdragen. Al die contributions zijn voor iedereen beschikbaar.

Voor wat betreft de paywalls, zie mijn punt hierboven voor het afnemen van een licentie, en anders: een individual RedHat developer subscription is gratis, je krijgt toegang tot alle software en documentatie. RedHat Bugzilla is volgens mij altijd open geweest, workarounds of oplossingen worden soms inderdaad achter de paywall "verstopt".

Wil je dat niet, kun je voor de RedHat produkten overstappen naar Fedora, daar is alles helemaal gratis. En heb je dus ook alleen community support.

Typisch dat mensen vinden dat naast het gratis aanbieden van het produkt, de support, updates, bugfixes, feature requests etc. ook maar gratis moeten zijn maar daarnaast vinden dat zij er wel geld op mogen verdienen.

/rantmode uit

[magician2000]

Heb je ooit zaken gedaan met Red Hat? Als ik je relaas lees dan denk ik van niet.

Het bedrijf Red Hat is een complete ramp. Een (kleine) individuele klant interesseren ze zich absoluut niet voor. Dat heb ik persoonlijk mogen ondervinden. Dat was een aantal jaar geleden. Maar alles wat ik hoor, is het sindsdien enkel slechter geworden op dat vlak.

Nee, Red Hat blijf ik ver vandaan. Ik vertrouw ze absoluut niet meer.

[moredruid]

Jazeker wel, maar wel vanuit een internationaal bekende enterprise IT partner en een enterprise klant.

Ik weet niet over welk deel van hun dienstverlening je ervaring zo slecht is, als het om licentiedeals gaat vrees ik dat het bij Microsoft of Oracle niet beter is dan bij Redhat/IBM.

Als het gaat om support, dan heb ik daar alleen maar goede ervaringen mee (ik heb het dan over de gewone 1e en 2e lijns die je helpt bij een ticket dat is aangemeld op hun website, we hadden alleen dedicated support als we een consultant van hun lieten overkomen). Dat was wel een aantal jaren geleden, mogelijk is het sindsdien minder geworden.

[TijnC]

Als jij voor jouw klant gebruik maakt van Red Hat producten, dan kan die klant aan alle documentatie etc. Wat is dan het probleem?

Jij kan trouwens ook een gratis developer account nemen. Kan je ook overal aan.

[HollowGamer]

Ik weet niet of het goed of slecht nieuws is.
Het probleem met forks, is dat ze net weer allemaal anders zijn en ook developers splitten in groepen.

Tot nu toe hebben we het best veel gezien in de Linux/opensource wereld:
- OpenOffice vs LibreOffice
- MySQL vs MariaDB
- Qt (KDE gaat forken)
- ..

En zijn vast meer voorbeelden te verzinnen, maar het forken levert wel problemen op.
Wat als developers weglopen? Of zoiets hebben van, ja leuk Linux, maar dan liever Apple/MS, ook die hebben tegenwoordig opensource spul.

Verder draai ik Fedora, om weer over te stappen naar iets anders, zie ik niet zo zitten.
Het heeft juist alles wat ik nodig heb, tenzij SUSE/IBM hetzelfde gaan aanbieden (zoals Fedora Silverblue/coreOS).

Bij Canonical blijf ik liever weg. Ze houden zich (helemaal) niet aan standaarden, en hun projecten sterven allemaal in vroege dood. Maar om nu te zeggen dat Oracle een betere partij is.. erg jammer van RH. Misschien die CEO eruit gooien en iemand aannemen die geen stomme beslissingen neemt?

[The Zep Man]

Tot nu toe is de angst voor 'forks are bad' ongegrond gebleken. Het bestaande project of een fork daarvan wordt de de facto standaard, en men gaat weer over tot de orde van de dag.

De mogelijkheid om forks te maken heeft in het verleden meer voordelen dan nadelen opgeleverd.

OpenOffice.org -> LibreOffice: veel snellere ontwikkeling.

MySQL -> MariaDB: houdt Oracle 'eerlijk', en stelt men in staat om van Oracle af te stappen.

ownCloud -> Nextcloud: meer ruimte voor het vrije karakter van het product, geen afgescheiden functionaliteit voor een betaalde 'enterprise'-versie meer, etc.

OpenELEC -> LibreELEC: afgepslitst vanwege gebrekkig leiderschap bij OpenELEC.

Er zijn ook zat voorbeelden van dat forks niet overleven. Daar is niets mis mee. Dan stap je over op wat wel overleeft.

[Reactie gewijzigd door The Zep Man op 28 juli 2024 21:23]

[HollowGamer]

Dat is wel een goed punt.

Bedoel als je kijkt naar LibreOffice, dan zie je dat die veel eerder waren met stappen zoals minder leunen op Java.

Bij MySQL/MariaDB ligt dat net wat anders. Er zitten namelijk verschillen in de engine. Bijvoorbeeld: bij MySQL heb je echt een JSON-column, terwijl MariaDB daarvoor gewoon TEXT gebruikt. Ook de opties daarin zijn anders. MariaDB gaat ook anders om met innoDB. Het werkt ongeveer allemaal hetzelfde, maar als developer kun je dus niet zomaar uitgaan dat iets van MySQL ook in MariaDB zit (of andersom). Overigens ben ik een groot fan van MariaDB, maar wilde gewoon het verschil aangeven.

Het 'gevaar' is dus dat je niet zomaar kan overstappen van project X naar fork Y. Er zullen vast migratie-scripts zijn, maar dan nog heb je zoals eerder aangeven, last van feature X/Y of bug daar.

Zeg niet dat dit voor elk project geld, maar ik kan mij niet voorstellen dat ik Fedora Silverblue zou kunnen 'upgraden' naar 'Oracle Silverblue' - om maar iets te noemen. Voor mij als developer, maar ook als user, is dat niet erg prettig. Het kost tijd, en in het bedrijfsleven dus geld. Blijven hangen kan ook niet, want bij MySQL zie je ook hoe mensen daar van afstappen of zelfs niet meer ondersteunen.

Ik vraag mij ook echt af wat mensen nu vinden van iets als Rocky OS. Dat zal nog wel leunen op RHEL, maar als een grote groep dat niet meer interessant vindt, dan mag je dus weer overstappen naar iets anders (terwijl je net naar Rocky OS bent overgestapt).

Geef de developers niet de schuld, maar de beleidbepalers bij RH.

[Reactie gewijzigd door HollowGamer op 28 juli 2024 21:23]

[The Zep Man]

Bedoel als je kijkt naar LibreOffice, dan zie je dat die veel eerder waren met stappen zoals minder leunen op Java.

Dat was een gevolg van de keuze. Maar ook de ontwikkeling in het algemeen, zoals compatibiliteit. Dat nam een vogelvlucht, terwijl het onder Apache jarenlang stil lag.

Bij MySQL/MariaDB ligt dat net wat anders. Er zitten namelijk verschillen in de engine. Bijvoorbeeld: bij MySQL heb je echt een JSON-column, terwijl MariaDB daarvoor gewoon TEXT gebruikt. Ook de opties daarin zijn anders. MariaDB gaat ook anders om met innoDB. Het werkt ongeveer allemaal hetzelfde, maar als developer kun je dus niet zomaar uitgaan dat iets van MySQL ook in MariaDB zit (of andersom). Overigens ben ik een groot fan van MariaDB, maar wilde gewoon het verschil aangeven.

Als ontwikkelaar hoor je ook abstract om te gaan met je databaselaag. Ik zou zelf nooit een JSON-specifieke kolom gebruiken. Dat leunt te veel op de functie van een enkele DBMS.

Het 'gevaar' is dus dat je niet zomaar kan overstappen van project X naar fork Y. Er zullen vast migratie-scripts zijn, maar dan nog heb je zoals eerder aangeven, last van feature X/Y of bug daar.

Dat gevaar heb je zelf in de hand. Het ligt eraan hoe je ontwikkelt.

Zeg niet dat dit voor elk project geld, maar ik kan mij niet voorstellen dat ik Fedora Silverblue zou kunnen 'upgraden' naar 'Oracle Silverblue' - om maar iets te noemen. Voor mij als developer, maar ook als user, is dat niet erg prettig. Het kost tijd, en in het bedrijfsleven dus geld. Blijven hangen kan ook niet, want bij MySQL zie je ook hoe mensen daar van afstappen of zelfs niet meer ondersteunen.

Soms kosten dingen geld. Als bedrijf moet je dan maar betalen.

Geef de developers niet de schuld, maar de beleidbepalers bij RH.

Ik kijk naar Red Hat als een enkele entiteit. Het staat bij mij nu op dezelfde lijst als bijvoorbeeld Citrix en Oracle: open source bad faith actor, vermijden wanneer het kan.

[HollowGamer]

Als ontwikkelaar hoor je ook abstract om te gaan met je databaselaag. Ik zou zelf nooit een JSON-specifieke kolom gebruiken. Dat leunt te veel op de functie van een enkele DBMS.

Het is heel normaal om types in je database te gebruiken hoor.

Het voordeel is namelijk dat je dus JSON_EXTRACT, etc. kan doen, en niet voor alles een koppel tabel hoeft te maken. Verder is JSON gewoon prima, daar hoef je niet weer iets apart voor te gebruiken in mijn ogen.

Dat gevaar heb je zelf in de hand. Het ligt eraan hoe je ontwikkelt.

Zeg je dat ook tegen de beheerders die juist allemaal overstapte op iets als CentOS, en vertrouwde op goede (langer termijn) support?

Je richt het OS ook in voor die software bijvoorbeeld. Je weet dat je bij CentOS meer kiest voor stable, dus je software zal ook meer op dat leunen. *Het kan anders, maar veel bedrijven werken zo.

Soms kosten dingen geld. Als bedrijf moet je dan maar betalen.

Of je zegt, weg met Linux en opensource, we gaan wel naar iets dat langer ondersteuning heeft.
Je moet er toch niet aan denken dat die mensen overstappen naar een partij als Oracle bijvoorbeeld?

Ik kijk naar Red Hat als een enkele entiteit. Het staat bij mij nu op dezelfde lijst als bijvoorbeeld Citrix en Oracle: open source bad faith actor, vermijden wanneer het kan.

Ik vind het een moeilijke, aangezien RH altijd veel heeft gedaan en nog altijd doet voor Linux.
Hun RHEL repo is nu closed, maar nog altijd dragen ze veel bij aan de kernel, Gnome, etc.

Bij Oracle heb ik meer het gevoel dat ze geld willen verdienen, dan RH (al begin ik nu ook te twijfelen).

[leonbong]

Oracle, die zijn zelf heel soepel met licenties.
Je krijgt altijd een keurige brief of je even onmiddellijk wil betalen, want anders zien we je bij de rechtbank.

Met vriendelijke groet,
Oracle
Ik snap niet dat dat bedrijf überhaupt nog nieuwe klanten krijgt.

[The Zep Man]

Zeg je dat ook tegen de beheerders die juist allemaal overstapte op iets als CentOS, en vertrouwde op goede (langer termijn) support?

Ik had het over ontwikkeling, niet beheer. Ik zeg niets tegen die beheerders, want de eisen en wensen van elke beheerder (en de business die daarachter zit) zullen anders zijn.

Je richt het OS ook in voor die software bijvoorbeeld. Je weet dat je bij CentOS meer kiest voor stable, dus je software zal ook meer op dat leunen. *Het kan anders, maar veel bedrijven werken zo.

Ondernemen is risico's nemen.

Of je zegt, weg met Linux en opensource, we gaan wel naar iets dat langer ondersteuning heeft.

Dat zeg ik niet, maar ook dat kan een organisatie overwegen.

Je moet er toch niet aan denken dat die mensen overstappen naar een partij als Oracle bijvoorbeeld?

Dat is een eigen keuze. Er waren ook bedrijven die ooit volop ingezet hadden op SCO UNIX. Iedereen heeft recht op diens eigen portie ellende.

Ik vind het een moeilijke, aangezien RH altijd veel heeft gedaan en nog altijd doet voor Linux.
Hun RHEL repo is nu closed, maar nog altijd dragen ze veel bij aan de kernel, Gnome, etc.

Vrijwillige bijdragen onder open licenties in open repositories worden gewaardeerd, maar verder is het bedrijf bij mij afgeschreven. Dat is echter enkel bij mij zo.

Bij Oracle heb ik meer het gevoel dat ze geld willen verdienen, dan RH (al begin ik nu ook te twijfelen).

Beide organisaties zijn beursgenoteerd, en daarom kan je gekke sprongen verwachten. Geld verdienen is namelijk aan het einde van de dag altijd het belangrijkste voor dergelijke organisaties. Red Hat's aandelen stortte sinds het begin van Q2 behoorlijk in, dus ook binnen die organisatie zal het er onstuimig aan toegaan (met dit soort beslissingen als gevolg).

[Reactie gewijzigd door The Zep Man op 28 juli 2024 21:23]

[Cilph]

Als ontwikkelaar hoor je ook abstract om te gaan met je databaselaag. Ik zou zelf nooit een JSON-specifieke kolom gebruiken. Dat leunt te veel op de functie van een enkele DBMS.

Nou ja, je zou moeten ontwikkelen dat overstappen van database lichte moeite is, niet nul moeite. Je kan prima database specifieke features gebruiken als je een mooie abstractielaag hebt. De SQL standaard heeft bijvoorbeeld pas recentelijk JSON support gekregen.

[bzuidgeest]

Oracle SQL, postgresql, mysql etc etc.... Ze hebben allemaal een json type (of minsten json query mogelijkheden, sql server, mariadb) met bijbehorende optimalisaties en ondersteuning.
Het is al lang niet meer enkele db. En als er al geen standaardisatie voor is dan komt die wel voor SQL,

We leven in een tijd van "document" storage en hiërarchische data. JSON plat slaan is in veel gevallen gewoon inefficiënt. Zeker als het "document" alleen als geheel word gebruikt. Als je het dan platslaat in de db doe je twee conversies voor niets.

JSON kolommen niet gebruiken als je ze tot je beschikking hebt, is gewoon jezelf in de vingers snijden.

[xFeverr]

[...]
Als ontwikkelaar hoor je ook abstract om te gaan met je databaselaag. Ik zou zelf nooit een JSON-specifieke kolom gebruiken. Dat leunt te veel op de functie van een enkele DBMS.
[...]

Dat kun je toch ook gewoon weg abstraheren? Dan kun je de JSON-specifieke functies gebruiken van je DBMS als ze er zjin, en anders doe je het gewoon lekker met text als ze er niet zijn. Als je er zo in staat dan haal je nooit een voordeel uit het kiezen voor een specifiek DBMS en altijd de nadelen van het DBMS dat geen van de functies heeft.

[84hannes]

OpenOffice.org (...)
MySQL (...)
ownCloud (...)
OpenELEC (...)

Ik weet dat je niet probeert een uitputtende lijst te maken, maar ik vind toch dat xfree86 genoemd mag worden. In 2002/2003 was er wat ontevredenheid binnen het core team, een grote groep ontwikkelaars stapte over naar X.org, en sindsdien heb ik de term xfree86 alleen nog in historisch perspectief gezien.

[novasurp]

De OpenDocument-standaard heeft zijn kans op mainstream worden compleet vergooid met de onnodige splitsing tussen OpenOffice en LibreOffice (puur gedaan omdat de LibreOffice ontwikkelaars geen Apache-licentie wilden gebruiken). OpenOffice is nog steeds bekender, ondanks dat het heel ver achter loopt.

[xajac]

Voor Red Hat inc is dit juist de beste oplossing.


Ze !ossen het probleem op van mee-eters die niet willen betalen.

[supersnathan94]

Het probleem is dat Red hat hier het randje van de licentie opzoekt.

De licentievoorwaarden stellen dat de source beschikbaar moet zijn, maar er is nooit gespecificeerd dat dit niet tegen betaling mag zijn. Red Hat leunt zelf ontzettend op bijdragen van anderen. Uiteraard hebben ze zelf ook veel zaken toegevoegd, maar in de basis is het natuurlijk wel vrij toegankelijke software en broncode.

Het grote punt van Open source is dan ook dat we met z’n allen bijdragen leveren om het product beter te maken. Beetje quid pro quo. Dat RH dan nu besluit haar broncode tegen betaling beschikbaar te stellen druist wel tegen dat gedachtegoed in.

[The Zep Man]

De licentievoorwaarden stellen dat de source beschikbaar moet zijn, maar er is nooit gespecificeerd dat dit niet tegen betaling mag zijn.

Wel is in de GPL gespecificeerd dat bij het verplicht delen van broncode geen andere beperkingen opgelegd mogen worden. Of Red Hat hiermee de licentie overtreedt moet in de rechtszaal uitgevochten worden, maar netjes lijkt mij anders.

Dat RH dan nu besluit haar broncode tegen betaling beschikbaar te stellen druist wel tegen dat gedachtegoed in.

Het probleem is niet dat RH tegen betaling het product en daarmee de broncode beschikbaar stelt, maar dat Red Hat de licentie intrekt als klanten de broncode weer verder delen (gratis of anders).

[The Zep Man]

Ze !ossen het probleem op van mee-eters die niet willen betalen.

Behalve dat Red Hat weer onbetaald mee-eet van anderen. Dus 'het probleem' (welk probleem?) bestaat nog steeds.

[Reactie gewijzigd door The Zep Man op 28 juli 2024 21:23]

[brecht_vb]

Is er ergens te traceren wat RH en anderen contribute?

[ViPER_DMRT]

https://www.redhat.com/en...gram-office/contributions

They bring a lot, a lot.

[moredruid]

LWN heeft hier wel een (redelijk recent) artikel over: Development statistics for the 6.1 kernel (and beyond)
https://lwn.net/Articles/915435/

[PureTryOut]

Wat? KDE gaat niet Qt forken lol. Ik ben nu onderweg naar Akademy en spreek daar veel KDE ontwikkelaars, daar zijn echt geen plannen voor.

Of je moet doelen op de Qt 5.15 patchset, maar dat valt echt geen fork te noemen.

[blorf]

Het is mij onduidelijk wat dat zou moeten betekenen. Hoe moet je dat zien? Ik heb beide geinstalleerd (FreeBSD) voor de programma's die er iets van nodig hebben. Qt is vermoed ik als dependency van Transmission geinstalleerd, en ik vind Konsole af en toe wel bruikbaar.
De gebruikte schijfruimte en bandbreedte om het te downloaden is te verwaarlozen. Geen hele desktop, overigens. Een kale X met openbox.

Wel een mooie ontwikkeling. Volgens mij moeten ze bij Red Hat even door krijgen dat hun actie averechts gaat werken. Wie gaat het zo nog proberen?

[84hannes]

Ik was ook even geschrokken, maar met een beetje creativiteit zou je van een Qt5-fork voor maintenance-doeleinden kunnen spreken. Niets om van wakker te liggen dus.

[kalikari]

Er zijn ook voorbeelden waarbij de fork juist weer na verloop van tijd terug komt en zo verbeteringen hebben toegevoegd.

Zo was er onenigheid binnen het gcc project. Dat heeft geresulteerd in het egcs project. Dit was de compiler die je wilde gebruiken ipv gcc. Jaren later zijn ze weer gemerged.

https://gcc.gnu.org/news/announcement.html
https://www.lrde.epita.fr...prog2/History-of-GCC.html

Iets vergelijkbaars met OpenWRT. De afsplitsing LEDE heeft een tijdje als fork van OpenWRT bestaan en verloop van tijd zijn weg weer terug gevonden naar het OpenWRT project.

https://openwrt.org/about

Dit zijn twee voorbeelden van een fork door onenigheid over de richting van een project die uiteindelijk weer terug mergen. Mening verschillen zijn dan bijgelegd en de positieve dingen uit de fork komen in het oorspronkelijke project. Hier wordt dan iedereen beter van. Dat is de kracht van open source.

[Skender]

Heb je meer info over die KDE fork van Qt?
KDE heeft eigen patches voor Qt5, omdat Qt5 end of life is, maar de huidige KDE release er nog gebruik van maakt. Maar dat is tijdelijk, want de main branch is intussen al volledig overgeschakeld op Qt6, en ik vind niets terug over een KDE fork van Qt6...

[HollowGamer]

Ook @PureTryOut - Beetje een ongelukkige woordkeuze wellicht, maar in mijn ogen ben je wel een fork, als je op een basis zelf patches gaat doen:
https://www.phoronix.com/news/KDE-Qt-5-Patch-Collection
https://community.kde.org/Qt5PatchCollection

"We only include patches that have been approved upstream in the Qt project. If a patch cannot be merged upstream for technical reasons (e.g. the class no longer exists), it can also be merged."

Dat betekent dus dat in hun 'fork' andere classes/code kan zitten. Het is niet hetzelfde, en dus kun je gewoon spreken van een fork (in mijn ogen). Een patchset is iets wat je op bestaande code doet, maar hier lijkt echt een repo te zijn van Qt5.

Ze willen uiteindelijk volledig overstappen naar Qt6, maar het had niet veel gescheeld of er was een echte fork gekomen. Vergeet niet dat Qt redelijk wat backslash heeft gehad, en daarop weer zaken heeft aangepast.

[Reactie gewijzigd door HollowGamer op 28 juli 2024 21:23]

[devices]

Verder draai ik Fedora, om weer over te stappen naar iets anders, zie ik niet zo zitten.
Het heeft juist alles wat ik nodig heb, tenzij SUSE/IBM hetzelfde gaan aanbieden (zoals Fedora Silverblue/coreOS).

Waarom zou SUSE dit aanbieden? Fedora is upstream van Red Hat en niet andersom. Ik zie geen reden waarom ze Fedora zouden willen aanbieden. Dan zouden ze ook CentOS stream moeten aanbieden?

[CAPSLOCK2000]

[quote]
Ik weet niet of het goed of slecht nieuws is.

Tot nu toe hebben we het best veel gezien in de Linux/opensource wereld:
- OpenOffice vs LibreOffice
- MySQL vs MariaDB
- Qt (KDE gaat forken)
- ..

Gezien al Linux al meer dan 30 jaar bestaat vind ik dat helemaal niet veel forks. Er zijn er inderdaad meer, maar forks zijn juist behoorlijk zeldzaam. Als ze voorkomen is het overigens meestal omdat de oorspronkelijke ontwikkelaar is weggevallen en iemand anders het stokje overneemt.
Of QT echt door KDE geforked word moeten we nog zien, dat hebben we wel vaker gehoord maar dusver is het toch steeds weer goedgekomen.
Het komt veel vaker voor dat projecten er ofwel mee stoppen, of wel het werk van een ander project dunnetjes over doen. Misschien ook wel goed om even te vermelden is dat forken van closed source software in praktijk niet mogelijk is en dit verschijnsel dus niet voorkomt bij closed source partijen. Die richten een heel nieuw bedrijf op en beginnen van voren af aan opnieuw. Dat is nog veel verspillender (wat ik zelf overigens niet als probleem zie maar als deel van het evolutionaire proces waar op termijn alles beter van wordt).

En zijn vast meer voorbeelden te verzinnen, maar het forken levert wel problemen op.
Wat als developers weglopen? Of zoiets hebben van, ja leuk Linux, maar dan liever Apple/MS, ook die hebben tegenwoordig opensource spul.

Kun je een concreet geval noemen waarin dit een probleem was? (Buiten een libc incidentje in de vorige eeuw). In de voorbeelden die je geeft is het overigens juist de commerciele leverancier die dwars ligt waardoor de community weinig keuze heeft anders dan te forken. Over het algemeen heeft niemand daar zin in. In eigenlijk alle gevallen die ik ken is er vrij snel gekozen voor de ene of de andere tak, meestal is er eigenlijk weinig keuze. Ik denk dat het hier ook zo zal gaan (voor RHEL is dat slecht niet).

Bij Canonical blijf ik liever weg. Ze houden zich (helemaal) niet aan standaarden, en hun projecten sterven allemaal in vroege dood. Maar om nu te zeggen dat Oracle een betere partij is.. erg jammer van RH.

Mijn indruk is dat RHEL het doet omdat Oracle zich als profiteur opstelt, maar helemaal kan ik de vinger er nog niet op leggen.

[Reactie gewijzigd door CAPSLOCK2000 op 28 juli 2024 21:23]

[wimdebok]

De omgang van IBM met Red Hat geeft andere bedrijven ook mogelijkheden, zoals Oracle en Suse, meeliften op, het kan lucratief zijn. Benieuwd hoe dat afloopt! Leuk initiatief.

Maar voor mij heeft het gedoe rond eerst Centos en nu met Rocky wel geleid tot het willen afstappen van de Red Hat - lookalikes en probeer nu thuis te raken in Debian.

In de loop der tijd, na in het begin ander Unix varianten, verzeild geraakt in de Red Hat achtigen. Veel grote organisaties maken hier gebruik van. Dus of het nu Centos is om je voor te bereiden op een Red Hat examen, het uitproberen van software en het draaien op de 'eigen' server. Ideaal. Het geintje met Centos, spelregels veranderen tijdens het spel, was al niet leuk nu het gedoe rond de sources.

Begrijp het niet erg, het is de manier om het woord van Red Hat te verspreiden, Red Hat verdient zijn geld met ondersteuning en zijn certificaten. Al zou je voor Red Hat IBM moeten schrijven.

Zoveel verschillen al die distributies niet, gebruik ze toch voor een beperkt aantal services en die draaien overal. Dus nu Debian. He waar zijn mijn logfiles gebleven? Ah, systemd de emacs onder de init systemen. Moet ik toch nog een beetje aan Red Hat denken.

[HollowGamer]

Oracle is niet een haar beter (helaas). Die hebben al het moois dat Sun ons ooit heeft gebracht, allemaal de nek omgedraaid (niet alles, maar genoeg).

Het staat distro's vrij om hun eigen init systeem te kiezen. De meeste zullen bij systemd zitten tegenwoordig, maar zoals je kunt lezen op Wikipedia, komt dit ook van een RH developer af.

Er zijn gewoon ontzettend veel Linux software/utils waarbij RH de lead in heeft genomen. Zonder RH hadden we nu geen mooie dingen gehad. Het is gewoon jammer dat er in de top dingen veranderd zijn.

[wimdebok]

Denk zomaar dat SunOS het eerste Unix systeem is waar ik ooit mee gewerkt heb, op Sparc workstations. Wist niet dat Oracle daar mee aan de rol is gegaan. Heb ook niet de illusie dat nu alle zegen van Oracle moet komen als het om Linux gaat.

Zeker, die ontwikkelaar heet Lennart Poettering. Het is aan Red Hat te danken dat systemd uiteindelijk in Linux is gekomen. Systemd is controversieel in de Linux gemeenschap. Wat zo is het wel, Red Hat is een belangrijke distributies. Het is natuurlijk nu IBM die de dienst uit maakt. Heb ook begrepen dat er aardig wat ontslsagen zijn gevallen bij Red Hat. Het zal de stemming er niet beter op maken.

[WOteB2]

Succes met Debian, ik werk er al jaren mee en kom er telkens weer op uit.
Op dit moment draai ik op een van de chromebooks (geflasht met MrChromebox) Endeavour OS (een Arch distro) want dit systeem is als enigste waar Debian niet lekker op draait. Maar verder draait alles hier op Debian.

[wimdebok]

Dank je, ben nu het wat aan het uitproberen op een VM, zie er heel mooi uit. Ooit in een verleden bij mijn eerste stapje op Linux gebied met Debian in de weer geweest om dat op vakkundige wijze om zeep te helpen.

Word altijd heel blij van Linux en het leuke aan Debian vind ik, naast echt een community distributie het is a la Python batteries included. Veel packages waar ik bij Centos/Rocky op zoek moest naar ander Repositories zitten hier allemaal in.

[moredruid]

Debian is zeker heel mooi en niet voor niets de "ouder" van heel veel spinoffs.

Niet alles zit in de standaard repo's, je zult in sommige gevallen ook contrib en non-free moeten enablen in je sources.list. Vergelijkbaar met de EPEL repo's van CentOS.

Een ander voordeel is dat heel veel tutorials van Ubuntu 1:1 overgenomen kunnen worden. Vroegah vond je nog veel RedHat/CentOS guides bij een simpele zoekactie in Google, maar tegenwoordig moet je eerst door 3-4 pagina's Ubuntu spul scrollen of het specifiek in je zoekactie meenemen.

[wimdebok]

Waar ik wat wegwijs in moet worden is apt vs yum, deb vs rpm. En hoe de installatie verloopt. Om nu te zien als ik in het begin voor gnome kies, je een compleet circus met spelletjes krijgen. Dat /var/log/messages niet aanwezg is. Syslog installeren of misschien beter, meer vertrouwd raken met systemd commando's.

Ben benieuwd voor welke extra's extra repo's nodig zijn. Kan denken aan Visual Code (die ik niet zag). Maar zag toch eel veel commando's waar je normaal gesproken een extra repo moet toevoegen. Wel leuk!

[moredruid]

Uhm /var/log/messages heb ik op debian nog nooit gemist Dat zou dan iets moeten zijn in de laatste release.

[edit]: verrek, da's inderdaad syslog geworden. /onder zijn steen vandaan kruipt.

[Reactie gewijzigd door moredruid op 28 juli 2024 21:23]

[wimdebok]

Ik kjk net op mijn rocky (rh 9.2) machine en daar is een logfile /var/log/messages waar systeemberichten in komen en, net hoe je het configureert ook berichten van andere toepassingen. Een tekst file. Net zoals je als servvices installeert nieuwe logfiles in eigen directories krijgt.

Op de Debian die ik installeer is die er niet. Net zoals het commando 'shutdown -r now' wat ik als sinds jaar en dag gebruik ook niet meer werkt. Macht der gewoonte.

Het is natuurlijk de bedoelding dat ik mijn systeem opnieuw opstart/stop via de gui of systemctl commando's en de logfiles bekijken via journalctl.

Dat is iets waar je even aan moet wennen bij de een ander systeem zoals Debian. Net even anders en ook wat wordt er wel en niet geinstalleerd bij een minimale install.

[Grimm]

Blijft grappig dat een minuscuul deel van de OS markt ...

Linux is het meest gebruikte OS ter wereld. Ook als je Android buiten beschouwing laat.

[pvdheu]

Inderdaad Android in deze vergelijking buiten beschouwing laten want Android mag dan gebaseerd zijn op een Linux Kernel, het is geen Linux OS.

En het meest gebruikte OS buiten android om is nog altijd Windows. De issue hier is niet of nauwelijks gerelateerd an de server markt, en ook daar is "Linux" alles behalve dominant sommige Linux varianten of op Linux gebaseerde oplossingen komen uiteraard heel veel voor, maar er is geen overheersende versie van "Linux". Dat was het punt in mijn originele post welke door de fanboiz al gedownvote is geworden uiteraard.

Linux is irrelevant in de consumer en desktop markt en daar zal geen verandering in komen. En het is in deze markt dat de meeste kritiek en gehuil te horen is. In de wereld van content creators die de beslissing van RH graag aangrijpen om kliks te krijgen omdat verder weinig of geen interesse is voor Linux, buiten de zeer kleine groep van prive gebruikers, in de desktop gerelateerd markt.

Linux is een uitstekend OS voor server gerelateerde toepassingen en hier zal de beslissing van RH geen of weinig impact hebben. In de desktop markt kan je alle mogelijke "maar als" en "dan toch" of Misschien" redenen bedenken, maar dit blijft een markt waar Linux geen rol speelt en dat geldt ook voor de games markt.

Deze ontwikkelingen laten ook weer eens zien dat de al ultra kleine markt waar Linux zich in bevind de fragmentatie tussen distros de situatie alleen maar nog minder relevant maakt. En hoezeer men hier ook zal proberen om te doen alsof dat niet zo is, gezien de bedenken van Linux nog altijd die mening heeft/deelt denk ik dat ik hier toch wel op het juiste spoor zit..

Maar deze reactie zal ook wel weer gedownvote worden want men zal liever de kop in het zand steken en doet alsof het niet wordt gepost dan dat met met feitelijk argumenten komt die het tegendeel bewijzen omdat die argumenten eenvoudigweg niet bestaan.

Klanten van RedHat die hun software commercieel/professioneel gebruiken hebben niet of nauwelijks gevolgen van deze verandering, de partijen die gratis op de eerste rang willen zitten zijn de schreeuwers hier. En ik denk dat het RH precies daarom te doen is, van de lastige groep gebruikers afkomen die een grote mond hebben maar effectief enkel geld kosten. Bij bedrijven als deze worden kleine klanten/gebruikers die een grote mond hebben effectief/op z'n best op een minimum effort ondersteund en als die klant wil gaan dan is dat maar zo, daar gaat niemand een boterham minder om eten, integendeel, de tijd die daarmee vrijkomt kan aan betalende grote klanten worden besteed.

Je kan het met die instelling niet eens zijn uiteraard, maar dat is wel hoe het in deze werkt. Het is ook waarom veel game studios zich niet aan Linux ondersteuning wagen, het kost enkel geld en de rompslomp is de handvol potentiele gebruikers niet waard.

[moredruid]

Linux is eigenlijk niet veel anders dan de kernel en de drivers om de hardware aan te sturen, een distributie (waar jij volgens mij op doelt) is Linux + een berg userland libraries en binaries volgens een bepaald systeem met een mooie sticker van een distro erop geplakt, en daar zijn er inderdaad heel veel (te veel) van.

Dat gezegd hebbende: Linux is wel het meeste gebruikte OS voor routers, security-camera's, NAS-en, raspberry pi's enz. en dat zijn een hele hoop apparaten, Daarnaast is het al jaren het dominante server OS, zelfs op Azure draait meer dan 50% van de systemen Linux. Dus in een absoluut aantal zou het zomaar heel dicht in de buurt kunnen komen van Windows of het zelfs overtreffen, alleen wordt dit niet zo gemeten (de meeste OS marktaandeel rapportages kijken naar browser client en zoals je zou verwachten zit die niet in een router of een security camera).

Linux is en wordt steeds relevanter in de consumer markt maar niet op het gebied van PC (wat een hard aflopende markt is door smartphones en tablets), denk aan smart devices zoals connected ovens, koelkasten, thermostaten en een hoop andere - al dan niet - IoT apparaten. Dat de markt voor Linux op PC miniem is ben ik zeker met je eens.

Voor wat betreft je mening over partijen die gratis willen meeliften: die deel ik volledig. FOSS ≠ gratis (zie mijn reactie op de 1e reactie).

Veel game studio's hoeven niet veel te doen voor de linux ondersteuning, dat doen degene die de engines schrijven wel (denk aan de Unreal engine). Vandaar dat Steam ook zoveel titels heeft met Linux ondersteuning, en hun Steamdeck ook op Linux draait.

[Grimm]

En het meest gebruikte OS buiten android om is nog altijd Windows.

Nee, dat is Linux. Wat jij waarschijnlijk bedoelt is het meest gebruikte desktop OS.
Dat is inderdaad windows. Maar als je dat bedoelde, dan moet je dat aangeven,
dat voorkomt spraakverwarring.

[crazyboy01]

Jij hebt duidelijk geen idee wat er speelt in de IT-wereld buiten de computers in je huis en misschien op kantoor, daar draait binnenshuis inderdaad vaak Windows, vooral omdat men dat gewend is. Waar het echte verhaal begint van de wereld van bv het internet, maak je 9/10 keer verbinding met Linux machines. Het internet draait daar letterlijk op. Daarbij draait het lichter, dus met goede gamesupport kun je zeker wel het optimale uit je games halen. Maar nogmaals, ook met dat soort opmerkingen: je bekijkt het vooral vanuit de kant van het desktopgebruik in je vrije tijd. Dan zit je onder dit soort artikelen fout, helemaal als het over Red Hat gaat dat al helemáál niets met thuisgebruik te maken heeft.

[pvdheu]

Deze issue treft de server/professionele/commerciële gebruikers niet of nauwelijks.

De aanname van wat ik wel of niet weet of in mijn mening meeneem is op zijn zachtst gezegd "typisch" en eerlijk gezegd, een deel van het probleem hier.

Zou Linux een goede basis zijn voor een vlotte en effectieve game omgeving? Absoluut.
Is Linux een geschikte kandidaat voor game support? Nee, de op zich al kleine doelgroep is zo gefragmenteerd en de onderlinge "gevechten" over wie de beste/snelste/meest open/minst "data verzamelend" is binnen deze kleine groep maakt het alleen maar erger. Er is geen "Linux" er zijn heel veel verschillende versies/implementaties/visies op/van Linux en verschillen zijn niet zelden zo aanzienlijk dat het een per distro behandeling vereist om ondersteuning te bieden.. En dat is simpelweg commercieel totaal niet interessant en zal enkel geld kosten.

"De fragmentatie van Linux is, specifiek in de desktop markt, de grootste vijand van Linux"
Niet mijn woorden/mening.. Ene Linus Torvald is die mening toebedeeld..

[crazyboy01]

Ik, en ik denk de rest hieronder ook, valt niet over je gehele comment maar vooral over

minuscuul deel van de OS markt

Ik ben het wel eens met de rest van wat je schrijft maar zelfs met je verdere uitleg is dit stukje zin gewoon ontzettend misplaatst.

[HollowGamer]

Linux is geen bodemloze put, sterker nog, ik verwacht een flinke groei.

Kijk voor de grap naar een land als China. Die willen steeds meer af van (illegale) Windows copies, en willen ook meer controle (minder VS), dus dan is een eigen Linux-distro geen slechte optie.

Verder hebben projecten als raspberry pi ook meegeholpen, en veel servers draaien toch echt Linux.
Dus wellicht kijk je met de verkeerde bril, en vergeet je hoeveel enterprises Linux gebruiken.

Oh, en over Valve.. vandaag was nog maar eens bevestigd in het review, dat hun OS, toch echt wel wat beter was voor een handheld, dan Windows 11.

[Reactie gewijzigd door HollowGamer op 28 juli 2024 21:23]

[Stry]

Hoe maak je duidelijk dat je eigenlijk geen flauw idee hebt waarover je praat...

[Verwijderd]

Waarom wil SuSE dit doen? Heel lief natuurlijk, maar het kost SuSE geld, en RedHat heeft minder kosten en herbevestigt dat zij de Standaard zijn.

[xajac]

Red hat heeft niet minder kosten.


Je kan straks niet meer simpelweg de broncode overnemen van Red hat, dat is verboden in de licentie, dus wilt SUSE een alternatief ontwikkelen op basis van de huidige broncode.

[z1rconium]

Dat kan wel, alleen sluiten ze dan je RH account af.

[HollowGamer]

Omdat het daarmee weer een groep developers + distro's kan binnenhalen.
Uiteindelijk levert (of denken ze) dat hun ook geld, mankracht, etc. op.

Verder snap ik even niet wat je bedoelt met RH en standaard?
Er is niet echt een standaard in de Linux-wereld (dat is een voordeel en nadeel tegelijk), dus RH bepaald de standaard(-set) niet.

[moredruid]

Veel corporates gaan wel voor RedHat ivm de support en eventuele licensing die anders geregeld moet worden met een 3e partij. Partijen zoals Oracle, IBM en Microsoft hebben cross-licensing deals en als je een produkt van hun gebruikt wat eventueel inbreuk pleegt op een van de patenten van die partijen ben je daarmee verschoond van een boete. Dat moet je anders allemaal zelf gaan regelen. Dat is hier in Europa iets minder van toepassing dan in de US, maar wel degelijk een issue als je wereldwijd opereert.

Voor wat betreft de (open) standaarden, daar zijn werkgroepen voor en RedHat is lid van heel veel van dit soort groepen. Wat je ook wel ziet is dat een bepaald produkt van bijvoorbeeld Oracle (java) de de-facto standaard is, maar dat door de draconische licensing van Oracle tegenwoordig openjdk de standaard is geworden.

We zullen zien of RedHat zich hiermee in de vingers snijdt. Ik denk het wel, hun marktaandeel zal denk ik afnemen omdat er geen "vrije" varianten meer gebruikt gaan worden. Als je dan toch voor "zonder support" moet gaan dan maakt je distro ook niet meer uit. En via de universiteiten komen er steeds meer mensen met Linux kennis op de markt, echter die zijn bijna allemaal gewend aan Ubuntu. Die je gratis kan downloaden en gebruiken en waarop je support kan kopen als je dat wil.

[Dark Angel 58]

Kan dit zomaar? Red Hat Linux distributie overnemen, forken, naam aanpassen en het gratis verspreiden?
Zijn er geen voorwaarden?

[Reactie gewijzigd door Dark Angel 58 op 28 juli 2024 21:23]

[Cilph]

Waarom niet? Open source licentie, en de punt waarvanaf ze forken was al gratis.

[Wraldpyk]

Hangt van het type Open Source licentie af natuurlijk, zo mag je bij MIT het zelfs verkopen of insluiten in betaalde software, maar er zijn ok licenties die her-distributie voorkomen.

Nu weet ik niet wat de betreffende licentie is, maar ik neem aan dat SUSE wel hun research gedaan heeft.

[xajac]

GPL

[michel1000]

Gebeurt bij Ubuntu (levert Canonical ook betaalde support bij) erg veel. Zelfs door bedrijven die daar indirect geld mee verdienen bv PopOS van System76.

[Reactie gewijzigd door michel1000 op 28 juli 2024 21:23]

[rbr320]

Gebeurt bij Ubuntu (levert Canonical ook betaalde support bij) erg veel. Zelfs door bedrijven die daar indirect geld mee verdienen bv PopOS van System76.

Die situatie is momenteel niet helemaal vergelijkbaar. PopOS gebruikt momenteel namelijk domweg de officiële repo's van Ubuntu en levert daarnaast nog een eigen repo (voorheen een ppa) mee waar hun eigen sausje in zit. Mocht Canonical echter ooit besluiten een soortgelijke stunt uit te halen als Red Hat heeft gedaan dan is het inderdaad een kwestie van forken en doorgaan.

[illum1n4ti]

Nou dat vind ik niet. Ubuntu Pro kan je alleen gebruiken achter betaal systeem waardoor ook Canonical jou 10 jaar support biedt.
Ik zie ook geen git van ubuntu pro. laten we appels met appels vergelijken

[ArawnofAnnwn]

Sterker nog, het is andersom eerder lastig. Of wat RH doet legaal is, door het te blokkeren, is de grote vraag. Nu ben ik zelf geen expert op het gebied van licenties, maar van wat ik begreep van andere die daar wel veel verstand van hebben, is het een lastige kwestie. Het zou goed kunnen dat RH dit in de toekomst mag gaan verdedigen voor de rechter. En nogmaals, ik ben geen expert, dit hoor ik weer van mensen die dat wel zijn. Wie zo'n rechtzaak wint, weet ik ook niet, als ze al genoeg geld bij elkaar kunnen krijgen om big blue aan te klagen.

[RoyD]

Eigen RedHat programma's in de distributie kunnen natuurlijk wel closed source worden.

[ArawnofAnnwn]

Dat opzich wel, de vraag is dan (geen idee) of de licentie zomaar veranderd mag worden

[Oon]

Absoluut! Alle code die is gecommit onder de oude licentie blijft bestaan onder de oude licentie. Nieuwe commits kunnen onder een nieuwe licentie, en ze kunnen de licentie aanpassen en een nieuwe repository hosten, maar als je al een kopie hebt met de oude licentie mag je die gewoon onder de oude licentie blijven gebruiken.
Dat is het hele mooie aan codelicenties, je kunt niet zomaar een open-source project closed-source maken, tenzij je een licentie hebt waarin dat expliciet staat beschreven. Als het jouw eigendom is en er geen toevoegingen van anderen of libraries met een andere licentie die het niet toestaat in zitten kun je wel toegang tot de broncode achter een betaalmuur stoppen of onmogelijk maken, maar een kopietje van de code die beschikbaar was onder een licentie die hergebruik toestaat blijft altijd legaal om te gebruiken.

[Gover]

Dat wordt dan fork nummertje 52 (+/- telfouten)

[YGDRASSIL]

Je neemt niet de distributie over. Je maakt een eigen repo op basis van een snapshot op een bepaald moment. Die repo gaat zelfstandig verder. De nieuwe repo moet wel voldoen aan de voorwaardes van de licentie van wat je forked.

[Killemov]

Het is eerder maar de vraag of het omgekeerde mag in deze situatie, open source closed maken. En wat is maakt RHEL eigenlijk RHEL? De kernel is sowieso open, dus wat tooling? Aparte move van SUSE, ik zou eerder de echt handige dingen in de eigen Enterprise versie integreren.

[xajac]

Het is geen closed source, klanten mogen de broncode inzien.


Volgens de GPL hoef je alleen de broncode beschikbaar te stellen voor klanten en mag je daarvoor een vergoeding vragen.

[Blokker_1999]

De vergoeding voor het inzien van de code mag onder GPL enkel dienen om de werkelijke kosten te dekken. Wat het voor RHEL mogelijk maakt om het echt achter een paywall te steken is dat niet alle software onder GPL valt, maar er ook andere licenties zijn die het wel mogelijk maken alsook natuurlijk die delen die ze zelf scrijven van hun OS, daar kunnen ze mee doen wat ze wensen.

[stuiterveer]

Wat het voor RHEL mogelijk maakt om het echt achter een paywall te steken is dat niet alle software onder GPL valt

Nu ben ik geen sysadmin en weet ik ook niet welke tiers aan beschikbaarheid er zijn qua source, maar dekt de GPL niet vooral het krijgen van de source voor iemand die het product zelf ook bezit? Dus zolang ze de broncode delen, ook al moet je daarvoor inloggen met een account die betaald heeft voor de distro, dan ben je in feite niet aan het betalen voor het krijgen van de broncode. Dan betaal je voor het gebruik van het OS zelf. Dus hoe ik het op dit moment verwerk is dat de broncode niet achter een extra paywall komt voor mensen die er, aan de hand van de licentie, recht op hebben. Is dit niet gewoon volledig correct qua afhandeling vanuit Red Hat, ook al vinden mensen het universeel een dick move?

[Reactie gewijzigd door stuiterveer op 28 juli 2024 21:23]

[supersnathan94]

Is dit niet gewoon volledig correct qua afhandeling vanuit Red Hat, ook al vinden mensen het universeel een dick move?

Ja. Helaas.

[nielsdc]

Ja, maar die klanten mogen de source code gewoon verder verspreiden volgens de GPL. RH wil dit voorkomen via de licentie voorwaarden (Als je de source code verspreid trekken we je licentie in). Het feit dat klanten de source code kunnen inzien betekend niet dat het open source is, daarvoor moet de source code ook vrij te distribueren zijn. ( zie https://opensource.org/osd/)

Dus inderdaad geen closed source, maar ook geen open source.

[35MHz OC]

Niet geheel. Je mag als abonnent van RHEL de source verder verspreiden volgens de geldende licenties. Echter beeindigd Red Hat dan je abonnement op RHEL volgens hun support voorwaarden. De restricties zitten dus niet op de software, maar op het RHEL abonnement. Dit is legaal, maar bij lange na niet compatible met de opvattingen van de FOSS gemeenschap.

[Game-Over]

Zelfde is eigenlijk gebeurt met Android.
Steeds meer closed source toevoegen. Gelijktijdig het open source deel vrijwel niet updaten.
Het resultaat is effectief closed source is geworden. Niet omdat het open deel closed is geworden maar omdat het open deel dusdanig ouderwets is dat het een alles of niets verhaal is geworden.
Het platform verlaten of de mix van open en closed aanvaarden.

[xajac]

Dat is het concept van linux. Bekijk de stamboom maar eens, bijna elke distro is gejat van een ander.

[HollowGamer]

Dat ligt aan de licentie van het project. In de meeste gevallen hebben deze een opensource license, en mag je dus deze forken, maar niet de trademarks gebruiken bijvoorbeeld.

Het probleem is dat sommige licenties best ingewikkeld zijn, maar gok dat er hier wel rekening mee is gehouden.

Je kan het eerder andersom draaien - waarom mag RHEL de source op slot gooien? Andere partijen en developers hebben hier direct/indirect aan mee gedaan. Zeg niet dat Red Hat niets gedaan heeft, wellicht het grootste (+ betaalde mensen), maar eigenlijk is het een wassenneus naar de developers toe.

[Dorank]

waarom mag RHEL de source op slot gooien?

Omdat dat toegestaan is. B.V. GPL staat dat gewoon toe, je hebt onder GPL alleen verplichtingen aan personen aan wie je iets beschikbaar stelt.

[Dorank]

Er zijn voorwaarden. Alles wat normaal in een distributie zit en wat niet geheel door RH is ontwikkeld onder een door hun zelf vastgelegde licentie, valt al onder een license die ervoor zorgt dat de software vrij beschikbaar is. Wellicht dat de installer alleen uit eigen code van RH bestaat, maar dat zou betekeken dat nieuwe versie onder een andere licentie zouden kunnen vallen. Aan de huidige versies kunnen ze niets meer veranderen.

[moredruid]

Door de manier waarop Rocky Linux dit doet lijkt dit legaal te kunnen. Meer info hier: https://rockylinux.org/news/keeping-open-source-open/

Ze nemen een RedHat instance af bij een cloud provider. Dan downloaden ze alle source packages (die aangeboden moeten worden want deels Open Source en anders vaak noodzakelijk voor development doeleinden) en daarvan bouwen ze hun eigen distro.

[xajac]

Wat hebben we hier aan? Hun versie zal uit de pas blijven lopen met red hat gezien ze de broncode niet legaal kunnen gebruiken voor hun eigen project.


Dan kun je net zo goed rocky of alma zelfstandig verder ontwikkelen.

[Maurits van Baerle]

Gokje, omdat je er bij SUSE wel een support contract op kunt krijgen en bij Rocky en Alma niet?

[Skender]

Dat kon al hé. Bij SUSE kun je support kopen voor CentOS en RHEL (naast uiteraard ook support voor SLE) https://www.suse.com/products/suse-liberty-linux/

[xajac]

Tegen betaling, als je dit professioneel nodig hebt met professionele support kun je net zo goed bij Red Hat blijven.

[Marve79]

Oracle die kritiek uit het moet niet gekker worden.

[beerse]

Zowel qua licentie politiek als ook als leverancier van OracleLinux, wat ook ooit als fork van RedHat is begonnen.

[leonbong]

Haha
Oracle het bedrijf dat elke klant financieel te grazen neemt, heeft commentaar.
Waarschijnlijk zijn ze boos dat ze het niet zelf hebben bedacht.

[Geekomatic]

Ehm, ik heb als IT manager een lijstje van 3 firma's,
waar ik nooit nieuwe contracten mee zal afsluiten,
en bestaand gebruik actief afbouw.
Vanwege dit soort embrace en dan lock-in praktijken met prijsverhogingen.
Dat lijstje is, in volgorde: Oracle, IBM, SAP.
.
Met Oracle zijn we maar ter nauwernood ontsnapt aan hun JDK praktijken.
"Gebruik je 1 (EEn) keer Oracle JDK in je bedrijf,
dan betaal je voor al je 1000-en werknemers een licentie."
We waren 'gelukkig' al een tijd bezig om naar OpenJDK over te gaan.
De overheid betaalt nu miljoenen voor dit grapje.
Wel ironisch dat Oracle in dit geval de vermoorde onschuld speelt.
.
IBM gaat dit ook doen met RHEL, is mijn stellige voorspelling...
De fork is dus zeker terecht , IMO.

[Reactie gewijzigd door Geekomatic op 28 juli 2024 21:23]

[wimdebok]

Veel bedrijven maken die keuze, voor de grote giganten, juist wel omdat ze bang zijn in geval van nood zonder ondersteuning te zitten. . Ik vind dat je gelijk hebt. Het kost natuurlijk allemaal een vermogen aan licenties. Zou wel benieuwd zijn welk bedrag bijvoorbeeld de overheid kwijt is aan licenties. Dit geldt niet alleen voor de overheid.

[himlims_]

SUSE vond/vind ik altijd beetje een vreemde eend in linux land. YAST YUM etc.
Onderaan de streep werk(te) het erg gebruiksvriendelijk. Mijn pa zit inmiddels al bijna 10jr op een Suse/Linux bak. (nadat zoveelste keer zijn windows omzeep geholpen had "klik maar een eind raak" kan nu wel)

ik krijg dat mijn pa niet uitgelegd; reclame, 'dames in de buurt' 'u heeft ene grote prijs gewonnen etc' en maar klikken.

Wanneer zijn linux bak echt op is, wordt het een chromebook voor hem : ) voor de meeste computer gebruikers doet men heden dag niet meer dan een browser openen. (misschien nog wat met fotos en lokaal text verwerken)

[Reactie gewijzigd door himlims_ op 28 juli 2024 21:23]

[HollowGamer]

Yes, dat is mijn ervaring ook met (Open)SUSE.

Je zit bij hun ook echt vast in het ecosysteem dat zei gebruiken. Dat geld ook voor RH-distro's hoor, maar bij SUSE heb ik dat altijd meer gevonden. Hun hele buildsysteem is bijvoorbeeld niets voor mij, en sommige keuzes zijn gewoon vreemd/ouderwets/traditioneel. Novell heeft er ook invloed op gehad, beetje een zelfde partij als IBM (meer traditioneel).

RH kiest doorgaans voor sneller nieuwe (unstable/unproven) features, zoals systemd, Gnome-Shell, etc. destijds. SUSE heeft iets als OpenSUSE Tumbleweed, maar dat is wel weer rolling (voor en nadelen).

Begrijp mij niet verkeerd, heb niets tegen SUSE, maar het is niet echt mijn go to distro.

[Reactie gewijzigd door HollowGamer op 28 juli 2024 21:23]

[himlims_]

ik kan het moeilijk uitleggen, verwoorden of uberhoubt aangeven waar 'dat' in zit.

suse werkte in mijn optie 'iets' anders dan de rest van linux land. zeg niet dat slecht is, maar .. anders

is nog uti de tijd dat ze toen met novell in zee zijn gegaan

[HollowGamer]

Yep, je haalt mij de woorden uit de mond.
Het is gewoon anders, beetje een vreemde eend, tussen de rest van de distro's.

Het is niet als Canonical (dat maar dingen doet), het is geen RH (dat van alles doet), en het is geen Oracle (dat niets gratis doet). Het lijkt me meer zoals gezegd, een soort IBM. Niet te gek, vasthouden aan wat we kennen, en langzaam meegroeien.

[dcm360]

RH kiest doorgaans voor sneller nieuwe (unstable/unproven) features, zoals systemd, Gnome-Shell, etc. destijds.

Uiteraard zijn de voorbeelden die je noemt eerder in RH terechtgekomen dan elders, want het zijn projecten van (of ondersteund door) RH.

SUSE heeft iets als OpenSUSE Tumbleweed, maar dat is wel weer rolling (voor en nadelen).

Wat ervaring betreft lijken Tumbleweed en Leap (de point release variant) elkaar niet eens zo ver te ontlopen. Grootste verschil is vooral dat ik nu wat vaker heb van 'hee, dit is nieuw'.

[WOteB2]

RH kiest doorgaans voor sneller nieuwe (unstable/unproven) features, zoals systemd, Gnome-Shell, etc. destijds. SUSE heeft iets als OpenSUSE Tumbleweed, maar dat is wel weer rolling (voor en nadelen).

Die Tumbleweed van OpenSUSE is een voorbeeld van hoe een rolling release goed werkt. Er worden pas nieuwe spullen in gestopt als het stabiel genoeg is. Heel betrouwbaar.
Ik heb het zelf ook een poos gedraaid op een test systeem.
Lijkt eigenlijk heel veel op Debian Testing qua betrouwbaarheid, ook stabiel genoeg om mee te werken.

[Kevjoe]

Ik zit ondertussen al enkele maanden op openSUSE Tumbleweed en het is oprecht de stabielste distributie die ik al gebruikt heb, letterlijk 0 issues.
Ik kan het niet genoeg aanraden.

[pixel]

ik neem aan dat je YAST2/zypper bedoeld?