15 ms·

Keeping Open Source Open

268 points by deafcalculus 3y ago

lxe 3y ago
What is RHEL compatibility so important and why is it always such a hot topic?
- geerlingguy 3y ago
  Red Hat is like the 10,000 pound gorilla in the world of Enterprise Linux, and traditionally has walked a fine line (well, mind you) in bringing open source to the table against enterprise proprietary vendors. Other open source competitors like SUSE and Canonical have much smaller revenues, so Red Hat could be seen as having a bit more influence over Linux's overall direction (they employ a ton of devs, they have a ton of resources). Case in point, the systemd controversy. There's also a historic argument that one cannot trust FOSS in the hands of any corporation, but we start getting into more philosophical and nearly-religious debate at that point.
  - mst 3y ago
    > Red Hat is like the 10,000 pound gorilla in the world of Enterprise Linux, and traditionally has walked a fine line (well, mind you) I'm not particularly fond of this latest move but I'm unconvinced they've fallen off the line yet. Even with this decision in place I believe that Red Hat will still be by far a net positive to have around for open source overall. They could change my mind about that, certainly, but they'd have to make a substantially more egregious move to do so.
- chronogram 3y ago
  Not RHEL compatibility, because that's what Stream also has, the bug-for-bug similar behaviour is wanted when you have RHEL servers but test on Centos without having to bother with licenses or terms.
  - piaste 3y ago
    If you have RHEL in production, you are already allowed to install it on test servers without restrictions. Or so I'm told.
geerlingguy 3y ago
It sounds like they have two different mechanisms they can pull from currently, which will get them to parity with RHEL releases. Red Hat would need to shift a few knobs and probably offend quite a few people running UBI images at least (including a zillion folks in the OpenShift community who rely on them) to cut off this current approach to getting the sources. I wonder if Red Hat is willing to play this game of whack a mole? And IMO, was it worth it?
- ss48 3y ago
  Could they not just leave these alternate channels a few weeks or months behind the current release that only the subscribers have access to? That would keep them as the most current, up-to-date source over Rocky Linux.
  - mst 3y ago
    "Approximately the same lag as you used to get with CentOS" would seem pretty fair to me - I'm aware people grumbled about it and understandably so, but it was still a relatively stable and relatively co-operative situation. I feel like returning to that apparent Schelling Point could quite easily be an improvement over the Red Queen's Race that I worry is developing here.
- soneil 3y ago
  > And IMO, was it worth it? I suspect they're playing with unintended consequences now. One of the nice "features" of buying CentOS, is that it meant CentOS was never going to compete - there was a clear line between community and professional, and CentOS were never going to sell you professional services. Pushing everyone to non-RH builds has removed that line, and there's a strong chance that non-RH builds selling professional services, is going to have a higher opportunity-cost than publishing CentOS did.
  - bonzini 3y ago
    That wasn't relevant in buying CentOS, plenty of people were selling personal services for CentOS. IBM itself was doing it, and perhaps Kyndryl is still doing the same for the newfangled RHEL rebuilds. And even now, technically RESF is the one producing the distro and it's also not selling professional services. Who produces the distro has no effect on who sells the services.
EvanAnderson 3y ago
Are the RHEL SRPMS watermarked for individual Customers in any way? It seems like Redhat has no mechanism to stop a torrent of the SRPMS showing-up. Attribution would be exceedingly difficult. Since distribution of FLOSS-licensed source isn’t copyright infringement it’s not like they could DMCA it away. Arguably the specfiles are able to be copyrighted. I wonder what the license is like for those.
- redundantly 3y ago
  > Are the RHEL SRPMS watermarked for individual Customers in any way? Highly unlikely. File hashing can be used to easily check for this.
  - Brian_K_White 3y ago
    Not no mention, source is text. Plain diff shows any differences. There is a lot of text, and so a lot of haystack to make small changes, but no way to hide them at all, and no way to break the product if the diffs are undiffed or further diffed to obscure the origin. RH can't actually do what their trying to do, but that's less important than the fact that they want to. I can't see voluntarily having anything to do with them now. I see no value in any product or service they might offer that is worth knowingly working with someone who has exposed such a lack of integrity.
fariszr 3y ago
> One option is through the usage of UBI container images which are based on RHEL and available from multiple online sources (including Docker Hub). Using the UBI image, it is easily possible to obtain Red Hat sources reliably and unencumbered. We have validated this through OCI (Open Container Initiative) containers and it works exactly as expected. > Another method that we will leverage is pay-per-use public cloud instances. With this, anyone can spin up RHEL images in the cloud and thus obtain the source code for all packages and errata. This is the easiest for us to scale as we can do all of this through CI pipelines, spinning up cloud images to obtain the sources via DNF, and post to our Git repositories automatically. That's quite the workaround, the rocky team has proven it's willing to get hacky if needed.
- Shakahs 3y ago
  The public cloud route is pretty elegant. Red Hat is restricting source code to subscribers only, so Rocky contributors will just subscribe for an hour at a time when they need to download source code. There’s no way for Red Hat to stop this without terminating all public cloud licensing everywhere.
  - dlor 3y ago
    I'm not a lawyer, but that's definitely not their only recourse here. Lawyers are not going to look at this coordinated attempt to subvert a EULA and say "oh well, nothing we can do here".
    - deleted 3y ago
      [deleted]
    - musicale 3y ago
      > I'm not a lawyer, but that's definitely not their only recourse here. Agreed - Rocky Linux probably has other options, but these seem like decent ones. > Lawyers are not going to look at this coordinated attempt to subvert a EULA and say "oh well, nothing we can do here". It does seem like Red Hat wants to subvert the GPL, but I'm not sure who would be suing them for doing so.
axus 3y ago
I was poking around the Rocky Linux website, and wondering where to download the latest source code for Rocky 9.2? Let's say IBM decides not to burn up the ecosystem, will Oracle / Alma start using the source that Rocky exfiltrates? Related question, as a Red Hat subscriber can I still distribute Red Hat ISO and source code? It seems like I should be able to distribute ISO images and source after obtaining them.. but not repackage it? I don't plan to impose any restrictions on the people I distribute to.
- EvanAnderson 3y ago
  Red Hat can't stop you from exercising your rights under the GPL to redistribute the code. You also can't compel them to do business with you. They've structured their support agreements such that if you do exercise your rights under the GPL they will stop supporting you (and decline to offer you future subscriptions). The value proposition for RHEL is ostensibly support (and a "throat to choke", for whatever that's actually worth). Red Hat's gamble is that no "legitimate" Red Hat subscriber would risk their support entitlement (and the ability to contract with Red Hat for support in the future) by exercising their rights under the GPL. It's a clever hack. It runs counter to ideals of Free software (and I find it personally repugnant) but it's clever.
  - Arnavion 3y ago
    To be clear, it's not yet known for certain if the chilling effect of a terminated contract violates the "no further restrictions" clause of the GPL or not. Evidently IBM's lawyers think it doesn't. But it would be good to test it in court first.
    - paulryanrogers 3y ago
      GRSecurity started down this road. IBM though has deeper pockets
      - bonzini 3y ago
        It's not grsecurity's idea, it started on the 90s when Spender was in kindergarten or so. It's always been the way free software companies made money.
