Rocky Linux claims to have found 'path forward' from CentOS source purge The backlash against Red Hat's decision to stop distributing the source code of RHEL for free to non-customers continues to widen. Last week, we reported that Red Hat would pull the sources of its enterprise distribution from its public Git servers. To quote Douglas Adams once again: "This has made a lot of people very angry …
Yes and I suspect that some of their paying customers also make use of the free distributions, so unless Red Hat change their pricing structure, those customers could be facing much higher costs. At least that would provide some incentive for those customers to go shopping elsewhere.
Can confirm - My shop's dev infra is Rocky (previously Cent, natch) and prod infra is RHEL.
The two are complementary, and with the rate we automate and spin up dev infra, the "free" tier isn't enough.
Probably more importantly for the long run: I would know literally nothing about RHEL were it not for CentOS being a free distro 10 years ago. I now have a great appreciation for its 10 years of support and stability, but I would not have ever learned it but for the free version being available on my strict $0 budget.
Advance warning? They've being doing similar things almost annually for 20+ years now.
Guess what Red Hat gets from you running unentitled RHEL in dev instead of Rocky? Still nothing!
Just keep your entitlements up to date in prod, in case they audit you.
Don't get me wrong, I hate the entitlements model with a burning passion, but this is not a catastrophe.
> My shop's dev infra is Rocky (previously Cent, natch) and prod infra is RHEL.
Out of interest, have you (or others here) looked at CentOS Stream? One would assume it would be good at least for dev infra. RHEL bug-for-bug compatibility is really an issue only if you depend heavily on 3.party closed-source packages, which I feel is an anti-pattern anyway for Linux users.
No, you'll find in some environments, developing with what is in the distribution, and only in extreme circumstances with what could be in a third party repo, is a *requirement*. That means, with the tools and versions as they are. With Stream you cannot ensure that while you're developing, you are working with those specific tools and versions (and backported patches as per the distribution), because something might be updated today (to fix something) but that fix is not in your production system. And then, when you go from Dev (on Stream) to Staging (on production distribution), all hell breaks loose because there's something happening on Staging that doesn't happen in Dev and no-one knows why until you see the yum/dnf log that says a vital component was updated.
So, given I work with nationally critical infrastructure, I fully appreciate this exact point. CentOS (or Rocky or Alma) for dev at the exact code point that your production/staging environment is at is very important. It's frustrating, sure, especially when you *know* the bug was fixed by a very responsive team, but the fix is not backported to the distribution until the next minor version comes along (if you're lucky).
Yes. I've seen what happens in CentOS Stream. The other day for example, they pushed out an update to gnupg2 which removed its ability to verify signatures using SHA1. Good move to remove insecure stuff... except that the key used to GPG sign all the packages in the distro uses SHA1 so immediately after applying that fix, you could no longer use dnf or rpm to upgrade or downgrade any packages because they all have invalid signatures. That is the level of testing that CentOS Stream packages get before they are inflicted on its users.
Run, run away.
I think this is part of the plan: not only to hinder the rebuilds, but also to signal to all users that the reliance on rebuilds is not stable by any means. And the announcement does not affect the stability of paid RH products in any way.
What ended up happening in the end was openSUSE Leap becoming downstream of SLES while Tumbleweed became the new upstream of sorts. However, Leap is going the way of the dodo in favour of ALP which is the same kind of containerised nonsense every other commercial distro is angling for.
If you want an unchanging server, use Debian Stable with only the most common essential packages, as those will get ELTS through Freexian, offering 10 years of patches total.!
SUSE have never provided the source to allow a community build so there can't be blow back from stopping. Plus SUSE haven't said anything that people can take as an insult. If Redhat had said in 2022 "we'll keep providing the source for rhel8 but rhel9 will be the breakpoint" they'd have had less blowback. Instead they've benefited from centos et al acting as a feeder for people to adopt RHEL but pulled the rug on a lot of people who have existing installations.
SUSE source is completely available, arguably "the path" isn't quite as convenient though (but perhaps simply due to lack of knowledge?). I did post on their forum that there's an opportunity for them here to become the preferred cloned enterprise distro. A lot of what SUSE provides isn't "well known" and they provide a lot. So, it's also possible that if people better understood what all SUSE provides they might say "wow. that's 10x better than Red Hat of old"... and that may well be the case. We'll see.
I've watched and used Linux since it was released, but never Red Hat. (Mostly used the BSDs, which seem to be more of a literary tradition than the Linux tied-to-executable form.) I find it hard to understand who is inconvenienced by these moves. The closest I've read is people who are clients of (expensive) proprietary software that is only "certified" to work on specific builds of Red Hat. And all you get for that is a specific set of versions and build configurations (bugs, if you like) for software that is readily available elsewhere.
Seems to me that the complaint must be with these proprietary software providers, for the lack of faith in their product, or lack of testing against other distributions. If the software is so expensive and so singular, I expect that most of the clients do indeed spring for matching Red Hat licenses. So again, I'm missing who's actually inconvenienced here.
One problem with RHEL it's that it's license activation process adds complexity if you want use it in automated systems like CI/CD. In those cases having the possibility to throw a CentOS at them and be done with it, with the confidence that your test environment will work the same way as your production system it's a godsend. Also, having local mirror of the repository is a pain, but with CentOS it was easy.
"I find it hard to understand who is inconvenienced by these moves."
You mean apart from those building the Rocky & Alma downstream distros?
1. Companies who use RHEL in production because they need support* but who also run a downstream rebuild for training, testing and/or development boxes because they don't need support on those. Are they going to have to pay more for those secondary functions? This is the risk for RH. If the matching downstream builds aren't available those customers are going to have to reconsider whether RHEL is still the best choice for production.
2. The certifying** application vendors who certify against RHEL because its existing place in the OS market has made it a valuable market place for applications. If this makes their customers wish to look elsewhere they are going to have to do the same. The testing against a platform is expensive. Maintaining multiple versions if testing reveals that's required is expensive***.
3. The customers of the vendors of the certified products who might not have a problem per se with running RHEL but will have one if their vendor switches platforms.
* Support is what provides the customers' perceived value for money.
** In regulated application areas certification of the S/W they use is an external requirement that the customer needs to meet.
*** "Inconvenience" isn't the issue; it's the cost.
but who also run a downstream rebuild for training, testing and/or development boxes because they don't need support on those.
Worth remembering that a free RHEL Developer account gets you 16 unsupported licences (up to 128 cores across those instances), which is 16 more than Microsoft gives Windows devs. So for training or dev or even small (self-supported) production workloads, developers can use their dev account licenses.
This policy/allowance of course remains at the whims of RHEL (beware building a business on it) and testing can be difficult because you have to activate those instances with your account credentials - as Claudio4 mentioned above, for automated CI/CD pipelines or anything where you might be standing up and tearing down instances automagically, throwing CentOS or similar at it was much more straightforward from an activation standpoint. I doubt that is unfixable, but you'd need some monitoring to avoid it trying to spin up a 17th instance and falling over.
As you mention, the main appeal of RHEL is support, and certification for vendors and customers operating in regulated industries.
That's not entirely true. With an MSDN licence you can download (and activate) a large development estate, provided it is for *development only*. You get an enterprise key for that purpose. But, woe betide you if you go and use that key to activate production stuff (build systems could possibly be considered production, but usually fall into development). Then you're in deep trouble.
"RHEL Developer account gets you 16 unsupported licences (up to 128 cores across those instances), which is 16 more than Microsoft gives Windows devs."
Which is absolutely irrelevant as you can't even buy a machine without Windows, For x developers that's x licences at bulk price. A lot more than 16.
Developer Subscription for Teams, enabling organizations already running other Red Hat technologies to access Red Hat Enterprise Linux for their development activities without friction.
https://developers.redhat.com/articles/2022/07/06/what-qualifies-red-hat-developer-subscription-teams#
> Companies who use RHEL in production
RedHat customers.
> The certifying** application vendors who certify against RHEL
RedHat customers.
> The customers of the vendors of the certified products
RedHat customers, whether they like it or not (they already didn't so no change there).
> those building the Rocky & Alma downstream distros?
Not RedHat customers.
1. No, they aren't going to have to pay. Talk to your rep.
No I don't work for rh. I just ... talked to my rep. You're making beautiful strawman arguments, but they're pointless because *everyone* who uses RHEL has access to a rep who can dispel each and every one of these.
Some of the people inconvenienced by this are people with Free Software projects who test their software before release. I have several minor projects which I run through automated tests on a variety of distros (and BSD) before each release.
Red Hat have a developer program which could theoretically get me a free copy for testing, but I'm not going to assume the legal liabilities which come with signing the licenses. These licenses include terms which do things like agreeing to subjecting myself to the jurisdiction of a foreign court and agreeing to reimburse Red Hat for the cost of license audits, etc. No other distro that my projects support require me to do anything similar.
I'm currently using AlmaLinux. If they can't come up with a reasonable work-around, then I will simply drop Red Hat clones as a testing target.
Centos Stream and Fedora aren't viable substitutes as they are not the same as RHEL and the whole point of testing on a specific target (as opposed to "but it works on my PC!") is to duplicate a user's operating conditions.
I don't imagine that Red Hat will care one way or the other about me in particular, but other people in the same boat will likely be making the same decision as well.
Exactly.
IBM are now assuming full responsibility for testing a huge array of projects that previously took on some of that work. While some of them might continue testing with the RHEL "upstream alpha", I'm sure many just won't bother.
Qt did something similar with 5.15. Locking out the canaries resulted in a far higher rate of regressions than we'd ever seen before, and made us seriously consider whether we actually wanted to renew our licences.
The last article here mentioned Red Hat required its customers to agree not to redistribute GPL source code made available to them from Red Hat. That is very naughty and not mentioned at all in this article. I will take it as proof that Red Hat knows that this requirement is legally problematic.
Liam pointed out in the article "The GPL doesn't free them from their Red Hat contracts: they can redistribute the source code if they so wish, but equally, the Hat can respond to them doing so by terminating their customer contracts, and that is 100 percent compliant with the GPL."
^ I fully agree with this and I hope that a court case does follow so that the resulting judgement gives us clarity if nothing else. Even if it is superficially an adverse one, that is still useful because it will be an indication that GPL licences, etc. need to be amended to stop future foul play.
> Relicensing existing projects isn't easy. It means all the original contributors or their heirs need to be traced and agreement obtained. It's one reason the Linux kernel is still GPL2.
That is incorrect, or at least partially. Anyone using a GPL'ed program can use it, at their option, under the tersm of any later version.
The kernel modified the GPL license to remove that option as Linus didnt like GPL v3 and it would be causing problems for other less free code.
It isn't an modicication to the licence (which would prevent it from importing GPL code), it's simply down to the terms used to designate the licence:
None of those formulations affect the terms of any version of the lience in any way whatsoever.
> GPL licences, etc. need to be amended to stop future foul play
So the licences need to say that if you managed to get a copy of version 1.2 of a program from a specific supplier, that supplier is then bound to give you a copy of v1.3?
If you violate the RHEL subscription terms, you have decided to forego your copy of v1.3 - you still have v1.2 in all its glory.
What licence has ever said that you get the next version? If you want to say "GPL" then please quote the clause (you can easily get a copy to quote from): nope, it days that if you already have a copy of the v1.3 executable you can get the sources (for a reasonable fee - which can be via a subscription) but it doesn't say the vendor has to give you that executable in the first place.
Although I do agree that a court case would be good, as that does tend to make things clear to everyone (even if it also makes the lawyers fatter and more prone gout or diabetes).
And whether it would work in contract law. There is no "dual-licensing" available to RedHat. GPL requires they make the source available to customers that they provide derived binaries to under the GPL, that is, RedHat have GPLed source under license (via GPL) from its authors, they provide this source to their customers and they must do it under the terms of the GPL. The customer now has two separate relationships with RH, one their support contract, the other a GPL license on the source code (this is only a relationship with RHEL if they have contributions to the affected code).
The situation is now:
1. Support contract.
2. Source code license, partly from RH, coming after support contract. Even if the GPL "no additional restrictions" cause doesn't prevent RH contradicting it in their support contract, the fact that this license is granted after they already have a contract might require some careful construction, because otherwise who is to say this isn't a modification to their existing contract? They may be able to not renew, but can they actually terminate?
or
2. There is no RH owned code in that provided, so the GPL license doesn't involve their relationship with RH. In which case are RH really going to terminate a customer for distributing code that is openly available elsewhere and not theirs in the first place.
You might also wonder whether this is why they are apparently starting to drop things like LibreOffice whose non-GPL licenses may prevent them doing this. You might also wonder how this would affect anyone distributing packages built on RHEL systems, think Oracle Java headers.
You are quite right.
I can see the value in Red Hat getting a revenue stream in return for their excellent work. If a customer finds the relationship problematic they can take the source code elsewhere and under those circumstances loss of Red Hat support would not be an issue. The freedoms granted by the GPL are still effectively preserved, but by a thinner margin than I am used to.
I am concerned that as Red Hat have found this opportunity others will follow without contributing patches up stream. I see it as a weak part of the GPL. I hope it is not so weak that it can be embraced, extended and exploited.
The four freedoms are
0. The freedom to run the program as you wish, for any purpose
1. The freedom to study how the program works, and change it so it does your computing as you wish
2. The freedom to redistribute copies so you can help others
3. The freedom to distribute copies of your modified versions to others
The only freedom Red Hat grants you is freedom 1.
You don't have freedom 0 because you agree to licence audits
You don't have freedoms 2 or 3 because your subscription will be terminated if you exercise them.
> You don't have freedoms 2 or 3 because your subscription will be terminated if you exercise them.
Nonsense.
You have those freedoms and keep them forever.
If your subscription is terminated then you still have that version and can continue to use and distribute it at will.
What you lose when your subscription goes is the automatic provision of an updated copy from RHEL.
There is absolutely NOTHING in the GPL that gives you the right to receive any source code mods if you happen to gave an older copy of the sources or executable.
IF you get an executable THEN you the right to the GPLed sources.
BUT you voluntarily[1] gave up the subscription that would get you that executable. The End.
Your access to Freedom 0 is also almost totally unlimited: you are free to take a copy of a GPLed executable out of the RHEL distro and use it anywhere. The only way this is being limited is because you are voluntary choosing to run the *whole* RHEL distro, which is *not* under the GPL: the subscription management software and any number of non-GPL code.
You don't *want* to take the GPL exes out and try to use them without the entirety of the RHEL distro because that is too costly for your purposes. That is your choice to determine and has no bearing on whether you would be within your licenced rights to do so.
[1] yes, voluntarily: you knew you were breaking the subscription rules and chose to do so.
No, its more like "you promise not to engage in those freedoms while we maintain a contract".
You allways have those freedoms, you can use them at any time, but RH may decide to cancel the contract.
Thus you have a choice, which is more important to you as a business right now, the support contract or the freedoms?
Here is another example. You have the freedom to drive a car, anywhere at any speed, for any length of time. BUT you agree to give up or accept limits on those freedoms when on the public highway, where you are NOT permitted to drive anywhere at all times (roads can be closed and traffic diverted) and you are NOT premitted to drive at any speed on any particular roads.
If you break those rules you can lose your driving license, but you can drive all you like, at any speed unlicensed on private land.
I can see the value in Red Hat getting a revenue stream in return for their excellent work.
Red Hat packages code from many projects. How many of the authors of these projects are given a revenue stream by Red Hat ?
This is why people are upset: Red Hat is taking code for free, using it to make money (which no one complains about) but stops its customers using that freedom.
Yes: Red Hat does contribute to some packages, but not all.
With each new release could someone buy a copy then publicly redistribute it? Red Hat would then cut them off as a customer so it would require a new volunteer for each release. I assume Red Hat would try and vet customers to avoid this but would this be a possible work around?
Disto feeds do not depend on each release, but instead, a constant feed of updates daily, so you would need a new volunteer for each time Redhat cancels the contract for the current volunteer who has signed up and spent $500 on a license.
The real fun will start if staff members of large Redhat customers start to push the code base out from within the customers' environment - I can just see Redhat going to war with its own customers about the actions/mistakes of staff members.
Even every company demands source as per GPL. As is their right.
Then every time employee leaves the company from any of their customers they leak the source as is possibly not their right.
Then as a result the company terminates the contract of the employee, as was happening anyway. Employee gets good reference. Community gets the source.
Never happen, but it's nice to dream.
This strikes me as a novel and interesting attack on the rights the GPL tries to grant. Basically it says, "yes, the license guarantees you these rights, but if you try to exercise them we will fire you as a customer." If this works I expect to see more places try it, essentially gutting the GPL. Lawsuits requiring, say, router manufacturers to publish the GPL source they use won't mean much if there's a sticker on the shrinkwrap saying you can't legally do anything with the source if you get it.
> Lawsuits requiring, say, router manufacturers to publish the GPL source they use won't mean much if there's a sticker on the shrinkwrap saying you can't legally do anything with the source if you get it.
Buying a router with GPLed code inside is a perfect example of how GPL is intended to work and your suggested sticker would absolutely go against the licence term and be totally invalid.
The GPL is designed to let you take your router and fix any issues you have with it - you can fix bugs, update it as protocols change, add useful features, remove unwanted ones (all so long as those are in the scope of the GPLed portion of the code, of course).
No matter how many stickers were on the package, you will be legally allowed to keep your router running, even if the manufacturer stops making it or simply vanishes off the faceof the Earth.
> The GPL is designed to let you take your router and fix any issues you have with it
*BUT* the GPL does *NOT* mean that you have an immediate right to any updated code the manufacturer may make for that router.[1]
Unless you have explicitly purchased that right, via a subscription (and the cost of that subscription can start at just your email address and work up to as many dollars as can be squeezed out of you). Without any sub, the best you could do is hope to make a claim under consumer protection, e.g. "not fit for sale" in its original form, but that would not guarantee a firmware update, maybe just get you your money back instead.
Even if you do buy an update subscription, it is at the discretion of the manufacturer whether they want to keep you as a customer: they can cancel your subscription (and repay, pro rata, the charges). If they do so, you have the right to the GPLed sources to any and all of the releases you have received so far. BUT *not* to any more updates, of course. As for the conditions for cancelling a subscription, some are obvious (no payment, company vanishes, the company's dev team vanishes) and need not be listed (although there will probably be a statement saying they sub is annually renewable but they don't guarantee any specific number of releases in that time period), others will be listed in the subscription agreement at time of purchase.
No matter what, the GPL has protected your right to get a copy of the code that is running on your device, which is the sole purpose of the GPL. Job done.
[1] more and more manufacturers of random goods are providing software updates, bu by no means all. Those that do are only doing so because they believe is is good business to do so; nothing compels them to do so (unless they know the software is so crap they'll be done for "not of merchantable quality" and just issue slight improvements to stave off the lawsuits).
If Red Hat terminates a subscription because of redistribution of GPL'd works, it violates GPL. See https://access.redhat.com/articles/5112
"2. You may not impose restrictions on any of these rights." Red Hat will violate the GPL even if it tries to place additional restrictions, namely preventing further redistribution, invoking the automatic termination terms.
Red Hat's page links to the GPL itself and separate works bundled with GPL'd works are not so restricted. Surely some clever engineer, not already laid off, could find a way to add a separate binary that would break an otherwise unbreakable distro if left out.
"The core argument is that the free rebuilds of RHEL add no value either to Red Hat as a company or to the open source ecosystem as a whole; they simply deprive Red Hat of revenue that it fairly earned producing arguably the stablest of stable distros… "
The big issue for me is that IBM took something provided with a copy left license and now tries to say they are compliant with the license while attempting to restricting the copy right.
Nothing in the GPL says others have to provide additional value to anyone upstream when they exercise their right to copy/modify/use the source so that core argument doesn't have any merit.
The discussion if free and open source allows for a sustainable commercially viable business model is interesting but i haven't seen anything in any copy left type license that says you are free to add additonal restrictions if the original license doesn't fit your business model.
> agree not to redistribute GPL source code
Nobody has the right to redistribute source under the GPL. More "permissive" licenses are not copyleft thus its a non-issue, RH can do what it likes with those and everyone else can too. Only the GPL uses copyright in the form of "copyleft" to provide source code.
BUT, you only have the right to source code if you have the corresponding binary. Never the other way around. The GPL makes sure that you can get the source for the binaries you have.
The GPL protects your rights to distribute binaries, and anyone getting it from you also get those rights.
Thus RH gives the customer binaries, as they paid for access to said binaries they have source code access. If they leave the support agrement, the GPL states they still have rights to the source from RH, but ONLY for that binary, thus not a future version. If they want a new version, they must re-subscribe.
A customer of RH has rights under the GPL to distribute binaries, but RH can terminate the support contract should they do so, they may not bother to do so, its up to them. The former customer still has the binaries and still can get source for those versions, but no support contract. They may be former customers but RH cant stop them running GPL'd binaries they already have. Like I said for the non-copyleft licenses, RH could stop them running those, and the customer has no right to source code for BSD code etc anyway.
Anyone getting the binary from the customer, should the RH customer distribute it, also gets the right to the source code for THAT VERSION from RH. Now, RH will want to muck about and play silly buggers with granting source access to former and non-customers but they have done so before and that would be a GPL violation. But remember, you only have the right to the source for THAT BINARY YOU HAVE.
There is no provision in the GPL for redistributing source code. It concerns itself with distribution of binaries and giving access to the source code. Thus RH are well able to tell the customer NOT to distribute the sources, even if the customer distributes the binaries it is RH that must give access to the source.
The GPL allows access to the source because it allows you to modify and study the code. Should the custmer modify a RH binary, then distribute it, THATS when they are responsible to grant access to the modified source when REQUESTED.
Baiscally its this:
1. You get the GPL binaries from RH.
2. You only get that with a paid for contract.
3. You get the sorces for that and future versions easily.
4. You want to leave the contract? OK, no future versions or updates for you. Good luck. You want the source? Well you have that right and we might play silly buggers etc.
5. Or you want to distribute the GPL binaries? Go ahead, but we RESERVE the right to cancel the contract should we decide to do so, thus see point 4. You are not being stopped, just asked to decide to follow the rules of the contract or not.
6. Anything not GPL'ed may or may not be, now or in the future, legal for you to run or distribute, such is the freedom we (RH) are given by these permissivle licenses, sorry about that.
If anything this shows that there are great ways to make money off Free Software, gone will be the days of people crying out that it cant work, well here we are. And also it shows just how horrible persissive licenses are as the GPL protects you and your rights even when you are out of contract with RH.
> Nobody has the right to redistribute source under the GPL
GPL says "1. You may copy and distribute verbatim copies of the Program's source code as you receive it, in any medium"
So once I have the source code I have the right to distribute it anywhere (as long as I "conspicuously and appropriately publish on each copy an appropriate copyright notice and disclaimer of warranty; keep intact all the notices that refer to this License and to the absence of any warranty; and give any other recipients of the Program a copy of this License along with the Program."
There's no _mandate_ that I distribute the source (unless I distribute a binary based on that source) but I do have the right to do it. And whoever I send the source to _also_ has the right to distribute it, and so on.
From the article--
"...We suspect that the company is not going to back down on this..."
It's well-nigh way past time that everyone take a very serious dose of reality medication and therapy, along with a course in "Reading Comprehension 101". This will come as a shock to a lot of people, but,
There IS NO 'COMPANY'! See this week's Comment Section of "Distrowatch", here.
That "Reading Comprehension 101" is certainly needed because it's very clear indeed in the context that the company is Red Hat. In case "Big Purple" went over your head IBM which took over Red Hat is often referred to as Big Blue and, as mixing red and blue gives purple, the resulting amalgam is commonly referred to hereabouts as Big Purple.
The GPL doesn't free them from their Red Hat contracts: they can redistribute the source code if they so wish, but equally, the Hat can respond to them doing so by terminating their customer contracts, and that is 100 percent compliant with the GPL.
Is it though? Is there a legal basis for that assertion? I'm not a lawyer but as I read it the GPL requires you not to place any restrictions on the right to further distribute the source code. (Section 6 of the GPL2, and section 10 of the GPL3). The wording seems fairly plain and unambiguous, yet this seems to be entirely what Red Hat are doing? ("That's a nice support contract.... shame if something were to happen to it....").
Can you explain how terminating their contracts should they do this isn't a restriction as defined by the GPL? The choice seems to be continue to receive support or be able to exercise your rights under the GPL. That is restrictive surely?
I assume I am wrong in this, as to take the risk of potentially invalidating a whole chunk of the licences that your business is built atop would seem like madness. This suggests they've got actual lawyers involved.
But as a simple computer programmer can someone explain what I'm missing?
Don't really have a problem with RH making money, but to do it in the face of the licences they've agreed to. That's not right.
RH have complied with the GPL by making the source code to the software available to the customer. The customer may download the source code if they want to, that's fine.
If the customer then dumps it on Github, RH may not want them as a customer. Obviously this is not expressly written into the GPL or in the RHEL software licence.
I assume I am wrong in this, as to take the risk of potentially invalidating a whole chunk of the licences that your business is built atop would seem like madness.
The licences belonging to those distros which just build the RHEL source and make it freely available or more cheaply available than RHEL? I haven't done the maths but RH seem to have worked out it's not much and they might get more custom from people with RHEL copies going to RHEL.
As Doctor Syntax says above it's going to take a court to decide whether RH hinting that they'll terminate you as a customer if you choose to exercise your license rights to publish the source code. The GPL says you can't impose extra restrictions. Does the RH contract count as an "extra restriction"?
It might even turn out that different legal systems around the world will decide to interpret this differently.
In the end this is bound to end up in court and quite likely in more than one.
I've read opinions in other places that this isn't really aimed at the freebie clones but at the commercial ones who'd business model is to take the code from RH and then sell support at less than RH sell it for.
The business relationship between publisher/licensor and customer/licensee is not written into the GPL. The GPL is not about that, it's only bothered with ensuring that the software's source code is made available to the customer/licensee. If the business relationship is over, the GPL doesn't give the customer/licensee the right to continue receiving source code from the publisher/licensor.
The GPL is bothered with more than ensuring that the software's source code is made available to the customer/licensee. It's bothered about it being made available with the right to redistribute without further restrictions.
That is written into the GPL, including an obligation not to impose such restrictions on those to whom copies of code are supplied. The question here is whether the business relationship under which RH provide GPLed code implying such a restriction on their customers.
> The question here is whether the business relationship under which RH provide GPLed code implying such a restriction on their customers.
It doesn't restrict what you do with the copy you already have, do the GPL terms are satisfied.
It does restrict whether RH wants to let you have a copy of the *next* release - which is nothing to do with the GPL, it is entirely about business relationships.
It does restrict whether RH wants to let you have a copy of the *next* release - which is nothing to do with the GPL, it is entirely about business relationships.
*Sigh*. Therefore it does place a restriction upon what you do with the copy you have. A negative consequence is a restriction. It really isn't that hard to comprehend. What is happening here is a twin approach of bullying (take us to court if you dare small distro) and brinkmanship (we believe we're big enough to get away with this). What I'd like to see is (everyone's favourite) Oracle take them on.
*sigh* It places no restriction - positive or negative - on your use of the material you already have.
The licence has nothing whatsoever to do with anything else other than *that* copy.
What happens with respect to anything else, such as whether you are able to get an new copy, is never once mentioned in the licence and is out of scope.
Until you can get a court to agree with your extended interpretation. So go to it. It needs testing.
This post has been deleted by its author
"*sigh* It places no restriction - positive or negative - on your use of the material you already have."
Why do you think *that* is relevant? It isn't. And you do intentionally refuse to understand term "any restriction", do you?
It covers everything, including *future actions*. Which part of "any" you do not understand?
>> "*sigh* It places no restriction - positive or negative - on your use of the material you already have."
> Why do you think *that* is relevant?
Because the licence can only apply to material you have.
How can a licence be relevant to something you don't have, something that possibly doesn't yet exist and may in fact *never* exist?
One question I'd like answered is that if you are a current Red Hat support customer, with totally contract compliant use of the binaries and source, if you then terminate your support agreement in anyway at all, do you still maintain access to the portal for the source of the version of Red Hat that you already have? I know you could pull down the sources while you are a customer, but the terms of the GPL suggest that you should still have access to the source of the binaries you already have after you're no longer a customer.
If RH pull your access to the git repositories for your current version because you're no longer paying for support, then this would count as a restriction as far as I see it.
I wonder how RH will maintain guarded access to specific versions while withholding anything newer?
RH do not have to allow you access to the portal in any situation - if they decide not to like you for any reason, they can require you to make a formal request and include a "nominal" fee (including media costs and postage) before they send you a copy of the sources.
If they are feeling really pissy, you may get some of the material as printout or eight-track tape.
They are also under no obligation to provide sources for non-copyleft binaries.
PS Yes, a nowadays a printout does count as "machine readable" - at least, RH would probably argue that and demonstrate using a recent model document capture device; or they could be really mean[1] and print out in a bar code, like we used to get along the edges of computer magazines.
[1] 'cos the hardware is rare as hen's teeth
LOL. If that were illegal; then no "third party" support organization would be able to operate. Like your corner auto repair shop. Or tire store. Or appliance repair shop... ...etc.
Once you buy something; it's yours to do with as you will. Unless it's something under copyright; which adds (or subtracts) some restrictions. You can buy a book; read it; and later sell it to someone else; without restriction. But because of copyright laws; you can't make *copies* of that book and sell them; unless the copyright owner has given permission.
Now; Linux is software; which also comes under copyright law; but the GPL explicitly allows one to make copies of software licensed under it and redistribute them however one might want. But when you do that; all those copies are *also* licensed under the GPL (one can't change an upstream license without the approval of the original copyright owner). Which is basically what Red Hat is trying to do by; in essence; when saying "if you redistribute; we'll cancel your subscription to RHEL."
"Obviously this is not expressly written into the GPL or in the RHEL software licence."
What is expressly written into the GPL is that (a) it applies to derivatives, (b) the recipient of GPL code, if redistributing it, is bound to pass on the GPL with the code and (c) is not allowed to add further restrictions if they do and (d) is entitled to remove them if they have been added.
In this both Red Hat and their customers are recipients. RH as a recipient is bound by the GPL and if it modifies the code the resulting derivative is still covered by GPL, must provide the modified code if required and should not add further restrictions.
The question is then whether these contractual terms for RHEL are an implied further restriction.
https://www.suse.com/download/sles/
Free support for 60 days
https://www.suse.com/source-code/
Typically, the source code is distributed along with the binaries. You can also send us a written request to provide the source code for a SUSE product by addressing your written request to:
SUSE Software Solutions Germany GmbH
c/o IP & Privacy Counsel
Maxfeldstrasse 5 , 90409
Nuremberg, Germany
This post has been deleted by its author
If the Red Hat contract is for support not for the code, then it is not part of the GPL agreement and they can withdraw or refuse to renew support at any time. Given that current customers have, up to now, had access to free distributions but still are paying implies that they would not want to lose Red Hat support.
But it would seem to me customers willing to give up future support could redistribute the code. So for each release if a customer can be found that is willing to give up support, then that release might be available for free distribution.
But could Red Hat also sell a separate a piece of proprietary code needed to make the distribution truly useful commercial use?
> if it modifies the code the resulting derivative is still covered by GPL, must provide the modified code if required and should not add further restrictions.
True.
And the definition of "if required" by GPL is if you have a copy of the executable of their modified form. Which you don't because you lost the subscription and RH never sent you a copy of those executables.
What RH has done isn't making them any friends but it also isn't breaching GPL.
If the customer then dumps it on Github, RH may not want them as a customer. Obviously this is not expressly written into the GPL or in the RHEL software licence.
Yes, it is, and the wording to me seems 'Obvious':
section 6 of the GPL 2:
6. Each time you redistribute the Program (or any work based on the Program), the recipient automatically receives a license from the original licensor to copy, distribute or modify the Program subject to these terms and conditions. You may not impose any further restrictions on the recipients' exercise of the rights granted herein. You are not responsible for enforcing compliance by third parties to this License.
or section 10 of the GPL 3:
10. Automatic Licensing of Downstream Recipients.
Each time you convey a covered work, the recipient automatically receives a license from the original licensors, to run, modify and propagate that work, subject to this License. You are not responsible for enforcing compliance by third parties with this License.
An “entity transaction” is a transaction transferring control of an organization, or substantially all assets of one, or subdividing an organization, or merging organizations. If propagation of a covered work results from an entity transaction, each party to that transaction who receives a copy of the work also receives whatever licenses to the work the party's predecessor in interest had or could give under the previous paragraph, plus a right to possession of the Corresponding Source of the work from the predecessor in interest, if the predecessor has it or can get it with reasonable efforts.
You may not impose any further restrictions on the exercise of the rights granted or affirmed under this License. For example, you may not impose a license fee, royalty, or other charge for exercise of rights granted under this License, and you may not initiate litigation (including a cross-claim or counterclaim in a lawsuit) alleging that any patent claim is infringed by making, using, selling, offering for sale, or importing the Program or any portion of it.
So, again, I ask... how can RH do this and not have invalidated their licence to huge chunks of their distribution? Therefore making their distribution of those sections illegal? (One of these being Linux).
Yes, they can restrict their customers via contract, but I don't understand how they've not invalidated their licence to the software in doing so.
That is the bit I would like explaining.
You say the GPL doesn't forbid what they're doing, but it really seems it does??
Much of Linux (particularly the kernel) is distributed under the GPL; not GPL V2 or GPL V3.
GPL V1 - the original GPL - in 3 (b) states:
b) accompany it with a written offer, valid for at least three
years, to give any third party free (except for a nominal charge
for the cost of distribution) a complete machine-readable copy of the
corresponding source code, to be distributed under the terms of
Paragraphs 1 and 2 above; or,
"Any third party" would seem to me to include exactly that: "Any"; whether an actual customer or not.
b) there is one of two choices. The full context is:
" 3. You may copy and distribute the Program (or a portion or derivative of
it, under Paragraph 2) in object code or executable form under the terms of
Paragraphs 1 and 2 above provided that you also do one of the following:
a) accompany it with the complete corresponding machine-readable
source code, which must be distributed under the terms of
Paragraphs 1 and 2 above; or,
b) accompany it with a written offer, valid for at least three
years, to give any third party free (except for a nominal charge
for the cost of distribution) a complete machine-readable copy of the
corresponding source code, to be distributed under the terms of
Paragraphs 1 and 2 above; or,"
RH complies with this clause by satisfying a), not satisfying b). If RH supplies you with RHEL binaries it also supplies you with the corresponding sources, thus a) is satisfied, which means b) does not have to be satisfied. a) contains no "third party" clause.
Much of Linux (particularly the kernel) is distributed under the GPL; not GPL V2 or GPL V3.
linux$ grep --exclude-dir=.git -rn '^// SPDX' | cut -f 3 -d \ | tr -d \(\) | sort | uniq --count | sort -rn
11993 GPL-2.0
9562 GPL-2.0-only
5926 GPL-2.0-or-later
3322 GPL-2.0+
511 BSD-3-Clause
309 MIT
273 ISC
120 LGPL-2.1
50 BSD-3-Clause-Clear
29 GPL-1.0+
13 LGPL-2.1+
13 Apache-2.0
7 Zlib
4 LGPL-2.1-or-later
4
3 BSD-2-Clause
2 LGPL-2.0+
What needs to happen is that one of the copyright holders of code that Red Hat are distributing needs to take them to court for software piracy.
If Red Hat violate the GPL, which clearly they are, then they lose the right to distribute GPL software. Then they don't have a business unless they want to switch from Red Hat Linux to Red Hat BSD.
> how can RH do this and not have invalidated their licence to huge chunks of their distribution?
Go back over the sections you have quoted. If you have a copy of executables for v1.2 then you have the right to get a copy of the sources for v1.2[1]. GPL satisfied.
Nowhere does it say that RH is then required to supply you with executables for v1.3; even if RH create v1.3 by modifying the GPLed sources for v1.2, until you get a copy of the 1.3 executable from RH they do not need to let you have the 1.3 sources.
And if you no longer have a subscription to RHEL there is no requirement for RH to supply the executables of v1.3 to you.
RH have changed the pricing and are not making friends, but their product (the subscription, that is), their pricing. If enough customers stop paying then RH may change their minds (or not) but inaccurate arguments about licensing help nobody.
[1] but only of the GPLed bits and any scripts needed to build them - you don't have a right to, say, a free copy of the compiler used to make the executable - I can send you all the bits for a GPLed Windows executable that I built with VC6.. Nor do you any rights to sources from RH for non-copyleft programs, whether you have the executables or not.
So, again, I ask... how can RH do this and not have invalidated their licence to huge chunks of their distribution? Therefore making their distribution of those sections illegal? (One of these being Linux).
I can answer that from my perspective. It is because this is IBM and they clearly do not care about the license or the rights it grants. They are working on the basis of "deepest pockets" and couldn't give less of a sh1t about you or your rights and they know that plenty of customers will, initially at least, grin and bear it. What happens longer term remains to be seen but this doesn't seem like a long-term play, more of a cash-grab.
If the customer then dumps it on Github, RH may not want them as a customer.
That may well be true, but there seem to be at least 2 possible problems with it:
1) There is certainly a case to argue in court that by deliberately punishing customers who choose to freely publish GPL code, RH are violating the terms of the GPL licence. IANAL, and it is quite possible RH might win, but I am sure it will be an arguable case and that some lawyer or activist body will choose to take it on.
2) In practice, how would RH find out which customer made the source code available? The source code either is, or is not, the source code from which the software the customer received has been built. If RH have watermarked the code in some way then it is not the source code from which the software was built. And the GPL allows the receiver to remove any watermarks they can find (or make any other changes they want to the code, for that matter) before deciding to publish the code.
While I can imagine that what RH seem to be planning to do could be done, I don't think it is sustainable in the real world unless almost all their customers agree.
The problem here is that the GPL states that it's the definitive license of the work licensed under it; and that no additional terms can be imposed.
It also says that source code redistribution cannot be denied. Not binary; SOURCE.
Red Hat's business model is selling *support* for it's distribution. Which is perfectly legal under the GPL. It's not software. So not bound by GPL license terms. However; Red Hat's attempt to restrict *source* redistribution of the components licensed under the GPL within it's packaging via *contract* terms would seem to obviously add an additional "term" to the licensing the software is distributed under. Which isn't allowed by the GPL.
I've never had any issue with Red Hat's business model. It's very similar to a warranty; after all; which often can be extended for an additional length of time via additional payment; until the product reaches "End of Life". But the software in it's *distribution* is like a book who's author(s) (the copyright holders) have previously granted copying rights. That's what the GPL does.
The authors of the GPL (Free Software Foundation?) need to weigh in on this in an official stance. The question here isn't about the "cost" of the software. It's the freedom to use it as one sees fit. Red Hat doesn't "own" it in the traditional sense. So how can they add restrictions on how it can be used or disseminated? The *worst* they're allowed to do is not honor requests for support from those who didn't obtain it from them.
I don't think the GPL says anywhere that RH are obliged to continue licencing to customers who use the source code to build a copy of RHEL then sell it for cheaper. It makes about as much sense as RH being obliged to continue licencing to customers who copy the binaries and sell them for cheaper.
I would imagine they just terminate updates? So
You’ve got the source - *check*
No punitive action taken based on existing version (support until end of life or contract), *check*
No updates…
Seems air tight to me, if you’re an organization trying to build derivatives, you have play fake accounts ping up games to keep getting updates (which will get stopped fairly easily). If you’re not, then no harm. All seems totally fair, if I’m honest. “Here’s the code for what you’ve bought, give me a shout if you have issues, no I won’t help you if you’ve sold this to someone else and they have questions, they can come to me”
So, unless they terminate support for existing version before prior agreed EOL, I think it’s fine and makes sense…
Well, "legal".
Legal and fine are two different things.
I agree that this is almost certainly legal (IBM's lawyers will have spent a lot of time preparing their arguments), but it's not in the spirit of the GPL.
It almost certainly marks the beginning of the end, as a lot of RHEL customers will now spend a fair bit of effort reviewing whether to renew or migrate elsewhere. The cost of RHEL will rise and the quality will fall. This is inevitable.
>Can you explain how terminating their contracts should they do this isn't a restriction as defined by the GPL?
It's the GR trick. You buy the binary and have free access to the source if you want. Publish it, fine. But they then decide they're not going to sell you a different binary (eg the next version), if you ask to buy it.
Gpl2 has nothing to say about programs other than the one you received. It does not refer to future versions, or claim mastery over different programs (which would be absurd).
Bruce Perens gave an opinion on this matter, and carefully worded it as an opinion. But, really, it's doubtful that a court would back it up. As you walk the judge through it, they'll ask "why are we now talking about a different binary?": case dismissed.
Ultimately it comes down to the fact that you cannot order a business to sell something. If it doesn't want to, it doesn't have to (except in some countries with enlightened anti discrimination laws concerning race, gender, religion, etc, but they're not relevant to the debate here).
Gpl2 has nothing to say about programs other than the one you received. It does not refer to future versions, or claim mastery over different programs (which would be absurd).
But it does say about the distribution of the source code to that program, and the rights you were given to use that source code.
It's arguable that the threat of future support being withdrawn is a restriction. (As practically if your business depends on RHEL support, you can't distribute the source code to the current binaries without fear of future reprisals).
That would invalidate Red Hats licence to distribute the software.
That's the issue.
So..
1. I buy RHEL of RH and a support contract
2. I don't distribute the software
3. I require support.... I get it
or
1. I buy RHEL of RH and a support contract
2. I distribute the software
3. RH terminate my support contract
4. I can no longer get support for the product I bought in 1.
In the second instance the only thing I've done is distribute the source code; that's it. But now my support has been restricted; so it's likely I would choose to not distribute the software. That's the argument that's going to end up in court.
Ultimately it comes down to the fact that you cannot order a business to sell something. If it doesn't want to, it doesn't have to (except in some countries with enlightened anti discrimination laws concerning race, gender, religion, etc, but they're not relevant to the debate here).
No, you can't. But if that business no longer has a licence to the thing it's selling then you can force them not to sell it. The issue is with the source code RHEL is sub licencing, and if they've invalidated their licence to that.
>> Gpl2 has nothing to say about programs other than the one you received. It does not refer to , or claim mastery over different programs (which would be absurd).
> But it does say about the distribution of the source code to that program, and the rights you were given to use that source code.
Be careful with the word "that".
Try phrasing it as (very clunkily):
> But it does say about the distribution of the source code to [the copy you already have of the] program, and the rights you were given to use that source code [matching the copy you already have].
Otherwise we could misread your "that" to be referring to the "future versions", which I'm sure you never intended us to do.
Now, you have full control over the copy you already have and nobody can take that away from you, nor is anybody trying to take that away from you.
But unless you have a contract, totally separate from the GPL, you can not coerce RH into giving you a coy of an executable, let alone sources, for any *future* version.
That's pretty much how I see it too.
Those of us who can and care to may want to consider donating to the SFLC. They're likely going to need it, fighting IBM over this and whatever else they try and do is going to take forever and cost a fortune, think SCO v. The World writ even larger.
I really wonder what Oracle is going to do here since isn't their Linux basically just RHEL with Oracle branding?
I'm going to guess RHEL's support contracts, if they follow standard industry practice, have a clause saying they can terminate the contract at any time and for any reason. If so, this gets harder to argue because it's not a unique restriction on people who redistribute code, it's just them exercising their existing contract rights.
> I'm not a lawyer but as I read it the GPL requires you not to place any restrictions on the right to further distribute the source code.
They don't. You have the sources to v1.2, go right ahead and distribute them
RH will then choose to not send you the executables for v1.3 - as is their right - and without those executables you don't have a right to get the sources for v1.3 from RH. The End.
But you still have v1.2, executables and sources, and can distribute it at will.
BTW if you didn't get your copy of the v1.2 executables direct from RH then they have no liability to provide you with the sources.
>BTW if you didn't get your copy of the v1.2 executables direct from RH then they have no liability to provide you with the sources
Indeed, but the binary provider does.
This was one of the things that puzzled me when GR Security threatened this. It wasn't clear to me what GR Security customer was supposed to do, if one of their customers asked for the source code. It felt like there was not a lot that GR could actually do, had one of their customers been obliged. Felt like the whole thing depended on it being used in places where end customers were extremely unlikely to want the code in the first place.
The thing you need to keep in mind is:
THERE IS NOTHING PREVENTING THE CUSTMER OF REDHAT DOING ANYTHING THE GPL GRANTS THEM.
The restriction is on the contract with RH itself. Essentially you can have a support contract with RH is you dont do X Y or Z. If you do X Y or Z then the contract ends.
The only thing preventing redistribution of BINARIES is the custimer of RH themselves who must decide to do so or not.
Note I capitalised binaries. The GPL allows distribution of binaries, not source code. You have a right to the source after the fact of you getting a binary, not before. When you get the binary you should ask the AUTHORS for the source. The RH customers, unless they modify the program, are not the authors. In fact RH may not even have to give you the source to stuff they havnt modified as they could simply point you to the original source.
They've managed to remove the raison d'etre of the rebuild/clones.
I, for one, am not going to bother learning Red Hat specific stuff on a rebuild because there is now zero prospect of using Red Hat in production. My efforts will be focussed on debian and derivatives.
I know that some software vendors insist on a particular OS, but we can now say "no, that's not going in our network" - they can either lose a sale or agree to installing it on another OS.
I've been running a combination of debian/derivatives and Red Hat/derivatives for many years... strangely it's consistently been the debian ones which are far easier to maintain (especially when it comes to updating to latest releases)
I can't imagine RedHat going to lose too much business as they have fingers in many pies, Ansible to name one, but you certainly make a good point. Is it worth making an effort to learn the guts of RHEL if fewer companies are likely to bother with it? Probably far better to stick at learning the higher levels of being a Linux jack-of-all-trades and avoid bothering to know anything more than a few of core functions of RHEL.
Yeah... once upon a time CentOS (or possibly Fedora) seemed to be the distro(s) that Serious People worked with, because it was basically "the same as" a distro that had commercial support. Red Hat then nuked CentOS as a viable option by making it not "the same as" RHEL, and my entirely unscientific observation is that Serious People departed for Ubuntu.
Regardless what the Red Hat mouthpieces say, this behavior is totally consistent with what the big traditional monoliths like to do; those of us who've seen the likes of AIX or HP/UX or Oracle Linux understand that there really isn't a customer advantage in those island OSs; yes, some of the tools are really neat, but they could just as well have been developed on an open Linux platform as on the semi-proprietary custom OSs.
And even the mouthpiece's own rant doesn't allege that Red Hat _loses_ money from the rebuilds, merely that they don't _profit_ from them. There's no indication that the work that Red Hat does is not justifiable entirely by Red Hat's own business needs, but we're supposed to feel sorry for Red Hat (who capitalize on millions of hours of Other People's work) for their hours of work and sympathize with them that although Red Hat grifts upstream, the grifting downstream by the rebuilders is somehow less grifty!
>> Red Hat then nuked CentOS as a viable option by making it not "the same as" RHEL, and my entirely unscientific observation is that Serious People departed for Ubuntu.
This is certainly what my company did. CentOS for testing and dev, RHEL for production. Now it's Ubuntu for testing and dev, Ubuntu for production. It's actually better, they did us a favour.
Red Hat then nuked CentOS as a viable option by making it not "the same as" RHEL, and my entirely unscientific observation is that Serious People departed for Ubuntu.
That's exactly what I did, 2+ years ago, when the storm clouds gathered (and what about the 'A bit of advance warning wouldn't have gome amiss' thread? Seriously?)
However, unlike the AC commentard, I can't agree that this is a good thing. Ubuntu's Ok, but it's not nearly as polished as RHEL. RH actually does something useful with all their money and employees, and I still use a free dev system for some tricky stuff. If I could develop on RH, and produce an RH-compatible image that I could deploy without paying RH more than my customers pay me, I'd change back in a flash.
> I, for one, am not going to bother learning Red Hat specific stuff
> I know that some software vendors insist on a particular OS, but we can now say "no, that's not going in our network" - they can either lose a sale or agree to installing it on another OS.
Absolutely, go for it.
RH isn't breaking GPL but that does *not* mean we have to like them and continue to buy from them.
This is just another 'cake and eat it' pigeons coming home to roost moment. I think RedHat have a point about the direction of open source, but not in their stance.
When Liam says making it easy for competitors to copy work isn't what FOSS was ever about, what you really mean is it's never been what *Linux* is about.
Whilst using BSD source comes with some moral pressure to contribute back to the ecosystem it is not and never was necessary. It's never an issue to get hold of the source.
What the large Linux providers actually want is :
To make money from the software they produce
To do so on the backs of other people's work, some of which was provided for free under the expectation people would not make money off their work directly or indirectly
For other people not to be able to make money off the providers' work, despite the fact they have already done the same thing
As a sub point, when they manage to commercialise some of it, for the large cloud providers not to break their selling model
To still have other people carry on to provide them free labour
I can see this may attract a large amount of criticism and down votes, but consider that Red Hat and others, despite their code contributions, have driven and continue to drive Linux in a direction beneficial to them, not to the Unix community as a whole, or arguably even the Linux community as a whole.
There is nothing, except a huge amount of cost and effort, from stopping Red Hat slowly moving away from the GPL. That is what BSD did with their AT&T encumbered versions.
I don't doubt that Red Hat contribute a large amount of code and are on balance a major benefit to the Linux community. However, someone taking the benefit of another's work for commercial gain when that wasn't expected is the same thing whether it's Red Hat taking other Linux contributions and considerably enhancing it, or another party taking Red Hat's work and making few changes.
Just because you're working hard on it doesn't mean you're in the right.
Now, I do think RedHat have a point about funding. Too many open source products are inadequately funded, and if this continues they disappear.
However, RedHat and many others have no high ground here as can be seen with historic issues such as OpenSSL's Heartbleed. They're all relying on poorly funded and sometimes inadequately tested projects, and hoping they're sufficient to build their projects upon.
To do so on the backs of other people's work, some of which was provided for free under the expectation people would not make money off their work directly or indirectly
I don't think anyone using GPL has a problem with folks profiting from their contribution, only folks preventing freedoms that are part and parcel of open source work.
I have contributed in small ways to a project RHEL makes use of, even accepting bug-fixes from their folks, and I have absolutely no issue with them making money on the back of support work. I do think this was a dick move though, and suspect it will backfire in the long run as the incentive to follow the RHEL option becomes less attractive.
" some of which was provided for free under the expectation people would not make money off their work directly or indirectly"
This is true in the sense that the "number of people who contributed to linux and the userland expecting that no one would make money from it" is surely non-zero. It would be foolish to deny this. But is that number really significant? The Red Hat model of selling support in some form has been around about 30 years now and the GPL and friends has been endlessly debated for what feels like eternity. Stallman is critical of RH for violating the spirit of the GPL, but he's not unaware of Red Hat.
I think in practical terms pretty much anyone who contributed to Linux kernel has known that Red Hat and other would profit from support services, but went ahead and contributed anyway. It's not as if Red Hat have hidden their business model. I have sympathy with the feeling that this all violates the spirit of the GPL I think most people, even the most blinkered software obsessives, would be aware that "spirit" of a licence agreement isn't exactly assured to stand up in court.
It does feel rather spiteful, though, even if I don't think you could convince a court that it was a contractual breach.
> Red Hat contribute a large amount of code and are on balance a major benefit to the Linux community.
Change that "are" to "were" and I'd agree. It's probably not a stretch to say Linux would not be where it is today were it not for the original Red Hat Linux way back when.
In recent years, I'd say the scales have tipped the other way. Red Hat, even before the coating of Big Blue, was making moves to benefit Red Hat, not the Linux community.
Which should not be surprising. Doesn't mean we have to like it, or use their products, of course.
Maybe not Mint, but if you are working in a container-based environment it is now far easier than it was in the past. Going from Redhat to SUSE back in the Bare Metal days was something of a pain, moving from SUSE to Ubuntu when building on LCX was far less work and now with docker the underlying version of Linux is not even a major concern.
Wow. Really spitting in the face of Rocky, Alma, and all other RHEL derivatives:
“More recently, we have determined that there isn’t value in having a downstream rebuilder.”
“Ultimately, we do not find value in a RHEL rebuild”
“Simply rebuilding code, without adding value or changing it in any way, represents a real threat to open source companies everywhere.”
Sigh, I wrote this here over 5 years ago (Primarily about inserting systemd into Linux). Warning: It has elements of "I told you so"...
How can we make money?
A dilemma for a Really Enterprise Dependant Huge Applications Technology company - The technology they provide is open, so almost anyone could supply and support it. To continue growing, and maintain a healthy profit they could consider locking their existing customer base in; but they need to stop other suppliers moving in, who might offer a better and cheaper alternative, so they would like more control of the whole ecosystem. The scene: An imaginary high-level meeting somewhere - The agenda: Let's turn Linux into Windows - That makes a lot of money:-
Q: Windows is a monopoly, so how are we going to monopolise something that is free and open, because we will have to supply source code for anything that will do that? A: We make it convoluted and obtuse, then we will be the only people with the resources to offer it commercially; and to make certain, we keep changing it with dependencies to "our" stuff everywhere - Like Microsoft did with the Registry.
Q: How are we going to sell that idea? A: Well, we could create a problem and solve it - The script kiddies who like this stuff, keep fiddling with things and rebooting all of the time. They don't appear to understand the existing systems - Sell the idea they do not need to know why *NIX actually works.
Q: *NIX is designed to be dependable, and go for long periods without rebooting, How do we get around that. A:That is not the point, the kids don't know that; we can sell them the idea that a minute or two saved every time that they reboot is worth it, because they reboot lots of times in every session - They are mostly running single user laptops, and not big multi-user systems, so they might think that that is important - If there is somebody who realises that this is trivial, we sell them the idea of creating and destroying containers or stopping and starting VMs.
Q: OK, you have sold the concept, how are we going to make it happen? A: Well, you know that we contribute quite a lot to "open" stuff. Let's employ someone with a reputation for producing fragile, barely functioning stuff for desktop systems, and tell them that we need a "fast and agile" approach to create "more advanced" desktop style systems - They would lead a team that will spread this everywhere. I think I know someone who can do it - We can have almost all of the enterprise market.
Q: What about the other large players, surely they can foil our plan?A: No, they won't want to, they are all big companies and can see the benefit of keeping newer, efficient competitors out of the market. Some of them sell equipment and system-wide consulting, so they might just use our stuff with a suitable discount/mark-up structure anyway.
This part from Mike McGrath's defense though:
"This is a real threat to open source, and one that has the potential to revert open source back into a hobbyist- and hackers-only activity."
Shows a real misunderstanding of open-source and a company represented by someone with such an incompatible view should really not be involved with the open-source community.
I would even suggest it is insulting to Linus and the hundreds of kernel maintainers. Effectively translates to "you guys are all a bunch of useless hippies without us!"
Quote: The key point a lot of the louder critics have missed is that the GPL only obliges the Hat to provide source code to parties to whom it has provided binaries, and not to the rest of the world. Red Hat customers still can get the source code, so the Hat isn't violating the GPL.
Red Hat only provides access to binaries distributed WHILE there is active support subscription in place. This means that access to all source and modification ends without the contract. And that's a restriction that defies section 3 of GPLv2. From a (non-GPL) worldly corporate closed IP world, that may seem "fair", but it's definitely not GPL compliant.
And, as I've pointed out, even if the above were "free", it's still a violation. Why? It's a restricted control point of access to what must be made available by requiring "something else". No different than saying the GPL has an addendum to Section 3 that says "you must be able to do 50 pull ups to get the source." Fortunately, this is not true.
As a workaround, people with the non-GPL compliant restricted access to the source can make that source available to the world. But that's hardly a solution to Red Hat's anti-GPL problem.
Edit: Also, a distribution is a distribution. The only case for non-source availability is a completely internal distribution. Red Hat's (bad) argument, if true, would mean that every subscription holder is part of Red Hat, to which I say, "Where's my paycheck, stock and corporate benefits?"
Red Hat only provides access to binaries distributed WHILE there is active support subscription in place. This means that access to all source and modification ends without the contract. And that's a restriction that defies section 3 of GPLv2.
Why? If your subscription is over you don't get updates or patches which means no new binaries, so why should RH continue to make the source code to those binaries available to you as if you were still a customer?
If it was within the GPL to only start making the source code available to you when you became a customer, why is it not within the GPL to stop making the source code available to you when you stop being a customer?
Subscriptions end, begin, expire, renew, change, etc. All of that is outside of the GPL.
Because of its insertion as a qualification it's a problem. However, Red Hat did responded to my misgivings with regards to their change of policy assuring me that upon request source code access will be provided.
So, my argument is true, but Red Hat has another path for getting to the source. Something they didn't spell out clearly when they made their announcement.
Btw, someone claiming to be a Red Hat employee did reach out to me and said that all you have to do is ask and the source will be provided to you in some (he said USB) electronic format. However, their agreement text says $5 USD. I'd argue if people take them up on the offer, and if everyone asks, it will cost Red Hat at lot more than what they were doing before. Why? Because it's not "one version" that they'd have to make source code wise, but that which matches the level of distribution (remember, Red Hat has chose that game to play here, not me) to a particular end party. It's a harder thing to to track, IMHO, you'd have to provide more than "I need source for 8", because one person might have 8.5, another, 8.6 and of course the packages will vary, though maybe Red Hat will simply ship to you the source for all packages (we'll assume?).
Regardless, anytime a company makes a change away from easy access to more difficult access, but yet, still "tip toe-ing the letter of the GPL" line, the end result still could be consumer distrust. But that's all outside of the GPL. Up to Red Hat with regards to managing their image.
Corporate image issues aside, it does appear that at least some employees at Red Hat are interested in being at least "letter" compliant with the GPL. And this is good news. So, the source is somehow going to be available. I know Rocky LInux has stated they have figured out "their path".... they just didn't give any detail about that.... but I figured Red Hat may have reached out (??) to discuss the "new path" if the old path is now restricted.
We'll see. Red Hat obviously has the right to do whatever within the rights granted to them by licensing they're under. Personally, I still miss the more over the top FOSS advocacy of Red Hat of old though. Where, you knew what they "could do", and they always went above and beyond, surprising many people.
I know Rocky LInux has stated they have figured out "their path".... they just didn't give any detail about that.... but I figured Red Hat may have reached out (??) to discuss the "new path" if the old path is now restricted.
They have now, see https://rockylinux.org/news/keeping-open-source-open/
There you go:
"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."
Seems pretty simple to get around this restriction. Red Hat can try to hinder redistribution, but it seems like they will ultimately fail due to the wonders of GPL.
The core argument is that the free rebuilds of RHEL add no value either to Red Hat as a company or to the open source ecosystem as a whole; they simply deprive Red Hat of revenue that it fairly earned producing arguably the stablest of stable distros…
What he's really saying is that open source doesn't work as a business model. This despite Red Hat's BILLIONS of USD in revenue (before pulling any of this nonsense).
Years ago, Red Hat's own argument was that software could be free and open source, and companies like themselves could earn money on support contracts. Not as profitable as proprietary software companies, but only needed to invest a fraction as much into software development as well, thanks to consuming open source software written and often maintained by others. Now they say they were wrong and people exercising their rights will bankrupt their business.
To say the rebuilds don't contribute anything to RH is nonsense as well. When they killed-off CentOS-8 they had to offer a "developer" program in its place, clearly showing they found value in smaller, unpaid consumers of those rebuilds.
In my experience, a new major RHEL release is largely worthless for about the first year, until the EPEL packages fill out. Using AMANDA or Borg for backups? Using tripwire or fail2ban to secure your server? Need agents for nagios/zabbix/etc. to monitor your server? Use NUT for UPS status monitoring? Need one of thousands of perl, php, python and rust libraries for your programs? NONE of that is included in RHEL... you have to wait for the community to build those. Red Hat is getting a lot of benefit out of all that work. And how much of the community volunteering large amounts of their time do you think are also paying for RHEL licenses?
RedHat is an ecosystem, and free rebuilds get more people into that ecosystem. If my former employer couldn't use CentOS on the desktop / client systems (Fedora was never stable enough) they wouldn't have been paying for RHEL on the servers. If we had to maintain a bunch of desktops running Debian, it wouldn't have taken long before the servers started making the switch as well. It's far too much of a hassle to maintain two quite different systems, and RHEL is nearly alone in its particular use of RPM/SRPM/YUM/DNF/etc., in large part because of how hostile they have become to derivatives. Meanwhile, Debian derivatives thrive and that ecosystem is likely to push RedHat into irrelevance if they continue on this course.
You're free to complain about the mold, leaky roof and rats in the kitchen, but if you do we won't renew your contract.
I for one will not be recommending any company I work with gets into bed with RedHat or IBM - quite the opposite.
The question is: Who can be trusted? I know we're all running to Ubuntu, but I'm left wondering if they're not able to pull the same stunt. Debian? Arch Linux? RedHat's approach had undermined the whole trust model open software is built on. I think someone needs to tweak the GPL to rebuild that trust.
Community to RedHat: "We've revoked your right to use our software on the grounds that we believe (rightly or wrongly) that you add no value to our businesses"
"I know we're all running to Ubuntu, but I'm left wondering if they're not able to pull the same stunt"
That is a valid point to make but Mark Shuttleworth isn't stupid. He will have seen all the negative blowback against this Red Hat decision and he will certainly not be repeating their mistake because he'll now be getting many new and unexpected paying customers who want active support.
As Napoleon Bonaparte said, "Never interrupt your enemy when he is making a mistake".
I don't really trust Canonical any more (or less) than Red Hat. Or IBM. Okay, actually more than IBM.
Yes, one would hope Shuttleworth won't repeat mistakes like this most recent Red Hat move, but he, or at least his decision-makers, have made some boneheaded plays as well.
Fwiw, Red Hat obviously believes this latest boondoggle isn't actually a mistake, regardless of what we here or the larger Linux community might believe. It may very well be that Shuttleworth will also evaluate moves like Red Hat's with an eye more towards short-term profits than long-term impact to trust, community engagement, customer uptake etc.
Wouldn't be the first time that a big dumb company wrote its own epitaph, even if it took a long time.
The word Software (when capitalised) refers only to Red Hat branded software, which the source code is not, and even if it was, it would already be part of CentOS Stream (without Red Hat branding) by the time the next RHEL point release is out anyway, meaning all one is taking from RHEL sources is the errata patches, none of which are branded.
It is entirely possible to abide by the subscription agreement and make rebuilds, at worst you just need volunteers who are willing to.separate branded content from unbranded content (and to avoid distributing the former) on behalf of the project developers.
Scenario:
I work for ACME software. ACME is a Red Hat Customer. They license the software compliant with all RHEL terms, and get a copy of the binary and source. ACME gives me a copy of RHEL+Source to install on a VM.
I, ACME employee, have been distributed a copy of the Software, and am now entitled to redistribute in any way the GPL allows, and neither ACME nor Red Hat can stop me. ACME can choose to fire me if their local laws allow them to terminate me without case, but they can't stop me from redistributing it. If I work in a country where I have to be fired with cause, they might not be able to do so, as I would be operating within my legal rights as granted to me by the terms of the GPL.
If Red Hat tried to terminate ACME's license, I think ACME could sue for breach of contract if the reason was solely because I, a private citizen with my own rights and freedoms, chose to redistribute software in a way I was legally allowed to and ACME had to legally allow me to do so. They can fire me, but RHEL guys, I can't STOP them from doing it. I HAVE to let them, because the GPL required it.
The GPL doesn't make any distinction between employer/employee. The company (a legal entitity) distributed the software to me (yes, and employee, but the GPL doesn't make that distinction) and they can't forbid be from copying the binaries unless they can prove I WASN'T allowed to access them.
Even if RHEL isn't violating the GPL, they could be violating their contract with their customers if they cancel due to further distribution of an unrelated third party not covered by the contract.
Seems like the employees of the Linux distros should try this legal theory. Seems like it might work as a counter to Big Purple's work-around.
And then RHEL look at the source, note the changes that makes that copy of the source - you know the extra whitespace here, the bit there, an extra newline, all that... that makes the copy of the source unique.
Goes to ACME and says - hey that source leak came from you. Are you sure you are not going to agree to a large uplift in your support contract next year. Be so sad to lose you...
Wait for the employment contracts with severe penalties for leaking "open" source to appear. Won't be long.
Maybe I didn't make the scenario clear.
The fact that 'me' is the Sysadmin tasked with installing RHEL is irrelevant to the terms of the GPL and its guarantees. I am an employee/contractor, and I don't legally somehow become the company in this scenario, because we're talking about three entities. RH has a contract with ACME. ACME has a contract with ME. All three are parties to software conveyed under the terms of the GPL v2/v3, but RH has no contractual relationship to ME, and can't hold ME accountable for terms it negotiated with ACME.
So while your correction about providing binaries is correct, it's not really relevant to what I'm suggesting.
From a judge's perspective (at least here in the US,) it looks like this:
This is a breach of contract case. RH agreed to provide certain software and source, with terms that governed the reasons RH may cancel the contract. The ACME has their own employment contract with their employee. RH is obligated by the GPL to provide sources to ACME. ACME is obligated by the GPL to provide sources upon proper request by the employee. RH is not directly violating the GPL, and neither is ACME. ACME is *required* to provide the sources to ME, the completely separate entity they happen to employ. All parties are presumed to be familiar with the terms of the GPL before RH offered a contract to ACME, else RH had no right to distribute the kernel and other software covered by the either version of the GPL.
If RH cancels ACME's access, they have (potentially) violated their contract with ACME by terminating for reasons not allowed under the contract.
That's the thrust of what I'm getting at. it's not a GPL violation case - it's a breach of contract case by RH. RH would seemingly have to plead that they sell software that you can neither download or use, which is absurd and would not fly. They are selling software that they know (or should know) MUST be allowed to be distributed further without additional restriction, and if they purposely represent that the customer can have a service agreement for support for X months, and they put restrictions in there that they know the customer legally cannot comply with, then they're negotiating in bad faith.
That's just another "that cow doesn't produce enough milk" story. Someone has to pay for all those useless IBM managers.
Remember containers happened on Linux because windows server were not adapted to multi-tenancy in the hosting industry.
If RH want to go through the same rabbit hole, that's fine. HCPs like AWS, AZ and GCP already make RH less relevant than 10 years ago.
Serverless computing is growing fast and WASM is around the corner. RHEL will follow Oracle database. So long.
So, here’s a thought experiment: If Linus Torvalds used RHEL without paying, would he be a so called “non-customer”?
If RedHat wants to split the world into customers and non-customers, replacing the concept of the community with the latter, then they should go full proprietary, starting with the kernel. By the way, they shouldn’t ship stuff like GCC and so on.
IBM/Red Hat can do what it likes so long as it’s legal. As can we. Personally have removed Fedora from my personal laptop and gone back to Debian. And because I can no longer rely on a free, unencumbered, binary compatible downstream for RHEL will be actively avoiding RHEL in future system design decisions.
Possibly the collective actions of all the others like me won’t have a noticeable impact on Red Hat revenue, or this move will be a net positive for them, but I doubt it. Those relying on free downstreams aren’t going to start paying, they’ll pivot. There’s a reason why they’re not paying now, and this move won’t change that.
One dick move too many for this former CentOS and RHEL fan.
.....this debate is interesting.....but it is SPECIFICALLY about RHEL.
Now......most users of RHEL are using RHEL as a (possibly substantial) portion of their IT environment. But these users are dependent on the whole IT environment. They test in the whole environment. They execute disaster recovery tests for the whole environment.
The idea that they will rip out ONLY RHEL and replace RHEL with something else is very likely impossible.....
......unless of course they can terminate the whole of their business for an unknown period!!.....while the new environment is built and tested.
Perhaps RedHat know this??
Just saying!!
Dev transitions to A N Other distro. They find a few issues and resolve them.
Staging transitions to A N Other. They find a few more issues and resolve them.
Production transitions to A N Other.
Done.
The real question is one of cost. Is it cheaper to buy more licences to cover Dev and Staging, and work out how to automate activation for the ephemeral VMs spun up briefly in Dev and DevOps, or is it cheaper to transition to A N Other that has retained its free, unsupported downstream?
This is mainly going to hurt educational institutions and small business customers that were using RHEL in production, but a rebuild for dev and testing in order to save money. The educational customers in particular are unlikely to have the money to buy a bunch more licenses; they're more likely to switch to something else.
"After over a decade of trying, it may be that Red Hat has finally found a way to shut down the RHEL rebuild aftermarket."
The problem is that this can be written:
"After over a decade of trying, it may be that Red Hat has finally found a way to shut down the open source right to redistribute source, modified or unmodified"
and
" It never was under any obligation to provide ready-packaged source code in a form that made it easy for competitors to construct identical copies. That is not what the GPL – or any other FOSS license – was ever about."
Correct. The GPL was not about that. The GPL is about mutual co-operation not competition. The best and most successful open source products are ones where one contributor is ok with the fact that the contribution benefits a competitor, because the GPL means it goes back the other way. This works when the open source code is not anyone's actual product, but an enabler of added value. Clearly, Red Hat now thinks that open source is harmful to its business model because the source code is the product. For all the talk of "services", they now see themselves selling licensed source code. This is not a business model which works with open source (well, until this legal hack). Mongo DB and Elasticsearch solved the problem be deactivating the open source licensing. They could, because those companies had copyright in most of the code, and CLAs for the rest allowing relicensing. Red Hat can't do that because it has copyright to almost none of RHEL.
The GPL is about the freedom to modify and redistribute source. RHEL is noe only nominally compliant with this. If people had known that this was the deal with RHEL before they committed to it, that's one kettle of fish. But Red Hat has pulled basically a relicensing trick. It's not very nice. This is enterprise software with long life cycles, they should have dated this to take effect at the next release. I think it is against the spirit of free software, and I think it is a bit unethical. I hope Red Hat takes a big reputational hit for this.
"Setting aside the large numbers of angry people who don't really understand how open source licenses work, our impression is that the core issue here is that there are an awful lot of people who feel that simply because this is Linux, they have some kind of right to get it for free. Unfortunately, they don't. That is not what the "free" in Free Software means, and it never was."
That's how I understand it. If you get the binaries, then you are entitled to the source and the GPL allows you to redistribute it. They can't stop you redistributing the source that you've been given, but they can cut you off from receiving further binaries that you haven't already paid for, which then removes the entitlement to the source. If there's anything amiss here then I'm sure FSF will be all over it. I'd have thought we would have heard by now.
On the other hand, how will RH know who is redistributing the source if it finds its way back into Rocky and the other clones? And I can't help thinking this is what has been hinted at.
The case here is a bad-faith contract. Because RH sells software, they either have to expect that it will just be bought and never downloaded, copied, or installed, which is bad faith. OR they have to be making a contract that they know the customer will be potentially required to violate, which is also bad faith. The critical flaw in their plan is the employer/employee relationship.
Inside RH customer's someone has to install the software. An employee. Now to RH that's all the same thing legally - there's nothing new or weird about that. But the the customer, they have to have some actually download/install RHEL, and the second they do that, the employer is distributing to the employee a binary whose code is covered by the GPL. The GPL doesn't care about employer/employee, and almost every legal system very much treats the employee and employer as separate legal entities. All that employment law about how each must act toward the other, that's all great but has nothing to do with the GPL. One legal entity has conveyed the copylefted software to another, and now that employee has all the rights and responsibilities covered by the GPL.
That's the rub - RH is selling support contracts that are ostensibly for X months, but (by virtue of GPLed software being the very core of their business) know that as soon as someone actually downloaded RHEL, they will be required to do something that will make it so that RH can cancel their contract. Thus, the 'contact was negotiated in bad faith' cause of action.
This distinction between customer (employer) and employee seems like an abstract thought experiment. I don't see it working that way in practice. If there was any argument that the customer is breaching the support contract in this way, it would be for RH to enforce. They would never enforce that construction. It would make no sense from a business standpoint, and if they did it would almost certainly be shot down. All we can really say is that the contract could be interpreted such that a customer sharing binaries and source code with its employees is in technical breach, but that breach does not operate automatically.
There's multiple relationships, and not all of them are between the same party.
RH is saying in effect that:
We are obligated to give you this source, and you must give it to at least one person (else you can't even DOWNLOAD it, much less install it or use it.) You must give that person the right to obtain the source. You do not have the right to refuse that person if they should ask. If you don't violate their rights, we will terminate the service contract. If you don't violate your employees rights under the GPL, then you are in violation of the GPL yourself, and are open to suit from the SFC or loss of your license. So we are taking your money, for a service we know, or plausibly should have known (since our whole business revolves around the same license) you can't actually use without violating the terms of the service.
There's no way that would survive any sort of sane challenge. One might even be able to prove a crime based on whether the RH was being reckless or negligent. Depending if one could meet prove the necessary scienter requirements, it might also be criminal fraud. A creative DA who is actually a lawyer (I am not, I just read a lot of legal opinions and blogs) might be able to prove incitement or inducement to commit fraud.
Maybe we just need to find a savvy DA rather than a company willing to sue. :D
Only if Red Hat tried to enforce this ridiculous construction of the contract which argues that the customer is in breach simply because it shares binaries and code with its employees responsible for installing it, would anyone have a claim that the contract was made in bad faith. This is fanciful. I'll tell you what, if they do that then they will lose all of their customers. Period. They will not do not do that, so this silly thought experiment can come to an end.
"One might even be able to prove a crime based on whether the RH was being reckless or negligent."
I really have no idea where this is coming from. All of this ultimately rests on an assumption that Red Hat would enforce their contract in a way that is ultimately unenforceable.
Your position makes no sense.
As per the logic I described, the ACME employee would then continuously mirror the sources out to sundry and all. I didn't spell that out because I thought it wasn't needed.
So at that point, there's a public mirror that's doing an end-run around Red Hat's terms the way they tried to do an end-run around the GPL. RH would either have to just give up enforcing the contract against anyone at all, or would have to enforce the terms against the company that the employee is using as the upstream mirror, and invite the suit I described. Either way, they lose.
And that doesn't cover the criminal side of things either. That depends on a DA's discretion whether a case is brought.
You didn't say anything about a public mirror. Your case was suggesting that giving the binaries and source to an employee for them to install was breaching the contract. But yes, what the employee then does with it by exercising their rights is crucial. So you suggest the employee might then create a public mirror. Okay. It raises an interesting problem, but I think the contract that the employer has with the employee could cater for this. Employer says that employee is not permitted to distribute this particular software that they work with in the course of their employment or else they are liable to be terminated. Effectively the employment contract stipulates that the employee will not exercise their rights under the GPL in this instance. GPL gives you the right to redistribute software. It does not give you the right to be employed. You can be terminated for doing some things that are otherwise within your rights as a private person.
And interestingly, once the employment is terminated, one way of the other, there is certainly nothing stopping the former employee distributing the software. It's a big can of worms. If the employee did create a public mirror and Red Hat were able to determine that this person received the software in their capacity of working for the customer, would they terminate the support contract? Maybe. Probably. And because of this, the employer would have a strong case that the employee's actions were harming its business. The GPL right to redistribute is not incompatible.
The law is not always logical, and often terms of art in a contract will modify the usual meaning. Anyway, there seem to be a lot of ways around this restriction that RH are trying to impose. Rocky Linux thinks it won't stop them. It was an ill advised move, and I think it will not help Red Hat's bottom line.
Debian's official support lifecycles are not even remotely close to RHEL/CentOS and despite all the container hype a majority of businesses rely largely on bare metal servers which get purchased, installed and then run for up to a decade with no more intervention than absolutely necessary. Complete OS major version upgrades are definitely not on the agenda.
In my decades of personal experience with Debian (which I use on many servers) it has never lived up to the propaganda of effortless reliable upgrades between versions. It's a useful, decent distro (switch to systemD notwithstanding) but it is not RHEL/CentOS and I would never risk upgrading a production server from one version of Debian to another.
The "effortless reliable upgrades between versions". has never been something I have ever seen anyone say about Debian and I got Linux magazines and books from the start of the century that talk about Debian.
There are several backup and snapshot tools both with gui and without it that you can use to revert things if something goes wrong so this is not that nightmare that it used to be.
Still a clean install tends to still be the better method.
Definitely a more pleasant experience, headaches and all that dealing with modem Windows.
Then again I think I would prefer a kick in the dragon balls that being one of those poor tech people who gets called in any time Windows "updates" and breaks things.
I don't upgrade RHEL/CentOS servers from one version to another, either. It's officially not supported. You're supposed to install from scratch for each new major version. Debian and Ubuntu will let you do it, but it doesn't always go smoothly. FreeBSD is the only OS where I've found upgrades across major versions to be reliable, if time consuming.
There could be a knock on effect to the whole Linux community should people start to move away from RHEL to others in the future over this though, as RH devs contribute a lot of work to open source projects and in the event this move backfires on IBM and actually their revenues go down because people start to switch to Ubuntu or Suse. Then IBM may look to shed more jobs in the RH division to keep the bean counters happy, which ultimately means less people developing on Linux overall.
As for how the other distros such as Rocky and Alma Linux get around not being able to compile from the RHEL source anymore, I guess they can still download the RHEL source code from IBM and then compare that again the Centos Stream sources, find where they match and compile their builds from Centos stream source and patches that way and still be compliant with the TOS of the RH dev accounts?
Maybe they have a way of automating this process with machine learning or other tools?
"as RH devs contribute a lot of work to open source projects "
RH derivatives, not actual RHEL with paid support. Which is the thing here: RH as corporation (or licenced RHEL users) doesn't provide much useful stuff to open source community.
RH CEO *has* to know that, he's just a greedy bastard.
Reading this article to August 1991 All Mighty Senators bootleg from archive.org.
Red Hat's desperation has been evident for a while, OpenShift is just not pulling in the revenue required to float these corporate beasts IBM/RH. Too many employees vs revenue, that ratio is out of whack for them. See exxon or apple for a decent ratio. Oracle's is ok for now. Ubuntu is lean and mean, decent ratio. SuSE and Rancher have problems, too many employees, sorry...
This is tricky territory.
Basically, if someone writes a piece of software and distributes it under a license that says "absolutely anyone can have this for free, pass on the source", all you can conclude is that they meant it and are entirely happy that people or companies do as the words say.
If anyone else starts re-interpretting their express, written-in-black-and-white-text and seeks to include clauses like "unless you're a mega-corp in which case cough up", you are in a very real way wrongly claiming some ownership of the source code and the right to alter the license terms. That, I suggest, is something the original author would like to dispute with you.
Whilst you may think that the mega-corp is unreasonably freeloading, it's only the author's view that matters. If the author decides that, really, they'd rather get some revenue for their labours, they have to re-license the code. That's a bit awkward if they've accepted contributions from others who disagree with the re-licensing.
I wonder if Bruce Perens is going to venture an opinion this time round?
It's one thing to do so in the face of a small company like GR and their lawyers, but I reckon IBM can afford bigger legal guns.
Basically, the way I see it is, if he says something like "yeah, IBM can do this, it's their right", he might have to explain why his opinion has changed, and an "expert" on the matter changing his mind when the GPL2 text hasn't starts making the expert look less expert than claimed, and his expert witness testimonies in various courts might get revisited.
Whereas if he repeats his GR opinion, IBM might be minded to make life uncomfortable for him and oblige him to explain himself, expensively.
It might just be difficult for him to continue any public work on the matter. That's not really a good thing - GPL needs it's defenders - but we might now see a consequence to him arising from a fairly pointless attack on a comparatively small company. Could have saved his guns for a more important battle...
and not just in the US.
You may have spotted from some of the above comments that I am not at all convinced that RH's stance is breaking the GPL as it stands. Clearly, many disagree - I'd love to disagree with myself on this, but so far none of the argument[1] has been convincing. RH have followed the Capitalist Dream, a loophole that they have driven a railway spike into.
Aside from walking away from RH, the only other way this can progress is to test it in court - but has the GPL already been tested enough in court that taking on this specific pont of interpretation and "in the spirit of" will be *the* point challenged or does it risk upsetting the whole apple cart? IANAL and hopefully have missed reports of GPL being demonstrated to be robust in court.
Walking away from RH poses - interesting - challenges. As individuals, we aren't RH's customers (not any more - I did buy a boxed copy in the 90s to run on the 486, but never even upgraded it).
How about discussing[2] positive ways of weening their actual customers off RHEL? Some comments have come from people in the depths of such companies - what would affect their choice to renew with RHEL? Anything better than passing FUD up the chain of command would be preferable...
[1] yes, argument, singular.
[2] yeah, this comment is over a day late and won't be spotted by many now, ah well
Nobody is trying to steal Red Hat's lunch. Who was the first open source billion dollar company? Red Hat. How did they get the there. They built a loyal community. This week Red Hat has chosen to further distance itself from that community. With open source, "we stand on the shoulders of giants." Much of what makes Red Hat useful is the software that surrounds it. Would I choose linux if I couldn't install a browser, office suite, email client.... no. The companies decision doesn't make business sense. They have opened the door for their competitors (fortunately there are many). Customers "voting with their feet" will take a while, but it will happen.
> Nobody is trying to steal Red Hat's lunch.
CentOS/Alma/Rocky aren't trying to steal the lunch, they supply SW but they don't sell anything.
Oracle on the other hand are trying to steal RH's income, they take the code from RH and then have a business model of selling support for less than RH do. So I suspect that RH saw OEL as trying to steal their lunch even before IBM got involved.
True, but if you read the statement (Whinge) from RH this is how they view it.
To some extent and I see where they are coming from, Oracle are not providing any effort directly towards the development of RHEL they are just using it another another source of yacht buying funds. I guess elsewhere Oracle are investing in Linux development. I know some shit hot Linux people who are or were, employed by Oracle.
My reading of the GPL is that they can't impose extra conditions and implying they will terminate you as a customer would be construed as being an extra condition particularly since it removes the fundamental right of the GPL. But then I'm not a lawyer.
The tone of this is generally highly critical, but it can't directly point to any violation on Red Hat's part.
Of course not. RedHat haven't started trying to enforce this new license regime yet.
They said themselves "No third party can effectively monitor RHEL compliance with the GPL agreements."
As soon as RedHat tries to come down on someone for redistributing GPL code, they want to hear about it, then we'll see if RedHat's policies stand up to legal scrutiny: "SFC serves as the global watchdog for GPL compliance, we welcome reports of RHEL-related violations. "
"The core argument is that the free rebuilds of RHEL add no value either to Red Hat as a company or to the open source ecosystem as a whole"
Which, of course is blatant bullshit, on both cases. Either he knows he lies or he's a moron. Or both, perhaps.
Major part of the drivers and other stuff comes from users of "rebuilds" of RHEL as there are only so many RHEL users compared to them others. Also without those "rebuilds" those drivers wouldn't exist at all because no-one pays RHEL for home use.
RedHat is assuming a position of a leech, just stealing GPL'd software from the ecosystem to make more profit. Not a surprise from IBM-owned corporation. It's also obvious they know exactly how little they produce their own code: The rest is stolen from others: "Hey mom, can I sell the code this other person owns? Sure you can, go ahead, it's free to use!"
In the longer term, this will affect IBM's Red Hat tentacle very badly. Cutting off RHEL from general source access cuts the number of eyes looking at that source to a small fraction of what they have now. Auditing IBM's releases is hardly something a customer would expect to do, so until the next frozen major release, nobody knows, apart from the gagged customers, what IBM is adding or changing?
And all this in-house "secret sauce" won't have more unidentified holes in it than usual?
Updated source will get leaked of course and the ransomware gangs will have a field day.
Operating systems with restricted availability source are gold mines of zero day exploits.
What I imagine will happen, if IBM persists in its efforts to close off the source to only paying customers through more and more creative contractual inventions, is that RHEL will simply fork and be taken over by a foundation that will appreciate and nurture the open source ecosystem that sustains it. Red Hat is not special. Yes, it does invest in creating software solutions that benefit its business, but anyone with similar skills and investment can do the same, and a foundation or consortium of commercial companies with the backing of the open source community can achieve great things for the benefit of many. The industry will move on and Red Hat as a brand will die off. RHEL will get a new name. If you want to contribute to the open source project, then you need to play by the rules.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
