Red Hat Enterprise Linux Sources Will Now Be Available To Paying Customers Only (redhat.com) 143
"CentOS Stream will now be the sole repository for public RHEL-related source code releases..." Red Hat posted this week on its blog, arguing that "The engagement around CentOS Stream, the engineering levels of investment, and the new priorities we're addressing for customers and partners now make maintaining separate, redundant, repositories inefficient."
Long-time Slashdot reader slack_justyb notes this means patches and changes will now hit CentOS Stream before actually hitting RHEL, which "will make it difficult for other distributions such as Alma Linux, Rocky Linux, and Oracle Linux to provide assured binary compatibility as their only source now will be ahead of what RHEL is actually using."
"Some commentators are pointing out that it's possible to sign up for a free Red Hat Developer account, and obtain the source code legitimately that way," writes the Register. "This is perfectly true, but the problem is that the license agreement that you have to sign to get that account prevents you from redistributing the software." Hackaday notes that beyond the the GPL v2 license on the kernel, Red Hat also has "an additional user agreement that terminates access to updates if the code is re-published."
Rocky Linux officially "remains confident in its ability to continue as a bug-for-bug compatible and freely available alternative to Red Hat Enterprise Linux, despite changes in accessibility." While this decision does change the automation we use for building Rocky Linux, we have already created a short term mitigation and are developing the longer term strategy. There will be no disruption or change for any Rocky Linux users, collaborators, or partners... The project pledges to keep its promise to maintain the full life-span of support for Rocky 8 and 9, and to continue to produce future RHEL-compatible versions as long as the option remains, allowing organizations to maintain the flexibility, control, and freedom they rely upon for their critical infrastructure. This is the open source way.
Gregory Kurtzer, founder of the Rocky Linux project, calls Red Hat's move "a minor inconvenience for the Rocky Linux team," but with "no disruption to Rocky Linux users. Moving forward we are becoming even more stable, supported, and secure."
AlmaLinux also weighs in: Can you just use CentOS Stream sources?
No, we are committed to remaining a downstream RHEL clone, and using CentOS Stream sources would make us upstream of RHEL. CentOS Stream sources, while being upstream of RHEL, do not always include all patches and updates that are included in RHEL packages.
Is Red Hat trying to kill downstream clones?
We cannot speak to Red Hat's intentions, and can only point to the things they have said publicly. We have had an incredible working relationship with Red Hat through the life of AlmaLinux OS and we hope to see that continue.
Long-time Slashdot reader slack_justyb notes this means patches and changes will now hit CentOS Stream before actually hitting RHEL, which "will make it difficult for other distributions such as Alma Linux, Rocky Linux, and Oracle Linux to provide assured binary compatibility as their only source now will be ahead of what RHEL is actually using."
"Some commentators are pointing out that it's possible to sign up for a free Red Hat Developer account, and obtain the source code legitimately that way," writes the Register. "This is perfectly true, but the problem is that the license agreement that you have to sign to get that account prevents you from redistributing the software." Hackaday notes that beyond the the GPL v2 license on the kernel, Red Hat also has "an additional user agreement that terminates access to updates if the code is re-published."
Rocky Linux officially "remains confident in its ability to continue as a bug-for-bug compatible and freely available alternative to Red Hat Enterprise Linux, despite changes in accessibility." While this decision does change the automation we use for building Rocky Linux, we have already created a short term mitigation and are developing the longer term strategy. There will be no disruption or change for any Rocky Linux users, collaborators, or partners... The project pledges to keep its promise to maintain the full life-span of support for Rocky 8 and 9, and to continue to produce future RHEL-compatible versions as long as the option remains, allowing organizations to maintain the flexibility, control, and freedom they rely upon for their critical infrastructure. This is the open source way.
Gregory Kurtzer, founder of the Rocky Linux project, calls Red Hat's move "a minor inconvenience for the Rocky Linux team," but with "no disruption to Rocky Linux users. Moving forward we are becoming even more stable, supported, and secure."
AlmaLinux also weighs in: Can you just use CentOS Stream sources?
No, we are committed to remaining a downstream RHEL clone, and using CentOS Stream sources would make us upstream of RHEL. CentOS Stream sources, while being upstream of RHEL, do not always include all patches and updates that are included in RHEL packages.
Is Red Hat trying to kill downstream clones?
We cannot speak to Red Hat's intentions, and can only point to the things they have said publicly. We have had an incredible working relationship with Red Hat through the life of AlmaLinux OS and we hope to see that continue.
Maybe time to look at the BSDs again (Score:3)
The Linux ecosystem seems to be going downhill in a hurry.
Comment removed (Score:5, Informative)
Re: (Score:2)
> I don't know? Debian?
Yes, Debian is the base for stable linux services everywhere.
Bookworm has firmware now, and multimedia was solved in Bullseye so there's not much that doesn't work trivially.
Re: (Score:3)
Re: (Score:2)
Fuck off.
Re: (Score:2)
I came to this thread with only one actual question in mind: how is Red Hat allowed to do what it seems this article suggests they're going to?
This comment is amazing. This is literally the only sentence you needed. And it's still more than twice as long as it needed to be. Just "How is Red Hat allowed to do this?" would be fine.
The really bizarre thing . . . did ChatGPT write all this? It doesn't tend to say things like "This doesn't really affect me directly, per se" and "I'm curious" does it?
The future is a mess.
Re: (Score:2)
There's a lot more to Linux than canonical and RH. They may be in your face more though, thanks to advertising.
Debian still exists.
Re:Maybe time to look at the BSDs again (Score:5, Insightful)
There's no problem this adds that BSD didn't have from the beginning. I.e. commercial derivatives of BSD were often nearly totally closed source. That wasn't, of course, true of the academic versions...usually.
Re: Maybe time to look at the BSDs again (Score:2)
Re: (Score:2)
Re: (Score:2)
Mostly on the Redhat branch of the family tree.
Still plenty of viable options.
Re: (Score:2)
The Redhat is not the Linux ecosystem. Redhat has always been the Microsoft of the Linux world.
's/Red Hat/IBM/g' (Score:3)
to get to the truth.
Re:'s/Red Hat/IBM/g' (Score:5, Informative)
While I'm sure that didn't help things/might have accelerated the timetable, RH has been trying to squash clones pretty much since the clones first came into existence. Well before the IBM acquisition I was in the room with some RH business folks on occasion and a favorite topic was ranting about 'freeloaders' using CentOS, and various ideas they were floating to try to "fix" the problem, penalizing paying customers if they were found to also have some CentOS deployed elsewhere, curtailing CentOS project efforts in various ways, etc.
Re: (Score:2)
Easy:
-When clones started, they came down hard on trademarks to make 'sanitation' hard. However the clones persisted, but RH didn't have the will to push harder. Which was also probably best for their business model, as the early 2000s still had the phenomenon of startups using free linux 'graduating' to paid linux and needing a nice place to start that would logically land with RH.
-RH took control of CentOS, and for *most* CentOS users, nothing changed.
However, some things did change. In RHEL, you have a
Re: (Score:3)
Of the messy things you described, the whole "keeping track of RH entitlements is much harder than just using a free distribution" has been a facet that has always been a killer for me. Even using RHEL is painful enough, can't imagine trying to handle it all in the context of a resold appliance.
The fact that RHEL has limited "free" usage for certain people, but you have to get into the entitlement management game amazed me that anyone would even bother thinking about that. It's none of the 'value' of RH an
Re: (Score:3)
RedHat has been pulling shenanigans for a long, long time. [slashdot.org] They don't need any help from IBM for their chicanery.
Re: (Score:2)
I was going to try Fedora (the KDE flavour) on my next system, but I assume IBM will start enshittifying that too before long.
I'll go with OpenSUSE I guess? Running Kubuntu now, but I don't like how snaps end up working, and they're really going all-in on snaps for everything...
Whatever. Still preferable to windows (Score:2)
In my workplace, you can have whatever you want on your desk, but mission critical stuff is either windows or redhat. A few versions behind. Still less of an exercise in getting blood from a stone than if windows were mandatory.
Lawsuit? (Score:2)
Re: (Score:2)
Hackaday notes that beyond the the GPL v2 license on the kernel, Red Hat also has "an additional user agreement that terminates access to updates if the code is re-published."
Unless they rewrote literally every other piece of the OS, it does seem likely. I doubt Red Hat's EULA can supersede the licenses of all the other pieces they're using but didn't create. This is a bit vague but "updates" on code that requires access to improvements be available by the original's licensing does seem like a potential breach, but IANAL.
Re:Lawsuit? (Score:5, Informative)
It surely doesn't violate the GPL or any open source license. Why would you think it does? The requirement to provide source code only applies to those to whom RH has distributed the binaries to. In other words the paying customers. Customers can download the SRPMS and distribute those to whomever they wish, which is likely how the downstream distros will do it, and RH cannot say anything about that, although perhaps RH could argue the .spec files themselves are copyrighted.
You, on the other hand, haven't been given a binary by RH, so you have no right to ask them for the source code. Remember licenses like the GPL only come into effect when re-distribution occurs. One does not even have to agree to the GPL to use GPL'd software. It drives me nuts when I see GPL'd software bundled on Windows that, when installing, show you the GPL and require you to click "I agree" to install.
Obviously RH is doing this to discourage the downstream distros. But it could also have to do with the cost of letting everyone in the world download the SRPMs directly.
Re: (Score:2)
True, but by the same license, Redhat will be unable do anything to prohibit people from distributiing the same GPL sources by the people that receive it.
Redhat may not be directly obligated to make their code free to everyone, even if it is covered by the GPL, but they cannot stop someone else from doing so, because the right to distribute GPL code you receive is granted by the person who gives you that code in the first place. If they did not mean to be doing this, then they should not be trying to d
Re: (Score:2)
You are right, this is no GPL violation but you can be sure it will make a lot of existing Fedora/ecosystem contributors unhappy. Is not like they aren't already bleeding contributors... see the recent example when Caolán McNamara left Red Hat, so the only choice Red Hat/IBM had was to stop packaging LibreOffice.
Re:Lawsuit? (Score:4, Interesting)
It does not violate the letter of the GPL, but certainly the spirit (retaliation against a customer for exercising their license rights).
GPL does not require you to distribute code to everyone, only to those that you share binaries with. So this means that by cutting off a customer from RHN, they no longer get binaries and therefore are not entitled to source code for the versions they were cut off from. So long as RH continues their practice of access control to even get the binary rpms, then they can restrict the src.rpms equally.
Re: (Score:2)
Yes, but if before you distribute binaries of GPL software to someone, can you have them sign an agreement not to redistribute the sources? Essentially say, "Yes, this is GPL software, but before we sell it to you, you have to waive your GPL rights." If they can't redistribute the sources, what's to stop IBM from having an agreement where buyers agree not to ask for the sources in the first place?
As I see it, this would violate the GPL by effectively adding new restrictions to the license, even if technic
Re: (Score:3)
It's not an extra restriction on the GPL it's a restriction on the RedHat Support Contract.
You can redistribute those sources just fine, assuming you remove the .spec file from the srpm, which is what makes the srpm valuable. Red hat may decide not to keep you as a customer, but there is no restriction to your freedom to distribute the sources provided.
You could claim it's retaliation, but it isn't, because customers willingly agree to the contracts knowing the term. The GPL isn't being violated in any way.
Re: Lawsuit? (Score:3)
Re: (Score:2)
Why do you think they are? They may be required to build the RPM but they aren't required technically to compile from the source, and replace the said binary.
Re: Lawsuit? (Score:5, Informative)
Re: Lawsuit? (Score:2)
Even if agreed to in advance, it's still retaliation. That doesn't make it illegal or against the gpl.
Re: (Score:3)
Yes, but if before you distribute binaries of GPL software to someone, can you have them sign an agreement not to redistribute the sources?
I would say "No" because your acceptance of the GPL is the only thing that allows you to distribute the software in any form at all. I think adding any new terms, prior to acceptance or after would violate Paragraph 2, section b [gnu.org]. Note, IANAL and I'm assuming GPL v2, which AFAIK is the most commonly used version.
Re: (Score:2)
They probably include some stuff with their code that isn't GPL, and could argue that it's THAT that is allowing them to cancel your subscription. (Certainly they include artwork that isn't GPL.)
Re: (Score:2)
CentOS back before R/IBM bought it out and presumably Rocky and Alma are quite careful to replace Redhat's trademarked images with their own to avoid that sort of thing.
Re: (Score:2)
Of course, there's tons of non-copyleft software that could be locked down as well.
Currently their stance is that their business contact termination can be terminated consistent with GPL. If hypothetically a court rules "nope, that's a further restriction", then RedHat might say "Fine, here's a public repository, but only for the copyleft stuff, the BSD/MIT/Apache stuff, however, is unavailable."
I found at least one article that doesn't like it, hopes it is a violation, but ultimately has to admit RedHat m
Re: Lawsuit? (Score:2)
GPL doesn't work like that. If you bundle proprietary things with GPL stuff, it's the proprietary things that become distributable, not the other way around. (If you, as a distributor, can't ensure that, then you're not allowed to start such packaging and distribution to begin with.)
Re: (Score:2)
If you *bundle*, that doesn't violate GPL. If you *link* in proprietary stuff, *then* that linked stuff is subject to the license (except the 'system library exception', otherwise you couldn't have GPL software on UNIX systems). If it is LGPL, then you can link as long as you cleanly delineate at a linking level without actually futzing with the source.
Re: (Score:2)
No the GPL does not magically open closed-source software. That's Microsoft FUD. When a GPL violation occurs, the entity that violated the GPL is now in a copyright infringement situation. At that point, besides any monetary damages that might arise from a lawsuit, they have three options going forward to mitigate the infringement:
1. remove the GPL'd software from their software
2. negotiate a proprietary license with the GPL'd software copyright holders (often impossible)
3. open all their source code un
Re: (Score:2)
GPL doesn't work like that. If you bundle proprietary things with GPL stuff, it's the proprietary things that become distributable, not the other way around. (If you, as a distributor, can't ensure that, then you're not allowed to start such packaging and distribution to begin with.)
GPL doesn't work like that either.
GPL applies to the source code, not the software, so there's no real bundling of proprietary things, at least not if you're thinking of GPL executables and non-GPL executables on the same system.
Now, where "bundling" does get you in trouble is if your GPL source code is using non-GPL libraries. Well then those libraries better have a compatible license or you can't actually satisfy the terms of the license.
Either way, I assume this doesn't actually violate the letter of the
Re:Lawsuit? (Score:5, Interesting)
But the GPL DOES state that you may not impose additional restrictions on anyone you provide a copy to. A court could easily decide that termination of the agreement as a penalty for exercising your rights under the GPL constitutes a restriction.
And that would void Redhat's right to distribute at all.
Re:Lawsuit? (Score:5, Informative)
Well, at least https://sfconservancy.org/blog... [sfconservancy.org] isn't so sure, even though they really want that to be the case:
Red Hat's lawyers clearly take the position that this business model complies with the GPL (though we aren't so sure), on grounds that that nothing in the GPL agreements requires an entity keep a business relationship with any other entity. They have further argued that such business relationships can be terminated based on any behaviors — including exercising rights guaranteed by the GPL agreements. Whether that analysis is correct is a matter of intense debate, and likely only a court case that disputed this particular issue would yield a definitive answer on whether that disagreeable behavior is permitted (or not) under the GPL agreements. Debates continue, even today, in copyleft expert circles, whether this model itself violates GPL. There is, however, no doubt that this provision is not in the spirit of the GPL agreements. The RHEL business model is unfriendly, captious, capricious, and cringe-worthy.
Re: (Score:2)
That's exactly why it will require a court to decide.
Re: (Score:2)
It may be up to a court to decide, but keep in mind that the GPL is written and maintained by the Free Software Foundation who have a vested interest in making sure that it is fully enforceable and very large portion of the software in RHEL is GNU software, so the FSF has standing to enforce against Red Hat. If a court decides that Red Hat did not violate the GPLv3 then the FSF always has the option to "fix" the GPL in a new GPLv4 version, then bump their software up to that version, so at the end of the d
Re: (Score:2)
You are right when Tivo did their thing, that FSF went and did GPLv3 to close the gap (which has been a tough sell for most software to embrace, *particularly* since it may be incompatible with SecureBoot depending on context, and a context that isn't necessarily controlled by the software distributor). So there's room to try.
However it may not be so straightforward. Keep in mind that GPL has been very careful not to just declare you have to have to share your source code with everyone. Not even requiring
Re: (Score:2)
Except they say they will distribute source to anyone who receives the binary from them. But not to sources to binaries the person has not yet received, and will not received.
That said, creates a whole fun level of aggravation to honor the 'for three years' requirement, knowing what version of binary you did or did not provide to the enduser in question for three years after terminating the access.
Re: (Score:2)
You can go through Red Hat's spywall and register for a "free" time limited subscription.
However, upon expiration of that subscription, even though you still possess the binaries (which still work, but honestly, it doesn't matter), the fact that you can no longer get the source is a violation of the GPL.
For a "customer", it is similar. Let's say I pay Red Hat for "support" and now have a longer lasting term subscription. As long as I continue to pay, I can continue to
Re: (Score:2)
Redhat is not obligated to provide source code to their product in perpetuity to people they have given it to. Sorry... the GPL doesn't work like that.
However, Redhat cannot directly stop someone who has received GPL code from redhat and turning around and distributing it freely, even if they are a paid subscriber to Redhat. Redhat may have indirect mechanisms to prevent, such as discontinuing a person's license, if they have means of tracing the source of someone who made their code available, but I
Re: (Score:2)
Section 3b does say,
Re: (Score:2)
Yes, for three years they still have to provide the source. However, they can be a pain in the ass about it. This was in fact an IBM policy back in the day for use of GPL software in products, you ship binary and the GPL, but require the user to reach out manually and request the source code. Then the source code would be mailed on CD to the requester. GPL even allows you to charge the requester for your costs associated with being a pain in the ass about source code distribution.
So either your subscript
Re: (Score:2)
It actually stipulates that you must offer it for at least three years. Frankly it's a pretty long term, for companies that may be easily out of business before their obligations are up.
Lawsuit? Nope, customers only complies with GPL. (Score:2)
Does this violate the gpl?
No. The GPL only requires you to distribute source to the people whom you distribute binaries to. There is no obligation to distribute to anyone else. Plus you can charge a reasonable distribution fee.
If you only distribute binaries to paying customers you are only obligated to distribute source to paying customers.
What the GPL uniquely does is prevent you from restricting what your paying customers can do with the source. They are free to make your source visible to the world.
Re: (Score:2)
b) Accompany it with a written offer, valid for at least three years, to give any third party, for a charge no more than your cost of physically performing source distribution, a complete machine-readable copy of the corresponding source code, to be distributed under the terms of Sections 1 and 2 above on a medium customarily used for software interchange; or,
Re: (Score:2)
GPLv2 section 3b:
b) Accompany it with a written offer, valid for at least three years, to give any third party, for a charge no more than your cost of physically performing source distribution, a complete machine-readable copy of the corresponding source code, to be distributed under the terms of Sections 1 and 2 above on a medium customarily used for software interchange; or,
The "thrid party" is the person "you" distributed your binary too, someone not a party to this agreement between the "copyright holder" and "you". Also note this is only one of your options. In the a) option you distribute you binary with the source and you are done. Again, you do not have to make it visible to the world. That is just a common courtesy.
Re: (Score:2)
It's not just "third party", it's "any third party". You seem convinced that this is only the person who received the binary, but what do you base this on? I don't see anything in the GPL license to support that idea.
If you look at question 6 of the GPL quiz [gnu.org], it even says "everyone".
Way to go slashdot... (Score:3)
One of the last sites that might carry this news to get around to posting this news....
Alma's statement is more careful and specific on how they are trying to cope short term, but admit a challenge amid hopes they can sort it out. Alma seems to think the path forward realistically must be done through some arrangement with RedHat, as there isn't a reasonable path forward under the RedHat terms.
Rocky's statement is confident, but their background discussion isn't consistent with that confidence:
https://etherpad.opendev.org/p... [opendev.org]
Currently, the main assumption is 'guess we'll subscribe to RHN and then things will be peachy', which as the summary points out, RH considers grounds for terminating your access to RH software. Well, either that or go into goat farming.
In any event, RH has been wanting to kill the clones for years, and IBM ownership has probably made that goal more important. They started from the onset by badgering the trademark issues to make it difficult to 'sanitize' a distribution, but the distributions still happened. They took over CentOS to basically kill CentOS bundling content from the "extra editions" of RedHat, and that pretty much worked. The broad CentOS user base didn't miss the extra packages and those that did use them found the SIG alternatives adequate, though not identical to RHEL equivalent editions.
Then of course ,CentOS stream to make it impossible for a lot of the 'enterprisey' use to get by on CentOS (explicitly incompatible with how a lot of third parties need enterprise linux lifecycle to work). Which spawned Alma and Rocky.
Now, finally, we get to them pushing things as far as they can while still dealing in some critical copyleft software, forbidding access to binaries to those that would facilitate clones, therefore getting out of their copyleft obligations. They *could* make things a bit more painful by closing off src.rpms for BSD/MIT/Apache type content, but I think they will try this out to see if it is sufficient to snuff out the clones.
Re: (Score:2)
You didn't link to AlmaLinux's statement, so here it is:
https://almalinux.org/blog/imp... [almalinux.org]
Seems pretty obvious Big Blue is trying to fight Google regarding who best personifies the motto "yes, do evil"...
Oh, and thanks again to the RedHat Leadership Puppets for selling their souls in the first place.
Re: (Score:3)
Google's too young to be really good at doing evil. IBM has had the "Do evil" model baked into them since at least WWII. IBM helped the Nazis keep the death camps humming. It's hard to compete with that.
Re: (Score:3)
Slightly disingenuous of your links/statement.
Rocky tries to be as transparent as possible. They have active conversations in the public. When they got this news, they were as surprised as many others. They had a PUBLIC meeting where ANYONE was invited on jitsi with notes on etherpad of "Whoa! What options do we have?" It seems sus to link to that and suggest they aren't confident when you are talking about their initial PUBLIC reaction vs where things are at days later.
Why not link to this?
https://rockylin [rockylinux.org]
Re: Way to go slashdot... (Score:2)
I never implied that Rocky wasn't committed to do the best they can, I'm saying they don't yet know a way forward. Which is same as Alma. Yes Rocky's prepared press release sells to instill confidence, but of course it does, that's the point.
Options include:
-clones figure out a way to keep on keeping on. If so, the catch is that rh will probably be looking to close whatever loophole they figure out.
-clones start trying to mimick based on CentOS stream. Unfortunately this stops short of the goal, as rh p
Re: (Score:2)
Right, so that leaves them in the unfortunate position of requiring people to violate the user agreement to continue existing. This may *technically* work, but it may not be legally advisable. Besides, RH seems to be of a mind to quash loopholes, so anticipate various measures to further screw things up for the clones. The free developer accounts, for example, may get much more restricted, or discontinued altogether.
GPL clauses (Score:2)
Cute.
But they've agreed to play in the open source pool:
a) Accompany it with the complete corresponding machine-readable
source code, which must be distributed under the terms of Sections
1 and 2 above on a medium customarily used for software interchange;
There's some other methods and clauses in there about how they can do that... but they MUST share the source code. No extra fees (past delivery), requirements, agreements, hoops, or any such thing.
Re: (Score:3)
And they're doing exactly that: for every customer they share binaries with, they're sharing the source code as well. That meets the terms of the GPL (and all the other Open Source licenses in RHEL, remember it's not all GPL).
However, there's no license that I'm aware of that says that once they give you access, they have to continue giving you access to future versions - that's purely governed under contract law (the terms and conditions of the RHEL subscription), not license law. So if they decide to stop
Re:GPL clauses (Score:5, Informative)
Red Hat doesn't really have a problem with people using them
So while working at a Red Hat partner before the pandemic, we had in-person meetings with some RedHat executives. So I haven't heard a pertinent conversation since 2019, but basically every year leading up to that I got to hear the RH execs grouse about CentOS. They rarely ever mentioned Oracle (I'm sure that pisses them off, but the extrapolated business impact isn't that big because Oracle just isn't that popular). Repeatedly called CentOS users freeloaders, and were talking about various ways they were considering to deal with the 'CentOS problem'. Your field rep probably doesn't care, or if they did, they know better than to sour a sales relationship over a lost cause, but RH leadership has long cared, though I'm sure there's different opinions competing for dictating the strategy.
Their main point of ire was that a customer might have 9,999 CentOS boxes and 1 RHEL box. Magically, all the support issues only happened on the 1 RHEL box. So they were kicking around the idea that you could run CentOS or you could run RHEL, but if you were found to be using a mix of RHEL or CentOS, your RHEL subscription would be invalidated. That was the 2019 conversation, and I suppose the prevailing strategy to the "CentOS" problem was "CentOS Stream". So then they had the "Alma/Rocky" problem, and I suppose this is a run at squashing that one.
Re: (Score:2)
Talking about an annual 1 day meeting I haven't attended in 4 years, I have no idea the specifics. Roughly however, it was a technical focused meeting rather than business, so the execs would have been basically babysitting us nerds, so probably not too high up the hierarchy. We are probably not that important a partner, so I'd expect basic mid-level management, barely "executives". High enough to show that our relationship warrants "executive" attention, but not high enough to be presumed shot callers.
At
Re: (Score:2)
for every customer they share binaries with, they're sharing the source code as well.
Which is all well and dandy. It'll only take a single customer to simply turn around and make the source code publicly available. Thank you GPL for all your fore-sight. .....EXCEPT they're making all their customers sign an agreement where they can no longer openly share the open-source GPL licensed source code with ANYONE.
And so any linux developer can go to any of their clients, ask for the source code that Red Hat gave them, and if they say "no", then the lawsuits start flowing.
Re: (Score:2)
That's not how the GPL works. Linus can't just walk into a random RHEL customer and demand source code or threaten to sue (well he could, but it'd be dumb and futile); sharing source code is only a condition of sharing binaries. So only if a RHEL customer was redistributing the binaries (which they already don't have a right to do under the subscription terms so would get their subscription cancelled) would that customer also have to redistribute the source (also getting their subscription cancelled).
Re: (Score:2)
Leaving the logistical issues aside that if GPL'd source code is being distributed, Redhat may not have any means to identify which party they might have given it to that is distributing it, I wonder if such punative action on the part of Redhat would constitute them trying to further restrct somone that they give the source code to from further distrributing it to whomever they want?
Obviously they cannot further di
Re: (Score:2)
So if you subscribe to RHEL, you receive binaries. You are able to get corresponding source to those binaries (per the GPL and some of the other applicable Open Source licenses). Under the license terms, you are free to redistribute that source.
However, Red Hat's subscription terms say they are free to stop providing you with access if you do so (just like they are free to stop providing that access if you stop paying, or probably for some other contract terms reasons too). Nothing in the GPL obligates them
Re: (Score:2)
But the GPL explicitly grants any receiver of source code that is so licensed with permission to redistribute it, and explicitly prevents the distributor of it from limiting the distribution of that source.
What is unclear is if redhat's threat to cancel a person's subscription if they simply release GPL source code that they obtained from redhat would constitute redhat attempting to impose such a restriction on redistribution.
I am also very skeptical that redhat is obligated to continue to provide sour
Re: (Score:2)
It's a fine line (that I can't claim to be sure of legal bits)... but Red Hat isn't restricting redistribution directly. They're saying they can cut off access to future software if you redistribute the current sources.
The future obligation is one way to satisfy the GPL (I'm specifically looking at GPLv2 since that's what the Linux kernel is under for example) source code requirement:
3. You may copy and distribute the Program (or a work based on it, under Section 2) in object code or executable form under the terms of Sections 1 and 2 above provided that you also do one of the following:
3(c) doesn't apply to RHEL at all, so Red Hat has the choice of 3(a) or 3(b). I would think that, since they make the source
Re: (Score:2)
I understand this.... what I'm wondering is if such punitive measures qualify as attempting to restrict distribution, which is expressly disallowed by the GPL, and would make Redhat in violation of it, if such measures qualified as restrictions.
I don't know the answer to this, but I sure wo
Re: (Score:2)
Does anyone know what would definitely, without question, qualify as restricting redistribution?
Just an easy example is what I'm looking for. Thanks,
Re: (Score:2)
Explicitly saying something that attempts to restrict distribution, such as for example, that you may not redistribute the source of a GPL source code without written from the party you received it from would certainly qualify as a disallowed restriction under the GPL. If you want to impose such a restriction, then you do not have the right to distribute the GPL'd work in the first place, unless you actually owned all of the copyrights in place on the work, in which case you wouldn't want to distribute u
Re: (Score:2)
Yes, any Linux dev can just walk into a random RHEL customer and demand source code.
If they get told "no, we can't, we agreed not to share the altered open source code" Then the dev can for sure sue Red Hat for taking their code and making it closed sourced, a clear violation of the GPL.
Re: (Score:2)
Yes, any Linux dev can just walk into a random RHEL customer and demand source code.
That's not how the GPL (nor any other Open Source license) works. You should try reading it, or asking a lawyer to explain it to you.
Incredibly frustrating (Score:5, Interesting)
I saw this news on AlmaLinux's Mastodon feed Wednesday - just as I was spinning up a new NFS server, in point of fact.
We're a very small Linux shop (university department). We don't make money from Linux... we're just trying to keep stuff running for our students and faculty. We've got engineering classes that have to use Linux, because a fair bit of engineering software (especially in the VLSI realm) is only available on Linux - and a lot of our students will end up working at engineering firms that run on Linux.
Every time IBM pulls another crap move like this, it wastes a chunk of time I don't really have. I am considering switching to Ubuntu, but a) that will take time, since our development and deployment is all centered around RHEL's paradigms; b) I don't yet know if all the software we need to use is compatible with Ubuntu, since these companies tend to narrowly support only certain very specific platforms; and c) I don't fully trust Canonical not to go down the same path as IBM in the future.
We don't have that many servers, so technically I could move them to RHEL proper - but at this point I don't want to support those IBM clowns on principal. Plus that wouldn't solve the problem of all the client workstations are students use... with those, we're way above the 16-device cutoff.
I don't need this. I'm just trying to do my job, and it's like these jackasses at IBM are actively working against me. Thanks for nothing.
Re: (Score:2)
Re: (Score:2)
Again, though, it comes back to "what distros are supported by the software we need to run?" I need to be sure that Cadence, Mentor Graphics, Synopsis, etc. etc. are all officially supported on whatever distro we use - and run well, without a lot of manual fiddling. Plus I have to sell the faculty on it.
Re: (Score:2)
The ironic thing is most of the engineering software these days is built for Windows. The Linux version is basically done with a commercial version of something similar to WineLib that lets you compile Windo
Re: (Score:2)
You sound understaffed.
Once IBM took over all the Redhat rules changed.
Old assumptions need to be discarded - any engineer can understand that when conditions change solutions must too.
Have them get you some help to deal with a sea change.
Debian is never going to look for an 'angle' to get more money out of you.
You sure its "Linux" not POSIX? (Score:2)
... a fair bit of engineering software (especially in the VLSI realm) is only available on Linux ...
Are you sure about that? A lot of "Linux" software is really POSIX software and builds and runs on BSD just fine.
Re: (Score:2)
These companies aren't giving out the source for their proprietary products - for the most part you're getting installers for pre-built binaries.
Re: (Score:2)
These companies aren't giving out the source for their proprietary products - for the most part you're getting installers for pre-built binaries.
"FreeBSD provides optional binary compatibility with Linux, commonly referred to as Linuxulator, allowing users to install and run unmodified Linux binaries."
https://docs.freebsd.org/en/bo... [freebsd.org].
If you look at the docs it is referring to CentOS so if your software has RedHat dependencies this might be an option.
FWIW, I'd look at Debian rather than Ubuntu. They seem more professional.
Best of luck.
Re: (Score:2)
That's interesting about FreeBSD - I didn't know about that at all. Thanks for the information!
I'll definitely take a look at Debian - as well as SUSE (which someone else mentioned).
Re: (Score:2)
I have seen exactly zero spam using Ubuntu. And where is this spyware? Are you referring to the decade-old issue where Ubuntu included an easily-disabled Amazon tie-in that they immediately removed when the community complained? Because that is only controversial to people who are motivated to hate Ubuntu and keep trying to spin a false narrative of spyware saturation based on that.
And based on this [wikipedia.org], Ubuntu was the only major Linux distro that even tried to support zfs. So by failing to support it, Ubun
systemD is fine guys right (Score:2)
Re: (Score:2)
Not that this or you have shown, no.
FTC (Score:2)
Given the effect the decision by IBM to cut access to the source has on the market, which effectively considers RH clones as public infrastructure, why hasn't the USA Federal Trade Commission stepped in, especially given the lock in through the OEM agreements with Microsoft & RH?
For example as with the Telecom industry attempt to move away from the Network Neutrality model in 2006.
https://itheresies.blogspot.com/2006_07_01_archive.html [blogspot.com]
https:// [ftc.gov]
Why an alternative build of Red Hat Enterprise ? (Score:2)
IBM Hat is nullifying their own license to distrib (Score:2)
I believe that by tacking extra restrictions onto the license the scumbags are IBM Hat are violating the GPL and lose their license to distribute GPL code for which they do not own the copyright. IBM is nullifying their right to distribute Linux and should be sent a cease and decist by
Looks like GPL violation to me (Score:2)
IANAL, but this is a clear violation of GPL. From the Registrar link in the story, "The key point being is that to obtain those binaries, customers – as well as developers on free accounts – must agree to a license agreement and are under the terms of a contract, which overrides the GPL license of the code itself."
If I am a customer of RHEL and I get the binary, then I have full rights to distribute the binaries. RHEL cannot prevent me from doing so. But if I distribute the binaries, then I have
Re: (Score:2)
I agree. I don't understand a lot of the commentary above - this appears to be a clear and obvious violation of the GPL and is exactly the sort of thing that was discussed all over the place 20 years ago.
To my understanding:
1. RH are perfectly fine to restrict who can access their software. They can sell it to only a small group of customers, bundle it with other software, give it away for free, whatever they want. The only restriction on them is that they must make the source code available to anyone who t
Re: (Score:2)
I want to believe that, but I think IBM's lawyers are smart enough (and evil enough) to figure out a way to violate the spirit of section 3 without technically violating the letter thereof.
I also think that this needs to eventually be tested in court, and will be, and that, if IBM gets away with it, there needs to be a response from the community. Which could involve one or more of the following:
IBM wants more money (Score:2)
IBM want's more money and doesn't like the fact that they believe others are benefiting from their work. They paid a lot for RedHat and would like to monetise it as much as possible.
They'd like to conveniently ignore the fact that RHEL profits from other peoples work and the majority of their value add is simply packaging the software.
IBM are trying to place additional restrictions on the software distribution process which appears, prima facie, to be explicitly against the requirements of the GPL.
Whlle I l
Re: (Score:2)
Yes they do have an obligation, however they have adopted a business model with a legal model which is in conflict with their current approach.
IBM did not write linux or the vast majority of the tools associated with the distribution, they're simply package maintainers.
Yes maximise value for shareholders, however do it legally. Open source GPL software simply isn't as profitable as other forms of software, IBM either knew this or should have known this when they bought Redhat, to try to skirt around this i
GPL Issues (Score:2)
Red Hat is attempting to skirt the GPL by putting their subscription users under contract, basically saying that you can exorsize your rights to redistribute the source under the GPL, but if you do so they will terminate your subscription. I believe that this action of "punishing" a user violates at least the spirit, if not the letter of the GPL.
There is a lot of GNU software in RHEL (e.g. bash, GNU coreutils, gnupg, gcc, emacs ... the list goes on and on). If the Free Software Foundation were to lay down
GPL vs BSD (Score:2)
Perhaps Red Hat intends to release the Corresponding Source to GPL-licensed programs freely, as that license requires, but keep BSD-licenced programs proprietary. That would probably be legal, and would still disrupt RHEL-derived distros.
It would also illustrate the utility of the GNU General Public License, from the perspective of a software developer: it prevents evil corporations from restricting redistribuition of modifications to your code.
DoD is a big freeloader (Score:2)
Re: (Score:2)
They are not a freeloader, they're simply using the software under the licence as allowed.
Redhat only provides support and packaging and the packaging is GPL. So if you don't need support it's silly to buy it. IBM is simply pissed that the open source business model is not as profitable as they think it should be. Their vision is that all of the clone users will be forced to use Redhat if they block access to SRPMs. The reality is that the majority of users will simply move to another distribution.
Debian pa
Re: (Score:2)