m4r71n 3y ago
> "Consequently, we now have to gather the source code from multiple sources, including CentOS Stream, pristine upstream packages, and RHEL SRPMs." Oh no! How dare they make us do the work? It feels tiring to hear these arguments that they must be provided with everything bundled neatly with no questions asked and no contributions to the actual upstreams.
- djbusby 3y ago
  They arent asking to be handed everything - they've simply explained how the process has changed now. Complaining about change; and describing the steps that are being taken is far from saying they "must be provided with everything bundled neatly with no questions asked"
- nhanlon 3y ago
  Yeah, that's not what any of us are saying. We already _do_ a lot of work. This is _more_ work.
  - deleted 3y ago
    [deleted]
  - notacoward 3y ago
    So who should be doing that work? On whose payroll? Should Red Hat engineers be spending their time de-branding and wrapping things up neatly for rebuilders to use? Note that every minute they spend on that is a minute they're not spending on adding features, fixing bugs, or backporting fixes to the last ten years' worth of releases. You know, the things they're actually obligated to do by their contracts with customers. Why should they continue letting free work for non-contractual partners - who seem increasingly inclined to be competitors - displace or delay that? This is the rebuilders' burden, and always has been. It should be their engineers doing that work, just as with other open-source project. If you want to rebuild TensorFlow or React, slap on your own branding, maybe sell support or consulting for it or enable others[1] to do so, do you think those teams will go out of their way to repackage stuff for your convenience? That's above and beyond common open-source practice. Expecting Red Hat to continue going above and beyond forever just seems awfully entitled. [1] "Team members don't do X but sponsors do" deserves its own thread.
cosmiccatnap 3y ago
It's sad to see a post like this get so much hate in the comments section. We all benefit greatly from an organization maintaining a stable Linux ecosystem and the idea that somehow redhat isn't entitled to give back to Linux as much as they have benefited from OSS goes to show just how much coolaid HN has been drinking as of late. These corporate concerns are not some law of nature and it's up to us to support people when they are willing to fight for end consumers, something that modern redhat has all together abandoned
- bonzini 3y ago
  > somehow redhat isn't entitled to give back to Linux So it's not enough to employ more than 1000 people working on upstream/Fedora/CentOS Stream, have a strict upstream first policy for features that go into RHEL and their other products, donate to a bunch of foundations and sponsor conferences, maintain the main repository of firmware updates for Linux, be consistently in the top three contributors to Linux, open source pretty much all the closed source code that they get from acquisitions, distribute source also when not required by the license, give away two distributions for free, and possibly more things I don't remember? Good to know, at least they tried.
  - isignal 3y ago
    It would make sense if they started out building a proprietary os (for which, btw, the count of people you mentioned is not enough, Microsoft employs vastly more people). If they contribute to open source projects and then cry for compensation, it makes no sense. They can expect compensation for services sure, but not for their open source contribution code. Those are the rules they are playing by. Not to mention that there’s vastly many more contributors who aren’t getting compensated.
  - jrm4 3y ago
    No. No it isn't. If you know the history, if you know the license, then you know the philosophy that you're taking from. I don't think they're evil, but the people who did the early work getting this started did so with one level of expectation, and this is a different one. You get no love, Red Hat.
fomine3 3y ago
Next: Add --accept-redhat-eula flag
- AlotOfReading 3y ago
  I'm not a copyright expert, but I'm pretty sure that'd run afoul of the "you may not impose any further restrictions" clause of GPL. Being able to modify and redistribute the source is the whole point.
  - fomine3 3y ago
    I see. So even RH blocked access to their srpm repository by any way, it's not about GPL. Finally RH needs to block providing binary by EULA but it will be annoying for evaluation and container.
ivolimmen 3y ago
May I remind everyone that these weird steps that the open source community is doing are not the result of Redhat per se but are a result of IBM that wants his investment back.
- Stranger43 3y ago
  They are the same entity now that's kind of what happens when a company gets merged into another company. It's also what a lot of people expected would happen when IBM bought RedHat and the whole centos-stream debarcle happened and i suspect a lot of what were seeing is that IBM/RedHat(can we start calling them big purple now) is not seeing the growth to RHEL sales they were expecting from those changes/decisions, or might even seeing a decline in greenfield deployments of RHEL.
indymike 3y ago
I really hope sanity breaks out at Red Hat.
Brian_K_White 3y ago
If RedHad don't like what Centos (of old) does, then why do they still insist on mooching off of GPL software? If they don't accept the terms of GPL, good news! They don't have to use it! Surely such hard working and deserving guys could write their own software and sell it honestly without needing to debase themselves by stealing from filthy hippies.
newaccount74 3y ago
> Moreover, Red Hat’s Terms of Service (TOS) and End User License Agreements (EULA) impose conditions that attempt to hinder legitimate customers from exercising their rights as guaranteed by the GPL. Does someone have more details on this?
- geerlingguy 3y ago
  I wrote this a couple days ago, sums it up: https://www.jeffgeerling.com/blog/2023/gplv2-red-hat-and-you https://www.jeffgeerling.com/blog/2023/gplv2-red-hat-and-you tl;dr - GPLv2 requires no restriction on free/paid recipients of binaries to also freely redistribute source code. Red Hat EULA says your subscription will be canceled if you redistribute the source code. Is that a restriction? A couple OSS laywers I spoke to said no. Common sense says it feels an awful lot like intimidation to effectively keep their product proprietary (what Fortune 500 company would like to have their Red Hat servers all go dead because some employee downloaded sources and uploaded them somewhere?)
  - smarx007 3y ago
    But they do make all of that source code available under CentOS Stream. GPL does not require an SLA for providing source code of all bugfixes and security patches free of charge in under 24h. Just embargoing security patches for 1-2 weeks from Stream would be a good enough move for RH to signal to enterprise customers that Rocky/Alma are not a drop-in gratis replacement for RHEL in production systems.
    - smarx007 3y ago
      I think what RH did is ethically questionable but is a great development for the use of GPL in the enterprise (for releasing SW under GPL that would otherwise remain closed-source): there is now a path for respecting GPL freedoms (in a slightly round-about way) without necessarily making the product gratis.
    - geerlingguy 3y ago
      The GPL requires all source code be available including the scripts and glue code required to build the binary alongside the source. You can't pull a Stream and offer "most" of the source, but not the source required to rebuild the latest stable release. That's counter to the spirit and the letter of GPLv2. Legally speaking, the contract vs copyright issue is the only ground Red Hat has to stand on here.
khanan 3y ago
When I was at IBM and RedHat did the "CentOS"-move, IBM-execs was actually pretty pissed off. It was bad optics and RedHat did it on their own, while IBM got "the blame". This is probably more of the same stuff. They think they can get away with being asshats and people will just blame IBM. We see you, RedHat. You are NOT on the right path.
Jedd 3y ago
Free. That word does not appear at all in TFA. In the IBM/RH blog post it references[1] the word appears once, disparagingly, in the gratis sense. I appreciate the beer / speech distinction can get tiring to explain repeatedly, but it feels like the move to distance themselves from the deeper implications & obligations of free is, shall we say, very carefully calculated. [1] https://www.redhat.com/en/blog/red-hats-commitment-open-source-response-gitcentosorg-changes https://www.redhat.com/en/blog/red-hats-commitment-open-sour...
- dogben 3y ago
  This makes me feel very uncomfortable.
