Would it be feasible to sed-replace the RHEL and/or Fedora selinux and container-selinux rulesets for use with other Linux distros?
AFAIU only SUSE can run both AppArmor and SELinux?
And browsers are running as unconfined in selinux with like all major distros; even on ChromiumOS (which was based on Gentoo, Gnome, and Chrome) where WASM or a paid shell (or 15-30% cut from the Play Store only) is the only way for the kids to Python on the Chromebooks we bought them for school.
Wouldn't it be great for them to not have to switch OSes and distros throughout the day.
Is this a clickbait title? Or do I misunderstand the word enterprise?
They are not done with using Linux for "a project or undertaking, typically one that is difficult or requires effort." or "a business or company."
They are no longer going to use a specific version of linux that was made by "a business or company."
Do people really care that much about linux distros? Between 2 decades of personal use and a few years of professional Fortune 20 use, linux seems to be linux to me. (Could just be that I have stuck to Debian flavors)
Red Hat Enterprise Linux is the name of a product.
Geerling supports a massive collection of Ansible playbooks, which goes pretty far beyond anybody’s personal use of Linux and would explain why this is a bigger deal than you or I ditching support for a distro.
In response to the origin post that Linux is Linux. Kubernetes and Docker tries really hard to hide this differentiator of Linux distros.
> but it seems most developers today can't install anything that isn't an npm package
It gets worse than that. It's a daily struggle to explain the different between npm, yarn and pnpm for example. If only they understood what is "an npm package".
Yes, we care about flavors of Linux in the enterprise. RHEL is an industry standard distribution that nearly all vendors support. We have a significant amount of commercial software that is only supported on RHEL or its derivates. Not running on a supported distro? You get no support. That’s a non-starter for mission critical systems in the enterprise.
We used to be able to run this software, fully supported, on CentOS. IBM pulled the rug out from under us. Rocky and Alma rose to the occasion, and the various vendors supported one or both, since it was still RHEL minus branding. Now IBM is cutting off those distros also in an attempt to force everyone into RHEL licenses and support contracts.
But because it IS Linux, after all, a lot of enterprises like mine have NEVER needed support for the OS itself. We just needed our vendors to support their software running on it, and we needed vulnarability patching on the OS, something which CentOS, Rocky, and Alma always provided.
If I had my way, 100% of what we run would be on Debian. I have Debian running everywhere possible. But not all 3rd party applications support Debian. I’m hoping that one consequence of IBM’s move here will be to drive them all to Debian.
Yeah, I'm hopeful the five year support window for Debian LTS releases now will help drive that migration. I suspect though the lowest-effort path for migrating from one commercial vendor to another will be towards Canonical, given Ubuntu's LTS releases and existing infrastructure around commercial support / certified hardware compatibility lists / etc. I may not be a huge fan of some of their decisions over the years but as my objections have tended to be technical rather than business/contractual/ethical I think they'd be nicer to deal with than IBM or Oracle, heh. :)
There can be quite a number of distro-specific quirks to bear in mind if you're targeting more than one, enough so that as a downstream product vendor it's nice to only have one or two ideally slowly-moving targets (say, RHEL and Ubuntu LTS) to test on/document/support instead of dozens. In turn it's also nice as an end-user to have a platform with long periods of stability/support so you're not having to rebuild/retune your systems' foundational bits every year.
(I have no particular dog in this fight. I mostly left the RedHat ecosystem behind a long time ago, but I understand it's still a big deal for a lot of vendors and clients. From an individual dev/user perspective, I agree that more or less as long as whatever is a posix-y environment, I can figure it out and get my work done, whether it's solaris or slackware or whatever haha.)
I'm surprised at all of the drama surrounding Red Hat's decisions. Red Hat is a for-profit company and not a charity. They (Red Hat) don't make any claims of offering RHEL for free to the whole world. If you want that, Canonical's Ubuntu may be a better option for you. Am I missing something?
I'm asking this non-facetiously: Is there a wikipedia page or a written record of all the people/corps who've been taken to task in court over a GPL violation, or a large company such as IBM? If yes, was the penalty commensurate?
It is incomplete however. For example, there was a long-running lawsuit against VMware that was never resolved. [1] Was sort of an odd case and pretty much no one else in the industry wanted to go near it.
] if you are redistributing copies of free software, you might as well charge a substantial fee and make some money. Redistributing free software is a good and legitimate activity; if you do it, you might as well make a profit from it. ...
] Except for one special situation, the GNU General Public License (GNU GPL) has no requirements about how much you can charge for distributing a copy of free software. You can charge nothing, a penny, a dollar, or a billion dollars. It's up to you, and the marketplace, ...
That's why the linked-to essays says "Technically, the GPL allows [a paywall]" from the text.
No they only have to offer source code to users of their software. In order to use their software you have to buy a license. They have been giving it away for years but are not obligated to. When GNU first came out they sold their source code for thousands of dollars and this is the format GPL was written to enforce.
You could run the things on CentOS just fine, but when you had need 'a supported solution' you just bought RHEL and did all the same things, just against 'a supportrd solution' and RH got their money.
No, anyone can definitely email them and ask for the code. If they refuse then thats a GPL violation and the copyright owner can sue them. The Software Freedom Conservancy are also working on a case using the legal theory that downstream recipients of GPLed code are third-party beneficiaries of the GPL agreement between the copyright holder and the redistributor, and as such, they are entitled to the source code and can sue for it. Hopefully they win, send them some donations towards legal costs if you want to help out.
> No, anyone can definitely email them and ask for the code. If they refuse then thats a GPL violation and the copyright owner can sue them.
Curious; I was quite sure that only recipients of binaries (basically, users of the program) were entitled to get source code, but the relevant part of the GPLv2 (https://www.gnu.org/licenses/old-licenses/gpl-2.0.html) at least looks like:
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:
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; or,
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,
c) Accompany it with the information you received as to the offer to distribute corresponding source code. (This alternative is allowed only for noncommercial distribution and only if you received the program in object code or executable form with such an offer, in accord with Subsection b above.)
which does indeed seem to suggest that if you're not preemptively shipping source to customers along with the binaries then "any third party" can ask for the code. Which is interesting context here; it would be interesting to hear an actual lawyer's reading of the situation, because that feels like such a big difference that it should have come up already.
i've been a long time lurker, non-commentator, oops. i just do most of my work on cent/rhel/rocky/oracle and i felt comfortable enough to join and comment for once
If they sold for profit and started putting their changes behind a paywall, that would be terrible. But they're just benefiting from Red Hat the same way that Red Hat benefits from upstream Linux. Red Hat is the one misbehaving here.
It would also still go in the other direction as well would it not? Meaning contributions via paid Red Hat devs would still benefit the wider Linux community, even as they close off the free forked versions.
I'm not sure exactly how much Red Hat contributes to Linux though but if I remember correctly it's quite a bit. Maybe Red Hat making more $$ = more devs. Or maybe this is just a net negative for the ecosystem code-wise (as opposed to just hurting the current users of the forked OSes) as it pushes more devs/software away from a very popular 'platform', reducing exposure, free online support on forums, testing, etc.
Red Hat is a huge contributor to Linux. They also are responsible for making it a trusted OS for people coming off traditional Unix in the 90s. They aren’t doing anything on the backs of others.
In what way is Red Hat not abiding by the license? My understanding is that Red Hat is making the source code available to their users via their customer portal. I don't think that they have an obligation to make their source code available to non-users.
They have an obligation under the GPL to allow end users to redistribute. Terminating the subscriber agreement for redistribution is punishing the user for exercising his right granted to him by the GPL.
End users are allowed to redistribute the source they received from Red Hat at their hearts content. What Red Hat is terminating, from my understanding, is the future access to new binaries and sources due to the service contract becoming void.
Your server will keep running, you'll have the sources for all the server's binaries, but no more support.
I mean, they’re within their right to pull support, but people are equally within their right to point out how that is shooting themselves and the RHEL communities in the foot.
This. What a good opportunity to compare: the (GitOps!) packaging workflows, build server security, software supply chain integrity controls, issue tracking / triage, wiki, documentation, kernel patching, cloud fuzzing / integration testing, and baseline MAC and DAC policies of the stable kernel patchset OSes within budget for schools, hobbyists, after workers, and corporations who can and for some services maybe should afford an SLA.
On worthwhile investments of time differentiating our offering in InfoSec and Operating Systems,
FWIU (RH) OpenShift (and MicroShift) does k8s containers most correctly in terms of separate SELinux contexts per container, which we should probably have for browser tabs, too. Do (a) browsers, (b) Cloudflare Runners, and (c) Docker WASM runtimes run WASM tasks without container-like process isolation; all as the same user and cgroup and context?
It's pretty sad. Red Hat should be optimizing for "maximum number of dollars over 10 years", not "maximum control over RHEL-compatible distribution". The second goal leads to more support for their competitors, and ultimately less people buying Red Hat subscriptions.
Anecdotally, we'll have to support more Linux varieties instead of comfortably mandating RHEL-compatible.
I don't think the author is expecting charitable behavior: it's more that Red Hat was deriving extraordinary amounts of value from his work, and was (partially) compensating for that by making his (and others') support for RHEL easier by providing them will access to RHEL.
In other words: Red Hat's behavior here is almost certainly going to make end-level support for their OS worse, not better, all for a tiny slice of their non-paying install base.
The sign-up path isn’t clear: When I signed up, it took a day for all the parts of Red Hat’s infrastructure to become aware of me. That delay wasn’t made clear at the time.
It expires every 12 months, and you have to take action to renew it, again with a not-very-clear path. It’s not possible to renew early (at least, I didn’t see how).
It adds extra friction: You don’t get a custom ISO or the like. Instead, you have to register your system during installation. It’s an extra step you don’t have to take.
There’s a subscriber agreement you must agree to, which not everyone wants to do.
The point is that this is a stupid decision. It will turn people off Red Hat, and at the same time it’s incredibly annoying and inconvenient for a large number of Rocky/Alma/etc users.
Most likely yes. Can't speak for other organizations but the one I work for licenses RHEL on our critical servers and uses CentOS/Alma on all non-critical infrastructure. Obviously the reason that is done is because it's easy to support what's essentially a single OS. With this new change, if Alma/Rocky go away we'll be looking at either Suse or Ubuntu most likely and RHEL will go away completely to be replaced with the licensed equivalents of Suse or Ubuntu so that we only need to support a single OS.
OpenSuse LEAP is 100% binary compatible with SLES. You can build an entire dev environment with LEAP, clone it and run a script to make it SLES.
Ubuntu is pushing snaps to hard IMHO. Suse is moving towards immutable OS with flatpacks, but doing so in a much more responsible manner that is not trying to lock down the ecosystem.
No, it won't unless the customer is also using upstream stuff elsewhere. But it will close an avenue of new customer acquisition. Can't say how often, but it happened that someone needed support for an upstream software (which is a big no-no) and ended up buying a downstream license.
Not directly but it might cause some upstream vendors and projects to rethink weather they want to recommend Red Hat as preferred platform and if the hosting vendors turn off the Red Hat clones that's going to ripple back to Red Hat, as a lot of corporate linux users will gravitate to the distro that's recommended by the application vendors.
Part of how canonical challenged Red Hat is that they deliberately made it really easy for a developer to run Ubuntu on their workstation and test environments.
That cuts both ways; RH doesn't owe anyone free (gratis) software, but they're also not entitled to good will or free work/contributions. Or users or customers, for that matter.
The issue here is the GPL and what does it provide, freedom wise , for a system that is built of other contributors who also released their work under the GPL. It is a bit funny to me that red hat wants to kill off clones of their os and plenty of people think this is ok and seeing it as freeloading because red hat gives back which I would say they may be required based on the GPL and their business model. Could the Linux foundation move to subscription base and charge red hat based on they also give back and suddenly require subscriptions? This though isn’t the first time I have seen the same story so I am less worried. I remember red hat initially moving to their enterprise release and there was quite a few months of unknown what people would do after rh9 - I suspect this will also work itself out. If red hat wants to be more closed source they should build off of FreeBSD or something that can be less opened.
Genuine question (I'm not intimately familiar with all the terms of the GPL) -- does the GPL require you to release the source code to anyone and everyone (even non-customers)?
No but it gives every customer the right to redistribute the sourcecode to software they bought if that code is covered by the GPL under the same terms as RedHat got from their upstream.
It looks like RedHat might be trying to avoid that clause by threatening to stop selling any software to people who might use that part of the GPL.
They've also been doing shady shit again recently. For instance, adding advertisements for their products to existing cli tools.
I haven't been tracking SUSE for a few years now, but they're they're not doing shady shit? Hopefully there's at least one good option in commercial-linux-land. ;)
The wording was along the lines of "There are security updates for package XYZ. If you join <something> (maybe its Ubuntu Pro like you mention?) you'd have access to them."
That's not really a message that should be showing up on a box running 20.04 LTS, which is years before its EOL date.
Yeah, I saw it too.. we used a precursor to Ubuntu Pro so I'm sure my message was less obnoxious.
I think they're also offering patches for some commonly installed third-party stuff like nodejs via Ubuntu Pro.
I actually quite like Ubuntu Pro for the fact I can send a developer a laptop and know that there's 24/7 support from Canonical. I was a little dubious at how good they'd be, but they were able to diagnose the problem and provide a fix.
> I think they're also offering patches for some commonly installed third-party stuff like nodejs via Ubuntu Pro.
Yeah. That rubs me the wrong way. Like, they're clearly entitled to pay developers money for whatever they want.
However, they're paying developers to develop patches they're not sharing back with their upstream in a timely fashion:
1. Without those patches going through the upstream channel(s), there's no real mechanism to push back on patches and aren't good enough (for whatever reason)
2. It feels like they're taking advantage of the rest of the OSS ecosystem that is writing software / developing fixes and providing them in a timely fashion
Perhaps the reaction has something to do with a product for which the USP is reliability and stability changing the terms on which the product is available very suddenly and without warning twice in the last few years?
The clones did contribute mind share to RHEL. That will now be lost. We don't know what the consequences of that will be.
PS: I think people should support Debian. A non-profit project with clear charitable status in many jurisdictions and a fully public development process. No sudden shifts if you use stable in production (or even oldstable).
Not going to touch the hair on fire tone of this in general... but one thing worth mentioning is I believe the "freeloader" comment meant Rocky, Alma, Oracle and the likes are the freeloaders who are repackaging and RESELLING without contributing anything.
If you read between the lines in 2020, this was the next logical step coming. I think they should have done both changes back in 2020 and put a wider emphasis on the developer program with free subs, and removing pain in the ass subscription limitations which is why people want to use Cent/Rocky/Alma to begin with.
I'm actually from one of the countries they are moving jobs to, it's very US-centric to see racism whenever someone uses any geographic location that's not the "rich West".
Red Hat had some pretty sizeable layoffs recently and a bulk of their recruiting efforts are in the countries with cheaper labour.
You are conflating geopolitics and economics that could concern someone who could end up being affected by such a trend (which the poster isn't, as they said later) with racism.
Is someone in a given country supposed to be HAPPY that a company founded in their country is intentionally putting support engineers within their founding country out of work, while simultaneously making support a worse experience for users?
Have you ever been in the situation of being on midnight call to the other side of the world while speaking with someone with whom you're having a mutually difficult time communicating? It sucks.
Moving support into localities for better servicing the customer is fine. This isn't the trend. Fuck RH and anyone else who does this.
> Moving support into localities for better servicing the customer is fine. This isn't the trend.
You and others in this thread are concluding that the choices provided are bad ones based solely on the locations of those choices, despite there being no good reason why these people cannot provide the same level of service that could be provided elsewhere (communication issues are curable by hiring the right people, and are not an incurable problem related to the country the speaker is in). This is precisely why I called it thinly-veiled racism. I stand by my original statement for this reason, and it was improperly flagged.
I'm not improperly judging anything. I have lived this for too long. "No good reason" is a fantasy.
There is "no good reason" other than the real world standing in the way, which is an economic motivation you keep neglecting, not a racial one.
You are either a racist, unintelligent, or else ignorant. You do not write as though you're unintelligent. I do not personally assume that people are racist because I disagree with them (though your writing makes me challenge that). I can therefore only conclude you're ignorant of what real people do at real jobs.
You're not wrong that economics motivate the choice of where to hire for a customer support function. Customer service is a cost center, so naturally companies will choose to hire where labor is cheap but the job can still be done. If it's not being done well, that's a problem to point out. But that's not what happened in this conversation.
To reiterate, here is how this thread went, in context:
>> I think you are underestimating the value of providing support to commercial users.
> You mean, the valuable support they are increasingly shifting to Colombia, Philippines and India?
The bottom reply added no value to the conversation; it made no substantive claim. Since it lacked any substance, the reply merely insinuated that people from these countries cannot provide support at a level that people from other countries (such as the USA) can, and without any explanation as to why. This is the modus operandi of racists who want to choose not to be overt - leaving it to the reader to implicitly understand the unstated. Some call it a "dog whistle."
Had the speaker said "well, they're moving these functions to Colombia, Philippines and India, which are providing worse service because of <some non racist reason>," the conversation would have gone rather differently.
> You are either a racist, unintelligent, or else ignorant. You do not write as though you're unintelligent. I do not personally assume that people are racist because I disagree with them (though your writing makes me challenge that). I can therefore only conclude you're ignorant of what real people do at real jobs.
I'm not going to dignify this with a response. Take this garbage to Twitter where it belongs.
Who cares? Every country has skillful, qualified information technology individuals. Additionally, a quick google search shows it looks like RH does offer US only support if a customer is willing to pay.
So, what Red Hat already offers.... Was Alma and co doing upstream development where they can prove it? Was Oracle patching upstream first or only in oracle linux? Was Rocky offering anything unique, value adding, or were they just copy pasting and selling?
It may sound loaded, but I'm genuinely asking, because from what I've seen the answer in regards to value add is pretty ambiguous.
AFAIK Oracle employs major contributors to btrfs and XFS. I'm mostly interested in filesystems, so I can't speak for other subsystems (seems like they do a decent amount of work on core kernel development — the really important stuff like schedulers and the memory subsystem — second place just below Google).
Oracle Linux is also not a pure RHEL clone. They customize it as they desire and ship it accordingly. For example, they have an alternative kernel for their distribution with different features.
But they also have RHEL native kernel version for version if you're to choose to run that instead. It's just that RHEL kernel is usually very old and UEK kernel has more modern features and improvements in it.
Overall while they have some extra packages available they are on top of RHEL clone and you don't have to use them.
If you build your business on top of GPL software, then this sort of repackaging/reselling is just something you have to live with. Want full control? Build your own OS and license it under the terms you want.
Is there anything to stop RedHat from pulling patches from Rocky? Is Rocky's code not available? Rocky isn't doing anything that CentOS (and RedHat project) isn't as far as I know.
The problem isn't Red Hat getting them, the problem is a Rocky "customer" would have to just wait for Red Hat to release the patch and then wait for rocky to re-build, and re release.
Wishy-washy language there about skirting lines doesn't make that a very good analysis.
You can use others' GPL code in your products and charge money for it. You have to "publish" the GPL'ed sources (and any sources of yours that derive from GPL'ed code) on demand -- publish as in: if someone asks, you have to give it to them, but there's no requirement that there be a public download page or anything like that, and you can send the sources out in DVDs or flash drives or whatever media you like, and you can charge nominal amounts for the media. I.e., you don't have to make it easy to get the sources. And you don't have to provide the built product for free.
You can do a lot within the boundaries of the GPL. If IBM/RH does that, so what?
One can even do this sort of thing w/o GPL. For example, SQLite3 is in the public domain, yet the SQLite Consortium exists and makes what I imagine is good money for D. R. Hipp and his employees with zero competition from forks precisely because SQLite3 is very difficult to credibly fork, and SQLite3 is difficult to fork because the better test suite for it is proprietary and secret.
To a business, open source is a tool. Even for individuals, open source is a tool. A young person just starting out and with few resources might make useful software open source so as to gain notoriety and better employment, or even to start a business.
Yup. It goes from "These businesses are abusing the GPL and software freedom!" to "Well, they are following the GPL but that doesn't result in what I want!"
This is why we have GPL 2 and 3, for example.
Disclaimer: I work at Red Hat, but nowhere near RHEL.
it's not just an issue of what "I" want, it's an issue of what the GPL is intended to do. If it doesn't result in the four freedoms, but the GPL allows it, then the GPL has failed to do what it was designed to do.
From the text of the GPL itself:
> Our General Public Licenses are designed to make sure that you
have the freedom to distribute copies of free software (and charge for
them if you wish), that you receive source code or can get it if you
want it, that you can change the software or use pieces of it in new
free programs, and that you know you can do these things.
RedHat is trying to sell software that is licensed under the GPL -- which has to be, because the base of it was written by others and the only reason RedHat is even allowed to use it or sell it is under the GPL -- and try to prevent users from having the freedom to re-distribute the GPL software they received, with or without their own modifications.
They are trying to subvert the GPL. They know they are. That's why they have all this language where they say they aren't intending to limit your rights under the GPL -- it's just that they'll refuse to have you as a customer if you exersize them, that's all.
Whether it is legal or not is a question for laywers. If it's legal, and it succesfully prevents users from redistributing GPL RedHat, then it's an accidental loophole, and has subverted the GPL's intent and design, as stated in the GPL itslef.
> and try to prevent users from having the freedom to re-distribute the GPL software they received, with or without their own modifications.
> refuse to have you as a customer if you exersize them, that's all.
refuse to -continue- to have you as a customer, that is. you are still perfectly entitled to the source code of, and distribution thereof, what you purchased.
The GPL doesn't create an obligation that you get continued access to future updates.
I probably should leave the conversation at this point (not because I don't think there's merit in discussing it with you - just don't want to muddy the waters).
you've fallen for the arguments and ways of thinking of your employer which is not a good thing.
> ... to make sure that you have the freedom to distribute copies of free software (and charge for them if you wish), that you receive source code or can get it if you want it, that you can change the software or use pieces of it in new free programs, and that you know you can do these things.
when i'm not allowed to be your customer anymore i don't have "the freedom to distribute copies". you're putting a limitation on me - that's not freedom. or specifically, regarding "that you receive source code or can get it if you want it": i can't get it if i want it when you're refusing me as a customer.
or citing https://www.gnu.org/licenses/gpl-faq.html:
> If you commercially distribute binaries not accompanied with source code, the GPL says you must provide a written offer to distribute the source code later. When users non-commercially redistribute the binaries they received from you, they must pass along a copy of this written offer. This means that people who did not get the binaries directly from you can still receive copies of the source code, along with the written offer.
> The reason we require the offer to be valid for any third party is so that people who receive the binaries indirectly in that way can order the source code from you.
so: there is explicitly no limitation allowed on the receiving of the source code. Red Hat is putting a limitation on it.
so for me it's clear that Red Hat is in violation of GPL, at least how the GPL was meant. maybe it's not legally waterproof because it's not formulated in a way that's withstanding a legal case against Red Hat but still: it's meant that way. and i hope and pray that in such a case the GPL (and every other license in use) is updated specifically against that (mis)use case so that Red Hat can't do such abominations.
> you've fallen for the arguments and ways of thinking of your employer which is not a good thing.
I recognized that as a risk, hence the disengagement, for sure. I also know that not just in matters like this, I am overly prone to analyzing and lawyering things, perhaps to too great a degree.
> when i'm not allowed to be your customer anymore i don't have "the freedom to distribute copies". you're putting a limitation on me - that's not freedom. or specifically, regarding "that you receive source code or can get it if you want it": i can't get it if i want it when you're refusing me as a customer.
I will say I absolutely get this perspective here and how it applies to the "spirit" of the GPL, and the way you phrase it is good in recognizing things as disparate but also intrinsically intertwined.
I will also say (on a personal level, I of course don't speak for RH) I think any such things should be addressed at the root, i.e. in the GPL.
> or citing https://www.gnu.org/licenses/gpl-faq.html: > If you commercially distribute binaries not accompanied with source code, the GPL says you must provide a written offer to distribute the source code later. When users non-commercially redistribute the binaries they received from you, they must pass along a copy of this written offer. This means that people who did not get the binaries directly from you can still receive copies of the source code, along with the written offer.
So this is very interesting. Say I want a copy of source code for X and you tell me you have it, but you're not an authoritative source of source code for X: how can I trust your copy, if I choose to get it from you?
Redistribution of sources is a nice right to have, but most people prefer to get them from authoritative sources as long as they're available. As long as IBM makes these sources available for a nominal fee, they're within the GPL, and people who want them should just go through that process.
> so: there is explicitly no limitation allowed on the receiving of the source code. Red Hat is putting a limitation on it.
IBM can't legally not provide a copy of the sources for a nominal fee. And they can't limit what you do with them as far as licensing goes, but it may well be that legally speaking they can terminate rights not under the GPL. Maybe this is just a loophole in the GPL. Maybe the courts will accept it, maybe not.
The GPL does quite intentionally not require you to provide a public download page (or git access, etc), and this was more or less discussed and a conscious decision by those who came up with the GPL, agreed. Albeit in pre-widespread-internet days when a "public download page" wasn't a thing yet (and the equivalents were much more expensive, thus why they might not have wanted to require that burden). But still. I agree this is more or less intentional and explicit in the GPL.
But that the GPL lets you take GPL software, add your own features on top, sell it, and tell customers that if they redistribute it themselves (as the GPL explicitly allows), you will refuse to sell them software in the future ever again? Nope nope nope. I think it's not entirely clear if the GPL allows that or not, but if it does, it seems pretty clear to me that it's inadvertant, and not what the GPL was intended to do.
At any rate, this is a different thing, and to me another level of shadiness, than simply pointing out that the GPL does not require an entity to distribute the source via public download links -- this is about the entity trying to prohibit users from re-distributing the source themselves, and the GPL really was intentionally designed to try and avoid such prohibitions, that's kind of it's whole reason for existing.
> But that the GPL lets you take GPL software, add your own features on top, sell it, and tell customers that if they redistribute it themselves (as the GPL explicitly allows), you will refuse to sell them software in the future ever again? Nope nope nope. I think it's not entirely clear if the GPL allows that or not, but if it does, it seems pretty clear to me that it's inadvertant, and not what the GPL was intended to do.
Does "Nope nope nope" answer the first question with "no", but then the "I think it's not entirely clear if the GPL allows that or not" answer it with "maybe"? Or was the "nope" think just a wish? I believe the GPL is silent on that. You might be right that this would be an inadvertent loophole, but as you know, it's not trivial to fix this sort of problem.
Nope nope nope means this is a different quality of thing, the things you are trying to put in the same category are in different categories.
the GPL, by it's own text explaining itself, is intended to ensure that users of GPL software always have the right to re-distribute it. It says that right in it.
If your point is that IBM has enough lawyers and money to prevent users from redistributing GPL software, and they may have figured out how to exersize a loophole that will be difficult to do anything about it, especially cause of all those lawyers and money... right, indeed, sure.
If you are suggesting that we should all consider this just fine, and you don't care what the GPL intended to do, and you don't think anyone else should either, and we should all aspire to make money by getting away with subverting the GPL... okay, thanks for sharing? But as for me: nope nope nope.
> If your point is that IBM has enough lawyers and money to prevent users from redistributing GPL software, and they may have figured out how to exersize a loophole that will be difficult to do anything about it, especially cause of all those lawyers and money... right, indeed, sure.
It's not. The that IBM has here is that they're doing is not lawyers and money, it's that their customers depend on them -- vendor lock-in if you wish.
> If you are suggesting that we should all consider this just fine, and you don't care what the GPL intended to do, and you don't think anyone else should either, and we should all aspire to make money by getting away with subverting the GPL... okay, thanks for sharing? But as for me: nope nope nope.
I'm suggesting something else entirely. First, that if IBM is legally right but you/we/they don't like it, there's voting with wallets, or sucking it up if you're stuck with IBM. Second, I'm suggesting that open source is a business tool for everyone from a poor individual to a multi-billion company -- a tool rather than an end in itself.
Now, I agree that open source as an end is fun ("look ma', what code I wrote!"), but people still need to put food on the table. Just like fine art, where artists want total freedom of expression, but often produce the kinds of art that will sell well because... it's nice to not be dependent on charity. Even back in the days when artists had patrons, they still had to appeal to the patrons' tastes, and if they wanted to revolutionize art they had to convince the patrons that that was a good thing.
If using open source while putting food on the table is incompatible with the freedom for users to redistribute open source software, than the aims of the GPL has failed.
Which is possible.
Where we disagree is that you are trying to summarize them all as the same thing -- either you are doing something that violates the license in a way that can be enforced in court, or it's all just the same category of doing what the license allows as a tool while putting food on the table.
The difference, I am suggesting, within that category, is simply that the GPL was very specifically designed to allow users of GPL software to redistribute that software without restriction, and Red Hat is trying to prevent this, while using GPL'd software.
It's as simple as that. This makes it different than just any generic "I'm within the letter of the license while trying to maximize the profit I can make from using this open source".
Whether it is within the license or not is not clear, only a court can decide.
Whether it violates the intent of the GPL is pretty clear, it says so right in the GPL.
Of course, nobody has to care about the intent of the GPL, but you don't have to consider open source an "end and not a tool" to care about the intent of the GPL. The choice is not just "I think open source is a political movement rather than tool", vs "I am fine with companies using GPL software to do things the GPL's whole reason for existing is to prevent, if that's what they need to do to maximize their profit, cause we're all just maximizing our profit here, whatever you can get away with is fine."
Open source is a tool, and GPL open source is a tool that preserves the right to modify and/or redistribute it, which is why some people choose to use it or license under it. I do understand that those rights are of no concern to you, right.
Don't forget that the FSF was selling binaries as a fundraising opportunity for a while as part of the Deluxe Distribution they'd sell for $5000, and before that Stallman was selling copies of GNU Emacs on tapes for $250.
Selling binaries has always been a business model.
Trying to prevent people from redistributing the source: no.
(Yes, in an internet world, it's hard to make money selling binaries if people can redistribute source, maybe. the FSF was selling binaries in a different context, for better or worse. You are still welcome to sell binaries. You are even welcome to charge for distribution of source. But the fundamental goal of the GPL is to give users the right to redistribute source without restriction. The FSF never tried to limit that.)
I 100% support and appreciate Jeff's (and everyone's) right to take a stance when it comes to how they spend their time. We have a finite amount of time available to us, and should spend it on what's important to us, especially as that changes. See Jeff's blog post on "Saying No"[1] that really hits home with why this is important.
What I'm having trouble understanding is the overwhelming use of IBM-related anecdotes (regardless of historical truthiness, and I'm not making any claim that it's wise or unwise to be wary - that's to each their own), reframed statements painted to appear like Red Hat's made brash statements about its community, and the general gall needed to make statements such as "tell your employees to stop [doing a thing]".
I get that this event may have felt like a violation of trust, and that a violation of trust probably hurts the most. To that end, I suppose emotional responses make sense. But it would have been significantly less cognitive load (on ones self, as an open source maintainer/contributor) to just pull your support and move forward.
I assure you I'm not being payed by anyone to make comments online, in fact my $dayjob is paying huge amounts of money to IBM/Red Hat for our partnership with them.
I've been using open source for over 20 years, and I admit to using CentOS because it was a FREE version of a stable RHEL distro.
I wish I could find a free, community-based and non-commercial distro in the Linux ecosystem that I was happy with, but I just can't. The closest one is Debian, but I still don't want to leave RHEL.
Sure, I'm reading from my personal notes since I've answered this question so many times online. And keep in mind that I wrote these notes a couple of years ago.
I work with large clients and having a known corporation behind your product is pretty nice, besides that RHEL-compatible distros are still the only ones supported by a lot of proprietary enterprise software.
I'm not only a RHEL-convert, but an SElinux convert, and I think it's pretty neat. It can completely sandbox an application, but it does have a steep learning curve.
Red Hat are behind a lot of innovation within the entire Linux ecosystem.
Dnf have some features that large clients require, like history and rollback.
Debian apt (last I checked) started services on install, which can be very disruptive. It also means they sometimes uninstall similar services because there's a conflict.
Cutting edge podman/oci stuff, signed container images, and more.
And before you reply with "yes but Debian also has X", keep in mind that Red hat has probably been doing it much longer.
Probably not much, unless you depend on commercial Linux applications that have adopted Red Hat Enterprise Linux as a standard platform and do not support Debian the same way.
I've read a suggestion that that actually would violate the assorted open source licenses in question, which generally require some version of giving the user the same source as was used to build the binaries they got. Of course, they might be able to just do it on the more permissively licensed packages.
>Red Hat seems to be upping the limit to 240 sockets per developer as of this writing
-- EDIT: I read twitter, seems it may mean number of machines as opposed to open sockets. But a very confusing post.
I stopped with RHEL 2 months ago at work, I use Slackware at home.
What does that quote mean, if I get a RHEL developer license, am I limited to the number of open sockets ? That almost goes back to the per user licenses in the old UNIX Days. If I ever had to use RHEL, I would now say no just because of this.
In Red Hat Subscription Management I can see that each entitlement for the "Red Hat Developer Subscription for Individuals" product is good for a system with up to 128 sockets. And you get 16 (or possibly 240, or possibly this is a bug) entitlements.
Slackware was my first distro decades ago, and I have lots of fond memories learning Linux with it. How is it these days? What makes it your distro of choice at home in 2023?
Not OP, but: stable, with up-to-date packages. Configuration and maintenance does not change drastically between versions (there's a paper manual, it's on its second revision).
I can be heads-down on something for months and not run updates, and then run them and they apply fine and don't hose anything.
Long support for releases, both officially and on slackbuids.org
From my end user perspective Slackware 15.0 works fine - up to date(ish) packages with what might be described as 'conservative' (old school) administration. For server use it might be best to have a look at the Slackware forum...
Slackware ftw. Came back to Slackware on pretty much all workstations/laptops around 10 years ago. Some servers are also running it but mostly I've switched to OpenBSD.
Whether machines or sockets, it doesn't matter, 240 is an insanely large amount to be given out like that. I'm flabbergasted that people are complaining about this.
Could somebody who maintains a particularly important open source software change the license to say basically “you must release your source code to anyone who requests it free of charge whether they are a customer or not”?
Yes Redhat is a for profit company, but them deciding to make a business off of software that has licenses that might change to their detriment is their problem. Oh wait is that what they are doing to others now too? Well I guess that’s what happens..
Free has never meant monetarily free. Open-source means you can recompile, and thus maintain after the EOL of the provider, and code secrets aren’t secret. This is already a step above proprietary software.
For example: Wordpress themes are OSS. You must pay the gatekeeper, but you can inspect the code.
But free lunch is something else. Which OSS developers can also require, I’m not discussing that.
Open source means you can redistribute the code having received it. If you aren't allowed to do so, the program is 'source-available', not open source.
Yea selling an entire OS that consists of a ton of other peoples open source projects—often paid for by other companies to have somebody work on a thing — then when people say “hey we should get a copy of the small tweaks you did to all of those bits” and they say no, seems like a situation where changing the license on enough critical parts force the OS maker to not withhold the software.
What would stop Redhat from saying “we’ve decided the only customers we care about will pay us 50k to be a customer, therefore anybody who doesn’t pay 50k cannot get source from us.. and anybody distributing the source code owes us 50k..”
When people buy RHEL what are they buying? I always thought that when buying RHEL you are buying their support, build infra, signatures, testing, etc. You're essentially buying the boring stuff- NOT the actual open source code which is available freely to anyone.
You can just as easily change your license to one which does not allow corporate use. This has the same result, the last previously licensed version of your project is forked by corporations. I.e. if your goal is to stop providing free use of your future work you're always welcome to it, but don't hold your breath that these companies will suddenly clamor back as a result.
It won't be exactly the same result. If the license is just not compatible with commercial use, the software just won't be used ever.
But yeah that clause would make it the same, because it's insane to demand that a company has to release all its source code just to use some open source library.
I can't personally judge yet how much this will affect their business, bad for optics and community and all that sure. But regardless the narrative still implies they were already successful (aka "a one-off success"). Businesses rarely last forever. A decade plus of success is still a big success.
The point is more about the extreme difficulty of building for-profit businesses strictly off Linux-style OSS. Where people will pay for premium versions supported by paid dev teams. Otherwise it's just a glorified consulting business and not really an OSS software selling business.
I'd be interested to hear the motivations for doing so. Whether they strong downward financial pressure or were stable + merely wanted more growth.
Did they shoot themselves in the foot? It was a lot easier selling RHEL licenses when people were running on-prem workloads. These days the support contract many enterprises want is from their cloud provider, not their OS vendor.
Time to rally around the flag here. This is an incredibly hostile move by Redhat - and the attitude that only they provide value in the ecosystem is incredibly toxic and a direct threat to what open source stands for.
If the SFC loses this case I wonder if this will lead to the creation and mass adoption of GPL v4 explicitly forbidding this loophole(and others which have popped up over the years).
SLES is worse than RHEL in my eyes. Their support is horrendous, absolutely the worst in the industry. Their early move to btrfs caused so many headaches at client sites. I haven't trusted their technical decision making since.
Glad to see redhat go down the shitter. I was never a fan, but that's not the reason to hate on redhat. Everything is behind a paywall or a license. They just seemed like another Microsoft, especially when they started licensing Linux on at a per CPU core level. I think the only thing going for it is their support, but in my 20 years in the industry I've only ever used vendor support like once or twice, I've usually overcome obstacles on my own. At a previous workplace we had Ubuntu without licensing or support. The company tried to make us switch our infrastructure to redhat because they wanted indemnification. So we instead purchased Ubuntu support/licensing and again - never once did we use it or need it. Virtually everything we built we figured out ourselves. So when it comes to vendor support, I usually don't give a shit.
My interest in RHEL+clones waned when a kernel update didn't play nice with ZFS, DKMS notwithstanding, and then dropped to zero when searches for configuration information began to inevitably lead to paywalled pages on Red Hat's site (also a problem for Wildfly vs. JBoss).
Vendor support is pretty crappy. By the time you're done gathering all the logs and running out the response time clock you've usually figured it out. Then at least half the time they do help, it's wrong because you're environment has some special requirement.
I'm done with everything related to Redhat after Redhat8(no it's not RHEL 8, it's their non-enterprise distro before it's ditched and Fedora was invented as far as I can recall), yes it's about two decades ago.
I since switched to Debian ecosystem, and never looked back. I was pissed off enough to never use any rpm-based distro ever since.
Yep, don't understand why the hate now and not back then when Redhat commercialised the hell out of everything. Even RH7 was bad trying to push their Satellite crap. However I note back then there was no Ubuntu and Debian was always lagging far far behind.
409 comments
[ 3.9 ms ] story [ 138 ms ] threadAFAIU only SUSE can run both AppArmor and SELinux?
And browsers are running as unconfined in selinux with like all major distros; even on ChromiumOS (which was based on Gentoo, Gnome, and Chrome) where WASM or a paid shell (or 15-30% cut from the Play Store only) is the only way for the kids to Python on the Chromebooks we bought them for school.
Wouldn't it be great for them to not have to switch OSes and distros throughout the day.
They are not done with using Linux for "a project or undertaking, typically one that is difficult or requires effort." or "a business or company."
They are no longer going to use a specific version of linux that was made by "a business or company."
Do people really care that much about linux distros? Between 2 decades of personal use and a few years of professional Fortune 20 use, linux seems to be linux to me. (Could just be that I have stuck to Debian flavors)
Geerling supports a massive collection of Ansible playbooks, which goes pretty far beyond anybody’s personal use of Linux and would explain why this is a bigger deal than you or I ditching support for a distro.
I would not have cared if it said 'I'm done with red hat enterprise linux'
I took it as 'I'm done with enterprise linux'
They sadly do. There's a whole wave of consultants and engineers tied to the RHEL ecosystem and wouldn't be able to install without typing "yum".
Your second point is valid but it seems most developers today can't install anything that isn't an npm package
In response to the origin post that Linux is Linux. Kubernetes and Docker tries really hard to hide this differentiator of Linux distros.
> but it seems most developers today can't install anything that isn't an npm package
It gets worse than that. It's a daily struggle to explain the different between npm, yarn and pnpm for example. If only they understood what is "an npm package".
https://access.redhat.com/documentation/en-us/red_hat_enterp...
We used to be able to run this software, fully supported, on CentOS. IBM pulled the rug out from under us. Rocky and Alma rose to the occasion, and the various vendors supported one or both, since it was still RHEL minus branding. Now IBM is cutting off those distros also in an attempt to force everyone into RHEL licenses and support contracts.
But because it IS Linux, after all, a lot of enterprises like mine have NEVER needed support for the OS itself. We just needed our vendors to support their software running on it, and we needed vulnarability patching on the OS, something which CentOS, Rocky, and Alma always provided.
If I had my way, 100% of what we run would be on Debian. I have Debian running everywhere possible. But not all 3rd party applications support Debian. I’m hoping that one consequence of IBM’s move here will be to drive them all to Debian.
(I have no particular dog in this fight. I mostly left the RedHat ecosystem behind a long time ago, but I understand it's still a big deal for a lot of vendors and clients. From an individual dev/user perspective, I agree that more or less as long as whatever is a posix-y environment, I can figure it out and get my work done, whether it's solaris or slackware or whatever haha.)
https://en.wikipedia.org/wiki/Open_source_license_litigation
[1] https://www.zdnet.com/article/linux-developer-abandons-vmwar...
That's definitionally not true. Quoting https://www.gnu.org/philosophy/selling.html
] if you are redistributing copies of free software, you might as well charge a substantial fee and make some money. Redistributing free software is a good and legitimate activity; if you do it, you might as well make a profit from it. ...
] Except for one special situation, the GNU General Public License (GNU GPL) has no requirements about how much you can charge for distributing a copy of free software. You can charge nothing, a penny, a dollar, or a billion dollars. It's up to you, and the marketplace, ...
That's why the linked-to essays says "Technically, the GPL allows [a paywall]" from the text.
https://www.gnu.org/philosophy/selling.en.html
To be clear, if they don't provide source code of GPL software to customers, that's an actual outright violation of the license.
https://sfconservancy.org/copyleft-compliance/vizio.html
Curious; I was quite sure that only recipients of binaries (basically, users of the program) were entitled to get source code, but the relevant part of the GPLv2 (https://www.gnu.org/licenses/old-licenses/gpl-2.0.html) at least looks like:
which does indeed seem to suggest that if you're not preemptively shipping source to customers along with the binaries then "any third party" can ask for the code. Which is interesting context here; it would be interesting to hear an actual lawyer's reading of the situation, because that feels like such a big difference that it should have come up already.... built on top of software and labour contributed by others.
What you're missing is how the open source ethos works.
the irony of Rocky, Oracle, and etc just flat out ripping off Red Hat.... which is the exact move that caused this change lol
I would argue that it's exactly how the open source ethos works
I'm not sure exactly how much Red Hat contributes to Linux though but if I remember correctly it's quite a bit. Maybe Red Hat making more $$ = more devs. Or maybe this is just a net negative for the ecosystem code-wise (as opposed to just hurting the current users of the forked OSes) as it pushes more devs/software away from a very popular 'platform', reducing exposure, free online support on forums, testing, etc.
Your server will keep running, you'll have the sources for all the server's binaries, but no more support.
On worthwhile investments of time differentiating our offering in InfoSec and Operating Systems,
FWIU (RH) OpenShift (and MicroShift) does k8s containers most correctly in terms of separate SELinux contexts per container, which we should probably have for browser tabs, too. Do (a) browsers, (b) Cloudflare Runners, and (c) Docker WASM runtimes run WASM tasks without container-like process isolation; all as the same user and cgroup and context?
This would be incredible
Anecdotally, we'll have to support more Linux varieties instead of comfortably mandating RHEL-compatible.
In other words: Red Hat's behavior here is almost certainly going to make end-level support for their OS worse, not better, all for a tiny slice of their non-paying install base.
It expires every 12 months, and you have to take action to renew it, again with a not-very-clear path. It’s not possible to renew early (at least, I didn’t see how).
It adds extra friction: You don’t get a custom ISO or the like. Instead, you have to register your system during installation. It’s an extra step you don’t have to take.
There’s a subscriber agreement you must agree to, which not everyone wants to do.
It isn't trustworthy in the same way that the downstream rebuilds were.
Will it turn paying customers off Red Hat? (Honest question)
Ubuntu is pushing snaps to hard IMHO. Suse is moving towards immutable OS with flatpacks, but doing so in a much more responsible manner that is not trying to lock down the ecosystem.
Part of how canonical challenged Red Hat is that they deliberately made it really easy for a developer to run Ubuntu on their workstation and test environments.
It looks like RedHat might be trying to avoid that clause by threatening to stop selling any software to people who might use that part of the GPL.
Why the suggestion for Canonical?
They've also been doing shady shit again recently. For instance, adding advertisements for their products to existing cli tools.
I haven't been tracking SUSE for a few years now, but they're they're not doing shady shit? Hopefully there's at least one good option in commercial-linux-land. ;)
Asking because their recent advertising added to the apt cli is promoting some kind of security packages. Seems like people need to pay for those?
Ubuntu Pro provides some extra support (five more years) for packages in Ubuntu's existing (gratis) Long Term Support (LTS) releases of Ubuntu.
The wording was along the lines of "There are security updates for package XYZ. If you join <something> (maybe its Ubuntu Pro like you mention?) you'd have access to them."
That's not really a message that should be showing up on a box running 20.04 LTS, which is years before its EOL date.
I think they're also offering patches for some commonly installed third-party stuff like nodejs via Ubuntu Pro.
I actually quite like Ubuntu Pro for the fact I can send a developer a laptop and know that there's 24/7 support from Canonical. I was a little dubious at how good they'd be, but they were able to diagnose the problem and provide a fix.
Yeah. That rubs me the wrong way. Like, they're clearly entitled to pay developers money for whatever they want.
However, they're paying developers to develop patches they're not sharing back with their upstream in a timely fashion:
1. Without those patches going through the upstream channel(s), there's no real mechanism to push back on patches and aren't good enough (for whatever reason)
2. It feels like they're taking advantage of the rest of the OSS ecosystem that is writing software / developing fixes and providing them in a timely fashion
:/
The clones did contribute mind share to RHEL. That will now be lost. We don't know what the consequences of that will be.
PS: I think people should support Debian. A non-profit project with clear charitable status in many jurisdictions and a fully public development process. No sudden shifts if you use stable in production (or even oldstable).
If you read between the lines in 2020, this was the next logical step coming. I think they should have done both changes back in 2020 and put a wider emphasis on the developer program with free subs, and removing pain in the ass subscription limitations which is why people want to use Cent/Rocky/Alma to begin with.
I think you are underestimating the value of providing support to commercial users.
Red Hat had some pretty sizeable layoffs recently and a bulk of their recruiting efforts are in the countries with cheaper labour.
You are conflating geopolitics and economics that could concern someone who could end up being affected by such a trend (which the poster isn't, as they said later) with racism.
Is someone in a given country supposed to be HAPPY that a company founded in their country is intentionally putting support engineers within their founding country out of work, while simultaneously making support a worse experience for users?
Have you ever been in the situation of being on midnight call to the other side of the world while speaking with someone with whom you're having a mutually difficult time communicating? It sucks.
Moving support into localities for better servicing the customer is fine. This isn't the trend. Fuck RH and anyone else who does this.
You and others in this thread are concluding that the choices provided are bad ones based solely on the locations of those choices, despite there being no good reason why these people cannot provide the same level of service that could be provided elsewhere (communication issues are curable by hiring the right people, and are not an incurable problem related to the country the speaker is in). This is precisely why I called it thinly-veiled racism. I stand by my original statement for this reason, and it was improperly flagged.
I'm not improperly judging anything. I have lived this for too long. "No good reason" is a fantasy.
There is "no good reason" other than the real world standing in the way, which is an economic motivation you keep neglecting, not a racial one.
You are either a racist, unintelligent, or else ignorant. You do not write as though you're unintelligent. I do not personally assume that people are racist because I disagree with them (though your writing makes me challenge that). I can therefore only conclude you're ignorant of what real people do at real jobs.
To reiterate, here is how this thread went, in context:
>> I think you are underestimating the value of providing support to commercial users.
> You mean, the valuable support they are increasingly shifting to Colombia, Philippines and India?
The bottom reply added no value to the conversation; it made no substantive claim. Since it lacked any substance, the reply merely insinuated that people from these countries cannot provide support at a level that people from other countries (such as the USA) can, and without any explanation as to why. This is the modus operandi of racists who want to choose not to be overt - leaving it to the reader to implicitly understand the unstated. Some call it a "dog whistle."
Had the speaker said "well, they're moving these functions to Colombia, Philippines and India, which are providing worse service because of <some non racist reason>," the conversation would have gone rather differently.
> You are either a racist, unintelligent, or else ignorant. You do not write as though you're unintelligent. I do not personally assume that people are racist because I disagree with them (though your writing makes me challenge that). I can therefore only conclude you're ignorant of what real people do at real jobs.
I'm not going to dignify this with a response. Take this garbage to Twitter where it belongs.
Let's part ways, you have no insights to add, only ugly accusations of people you've never met.
https://www.redhat.com/en/resources/security-strict-data-han...
It may sound loaded, but I'm genuinely asking, because from what I've seen the answer in regards to value add is pretty ambiguous.
AFAIK Oracle employs major contributors to btrfs and XFS. I'm mostly interested in filesystems, so I can't speak for other subsystems (seems like they do a decent amount of work on core kernel development — the really important stuff like schedulers and the memory subsystem — second place just below Google).
Overall while they have some extra packages available they are on top of RHEL clone and you don't have to use them.
You can use others' GPL code in your products and charge money for it. You have to "publish" the GPL'ed sources (and any sources of yours that derive from GPL'ed code) on demand -- publish as in: if someone asks, you have to give it to them, but there's no requirement that there be a public download page or anything like that, and you can send the sources out in DVDs or flash drives or whatever media you like, and you can charge nominal amounts for the media. I.e., you don't have to make it easy to get the sources. And you don't have to provide the built product for free.
You can do a lot within the boundaries of the GPL. If IBM/RH does that, so what?
One can even do this sort of thing w/o GPL. For example, SQLite3 is in the public domain, yet the SQLite Consortium exists and makes what I imagine is good money for D. R. Hipp and his employees with zero competition from forks precisely because SQLite3 is very difficult to credibly fork, and SQLite3 is difficult to fork because the better test suite for it is proprietary and secret.
To a business, open source is a tool. Even for individuals, open source is a tool. A young person just starting out and with few resources might make useful software open source so as to gain notoriety and better employment, or even to start a business.
This is why we have GPL 2 and 3, for example.
Disclaimer: I work at Red Hat, but nowhere near RHEL.
From the text of the GPL itself:
> Our General Public Licenses are designed to make sure that you have the freedom to distribute copies of free software (and charge for them if you wish), that you receive source code or can get it if you want it, that you can change the software or use pieces of it in new free programs, and that you know you can do these things.
RedHat is trying to sell software that is licensed under the GPL -- which has to be, because the base of it was written by others and the only reason RedHat is even allowed to use it or sell it is under the GPL -- and try to prevent users from having the freedom to re-distribute the GPL software they received, with or without their own modifications.
They are trying to subvert the GPL. They know they are. That's why they have all this language where they say they aren't intending to limit your rights under the GPL -- it's just that they'll refuse to have you as a customer if you exersize them, that's all.
Whether it is legal or not is a question for laywers. If it's legal, and it succesfully prevents users from redistributing GPL RedHat, then it's an accidental loophole, and has subverted the GPL's intent and design, as stated in the GPL itslef.
> refuse to have you as a customer if you exersize them, that's all.
refuse to -continue- to have you as a customer, that is. you are still perfectly entitled to the source code of, and distribution thereof, what you purchased.
The GPL doesn't create an obligation that you get continued access to future updates.
I probably should leave the conversation at this point (not because I don't think there's merit in discussing it with you - just don't want to muddy the waters).
> ... to make sure that you have the freedom to distribute copies of free software (and charge for them if you wish), that you receive source code or can get it if you want it, that you can change the software or use pieces of it in new free programs, and that you know you can do these things.
when i'm not allowed to be your customer anymore i don't have "the freedom to distribute copies". you're putting a limitation on me - that's not freedom. or specifically, regarding "that you receive source code or can get it if you want it": i can't get it if i want it when you're refusing me as a customer.
or citing https://www.gnu.org/licenses/gpl-faq.html: > If you commercially distribute binaries not accompanied with source code, the GPL says you must provide a written offer to distribute the source code later. When users non-commercially redistribute the binaries they received from you, they must pass along a copy of this written offer. This means that people who did not get the binaries directly from you can still receive copies of the source code, along with the written offer.
> The reason we require the offer to be valid for any third party is so that people who receive the binaries indirectly in that way can order the source code from you.
so: there is explicitly no limitation allowed on the receiving of the source code. Red Hat is putting a limitation on it.
so for me it's clear that Red Hat is in violation of GPL, at least how the GPL was meant. maybe it's not legally waterproof because it's not formulated in a way that's withstanding a legal case against Red Hat but still: it's meant that way. and i hope and pray that in such a case the GPL (and every other license in use) is updated specifically against that (mis)use case so that Red Hat can't do such abominations.
I recognized that as a risk, hence the disengagement, for sure. I also know that not just in matters like this, I am overly prone to analyzing and lawyering things, perhaps to too great a degree.
> when i'm not allowed to be your customer anymore i don't have "the freedom to distribute copies". you're putting a limitation on me - that's not freedom. or specifically, regarding "that you receive source code or can get it if you want it": i can't get it if i want it when you're refusing me as a customer.
I will say I absolutely get this perspective here and how it applies to the "spirit" of the GPL, and the way you phrase it is good in recognizing things as disparate but also intrinsically intertwined.
I will also say (on a personal level, I of course don't speak for RH) I think any such things should be addressed at the root, i.e. in the GPL.
Yes, but there's no time machines allowing time travel into the past.
So this is very interesting. Say I want a copy of source code for X and you tell me you have it, but you're not an authoritative source of source code for X: how can I trust your copy, if I choose to get it from you?
Redistribution of sources is a nice right to have, but most people prefer to get them from authoritative sources as long as they're available. As long as IBM makes these sources available for a nominal fee, they're within the GPL, and people who want them should just go through that process.
> so: there is explicitly no limitation allowed on the receiving of the source code. Red Hat is putting a limitation on it.
IBM can't legally not provide a copy of the sources for a nominal fee. And they can't limit what you do with them as far as licensing goes, but it may well be that legally speaking they can terminate rights not under the GPL. Maybe this is just a loophole in the GPL. Maybe the courts will accept it, maybe not.
But that the GPL lets you take GPL software, add your own features on top, sell it, and tell customers that if they redistribute it themselves (as the GPL explicitly allows), you will refuse to sell them software in the future ever again? Nope nope nope. I think it's not entirely clear if the GPL allows that or not, but if it does, it seems pretty clear to me that it's inadvertant, and not what the GPL was intended to do.
At any rate, this is a different thing, and to me another level of shadiness, than simply pointing out that the GPL does not require an entity to distribute the source via public download links -- this is about the entity trying to prohibit users from re-distributing the source themselves, and the GPL really was intentionally designed to try and avoid such prohibitions, that's kind of it's whole reason for existing.
Does "Nope nope nope" answer the first question with "no", but then the "I think it's not entirely clear if the GPL allows that or not" answer it with "maybe"? Or was the "nope" think just a wish? I believe the GPL is silent on that. You might be right that this would be an inadvertent loophole, but as you know, it's not trivial to fix this sort of problem.
the GPL, by it's own text explaining itself, is intended to ensure that users of GPL software always have the right to re-distribute it. It says that right in it.
If your point is that IBM has enough lawyers and money to prevent users from redistributing GPL software, and they may have figured out how to exersize a loophole that will be difficult to do anything about it, especially cause of all those lawyers and money... right, indeed, sure.
If you are suggesting that we should all consider this just fine, and you don't care what the GPL intended to do, and you don't think anyone else should either, and we should all aspire to make money by getting away with subverting the GPL... okay, thanks for sharing? But as for me: nope nope nope.
It's not. The that IBM has here is that they're doing is not lawyers and money, it's that their customers depend on them -- vendor lock-in if you wish.
> If you are suggesting that we should all consider this just fine, and you don't care what the GPL intended to do, and you don't think anyone else should either, and we should all aspire to make money by getting away with subverting the GPL... okay, thanks for sharing? But as for me: nope nope nope.
I'm suggesting something else entirely. First, that if IBM is legally right but you/we/they don't like it, there's voting with wallets, or sucking it up if you're stuck with IBM. Second, I'm suggesting that open source is a business tool for everyone from a poor individual to a multi-billion company -- a tool rather than an end in itself.
Now, I agree that open source as an end is fun ("look ma', what code I wrote!"), but people still need to put food on the table. Just like fine art, where artists want total freedom of expression, but often produce the kinds of art that will sell well because... it's nice to not be dependent on charity. Even back in the days when artists had patrons, they still had to appeal to the patrons' tastes, and if they wanted to revolutionize art they had to convince the patrons that that was a good thing.
Which is possible.
Where we disagree is that you are trying to summarize them all as the same thing -- either you are doing something that violates the license in a way that can be enforced in court, or it's all just the same category of doing what the license allows as a tool while putting food on the table.
The difference, I am suggesting, within that category, is simply that the GPL was very specifically designed to allow users of GPL software to redistribute that software without restriction, and Red Hat is trying to prevent this, while using GPL'd software.
It's as simple as that. This makes it different than just any generic "I'm within the letter of the license while trying to maximize the profit I can make from using this open source".
Whether it is within the license or not is not clear, only a court can decide.
Whether it violates the intent of the GPL is pretty clear, it says so right in the GPL.
Of course, nobody has to care about the intent of the GPL, but you don't have to consider open source an "end and not a tool" to care about the intent of the GPL. The choice is not just "I think open source is a political movement rather than tool", vs "I am fine with companies using GPL software to do things the GPL's whole reason for existing is to prevent, if that's what they need to do to maximize their profit, cause we're all just maximizing our profit here, whatever you can get away with is fine."
Open source is a tool, and GPL open source is a tool that preserves the right to modify and/or redistribute it, which is why some people choose to use it or license under it. I do understand that those rights are of no concern to you, right.
IBM has no problem putting food on its table. It's doing so by using open source products to accomplish it.
On the other hand, IBM is trying to prevents others from putting food on their tables, using the same open source products.
IBM is painting themselves as the victim here[1]. You and many others have taken the bait.
[1] https://www.redhat.com/en/blog/red-hats-commitment-open-sour...
Selling binaries has always been a business model.
Trying to prevent people from redistributing the source: no.
(Yes, in an internet world, it's hard to make money selling binaries if people can redistribute source, maybe. the FSF was selling binaries in a different context, for better or worse. You are still welcome to sell binaries. You are even welcome to charge for distribution of source. But the fundamental goal of the GPL is to give users the right to redistribute source without restriction. The FSF never tried to limit that.)
What I'm having trouble understanding is the overwhelming use of IBM-related anecdotes (regardless of historical truthiness, and I'm not making any claim that it's wise or unwise to be wary - that's to each their own), reframed statements painted to appear like Red Hat's made brash statements about its community, and the general gall needed to make statements such as "tell your employees to stop [doing a thing]".
I get that this event may have felt like a violation of trust, and that a violation of trust probably hurts the most. To that end, I suppose emotional responses make sense. But it would have been significantly less cognitive load (on ones self, as an open source maintainer/contributor) to just pull your support and move forward.
[1]https://www.jeffgeerling.com/blog/2022/just-say-no
I've been using open source for over 20 years, and I admit to using CentOS because it was a FREE version of a stable RHEL distro.
I wish I could find a free, community-based and non-commercial distro in the Linux ecosystem that I was happy with, but I just can't. The closest one is Debian, but I still don't want to leave RHEL.
I used CentOS for years, then switched to Debian, and it's been plain sailing, so I'm wondering what l could gain with RHEL.
I work with large clients and having a known corporation behind your product is pretty nice, besides that RHEL-compatible distros are still the only ones supported by a lot of proprietary enterprise software.
I'm not only a RHEL-convert, but an SElinux convert, and I think it's pretty neat. It can completely sandbox an application, but it does have a steep learning curve.
Red Hat are behind a lot of innovation within the entire Linux ecosystem.
Dnf have some features that large clients require, like history and rollback.
Debian apt (last I checked) started services on install, which can be very disruptive. It also means they sometimes uninstall similar services because there's a conflict.
Cutting edge podman/oci stuff, signed container images, and more.
And before you reply with "yes but Debian also has X", keep in mind that Red hat has probably been doing it much longer.
-- EDIT: I read twitter, seems it may mean number of machines as opposed to open sockets. But a very confusing post.
I stopped with RHEL 2 months ago at work, I use Slackware at home.
What does that quote mean, if I get a RHEL developer license, am I limited to the number of open sockets ? That almost goes back to the per user licenses in the old UNIX Days. If I ever had to use RHEL, I would now say no just because of this.
I assume they mean CPU sockets.
I the author of the post says, time stop RHEL support. I wonder if/when the FSF will weigh in.
I meant to say:
Like the author of the post says
Slackware was my first distro decades ago, and I have lots of fond memories learning Linux with it. How is it these days? What makes it your distro of choice at home in 2023?
I can be heads-down on something for months and not run updates, and then run them and they apply fine and don't hose anything.
Long support for releases, both officially and on slackbuids.org
>If for some reason you are unable to upgrade or handle your own security patches, limited security support may be available for a fee.
From https://slackware.osuosl.org/slackware-11.0/ChangeLog.txt
https://www.linuxquestions.org/questions/slackware-14/
and perhaps post a few questions once you have evaluated the basic OS.
Build scripts for software outside of base is at
http://slackbuilds.org/
There are various third party scripts for automating installation for software outside of the base.
For example: Wordpress themes are OSS. You must pay the gatekeeper, but you can inspect the code.
But free lunch is something else. Which OSS developers can also require, I’m not discussing that.
What would stop Redhat from saying “we’ve decided the only customers we care about will pay us 50k to be a customer, therefore anybody who doesn’t pay 50k cannot get source from us.. and anybody distributing the source code owes us 50k..”
The GPL doesn't allow this.
But yeah that clause would make it the same, because it's insane to demand that a company has to release all its source code just to use some open source library.
Maybe this supports the narrative? Assuming it goes poorly I mean.
The point is more about the extreme difficulty of building for-profit businesses strictly off Linux-style OSS. Where people will pay for premium versions supported by paid dev teams. Otherwise it's just a glorified consulting business and not really an OSS software selling business.
I'd be interested to hear the motivations for doing so. Whether they strong downward financial pressure or were stable + merely wanted more growth.
It is Gandhi, not Ghandi!
I since switched to Debian ecosystem, and never looked back. I was pissed off enough to never use any rpm-based distro ever since.