- mst 3y ago
  Could equally be a move to minimise how much of the discussion that springs up around this blog post gets derailed and eaten alive by arguments and/or misunderstandings around said distinction. Though I suspect we'll both end up less wrong by filing our theories under 'guesswork' and seeing what the actual state of play is six months from now.
WesolyKubeczek 3y ago
There’s one thing I don’t understand. They keep saying GPL this, GPL that. Meanwhile there has been this huge push to use permissive licenses for like two decades now, because GPL bad (you don’t have to go far, just look at any discussion around licensing here on HN). There’s nothing in .spec files that says they have the same license as the software they cover. Fedora contributions are required to come with a MIT-like license. So you have quite a small core of software under GPL — the kernel, glibc, coreutils, gcc, binutils, make… and not even the darling of security advisories, OpenSSL. Thanks to incessant corporate PR against GPL, the GPL-based software base is shrinking slowly but steadily. That Rust-based coreutils replacement? MIT.
- voxadam 3y ago
  Is an RPM spec file even copyrightable? It's pretty much the definition of tabular data akin to a simple recipe or a phonebook, neither of which are subject to copyright under US law as I understand things. I'm also not convinced that a spec file would satisfy the "threshold of originality" to make it copyrightable.
- throw_a_grenade 3y ago
  No, it's the other way around: GPL requires that all pieces required to compile the binary (the exact binary that triggers requirement for distributing source) needs to come along. IIUC if they distribute source as SRPMs, the .spec needs to be included and without limitations (legal or technical) that would prevent user from rebuilding the original software.
  - WesolyKubeczek 3y ago
    Well, nothing prevents you from rebuilding the upstream tarball, or tarball with RH's patches applied even, using upstream's instructions. Doesn't have to be the identical RPM package, does it? I don't really know how this might or might not work. My gut says that since the .spec is meaningless without the sources, it's a Modification of the work and thus the spec, patches, and the resulting SRPM is definitely a Derived Work. But every time anything quasi-legal is being brought up here or anywhere else, it gets drowned in the arguments over what the meaning of the word "is" is, so I don't know how you can twist it, legally. But then, the elephant in the room is that IBM may decide to give away only the GPLed SRPMs, and say a big fuck you to anything more permissive. People rallying against copyleft have made quite an impact, and the GPLed landscape is shrinking.
kazinator 3y ago
On another topic, we can finally see the motivation behind those SRPMs. The whole purpose of a SRPM is to take some upstream source code and repackage it into a different archive blob which has to be downloaded in its entirety and unpacked in order to determine whether any of the code is patched, or pure upstream. If, instead of a SRPM, you have some small, declarative text file which gives upstream URLs, SHA256 digests and build config steps, then that tiny declarative text file is all that someone needs from you to clone that package in their own distro, exactly The amount of material needed to repro your whole distro goes something like from gigabytes to megabytes. I mean, think about it. There is such a little declarative piece there in the process: the RPM spec file. Now, normally we think about building binaries from sources. But under RPM, you "build" source packages too! It's an obfuscation step intended to make people dependent on your way of handling sources.
- bonzini 3y ago
  What an idiocy. SRPMs can be used offline. The GPL requires the complete corresponding sources so you have to include the upstream sources anyway together with the binary RPMs; might as well bundle them in one file so you can share the metadata format between sources and binaries built from them. What you mention ("upstream URLs, SHA256 hashes" plus the content of the spec file) is exactly what you find on git.centos.org. Besides the main design of RPMs dates back to 1990. I suspect there was no conspiracy to hide SRPMs from Rocky Linux back then.
- deleted 3y ago
  [deleted]
- veeti 3y ago
  Or the SRPM was designed 30 years ago when people didn't have always online high speed connectivity.
  - cesarb 3y ago
    > when people didn't have always online high speed connectivity Or any connectivity at all! Back then, it was not unusual for Linux distributions (which came in CDs) to have both one or more "binaries" CDs and one or more "sources" CDs. One distribution which kept that tradition is Debian: you can download at https://cdimage.debian.org/debian-cd/current/source/iso-dvd/ https://cdimage.debian.org/debian-cd/current/source/iso-dvd/ a complete set of 19 DVDs containing the source code for all packages, and at https://cdimage.debian.org/debian-cd/current/amd64/jigdo-dvd/ https://cdimage.debian.org/debian-cd/current/amd64/jigdo-dvd... metadata to create a complete set of 21 DVDs containing all the binary packages for the x86-64 architecture.
mrweasel 3y ago
What exactly prevents Red Hat from adding one or more proprietary components, like a RHEL bootloader, or network manager and simply refusing to share the code for those components? If Red Hat doesn't back down, I don't see anyway around Rocky, Oracle and Alma doing a fork.
- toyg 3y ago
  They can't easily do that without really risking to break the gpl. Btw, Rocky, Oracle and Alma cannot fork; their entire value proposition is being RH-compatible. What could happen is a new giant trying to displace RH as the reference Linux platform, poaching significant amounts of devs from RH. That would require years and billions of dollars though.
  - mrweasel 3y ago
    > They can't easily do that without really risking to break the gpl. Why wouldn't they be able to do that? Sure, they can't patch the kernel or any of the existing stuff, but what would prevent them from writing a Grub replacement or a Red Hat shell? It has to be free of GPL code, but the operating system as a whole isn't what's under the GPL, it's the individual components, some of which aren't GPL, but BSD, MIT, ISC or some other licens.
    - rushikesh90 3y ago
      The whole point of selling RHEL is everything is coming from community and open source and they are making money only for support. If they start closing even a bit of software, they will loose customers to other enterprises like Microsoft
    - toyg 3y ago
      Red hat does a lot of work in kernel, subsystems, and libraries, where linking is necessary. They can, more or less, happily ignore the legal landscape as long as they stay open, because those licenses are interoperable; the minute they started closing things, they would have to pay a lot of attention not to break gpl constraints.
jillesvangurp 3y ago
The solution here is forking and accepting that IBM just doesn't want to share. The whole value of the Red Hat eco system is lots of people using the down stream variants. Actual direct licensees of Red Hat are not where most of the action is. The value creation is actually distributed across the ecosystem. People encounter issues, report them, and fixes are distributed. If you break that cycle and get IBM out of the loop, the process just continues elsewhere. The vast majority of that ecosystem does not pay IBM a single dollar and probably never will. IBM is a company that is in slow decline, so the remaining Red Hat employees are facing an extended period of that company just squeezing harder and harder until nothing remains. It's death by a thousand cuts. But the bottom line is that a lot of people doing the hard work of committing actual code on behalf of the ecosystem that are currently employed there will be facing endless rounds layoffs, reorganizations, restructurings, etc. If there isn't an employee exodus happening there already, that might soon start to happen. The only question is where those people will end up. A well funded foundation maintaining the fork of the distribution formerly known as Red Hat could be a nice destination for such people. Between Amazon, Oracle, and the countless users of Rocky, Alma, Centos, Fedora, etc. there should be plenty of brain power, motivation, and money to make that happen. They need a stable foundation. They don't need IBM to be part of that. Don't play IBM's game on their terms. Just cut them loose. They get to do whatever they want downstream, not upstream. And they get to contribute all their fixes under GPL. That's not optional. This foundation would be free to use these fixes as they need to. Comparability with IBM's downstream distribution should not be a goal for this foundation. And if IBM wants to pretend they can do it all by themselves, they are more than welcome to try. My prediction is that if the big supporters of this ecosystem join forces and do this, IBM will grumble a bit and then ultimately join the foundation because their alternative will be just writing off the investment they made in Red Hat and watch from the sidelines how most of the ecosystem stops depending on IBM's Red Hat.
- bonzini 3y ago
  > IBM will grumble a bit and then ultimately join the foundation because their alternative will be just writing off the investment they made in Red Hat and watch from the sidelines how most of the ecosystem stops depending on IBM's Red Hat. You could have said that if they switched to using CentOS Stream, and that would even have been my favorite outcome as a Red Hat employee. However, Rocky Linux is neither a sibling nor a fork of RHEL. It's a debranded clone that by definition cannot even have a single bugfix that isn't in RHEL. For Oracle it's okay because it's peanut money in order to annoy Red Hat, so they can afford this; for Amazon or Facebook it's no good and that's why they forked upstream at the Fedora or CentOS Stream level. As long as Rocky Linux stays a RHEL rebuild built by a third party like the CentOS of 2010 (except backed by corporate money rather than a guy in Nebraska), Red Hat is already putting millions into "the foundation". That's what they pay for the thousand people that develop Rocky Linux, ahem RHEL. Without them, there can be no Rocky Linux at all. So, as long as Rocky's money making side keeps undermining Red Hat's money making side, game theory predicts no other outcome than death for both RHEL and Rocky. _EDIT_: if you downvote, I'd be very glad to learn where I'm wrong
giamma 3y ago
So long "Upstream First" principle https://github.com/RedHatOfficial/open-source-participation-guidelines https://github.com/RedHatOfficial/open-source-participation-...
- worthless-trash 3y ago
  This is not at all in conflict with the upstream first, if so please tell me how you see it being in conflict.
  - giamma 3y ago
    The blog post says: "Previously, we obtained the source code for Rocky Linux exclusively from the CentOS Git repository as they recommended. However, this repository no longer hosts all of the versions corresponding to RHEL. Consequently, we now have to gather the source code from multiple sources, including CentOS Stream, pristine upstream packages, and RHEL SRPMs." Why would you need RHEL SRPMS if the upstream packages contained all the patches and why refer to them as "pristine upstream packages" in the first place?
    - happymellon 3y ago
      That's not "upstream first". They are going upstream because of a zero day patch that RedHat have, and is also upstreamed. Hence why they are going upstream, to get the upstreamed patch that CentOS has not merged yet. So your entire argument appears to be that RedHat are doing upstream first.
    - mst 3y ago
      I believe that currently RH send a patch to the upstream project, then apply/backport it to CentOS Stream, then if they consider it appropriate apply/backport that to RHEL, and it's the first step there being their first step that's the 'upstream first' part. The additional hassle Rocky are having is that since Stream is ahead of RHEL divining whether the third step was taken and if so with what, if any, backporting tweaks required, is rather trickier so to recreate the end result of all such third steps to get an identical (bar debranding) set of SRPMs to the ones used by RHEL your best approach has become to source the various bits of information you need to do that from multiple places. Also I -suspect- the 'pristine upstream packages' thing is referring to the fact that most package formats, rpm definitely included, prefer to have an untouched copy of the upstream sources plus a stack of patches in their source packages and combine them during package build for both clarity and debuggability reasons.
DeathArrow 3y ago
>Every user of Rocky Linux is valued and their contributions matter. That's very wrong. It's not Linux, it's GNU/Linux. [0] [0] https://www.gnu.org/gnu/linux-and-gnu.html https://www.gnu.org/gnu/linux-and-gnu.html
znpy 3y ago
Friendly reminder that not all open source licenses are as reassuring as the gpl is. Keep that in mind next time you make an open source contribution (and maybe sign off copyright) to a repository that is not protected by the gpl license.
gigatexal 3y ago
I originally had a strong anti-RedHat response to this change. When I thought about it and heard RH's response their sharp change makes sense. They sell RHEL. It's from what I gather their main source of income. Revenue from this funds things like SystemD, a lot of work in Gnome, many many things that RHEL customers and other users of Linux and desktop Linux benefit from. Of course many contributions to open source/GNU tools come from folks in no way affiliated or paid by RH and RH does use these packages but RH also provides a lot of value. So it stands to reason, to me at least, that to allow anyone to reskin/respin/or basically just ship a RHEL clone without RH branding that is "100% bug/binary compatible with RHEL" just without the license cost is giving away something you work on for free. No rational business would allow this. CentOS, Fedora are free. RHEL is not. Makes sense.
- toyg 3y ago
  How did they survive and thrive for 25+ years then? Rebuilders have always existed. They've just dialled the "greed" knob a bit higher, that's all.
  - gigatexal 3y ago
    I don't know for sure but if I had to guess early Linux some 25-years ago didn't have the prevalence of polish it has now at least on the desktop. In the server space it was probably solid. That being said businesses back then were likely leery of running a RH clone with just some Linux staff -- better to pay RH for support. Nowadays one could probably lean on staff to manage issues and arbitrage that go-it-alone mindset over paying the RH subscription. Now that loop-hole is closed.
  - mst 3y ago
    Historically they've generally politely ignored community rebuilders and got a trifle enervated by commercial rebuilders - they changed how they handled distributing kernel code (to a fully patched tree rather than a pristine tree and a stack of patches I -think- from memory) in response to Oracle doing a commercial rebuild. Exactly what the triggering incident was this time they've been very careful not to officially say (which is likely a better option than the optics of getting into a finger pointing war with a smaller target), and I suspect we won't be able to fully judge their motivations unless/until the details leak and/or are inferred by people close enough to the situation to guess correctly.
xinayder 3y ago
Watch IBM and RH publish changes to these features Rocky Linux will use to obtain the source, and effectively remove the "open source" part of it and violate the GPL.
lars_francke 3y ago
> One option is through the usage of UBI container images which are based on RHEL and available from multiple online sources (including Docker Hub). Using the UBI image, it is easily possible to obtain Red Hat sources reliably and unencumbered. We have validated this through OCI (Open Container Initiative) containers and it works exactly as expected. They have phrased this very carefully but there is a caveat here. UBI is using a small subset of RHEL packages. They say "possible to obtain Red Hat sources" and that's true, but you cannot - afaik - obtain all RHEL sources this way. This is not too important as they are using a different way to obtain the RHEL sources now. https://access.redhat.com/articles/4238681 https://access.redhat.com/articles/4238681
- captn3m0 3y ago
  Another similar question I have is around license requirements for various packages. How many of the packages in RHEL are actually GPL/copyleft, where RH must share sources? Could it decide to stop sharing source for non-copyleft packages next?

268 points by deafcalculus 3y ago

lxe 3y ago

What is RHEL compatibility so important and why is it always such a hot topic?

geerlingguy 3y ago
Red Hat is like the 10,000 pound gorilla in the world of Enterprise Linux, and traditionally has walked a fine line (well, mind you) in bringing open source to the table against enterprise proprietary vendors. Other open source competitors like SUSE and Canonical have much smaller revenues, so Red Hat could be seen as having a bit more influence over Linux's overall direction (they employ a ton of devs, they have a ton of resources). Case in point, the systemd controversy. There's also a historic argument that one cannot trust FOSS in the hands of any corporation, but we start getting into more philosophical and nearly-religious debate at that point.
- mst 3y ago
  > Red Hat is like the 10,000 pound gorilla in the world of Enterprise Linux, and traditionally has walked a fine line (well, mind you) I'm not particularly fond of this latest move but I'm unconvinced they've fallen off the line yet. Even with this decision in place I believe that Red Hat will still be by far a net positive to have around for open source overall. They could change my mind about that, certainly, but they'd have to make a substantially more egregious move to do so.
chronogram 3y ago
Not RHEL compatibility, because that's what Stream also has, the bug-for-bug similar behaviour is wanted when you have RHEL servers but test on Centos without having to bother with licenses or terms.
- piaste 3y ago
  If you have RHEL in production, you are already allowed to install it on test servers without restrictions. Or so I'm told.

geerlingguy 3y ago

It sounds like they have two different mechanisms they can pull from currently, which will get them to parity with RHEL releases. Red Hat would need to shift a few knobs and probably offend quite a few people running UBI images at least (including a zillion folks in the OpenShift community who rely on them) to cut off this current approach to getting the sources. I wonder if Red Hat is willing to play this game of whack a mole? And IMO, was it worth it?

ss48 3y ago
Could they not just leave these alternate channels a few weeks or months behind the current release that only the subscribers have access to? That would keep them as the most current, up-to-date source over Rocky Linux.
- mst 3y ago
  "Approximately the same lag as you used to get with CentOS" would seem pretty fair to me - I'm aware people grumbled about it and understandably so, but it was still a relatively stable and relatively co-operative situation. I feel like returning to that apparent Schelling Point could quite easily be an improvement over the Red Queen's Race that I worry is developing here.
soneil 3y ago
> And IMO, was it worth it? I suspect they're playing with unintended consequences now. One of the nice "features" of buying CentOS, is that it meant CentOS was never going to compete - there was a clear line between community and professional, and CentOS were never going to sell you professional services. Pushing everyone to non-RH builds has removed that line, and there's a strong chance that non-RH builds selling professional services, is going to have a higher opportunity-cost than publishing CentOS did.
- bonzini 3y ago
  That wasn't relevant in buying CentOS, plenty of people were selling personal services for CentOS. IBM itself was doing it, and perhaps Kyndryl is still doing the same for the newfangled RHEL rebuilds. And even now, technically RESF is the one producing the distro and it's also not selling professional services. Who produces the distro has no effect on who sells the services.

EvanAnderson 3y ago

Are the RHEL SRPMS watermarked for individual Customers in any way? It seems like Redhat has no mechanism to stop a torrent of the SRPMS showing-up. Attribution would be exceedingly difficult. Since distribution of FLOSS-licensed source isn’t copyright infringement it’s not like they could DMCA it away. Arguably the specfiles are able to be copyrighted. I wonder what the license is like for those.

redundantly 3y ago
> Are the RHEL SRPMS watermarked for individual Customers in any way? Highly unlikely. File hashing can be used to easily check for this.
- Brian_K_White 3y ago
  Not no mention, source is text. Plain diff shows any differences. There is a lot of text, and so a lot of haystack to make small changes, but no way to hide them at all, and no way to break the product if the diffs are undiffed or further diffed to obscure the origin. RH can't actually do what their trying to do, but that's less important than the fact that they want to. I can't see voluntarily having anything to do with them now. I see no value in any product or service they might offer that is worth knowingly working with someone who has exposed such a lack of integrity.

fariszr 3y ago

> One option is through the usage of UBI container images which are based on RHEL and available from multiple online sources (including Docker Hub). Using the UBI image, it is easily possible to obtain Red Hat sources reliably and unencumbered. We have validated this through OCI (Open Container Initiative) containers and it works exactly as expected. > Another method that we will leverage is pay-per-use public cloud instances. With this, anyone can spin up RHEL images in the cloud and thus obtain the source code for all packages and errata. This is the easiest for us to scale as we can do all of this through CI pipelines, spinning up cloud images to obtain the sources via DNF, and post to our Git repositories automatically. That's quite the workaround, the rocky team has proven it's willing to get hacky if needed.

Shakahs 3y ago
The public cloud route is pretty elegant. Red Hat is restricting source code to subscribers only, so Rocky contributors will just subscribe for an hour at a time when they need to download source code. There’s no way for Red Hat to stop this without terminating all public cloud licensing everywhere.
- dlor 3y ago
  I'm not a lawyer, but that's definitely not their only recourse here. Lawyers are not going to look at this coordinated attempt to subvert a EULA and say "oh well, nothing we can do here".
  - deleted 3y ago
    [deleted]
  - musicale 3y ago
    > I'm not a lawyer, but that's definitely not their only recourse here. Agreed - Rocky Linux probably has other options, but these seem like decent ones. > Lawyers are not going to look at this coordinated attempt to subvert a EULA and say "oh well, nothing we can do here". It does seem like Red Hat wants to subvert the GPL, but I'm not sure who would be suing them for doing so.

axus 3y ago

I was poking around the Rocky Linux website, and wondering where to download the latest source code for Rocky 9.2? Let's say IBM decides not to burn up the ecosystem, will Oracle / Alma start using the source that Rocky exfiltrates? Related question, as a Red Hat subscriber can I still distribute Red Hat ISO and source code? It seems like I should be able to distribute ISO images and source after obtaining them.. but not repackage it? I don't plan to impose any restrictions on the people I distribute to.

EvanAnderson 3y ago
Red Hat can't stop you from exercising your rights under the GPL to redistribute the code. You also can't compel them to do business with you. They've structured their support agreements such that if you do exercise your rights under the GPL they will stop supporting you (and decline to offer you future subscriptions). The value proposition for RHEL is ostensibly support (and a "throat to choke", for whatever that's actually worth). Red Hat's gamble is that no "legitimate" Red Hat subscriber would risk their support entitlement (and the ability to contract with Red Hat for support in the future) by exercising their rights under the GPL. It's a clever hack. It runs counter to ideals of Free software (and I find it personally repugnant) but it's clever.
- Arnavion 3y ago
  To be clear, it's not yet known for certain if the chilling effect of a terminated contract violates the "no further restrictions" clause of the GPL or not. Evidently IBM's lawyers think it doesn't. But it would be good to test it in court first.
  - paulryanrogers 3y ago
    GRSecurity started down this road. IBM though has deeper pockets
    - bonzini 3y ago
      It's not grsecurity's idea, it started on the 90s when Spender was in kindergarten or so. It's always been the way free software companies made money.

m4r71n 3y ago

> "Consequently, we now have to gather the source code from multiple sources, including CentOS Stream, pristine upstream packages, and RHEL SRPMs." Oh no! How dare they make us do the work? It feels tiring to hear these arguments that they must be provided with everything bundled neatly with no questions asked and no contributions to the actual upstreams.

djbusby 3y ago
They arent asking to be handed everything - they've simply explained how the process has changed now. Complaining about change; and describing the steps that are being taken is far from saying they "must be provided with everything bundled neatly with no questions asked"
nhanlon 3y ago
Yeah, that's not what any of us are saying. We already _do_ a lot of work. This is _more_ work.
- deleted 3y ago
  [deleted]
- notacoward 3y ago
  So who should be doing that work? On whose payroll? Should Red Hat engineers be spending their time de-branding and wrapping things up neatly for rebuilders to use? Note that every minute they spend on that is a minute they're not spending on adding features, fixing bugs, or backporting fixes to the last ten years' worth of releases. You know, the things they're actually obligated to do by their contracts with customers. Why should they continue letting free work for non-contractual partners - who seem increasingly inclined to be competitors - displace or delay that? This is the rebuilders' burden, and always has been. It should be their engineers doing that work, just as with other open-source project. If you want to rebuild TensorFlow or React, slap on your own branding, maybe sell support or consulting for it or enable others[1] to do so, do you think those teams will go out of their way to repackage stuff for your convenience? That's above and beyond common open-source practice. Expecting Red Hat to continue going above and beyond forever just seems awfully entitled. [1] "Team members don't do X but sponsors do" deserves its own thread.

cosmiccatnap 3y ago

It's sad to see a post like this get so much hate in the comments section. We all benefit greatly from an organization maintaining a stable Linux ecosystem and the idea that somehow redhat isn't entitled to give back to Linux as much as they have benefited from OSS goes to show just how much coolaid HN has been drinking as of late. These corporate concerns are not some law of nature and it's up to us to support people when they are willing to fight for end consumers, something that modern redhat has all together abandoned

bonzini 3y ago
> somehow redhat isn't entitled to give back to Linux So it's not enough to employ more than 1000 people working on upstream/Fedora/CentOS Stream, have a strict upstream first policy for features that go into RHEL and their other products, donate to a bunch of foundations and sponsor conferences, maintain the main repository of firmware updates for Linux, be consistently in the top three contributors to Linux, open source pretty much all the closed source code that they get from acquisitions, distribute source also when not required by the license, give away two distributions for free, and possibly more things I don't remember? Good to know, at least they tried.
- isignal 3y ago
  It would make sense if they started out building a proprietary os (for which, btw, the count of people you mentioned is not enough, Microsoft employs vastly more people). If they contribute to open source projects and then cry for compensation, it makes no sense. They can expect compensation for services sure, but not for their open source contribution code. Those are the rules they are playing by. Not to mention that there’s vastly many more contributors who aren’t getting compensated.
- jrm4 3y ago
  No. No it isn't. If you know the history, if you know the license, then you know the philosophy that you're taking from. I don't think they're evil, but the people who did the early work getting this started did so with one level of expectation, and this is a different one. You get no love, Red Hat.

fomine3 3y ago

Next: Add --accept-redhat-eula flag

AlotOfReading 3y ago
I'm not a copyright expert, but I'm pretty sure that'd run afoul of the "you may not impose any further restrictions" clause of GPL. Being able to modify and redistribute the source is the whole point.
- fomine3 3y ago
  I see. So even RH blocked access to their srpm repository by any way, it's not about GPL. Finally RH needs to block providing binary by EULA but it will be annoying for evaluation and container.

ivolimmen 3y ago

May I remind everyone that these weird steps that the open source community is doing are not the result of Redhat per se but are a result of IBM that wants his investment back.

Stranger43 3y ago
They are the same entity now that's kind of what happens when a company gets merged into another company. It's also what a lot of people expected would happen when IBM bought RedHat and the whole centos-stream debarcle happened and i suspect a lot of what were seeing is that IBM/RedHat(can we start calling them big purple now) is not seeing the growth to RHEL sales they were expecting from those changes/decisions, or might even seeing a decline in greenfield deployments of RHEL.

indymike 3y ago

I really hope sanity breaks out at Red Hat.

Brian_K_White 3y ago

If RedHad don't like what Centos (of old) does, then why do they still insist on mooching off of GPL software? If they don't accept the terms of GPL, good news! They don't have to use it! Surely such hard working and deserving guys could write their own software and sell it honestly without needing to debase themselves by stealing from filthy hippies.

newaccount74 3y ago

> Moreover, Red Hat’s Terms of Service (TOS) and End User License Agreements (EULA) impose conditions that attempt to hinder legitimate customers from exercising their rights as guaranteed by the GPL. Does someone have more details on this?

geerlingguy 3y ago
I wrote this a couple days ago, sums it up: https://www.jeffgeerling.com/blog/2023/gplv2-red-hat-and-you https://www.jeffgeerling.com/blog/2023/gplv2-red-hat-and-you tl;dr - GPLv2 requires no restriction on free/paid recipients of binaries to also freely redistribute source code. Red Hat EULA says your subscription will be canceled if you redistribute the source code. Is that a restriction? A couple OSS laywers I spoke to said no. Common sense says it feels an awful lot like intimidation to effectively keep their product proprietary (what Fortune 500 company would like to have their Red Hat servers all go dead because some employee downloaded sources and uploaded them somewhere?)
- smarx007 3y ago
  But they do make all of that source code available under CentOS Stream. GPL does not require an SLA for providing source code of all bugfixes and security patches free of charge in under 24h. Just embargoing security patches for 1-2 weeks from Stream would be a good enough move for RH to signal to enterprise customers that Rocky/Alma are not a drop-in gratis replacement for RHEL in production systems.
  - smarx007 3y ago
    I think what RH did is ethically questionable but is a great development for the use of GPL in the enterprise (for releasing SW under GPL that would otherwise remain closed-source): there is now a path for respecting GPL freedoms (in a slightly round-about way) without necessarily making the product gratis.
  - geerlingguy 3y ago
    The GPL requires all source code be available including the scripts and glue code required to build the binary alongside the source. You can't pull a Stream and offer "most" of the source, but not the source required to rebuild the latest stable release. That's counter to the spirit and the letter of GPLv2. Legally speaking, the contract vs copyright issue is the only ground Red Hat has to stand on here.

khanan 3y ago

When I was at IBM and RedHat did the "CentOS"-move, IBM-execs was actually pretty pissed off. It was bad optics and RedHat did it on their own, while IBM got "the blame". This is probably more of the same stuff. They think they can get away with being asshats and people will just blame IBM. We see you, RedHat. You are NOT on the right path.

Jedd 3y ago

Free. That word does not appear at all in TFA. In the IBM/RH blog post it references[1] the word appears once, disparagingly, in the gratis sense. I appreciate the beer / speech distinction can get tiring to explain repeatedly, but it feels like the move to distance themselves from the deeper implications & obligations of free is, shall we say, very carefully calculated. [1] https://www.redhat.com/en/blog/red-hats-commitment-open-source-response-gitcentosorg-changes https://www.redhat.com/en/blog/red-hats-commitment-open-sour...

dogben 3y ago
This makes me feel very uncomfortable.
mst 3y ago
Could equally be a move to minimise how much of the discussion that springs up around this blog post gets derailed and eaten alive by arguments and/or misunderstandings around said distinction. Though I suspect we'll both end up less wrong by filing our theories under 'guesswork' and seeing what the actual state of play is six months from now.

WesolyKubeczek 3y ago

There’s one thing I don’t understand. They keep saying GPL this, GPL that. Meanwhile there has been this huge push to use permissive licenses for like two decades now, because GPL bad (you don’t have to go far, just look at any discussion around licensing here on HN). There’s nothing in .spec files that says they have the same license as the software they cover. Fedora contributions are required to come with a MIT-like license. So you have quite a small core of software under GPL — the kernel, glibc, coreutils, gcc, binutils, make… and not even the darling of security advisories, OpenSSL. Thanks to incessant corporate PR against GPL, the GPL-based software base is shrinking slowly but steadily. That Rust-based coreutils replacement? MIT.

voxadam 3y ago
Is an RPM spec file even copyrightable? It's pretty much the definition of tabular data akin to a simple recipe or a phonebook, neither of which are subject to copyright under US law as I understand things. I'm also not convinced that a spec file would satisfy the "threshold of originality" to make it copyrightable.
throw_a_grenade 3y ago
No, it's the other way around: GPL requires that all pieces required to compile the binary (the exact binary that triggers requirement for distributing source) needs to come along. IIUC if they distribute source as SRPMs, the .spec needs to be included and without limitations (legal or technical) that would prevent user from rebuilding the original software.
- WesolyKubeczek 3y ago
  Well, nothing prevents you from rebuilding the upstream tarball, or tarball with RH's patches applied even, using upstream's instructions. Doesn't have to be the identical RPM package, does it? I don't really know how this might or might not work. My gut says that since the .spec is meaningless without the sources, it's a Modification of the work and thus the spec, patches, and the resulting SRPM is definitely a Derived Work. But every time anything quasi-legal is being brought up here or anywhere else, it gets drowned in the arguments over what the meaning of the word "is" is, so I don't know how you can twist it, legally. But then, the elephant in the room is that IBM may decide to give away only the GPLed SRPMs, and say a big fuck you to anything more permissive. People rallying against copyleft have made quite an impact, and the GPLed landscape is shrinking.

kazinator 3y ago

On another topic, we can finally see the motivation behind those SRPMs. The whole purpose of a SRPM is to take some upstream source code and repackage it into a different archive blob which has to be downloaded in its entirety and unpacked in order to determine whether any of the code is patched, or pure upstream. If, instead of a SRPM, you have some small, declarative text file which gives upstream URLs, SHA256 digests and build config steps, then that tiny declarative text file is all that someone needs from you to clone that package in their own distro, exactly The amount of material needed to repro your whole distro goes something like from gigabytes to megabytes. I mean, think about it. There is such a little declarative piece there in the process: the RPM spec file. Now, normally we think about building binaries from sources. But under RPM, you "build" source packages too! It's an obfuscation step intended to make people dependent on your way of handling sources.

bonzini 3y ago
What an idiocy. SRPMs can be used offline. The GPL requires the complete corresponding sources so you have to include the upstream sources anyway together with the binary RPMs; might as well bundle them in one file so you can share the metadata format between sources and binaries built from them. What you mention ("upstream URLs, SHA256 hashes" plus the content of the spec file) is exactly what you find on git.centos.org. Besides the main design of RPMs dates back to 1990. I suspect there was no conspiracy to hide SRPMs from Rocky Linux back then.
deleted 3y ago
[deleted]
veeti 3y ago
Or the SRPM was designed 30 years ago when people didn't have always online high speed connectivity.
- cesarb 3y ago
  > when people didn't have always online high speed connectivity Or any connectivity at all! Back then, it was not unusual for Linux distributions (which came in CDs) to have both one or more "binaries" CDs and one or more "sources" CDs. One distribution which kept that tradition is Debian: you can download at https://cdimage.debian.org/debian-cd/current/source/iso-dvd/ https://cdimage.debian.org/debian-cd/current/source/iso-dvd/ a complete set of 19 DVDs containing the source code for all packages, and at https://cdimage.debian.org/debian-cd/current/amd64/jigdo-dvd/ https://cdimage.debian.org/debian-cd/current/amd64/jigdo-dvd... metadata to create a complete set of 21 DVDs containing all the binary packages for the x86-64 architecture.

mrweasel 3y ago

What exactly prevents Red Hat from adding one or more proprietary components, like a RHEL bootloader, or network manager and simply refusing to share the code for those components? If Red Hat doesn't back down, I don't see anyway around Rocky, Oracle and Alma doing a fork.

toyg 3y ago
They can't easily do that without really risking to break the gpl. Btw, Rocky, Oracle and Alma cannot fork; their entire value proposition is being RH-compatible. What could happen is a new giant trying to displace RH as the reference Linux platform, poaching significant amounts of devs from RH. That would require years and billions of dollars though.
- mrweasel 3y ago
  > They can't easily do that without really risking to break the gpl. Why wouldn't they be able to do that? Sure, they can't patch the kernel or any of the existing stuff, but what would prevent them from writing a Grub replacement or a Red Hat shell? It has to be free of GPL code, but the operating system as a whole isn't what's under the GPL, it's the individual components, some of which aren't GPL, but BSD, MIT, ISC or some other licens.
  - rushikesh90 3y ago
    The whole point of selling RHEL is everything is coming from community and open source and they are making money only for support. If they start closing even a bit of software, they will loose customers to other enterprises like Microsoft
  - toyg 3y ago
    Red hat does a lot of work in kernel, subsystems, and libraries, where linking is necessary. They can, more or less, happily ignore the legal landscape as long as they stay open, because those licenses are interoperable; the minute they started closing things, they would have to pay a lot of attention not to break gpl constraints.

jillesvangurp 3y ago

The solution here is forking and accepting that IBM just doesn't want to share. The whole value of the Red Hat eco system is lots of people using the down stream variants. Actual direct licensees of Red Hat are not where most of the action is. The value creation is actually distributed across the ecosystem. People encounter issues, report them, and fixes are distributed. If you break that cycle and get IBM out of the loop, the process just continues elsewhere. The vast majority of that ecosystem does not pay IBM a single dollar and probably never will. IBM is a company that is in slow decline, so the remaining Red Hat employees are facing an extended period of that company just squeezing harder and harder until nothing remains. It's death by a thousand cuts. But the bottom line is that a lot of people doing the hard work of committing actual code on behalf of the ecosystem that are currently employed there will be facing endless rounds layoffs, reorganizations, restructurings, etc. If there isn't an employee exodus happening there already, that might soon start to happen. The only question is where those people will end up. A well funded foundation maintaining the fork of the distribution formerly known as Red Hat could be a nice destination for such people. Between Amazon, Oracle, and the countless users of Rocky, Alma, Centos, Fedora, etc. there should be plenty of brain power, motivation, and money to make that happen. They need a stable foundation. They don't need IBM to be part of that. Don't play IBM's game on their terms. Just cut them loose. They get to do whatever they want downstream, not upstream. And they get to contribute all their fixes under GPL. That's not optional. This foundation would be free to use these fixes as they need to. Comparability with IBM's downstream distribution should not be a goal for this foundation. And if IBM wants to pretend they can do it all by themselves, they are more than welcome to try. My prediction is that if the big supporters of this ecosystem join forces and do this, IBM will grumble a bit and then ultimately join the foundation because their alternative will be just writing off the investment they made in Red Hat and watch from the sidelines how most of the ecosystem stops depending on IBM's Red Hat.

bonzini 3y ago
> IBM will grumble a bit and then ultimately join the foundation because their alternative will be just writing off the investment they made in Red Hat and watch from the sidelines how most of the ecosystem stops depending on IBM's Red Hat. You could have said that if they switched to using CentOS Stream, and that would even have been my favorite outcome as a Red Hat employee. However, Rocky Linux is neither a sibling nor a fork of RHEL. It's a debranded clone that by definition cannot even have a single bugfix that isn't in RHEL. For Oracle it's okay because it's peanut money in order to annoy Red Hat, so they can afford this; for Amazon or Facebook it's no good and that's why they forked upstream at the Fedora or CentOS Stream level. As long as Rocky Linux stays a RHEL rebuild built by a third party like the CentOS of 2010 (except backed by corporate money rather than a guy in Nebraska), Red Hat is already putting millions into "the foundation". That's what they pay for the thousand people that develop Rocky Linux, ahem RHEL. Without them, there can be no Rocky Linux at all. So, as long as Rocky's money making side keeps undermining Red Hat's money making side, game theory predicts no other outcome than death for both RHEL and Rocky. _EDIT_: if you downvote, I'd be very glad to learn where I'm wrong

giamma 3y ago

So long "Upstream First" principle https://github.com/RedHatOfficial/open-source-participation-guidelines https://github.com/RedHatOfficial/open-source-participation-...

worthless-trash 3y ago
This is not at all in conflict with the upstream first, if so please tell me how you see it being in conflict.
- giamma 3y ago
  The blog post says: "Previously, we obtained the source code for Rocky Linux exclusively from the CentOS Git repository as they recommended. However, this repository no longer hosts all of the versions corresponding to RHEL. Consequently, we now have to gather the source code from multiple sources, including CentOS Stream, pristine upstream packages, and RHEL SRPMs." Why would you need RHEL SRPMS if the upstream packages contained all the patches and why refer to them as "pristine upstream packages" in the first place?
  - happymellon 3y ago
    That's not "upstream first". They are going upstream because of a zero day patch that RedHat have, and is also upstreamed. Hence why they are going upstream, to get the upstreamed patch that CentOS has not merged yet. So your entire argument appears to be that RedHat are doing upstream first.
  - mst 3y ago
    I believe that currently RH send a patch to the upstream project, then apply/backport it to CentOS Stream, then if they consider it appropriate apply/backport that to RHEL, and it's the first step there being their first step that's the 'upstream first' part. The additional hassle Rocky are having is that since Stream is ahead of RHEL divining whether the third step was taken and if so with what, if any, backporting tweaks required, is rather trickier so to recreate the end result of all such third steps to get an identical (bar debranding) set of SRPMs to the ones used by RHEL your best approach has become to source the various bits of information you need to do that from multiple places. Also I -suspect- the 'pristine upstream packages' thing is referring to the fact that most package formats, rpm definitely included, prefer to have an untouched copy of the upstream sources plus a stack of patches in their source packages and combine them during package build for both clarity and debuggability reasons.

DeathArrow 3y ago

>Every user of Rocky Linux is valued and their contributions matter. That's very wrong. It's not Linux, it's GNU/Linux. [0] [0] https://www.gnu.org/gnu/linux-and-gnu.html https://www.gnu.org/gnu/linux-and-gnu.html

znpy 3y ago

Friendly reminder that not all open source licenses are as reassuring as the gpl is. Keep that in mind next time you make an open source contribution (and maybe sign off copyright) to a repository that is not protected by the gpl license.

gigatexal 3y ago

I originally had a strong anti-RedHat response to this change. When I thought about it and heard RH's response their sharp change makes sense. They sell RHEL. It's from what I gather their main source of income. Revenue from this funds things like SystemD, a lot of work in Gnome, many many things that RHEL customers and other users of Linux and desktop Linux benefit from. Of course many contributions to open source/GNU tools come from folks in no way affiliated or paid by RH and RH does use these packages but RH also provides a lot of value. So it stands to reason, to me at least, that to allow anyone to reskin/respin/or basically just ship a RHEL clone without RH branding that is "100% bug/binary compatible with RHEL" just without the license cost is giving away something you work on for free. No rational business would allow this. CentOS, Fedora are free. RHEL is not. Makes sense.

toyg 3y ago
How did they survive and thrive for 25+ years then? Rebuilders have always existed. They've just dialled the "greed" knob a bit higher, that's all.
- gigatexal 3y ago
  I don't know for sure but if I had to guess early Linux some 25-years ago didn't have the prevalence of polish it has now at least on the desktop. In the server space it was probably solid. That being said businesses back then were likely leery of running a RH clone with just some Linux staff -- better to pay RH for support. Nowadays one could probably lean on staff to manage issues and arbitrage that go-it-alone mindset over paying the RH subscription. Now that loop-hole is closed.
- mst 3y ago
  Historically they've generally politely ignored community rebuilders and got a trifle enervated by commercial rebuilders - they changed how they handled distributing kernel code (to a fully patched tree rather than a pristine tree and a stack of patches I -think- from memory) in response to Oracle doing a commercial rebuild. Exactly what the triggering incident was this time they've been very careful not to officially say (which is likely a better option than the optics of getting into a finger pointing war with a smaller target), and I suspect we won't be able to fully judge their motivations unless/until the details leak and/or are inferred by people close enough to the situation to guess correctly.

xinayder 3y ago

Watch IBM and RH publish changes to these features Rocky Linux will use to obtain the source, and effectively remove the "open source" part of it and violate the GPL.

lars_francke 3y ago

> One option is through the usage of UBI container images which are based on RHEL and available from multiple online sources (including Docker Hub). Using the UBI image, it is easily possible to obtain Red Hat sources reliably and unencumbered. We have validated this through OCI (Open Container Initiative) containers and it works exactly as expected. They have phrased this very carefully but there is a caveat here. UBI is using a small subset of RHEL packages. They say "possible to obtain Red Hat sources" and that's true, but you cannot - afaik - obtain all RHEL sources this way. This is not too important as they are using a different way to obtain the RHEL sources now. https://access.redhat.com/articles/4238681 https://access.redhat.com/articles/4238681

captn3m0 3y ago
Another similar question I have is around license requirements for various packages. How many of the packages in RHEL are actually GPL/copyleft, where RH must share sources? Could it decide to stop sharing source for non-copyleft packages next?