Kuhn: A Comprehensive Analysis of the GPL Issues With the Red Hat Enterprise Linux (RHEL) Business Model
Perhaps the biggest problem with a murky business model that skirts the line of GPL compliance is that violations can and do happen — since even a minor deviation from the business model clearly violates the GPL agreements. Pre-IBM Red Hat deserves a certain amount of credit, as SFC is aware of only two documented incidents of GPL violations that have occurred since 2006 regarding the RHEL business model. We've decided to share some general details of these violations for the purpose of explaining where this business model can so easily cross the line.[...] In another violation incident, we learned that Red Hat, in a specific non-USA country, was requiring that any customer who lowered the number of RHEL machines under service contract with Red Hat sign an additional agreement. This additional agreement promised that the customer had deleted every copy of RHEL in their entire organization other than the copies of RHEL that were currently contracted for service with Red Hat. Again, this is a "further restriction". The GPL agreements give everyone the unfettered right to make and keep as many copies of the software as they like, and a distributor of GPL'd software may not require a user to attest that they've deleted these legitimate, licensed copies of third-party-licensed software under the GPL. SFC informed Red Hat's legal department of this violation, and we were assured that this additional agreement would no longer be presented to any Red Hat customers in the future.
Posted Jun 23, 2023 22:47 UTC (Fri)
by geofft (subscriber, #59789)
[Link] (20 responses)
In particular, the claim in all of them is that in the past, Red Hat has produced SRPMs from internal trees, and CentOS would snapshot the published SRPMs and rebuild them and also check them into repos on git.centos.org. After Red Hat acquired CentOS, they kept maintaining git.centos.org. (I don't really follow how CentOS got the SRPMs or whether that stopped, but my impression is they used to be on public RPM mirrors and no longer are?) However, now, Red Hat produces SRPMs from public sources (specifically, the "c9s" i.e. "CentOS 9 Stream" branches of gitlab.com/redhat/centos-stream/rpms), and so there is no need for a separate git.centos.org mirror. It's true that there might be more development on CentOS Stream than actually made it into a release, but you can (probably?) straightforwardly figure out which version did make it in. There shouldn't be private branches, except temporarily for embargoed security releases; if the GitLab history isn't agreement with the RHEL product, it would make development confusing for actual Red Hat employees working on actual Red Hat.
In other words, the claim in the article, "
I think Kuhn's points about how Red Hat dances on the border of GPL compliance are all very important, but I think it's also important to get clarity on whether we're actually losing CCS here, or whether we're effectively gaining Git history compared to the days when non-Red-Hatter CentOS folks were just snapshotting things into git.centos.org. (Every so often there's a claim on debian-devel@ that the "preferred form of modification," this century, includes VCS history and commit messages.)
... Separately, I just remembered that Red Hat has zero-cost zero-licensing container images running actual branded Red Hat, and they make CCS available (as they must for the GPL'd packages they distribute to the public!). Do these images cover enough of Red Hat that rebuilders can use them, either technically or legally?
Posted Jun 24, 2023 14:39 UTC (Sat)
by pbonzini (subscriber, #60935)
[Link] (15 responses)
> These were (and are) not actually the RHEL source releases — rather, they appear to be primarily a testing ground for what might appear in RHEL later
The first part is true, the second is less true and a bit biased in my opinion.
The first part is true because packages can be branched from Stream to the next RHEL minor update at any time, depending on the developers' plans, so it is true that RHEL packages might have never been in CentOS Stream. However: 1) with the exception of embargoed issues, bugs will always be fixed first in Stream and then in RHEL, so you'll never have a situation where Red Hat hides bugfixes from the community 2) the most active packages generally are also the ones that tend to branch last, so for example there will almost always be a kernel in CentOS Stream that is identical to what ends up in a RHEL minor release.
I think it's biased to say that CentOS Stream is a "testing ground for what might appear in RHEL" because Red Hat neither wants nor needs unwilling beta testers. Outside contributions should be code that the community wants in the next RHEL, not reports of bugs that slipped in. Bugs should be fixed upstream and secondarily in Rawhide rather than in CentOS Stream, which aims to be a *preview* of what *will* appear in RHEL later and also a stable, usable rolling distribution in its own right.
> CentOS Stream is a rebuild of RHEL. It is a rebuild of exactly RHEL sources taken from the same git tree as RHEL builds take those sources. It is not a middle - it is RHEL
Almost completely wrong. CentOS Stream is upstream of RHEL and RHEL is periodically branched from CentOS Stream. CentOS Stream is not good is you want your CI to test against a released version of RHEL, because it is always *ahead* of the last RHEL release.
On the other hand CentOS Stream *is* an enterprise Linux distro and it's pretty damn close to RHEL. There will be a CentOS Stream commit for almost any package that is released in RHEL, because the RHEL minor release branches are relatively short-lived and especially no meaningful development happens on them. Compare to the situation until RHEL8 where the sources went internal after the branch from Fedora, and you had years of internal development with nothing but periodic code drops.
> For the 5% of packages, are those the ones at gitlab.com/redhat/centos-stream/src, including a public kernel repo?
No, these "srcgit" repos are turned into regular RPMs; they are the heirs of the internal repos that were used to manage RPMs with thousands of patches applied, the first of which was the kernel. That old tooling dating back to the late 2000s has been cleaned up and is now used in these GitLab repos. See https://docs.centos.org/en-US/stream-contrib/contributing... for more info.
The packages that require manual work for a given minor release are those that: 1) are not available in the UBI (which still has to have public SRPMs); 2) are updated in the first place (many basic packages, say "sed", are not); and 3) are rebased to new upstream releases (if they aren't, all changes are visible in Stream); and 4) had some patches applied after branching from Stream and after stream was rebased.
There is a bigger change which affects packages not in the UBI, one of which is the kernel. This corresponds to just conditions 1 and 2 above, and I also missed it when I first commented here on LWN. After RHEL 9.1 was released, git.centos.org used to receive the same updates as RHEL 9.1 until 9.2 was released, and so on. See for example https://git.centos.org/rpms/kernel/commits/c9. To be honest I have no idea why this was still happening since there was no CentOS Linux 9; but anyway, these stable updates will not be available anymore. In most cases, new tooling will be needed to fetch the updated SRPMs from UBI and that will be it, but for some other packages like the kernel it will be harder and it's possible that the only solution there is clean room reverse engineering or giving up the bug-compatibility to some extent.
More in general, Alma and Rocky have a wide choice of ways they can build their own enterprise-ready Linux distro based on CentOS Stream, just like Facebook does internally. Whether they will stay faithful to their goal of being bug-compatible with RHEL, or perhaps only try to be ABI-compatible, depends on how much effort that want to put in the task; same for how they'll tackle the problem of stable updates They certainly will have to make some tough decisions, and cannot anymore just blindly rebuild whatever Red Hat served them on git.centos.org. ¯\_(ツ)_/¯
Disclaimer: some of the above might not be entirely accurate, but should not be completely wrong either. Corrections are welcome.
Posted Jun 24, 2023 15:54 UTC (Sat)
by mcatanzaro (subscriber, #93033)
[Link] (14 responses)
This part is not true. We are not allowed to fix higher-severity security issues in CentOS Stream until the fix has shipped in RHEL. Very few such issues are embargoed.
Posted Jun 24, 2023 18:54 UTC (Sat)
by pbonzini (subscriber, #60935)
[Link]
Posted Jun 24, 2023 19:57 UTC (Sat)
by passthejoe (guest, #156034)
[Link] (12 responses)
How far (in time) is it behind? Days? Weeks? Months?
Posted Jun 24, 2023 20:33 UTC (Sat)
by pizza (subscriber, #46)
[Link] (11 responses)
If you [1] cared about timely updates you'd have signed a service agreement with Red Hat.
If you're not explicitly paying someone for a specific level of service and responsiveness, any update you get is due to someone else's generosity and goodwill, and certainly not on any schedule that can be relied upon. Service guarantees cost money!
(Indeed, pre RH/Stream CentOS model routinely saw security updates held up for 1-2 months, twice a year, for the entirety of its existence while they iterated/rebased onto the latest RHEL point release.)
[1] the general you, not *you* specifically.
Posted Jun 27, 2023 8:25 UTC (Tue)
by TRauMa (guest, #16483)
[Link] (10 responses)
Or you'd use a distro that doesn't hold back security fixes deliberately. Basically you're telling the original poster to get screwed. Which is funny because Red Hat points to stream as the solution for everyone who wants to live in the RH eco system and doesn't fit their commercial target.
Posted Jun 27, 2023 12:56 UTC (Tue)
by pizza (subscriber, #46)
[Link] (9 responses)
Oh, please. Who, exactly, is holding back security fixes? And how is that practice different from *any* other distribution, least of all the RHEL clones?
What you don't seem to understand here is that these security fixes are being created, or at least backported, by RH engineers, and that is what their customers are paying for. *everyone else* already had to wait until after the stuff went out to RHEL, and then create their own update incorporating the RHEL changes. (And, funnily enough, none of the rebuilders provided any support/updates for X.y after X.y+1 came out. So this hysteria about "holding back fixes" is talking about what has been the status quo *all along*.
> Basically you're telling the original poster to get screwed.
No, I'm telling the original poster that they can't expect to get what everything they want without having to pay something for it. RH owes its non-customers [1] *nothing*.
> Which is funny because Red Hat points to stream as the solution for everyone who wants to live in the RH eco system and doesn't fit their commercial target.
And that's ... wrong how?
[1] By "customers" I also include everyone who received binaries from RH.
Posted Jun 29, 2023 10:04 UTC (Thu)
by madhatter (subscriber, #4665)
[Link] (8 responses)
See mcatanzaro (who works for RH) above:
> We are not allowed to fix higher-severity security issues in CentOS Stream until the fix has shipped in RHEL.
A security fix has been prepared, but because it hasn't yet gone through whatever internal processes are required for shipping in RHEL, it can't be released for CentOS. That is pretty much my working definition of "holding back a security fix".
Posted Jun 29, 2023 12:56 UTC (Thu)
by pizza (subscriber, #46)
[Link] (7 responses)
First, you realize this is for *embargoed* fixes, not "fixes" in general?
Secondly, rebuilders *always* had to wait until after a fix shipped into RHEL before they'd get the source to generate a build? And that RH *never* released sources to the rebuilders for anything other than the _current_ point release of RHEL?
And meanwhile, CentOS Stream still has the same processes and QA requirements as RHEL, so either way you were *never* going to get a fix for something until RH's internal processes were satisfied.
Posted Jun 29, 2023 13:38 UTC (Thu)
by madhatter (subscriber, #4665)
[Link] (6 responses)
That is exactly not how I read what mcatanzaro said. My understanding was that they are not allowed to fix *any* higher-severity security issues in CentOS (until a RHEL fix has shipped) and very few such issues are embargoed. RH had already copped to the withholding in the case of embargoed issues, so I don't think his/her comment can be read any other way.
Posted Jun 29, 2023 13:56 UTC (Thu)
by pizza (subscriber, #46)
[Link] (5 responses)
It was my understanding that very few issues are considered "high-severity" and even fewer of those are embargoed. So the vast majority of fixes land in CentOS *before* they end up in RHEL..
But even if you are completely correct, what exactly is the problem? Rapid access to serious updates is what RH's customers are paying for, after all! In the worst case it takes no longer to land publicly than it used to back in the old "we'll rebuild it after RHEL releases it" rebuilder paradigm, and everyone downstream was supposedly fine with that for the better part of two decades.
BTW, here's the full message, for context: https://lwn.net/ml/fedora-devel/D8JRWR.D2QFSVHOGZDV2@redh...
Posted Jun 29, 2023 14:07 UTC (Thu)
by madhatter (subscriber, #4665)
[Link] (4 responses)
You may be right that "very few issues are considered high-severity", but it's not just a numbers game: those are the very issues for which users most urgently need fixes, and for which there can be least justification for the withholding we are in fact assured takes place.
Posted Jun 29, 2023 14:24 UTC (Thu)
by pizza (subscriber, #46)
[Link] (3 responses)
I do not consider fixing something in place A before you fix it in place B to be "withholding" it from place B. To me, withholding would be never offering that fix in place B to begin with.
Because by that same argument, RH is "withholding" *all* fixes from CentOS7 until after they are released in RHEL7. A practice that the rebuilders (and their users) were supposedly okay with for a couple of decades.
Posted Jun 29, 2023 14:40 UTC (Thu)
by farnz (subscriber, #17727)
[Link]
Note, too, that the fix may well be published upstream already (possibly even by Red Hat employees), and RH are simply applying it to the RHEL package.
In this circumstance, it's no more "withholding" a fix than Debian "withholds" fixes that are present in the latest upstream release but not in the most recent Debian package.
Posted Jun 29, 2023 14:51 UTC (Thu)
by madhatter (subscriber, #4665)
[Link] (1 responses)
I do. I'm not saying such withholding is avoidable or reprehensible or surprising or unique to this case, but it *is* (to my mind, and apparently to mcatanzaro's mind) happening. If you don't want to think of it as such, that is of course up to you, but you might want to better define your terms before making general statements.
> Note, too, that the fix may well be published upstream already (possibly even by Red Hat employees), and RH are simply applying it to the RHEL package.
I don't see how it would have been published by RH employees, given that we've been told they are forbidden from working on it under those circumstances. If the upstream fix already exists from another source, and they're forbidden from pushing it through the CentOS pipe simply because it has not yet been pushed through the RHEL pipe, well then, that's withholding.
Posted Jun 29, 2023 15:55 UTC (Thu)
by farnz (subscriber, #17727)
[Link]
A fix may be published upstream first simply because at the time of fixing, the author didn't realise that they were fixing a security issue - this was just part of normal bug fixing when you take part in upstream development (and note that RH employs a lot of people who take part in upstream development). And the further behind the RHEL version of a package is, the more likely this is to be true, since you're less likely to remember all the development that's happened between the RHEL version being picked, and you making this fix.
And while it's a workable definition of "withholding", it does mean that any time you ship a released version and not the latest development tree, you're withholding fixes and features from your users - this isn't what most people think of when you say that things are being withheld.
Posted Jun 24, 2023 15:49 UTC (Sat)
by mcatanzaro (subscriber, #93033)
[Link] (3 responses)
Posted Jun 24, 2023 16:19 UTC (Sat)
by spmfox (subscriber, #125241)
[Link] (2 responses)
An example would be the recent XFS corruption bug. Is it possible something like this could make it into stream even for a few days?
Posted Jun 25, 2023 7:29 UTC (Sun)
by pbonzini (subscriber, #60935)
[Link] (1 responses)
The main issue of Stream is that it tells you what will be in RHEL, not what is on your *current* production machines that hypothetically run RHEL. That ironically makes it a better OS for production environments than for testing environments, in my opinion.
Posted Jun 25, 2023 12:27 UTC (Sun)
by pizza (subscriber, #46)
[Link]
Exactly. Despite all of the bits spilled about this, Stream is genuinely a better production environment for every use case [1] that doesn't *explicitly* require a specific RHEL point release. Those that have such strict requirements are brittle to the point where you won't/can't update beyond said point release without vendor approval, which makes even the old CentOS model (and what the current "free rebuilds" are still doing) a non-starter as once version N.M is released, updates for N.M-1 ceased.
(If you genuinely need bug-for-bug compatibility with a specific RHEL point release, the incremental cost for that license is going to be a rounding error on your other SW licensing/support costs. Please, prove me wrong.)
[1] Anectdotally, this applied to every environment I've deployed a CentOS installation, going back well over a decade.
Posted Jun 23, 2023 23:23 UTC (Fri)
by pizza (subscriber, #46)
[Link] (7 responses)
RH proceeded to pump a _ton_ of resources into CentOS, brought them back from the brink of death, and over the next few years completely overhauled the RHEL development pipeline from something developed entirely behind closed doors and tossed over the wall to something developed primarily in the open, permitting non-RH folks to materially participate instead of just rebuilding RHEL packages after the fact. By any measure, the "community" is larger and more vibrant than ever.
Posted Jun 24, 2023 10:03 UTC (Sat)
by nim-nim (subscriber, #34454)
[Link] (5 responses)
Rich entities like Microsoft or Amazon that intend to pay as little as possible to Red Hat fork at the Fedora (not RHEL) level and contribute engineering at the Fedora (not RHEL) level to keep their investment safe. And, if there was enough of those RHEL would be just one of many commercial derivatives of Fedora. But most Centos users had no intention to contribute anything but requests, as if software wrote qa-ed and packaged itself.
Posted Jun 24, 2023 13:55 UTC (Sat)
by pizza (subscriber, #46)
[Link] (2 responses)
"It's work/valuable when I have to do the packaging/testing, but not when $someone_else has to do it."
I'm reminded of the parallels with arguments that it's too much work to package & qa things properly for $distro, so we should all use upstream-provided flatpaks/appimages/tarballs/whatever instead. So it's clearly a lot of work, even from the original software author's perspecive. And the end-user's too, which is why everyone wants RHEL, just at zero cost and effort.
Posted Jun 26, 2023 6:26 UTC (Mon)
by taladar (subscriber, #68407)
[Link] (1 responses)
Not really. To be honest if I would never have anything to do with RHEL any more for the rest of my career as a sysadmin I would be happy. It is just so tiny in terms of number of packages and you have to jump through so many hoops to get something that works even half as well as Debian with RHEL.
Posted Jun 27, 2023 12:36 UTC (Tue)
by TRauMa (guest, #16483)
[Link]
Posted Jun 25, 2023 16:37 UTC (Sun)
by ceplm (subscriber, #41334)
[Link] (1 responses)
When I was hired to Red Hat (I have left long ago, and I don’t think I reveal any company secret here) I was told repeatedly that the found of the RH business strategy is that “we don’t sell software, just support, and just for technical reasons (we want to know exactly what binaries are on the supported system, also QA) we require our customers to use our binaries”. It might be even honest statement when I heard it (2006).
Then Oracle thingy happened, and as is usual with that company they went for the most immoral, despicable, and cost effective to grab as much money as they could, including stealing information from RH support to sell to their customers and similar stuff. I don’t know how much money RH actually lost to them, perhaps it truly hurt their bottom line (although I have my doubts), but I know it completely changed RH forever. RH never managed to find a good strategy against them, because RH was never able to go after them hard (what proportion of the real RHELs are sold only to be OS for Oracle DB?), and instead they made steps which irrevocably damaged RH by killing CentOS and all other redistributors of RH SRPMs.
It is yet one another story of greed destroying something beautiful.
Posted Jul 3, 2023 6:03 UTC (Mon)
by mattdm (subscriber, #18)
[Link]
This has never been the Red Hat strategy. Selling support causes bad incentives ("don't improve the UX -- that's a big reason people need support! And definitely don't document it!"). Red Hat subscriptions include support, but the value is in expertise and access.
Posted Jun 25, 2023 12:46 UTC (Sun)
by pixdrift (guest, #120838)
[Link]
CentOS 7.0 released 27 days after RHEL 7.0 shortly after the Red Hat announcement and I believe it still used the existing CentOS build process.
There was a major delay was with CentOS 8.0 which was post Red Hat announcement, and released 140 days after RHEL 8.0.
(CentOS wikipedia pages lists all the dates)
Something else relevant that was happening around this time (2012) was Oracle announcing that they would provide all errata and updates for Oracle Linux on their public yum repo.
Posted Jun 24, 2023 0:39 UTC (Sat)
by timrichardson (subscriber, #72836)
[Link] (8 responses)
I wonder if it can be fixed. Someone who holds copyright or the right to re-license can publish future versions under any licence they like, and free software licences can't restrain that, but Red Hat would not have either right for enough of RHEL.
Posted Jun 24, 2023 0:57 UTC (Sat)
by NYKevin (subscriber, #129325)
[Link] (7 responses)
Posted Jun 24, 2023 1:31 UTC (Sat)
by developer122 (guest, #152928)
[Link] (2 responses)
Posted Jun 24, 2023 8:50 UTC (Sat)
by ballombe (subscriber, #9523)
[Link]
Posted Jun 29, 2023 21:37 UTC (Thu)
by milesrout (subscriber, #126894)
[Link]
Posted Jun 24, 2023 12:59 UTC (Sat)
by geofft (subscriber, #59789)
[Link] (2 responses)
I'm a user. I'm interacting with it remotely through a computer network. Your software definitely supports such interaction. The fact that I'm connecting with openssl s_client instead of a web browser is your legal problem, not mine.
Suppose the Linux kernel switches to the AGPL. How are you going to offer me source when I connect to your server with a TCP client? Suppose 389 Directory Server switches to the AGPL, or Kubernetes does. Suppose your IRC client does and I send you something with /me, which is internally implemented with the "client-to-client protocol." Suppose curl switches to the AGPL, and you curl my web server - am I a "user" that you have to offer source to? Probably! (Maybe I've signed up for pingbacks or some other type of web hook from you. That would definitely make me a user.)
The AGPL "works" for a very small subset of software, namely network applications that render their own interface with download capabilities to a remote human user (so, in practice, web applications, though a BBS could do it with zmodem or something), and it prevents the code in that software from being reused in other types of software. If your web-based forum software has a nice function for email address validation, the Git developers can't use it even though Git is GPL'd and could otherwise move to the AGPL, because sometimes people use git daemon or git http-backend and their users interact with it over the Git CLI.
That last bit, I think, means there is an ethical obligation not to use the AGPL; it introduces a new problem in the field of free software licensing. If you've got some MIT-licensed software and you want to use some GPL'd subroutine I wrote, you can switch to the GPL. If you want to use some AGPL'd subroutine I wrote, you might not be able to. (Or you might be incentivized to turn your software into a webapp!) Historically free software has been a commons, at least in theory, and license incompatibilities have been seen as a bug. The AGPL draws a fairly artificial line between software where the AGPL provisions can be reasonably implemented and where it can't and essentially turns license proliferation into a feature.
Posted Jun 24, 2023 18:21 UTC (Sat)
by fw (subscriber, #26023)
[Link]
Posted Jun 25, 2023 3:44 UTC (Sun)
by NYKevin (subscriber, #129325)
[Link]
I was only bringing up the AGPL to counter the narrative that existing licenses are completely unprepared for a RHEL-like business model. The SaaS loophole has been known about forever, and is far from a new problem.
Posted Jun 26, 2023 12:23 UTC (Mon)
by paulj (subscriber, #341)
[Link]
Posted Jun 24, 2023 1:16 UTC (Sat)
by jengelh (guest, #33263)
[Link]
Any one customer could download SRPMs (or another form of source) and pass it on to other organizations down the line. If enough customers download SRPMs regularly, no one in particular stands out and it would be unwise for RH to cancel all those subscriptions just based on the fact that a download happened.
Posted Jun 24, 2023 1:37 UTC (Sat)
by developer122 (guest, #152928)
[Link] (3 responses)
I have to think the company must have expended considerable effort and expense in their decade-long campaign to take over and eliminate CentOS.
Posted Jun 24, 2023 10:08 UTC (Sat)
by nim-nim (subscriber, #34454)
[Link] (2 responses)
Centos was starved and killed by its own supporters.
Posted Jun 24, 2023 11:19 UTC (Sat)
by pizza (subscriber, #46)
[Link] (1 responses)
Not only that, RH invested a lot of effort into retooling the entire CentOS and RHEL development pipeline so that it was done completely in the open, and completely opened their internal tooling so that everyone could use it, making it vastly easier for the likes of Alma and Rocky to both spin up their own efforts, and keep them going. Now, the only tooling difference between RHEL and its clones is the git repo the build farm pulls from. Whereas Pre-RH CentOS (and similar efforts) basically had to construct their own revision control/tooling/environments from scratch and shoulder the entire burden of keeping it going.
> Centos was starved and killed by its own supporters.
Exactly. It's another variation of "I don't care about farmers going bankrupt left and right; I get my food from the grocery store" mentality.
Posted Jun 24, 2023 14:56 UTC (Sat)
by nim-nim (subscriber, #34454)
[Link]
Sure, but none of that was necessary to take over Centos (and a lot of it was already under way before the Centos take over). It was done to try to convince the few entities that *did* contribute some engineering Centos-side, to continue in a Red Hat context. Not sure if it was worth the effort, really, while it did avoid complete Centos implosion it weakened Fedora understanding both outside and within IBM. If IBM management really believes “useful productivisable” centos stream condenses out of thin air without something like “non business critical” Fedora bellow they’ll be in deep trouble in a few years.
By the time Solaris and AIX marketshare sank except in a few niches (for the second) they still had not finished the transition from ksh 83 (as in 1983) to ksh 95 (as in 1995). That’s where trying to trim “non business critical” bits leads.
Posted Jun 24, 2023 5:40 UTC (Sat)
by Subsentient (subscriber, #142918)
[Link] (5 responses)
It needs to happen. Punish them for doing this to free software.
Posted Jun 24, 2023 12:41 UTC (Sat)
by khim (subscriber, #9252)
[Link]
I actually hope that this will happen. And support it not with two but with three hands. Yup. It would kill GNU/Linux, more or less. Industry already have all ingredients needed to create replacement. They are just less popular than GNU ones. But if GPL would be banned… I don't think it'll take too much time to patch over the problem. The only question is if they would stick with Linux after Linus reassurances that GPL-as-excercised-by-Linux is not to be interpreted like that or if they would go with some other kernel. Fuchsia? seL4? We'll see, I guess, there are many options, actually. GNU was pretty advanced thing for it's time. But I think it's time for it to go. And the best, fast and guaranteed way to achieve that is to sure RedHat.
Posted Jun 24, 2023 13:26 UTC (Sat)
by mmcgrath (guest, #44906)
[Link]
For what though? Every line of code in RHEL is on CentOS Stream in the public (which is above and beyond what the GPL requires). Stream is different from Fedora and all the pundits, rebuilders whoever just need to go look and they can find it there.
Like it or not, the original blog post is accurate and everyone is greatly confused by what CentOS Stream is because they never bothered to go look.
Posted Jun 24, 2023 14:46 UTC (Sat)
by pbonzini (subscriber, #60935)
[Link] (2 responses)
1) this is not just Red Hat's idea, I even found an article from 2006 (https://lwn.net/Articles/178550/) where the FSF said they were fine with this
2) this is not a new idea either, all the extended-update minor releases of RHEL were never available in CentOS. CentOS only ever had the first 6 months of updates after which it rolled to the next RHEL minor release.
So if nobody has thought that this was a GPL violation until now, why would they start now?
Posted Jun 24, 2023 18:27 UTC (Sat)
by khim (subscriber, #9252)
[Link] (1 responses)
It kinda is is RedHat's idea. Or, rather, it's Cygnus idea. Only initially it was applied to GCC and autotools. And later RedHat bought Cygnus and used it to make RHEL. But that idea was invented years before Linus published it's infamous letter and years before RedHat was created. And FSF couldn't, really, say that it was Ok for 30+ years and now, suddenly, it's bad, bad, bad, not allowed.
Posted Jun 25, 2023 3:52 UTC (Sun)
by NYKevin (subscriber, #129325)
[Link]
Well, probably* not for GCC or any GNU code, but they could support a lawsuit by anyone else whose code is in RHEL. But first you'd have to convince that person that there is a violation worth pursuing, and having read Kuhn's article, I don't think they have a terribly strong case. Maybe they'd win, but personally, I would not want to get involved in a lawsuit with this many question marks.
* There is likely some theory of estoppel that bars such a claim, at least in common law jurisdictions. You can't tell someone "oh, yeah, you can use my software like that, the license I gave you allows it," and then change your interpretation of the license after they have done so.
Posted Jun 24, 2023 9:00 UTC (Sat)
by Wol (subscriber, #4433)
[Link] (12 responses)
As far as I can see, all these "further restrictions" are Red Hat saying "you want a service agreement? This is the cost". The customer is completely free to say "No".
YOU DO NOT HAVE THE RIGHT TO FORCE SOMEONE ELSE INTO A BUSINESS DEAL ON YOUR TERMS.
The British Government tried it (during the war) with disastrous results for the affected businesses.
If you want to do business with Red Hat (ie said service agreement), then you are in a weak bargaining position. They write the contract. And as I said, if you don't like the terms you can walk. So as I say, the contract does not IMPOSE further restrictions. If you VOLUNTARILY agree to them there's no legal problem. And if you feel you can't refuse (someone called it "blackmail") why on earth did you start doing business with Red Hat in the first place? You didn't have to ...
Cheers,
Posted Jun 24, 2023 12:01 UTC (Sat)
by jkingweb (subscriber, #113039)
[Link] (1 responses)
I am not a lawyer, of course, but I don't think that's correct. What the customer does or does not do is unimportant.
Red Hat received a license to distribute GPL software under a certain set of conditions. Arguably they are distributing the software under different conditions not allowed by that license.
Maybe it isn't a violation, but what is at issue here is the terms under which RHEL is distributed, not whether customers can choose not to be customers.
The potential grievance is up the stream, not down.
Posted Jun 24, 2023 14:00 UTC (Sat)
by Wol (subscriber, #4433)
[Link]
And in the UK, I'm pretty certain a lawyer who argued that would get sanctioned for being an idiot.
We have two COMPLETELY SEPARATE things here, a copyright licence, and a service contract.
The customer signs up for the service agreement.
Red Hat says "here's the source and binaries for RHEL" and hands them over. The GPL is effective JUST FOR AN INSTANT - by handing over the code for RHEL it comes into existence for that transfer then, as RH handed over the source, its terms are completely fulfilled and it vanishes again. The customer is now in possession of a GPL'd copy of RHEL, and is perfectly free to re-distribute it.
Should they do so, the terms of the service contract are broken, and THE SERVICE CONTRACT vanishes.
If the customer says to RH "we want to renew the service contract", then RH are perfectly free to say "You can't be trusted to stick to an agreement, we're not doing business with you".
It's actually EXACTLY THE SAME as the patent mess! If I give you a load of software under GPL2 (especially! if I am aware of patents I don't control), then COPYRIGHT law allows me to give you the software and the GPL has no problem with it, but you can't USE that software because PATENT law says so. Same with RHEL - the LICENCE says you can re-distribute, the CONTRACT says you won't. If you choose to exercise your licence rights, then RH will exercise their contract rights. Just because some people see a moral problem, doesn't mean there's a legal one.
Cheers,
Posted Jun 24, 2023 14:00 UTC (Sat)
by geofft (subscriber, #59789)
[Link] (9 responses)
Suppose Green Hat, Inc. decides to offer you a support contact for their Linux distro, for free, with unlimited seats, but one rule - every time you download source code from their servers it costs you $20. If you just let them ship you binaries you pay nothing. Is that permitted under the GPL? It's voluntary, right?
Or what do you make of the two examples in the blog post? Company A could have decided to continue to sell Product P and cease being a Red Hat customer for their internal systems. Does the fact that they wanted to keep being a customer mean that they made a voluntary agreement? The companies that reduced the number of RHEL seats could have reduced that number all the way to zero and not been subject to an audit to delete their additional copies of RHEL. Does that mean they consented to this term?
What about the patent sentence? Can I redistribute some GPL'd software with the addendum, "I've made this twice as fast and I have a patent on how I did that. You hereby voluntarily acknowledge that I'm giving you a limited, non-sublicensable patent license for internal evaluation use only"? Nobody's making you download the software from me. If you read that and downloaded it anyway and use it in production, you consented to me suing you, right?
The straightforward interpretation is this - that Red Hat, the redistributor, agrees in a contract with the original author (presuming of course the original author is not Red Hat!) to comply by the terms of the GPL. That is the voluntary agreement, which Red Hat is free to leave at any time! They can reimplement the software themselves if they don't want to comply with it. They can attempt to bargain with the original authors to get a non-GPL license. But so long as they are redistributing software under the GPL, one of the things they have voluntarily agreed to doing is that they will not go around redistributing the software with further restrictions.
Posted Jun 24, 2023 14:38 UTC (Sat)
by pizza (subscriber, #46)
[Link] (8 responses)
Bad example. the GPLv2 specifically says that for the corresponding source code, you can't charge more than the incremental cost of duplication/distribution.
> The straightforward interpretation is this - that Red Hat, the redistributor, agrees in a contract with the original author (presuming of course the original author is not Red Hat!) to comply by the terms of the GPL.
The GPL is a license, not a contract.
Posted Jun 24, 2023 17:04 UTC (Sat)
by geofft (subscriber, #59789)
[Link] (6 responses)
Sure but the entire discussion we're having is whether someone can make a "voluntary" agreement with me to let me do things in the course of redistributing GPL'd software to them that the GPL otherwise says I cannot do.
Green Hat, Inc. is of course happy to distribute sources to any of its current or former customers from the last three years for just the cost of media by emailing legal@, as required by the GPL. Any current customers who make such a request will immediately become former customers. If you don't want that, it's twenty bucks a tarball.
But okay, here's a better example: Green Hat simply chooses not to offer source code at all! They're a services provider, they sysadmin your systems and install the binaries onto them. You don't even get sources for your own internal debugging. Lots of customers are fine with this because they specifically don't want to do any debugging, that's why they have Green Hat manage their servers. The same policy applies that you can ask legal@ for sources in exchange for no longer being a customer nor ever becoming a customer again in the future. Is that permissible, or is Green Hat violating the license granted to it by the upstream authors?
> The GPL is a license, not a contract.
I don't think this is quite true (see e.g. this legal case that Conservancy was in and this older discussion covered on LWN), but assuming it is, it doesn't make a difference. Does replacing the word "contract" with "license" change the validity of the rest of what I wrote?
Posted Jun 24, 2023 18:04 UTC (Sat)
by Wol (subscriber, #4433)
[Link] (4 responses)
> I don't think this is quite true (see e.g. this legal case that Conservancy was in and this older discussion covered on LWN), but assuming it is, it doesn't make a difference. Does replacing the word "contract" with "license" change the validity of the rest of what I wrote?
A distinction without a difference, as I put it.
A contract is made when one party makes an "offer to treat", a second party accepts the offer, and the first party replies "done".
The only difference between your "normal" contract, and a licence like the GPL, is that the "offer to treat" and the "done" are one and the same.
That's why you get contract negotiations but not (normally) licence negotiations. I've given the example of shops mis-pricing items where they *can* say "sorry, mistake, NOT done". And quite often a contract offer is met with a counter-offer, but the reality licences and contracts are, to all intents and purposes, interchangeable.
Oh - and that's another reason why all this fuss about Red Hat is garbage. Contracts cannot place obligations on unrelated parties. So the GPL (a contract between the distributor and the copyright holder) cannot place obligations on a third party providing support services (and vice versa). The other thing to bear in mind is the law believes in "hats". Never mind that the same physical person can be all three of the copyright holder, the distributor, and the support service - as far as the law is concerned they are three different entities because they have three different "hats".
Cheers,
Posted Jun 24, 2023 19:18 UTC (Sat)
by geofft (subscriber, #59789)
[Link] (1 responses)
In this case Red Hat is both the distributor and the provider of support services. If they were not actually distributing GPL'd code, but simply offering support for people who happened to have it, there would be no issue (and there would be no SRPMs to make public or private). Red Hat is (voluntarily) bound by the GPL because that is the only thing that allows them to be a distributor; without it they would just be straight-up violating copyright.
(We should also be clear that "support services" includes providing software! The reason that Rocky is going for "bug-for-bug compatibility" with RHEL is that there are actual third parties who build software to run on top of RHEL and the exact behavior of RHEL is important. The whole commercial point of making it difficult or FUDdy to get the exact behavior of RHEL is that people will pay for the exact behavior of RHEL.)
> The other thing to bear in mind is the law believes in "hats". Never mind that the same physical person can be all three of the copyright holder, the distributor, and the support service - as far as the law is concerned they are three different entities because they have three different "hats".
At least in the US (the jurisdiction of Red Hat/IBM, Conservancy, the authors of the GPL, and many authors of the Linux kernel, which is probably the most interesting Red-Hat-redistributed software where Red Hat doesn't hold the full copyright), this isn't true.
There's a case going through the US courts right now, Davitashvili v. GrubHub, a class-action suit where customers of local restaurants are suing food delivery apps because the app agreements say that in-person takeout and delivery must be set at the same price, and they say that as takeout customers, they're harmed by this and this is illegal under antitrust law. But it turns out that most of the plaintiffs have signed up for these food delivery apps and clicked through binding arbitration agreements, and the defendants are trying to get the case moved into arbitration. The trouble here is that the plaintiffs are clearly acting with different "hats." They're not complaining about the service they got through the app, they're complaining that as takeout customers, the app that they happened to sign up with, long ago, is unfairly raising prices on them. Should they be required to settle this via arbitration? If the law really believed in "hats," the answer would be clearly no: the contract would only bind them as an app user. But that argument isn't being made at all. The argument is over the exact terms of the arbitration clause, what sorts of disputes it covers, and whether "infinite arbitration clauses" are legal under arbitration law. (The judge is saying no; it's being appealed, and the Chamber of Commerce has written an insistent amicus brief that contracts that broadly bind customers are very important to the economy. So they clearly don't believe in "hats" either, and as the representative of companies, they would have very good reason to believe in it!) Neither the plaintiffs nor the judge seem to be under the impression that there's a non-arbitration-specific argument that the app contract/license doesn't bind the plaintiffs when they're not using the app.
So I'm assuming you mean some other legal system - can you clarify which legal system you're talking about and point to some reference about this concept of "hats" in that system?
Posted Jun 24, 2023 21:12 UTC (Sat)
by Wol (subscriber, #4433)
[Link]
And if you want an example of the law treating different "hats" differently, I suffered from a perfect example where the Government decreed that I had to pay myself compensation! So of course, once everybody had taken their cut I was left worse off. The situation was a mutual insurance company, where to compensate policyholders for *alleged* (and imaginary!!!) harm, the company had to pay compensation from shareholder funds. Except, as a mutual company, the shareholder funds were owned by the policyholders!
UK law (indeed, most law) is riddled with this where - and surely this is the only way you can do it - laws apply to a CLASS of people, not individuals. And it's extremely rare for the law to recognise that if someone belongs to multiple classes - wears different hats - that applying the law proves that the law is an ass.
As for your case, while I don't understand what on earth is going on, it looks to me like at least one of the arguments being made is that, because SOME customers agreed to arbitration, that actually means that ALL customers are subject to arbitration.
Again, in the UK, I would expect a lawyer stupid enough to put that to a Judge to end up in the clink for a few days for being an idiot.
Cheers,
Posted Jun 25, 2023 1:47 UTC (Sun)
by comex (subscriber, #71521)
[Link] (1 responses)
As for the role of copyright owner, I imagine that anyone attempting to sue Red Hat over the affair would try to find a relevant copyright owner to act as plaintiff. However, you should note that the Software Freedom Conservancy, in its Vizio suit in the US, is currently testing the theory that recipients of GPL software have standing to sue over missing source code, as so-called third-party beneficiaries. If it succeeds, the same principle would presumably apply to Red Hat. I realize you are focused on UK law, but any suit against Red Hat would probably be in the US anyway…
Posted Jun 26, 2023 10:52 UTC (Mon)
by farnz (subscriber, #17727)
[Link]
But where's the violation in RH ceasing further distribution of software (in either binary or source form) to you?
RH will ship you source and binaries as long as you comply with the subscription agreement. If you breach that agreement, then RH will not ship you anything after a 30 day notice period.
What legal theory compels RH to distribute software to you indefinitely, if they're refusing to take your money?
Posted Jun 24, 2023 18:28 UTC (Sat)
by Wol (subscriber, #4433)
[Link]
But the point is, Red Hat is not saying "you can't redistribute RHEL", they are saying "There will be consequences if you do".
And as I keep on saying, "don't push YOUR value system on ME!". As a (non-software) company, the right to redistribute software is worth bugger all to me. Why shouldn't I trade it for the far more valuable service contract? I get that to you, the right to redistribute is more valuable than the service contract. So don't sign the service contract!
As an individual, I value the right to give and receive. So I won't sign a service contract, and I don't use RHEL (I can't stand the RHEL ecosystem, likewise I can't stand the debian one. I use Gentoo/SUSE/Slack/KDE). I want to download photos off the web for personal use, so all the photos I upload are CC-BY-SA-NC.
I want to introduce Scarlet to my employer. And any improvements we make to Scarlet I want to contribute back. More than that, since the primary copyright holder of Scarlet is a commerical entity, I'm planning to put a licence grant into Scarlet saying OpenQM can cherrypick any modifications I make. I know it's "pay forward", but it's also "give back".
So if YOU want a copy of Red Hat, what value are you giving back to Red Hat? Because if you are not giving back something THEY WANT, you can't demand anything in return. (ScarletDME/OpenQM is a little different I know, but not much. They *offered* it to me, I feel honour-bound to *offer* my work back to them. Share and share alike, you know?)
Cheers,
Posted Jun 29, 2023 10:11 UTC (Thu)
by madhatter (subscriber, #4665)
[Link]
That is not as clear-cut as you think. See eg https://lwn.net/Articles/747563/ (full disclosure: I wrote the article, though I did not give the talk on which it is based).
Posted Jun 24, 2023 15:30 UTC (Sat)
by smoogen (subscriber, #97)
[Link] (7 responses)
https://www.gnu.org/licenses/gpl-faq.html
I expect people on both sides of the argument can find things there that meet or don't meet their arguments.. but at least the arguments would be closer to what the FSF lawyers say they see as violations than what we think.
The main thing as Wol says later down is that copyright law and contract law are different things and each have about 2000 years of precedent which have to be reviewed and known when they intersect. Even lawyers who are versed in one may find that their readings are upset by how the other is acted upon in a country. To us programmers who like logic this seems like madness (it says IF THEN but you went somewhere else completely???), but it is how human society has somehow survived for a long time.
Posted Jun 24, 2023 21:50 UTC (Sat)
by Wol (subscriber, #4433)
[Link] (6 responses)
If Red Hat offers no value to you, then why do you want it?
If you want it, it clearly has value. Which means you have two choices - say "thank you" and accept what's on offer, or if you want a better deal you need to offer something back.
But all I see is people moaning and saying "Red Hat are awful immoral people - look, they're giving stuff away for free!". Even worse, many of them are offering ANTI-value in return, which is the dictionary definition of a parasite - something that takes what it wants and harms its host in the process. But what do you expect from a society that values "personal rights" above everything else - including other peoples' rights!
Cheers,
Posted Jun 25, 2023 19:51 UTC (Sun)
by Karellen (subscriber, #67644)
[Link] (5 responses)
Interesting take. I see it differently. I see a bunch of FOSS devs protecting the value they created. It's not "Red Hat offers no value to me", it's "Red Hat is offering value I created to 3rd parties, but under terms that aren't compatible with the terms I intended those 3rd parties to receive". It's not "I have two choices, to accept Red Hat's offer, or to decline it", it's "Red Hat is not giving 3rd parties the choice to have the software under the terms I offered it, despite the fact I require that it be re-offered under those terms". I see people moaning and saying "Red Hat are awful immoral people - they're giving away my stuff without also giving the recipients the freedoms I intended them to have when they received the stuff I made". Rather, it's Red Hat who have the choice here. Include and redistrubute my stuff under the license I released it with - including in the spirit of the license which should be clearly spelled out in the Preamble - or do not include it in their distribution.
Posted Jun 25, 2023 20:36 UTC (Sun)
by pizza (subscriber, #46)
[Link] (4 responses)
Red Hat is offering value that *they* created to third parties, under their own terms.
Those third parties can get the value *you* created from many, many places, including (presumably) directly from you.
Posted Jun 26, 2023 10:09 UTC (Mon)
by Karellen (subscriber, #67644)
[Link] (3 responses)
Posted Jun 26, 2023 10:53 UTC (Mon)
by farnz (subscriber, #17727)
[Link] (2 responses)
The spec files in the SRPMs for RHEL are source code, and are all written by Red Hat. If you're requiring RH to ship the specfiles for the binaries they ship to a third party (not their customers), then you're requiring them to ship code they wrote themselves under terms they don't like.
Posted Jun 26, 2023 14:13 UTC (Mon)
by paulj (subscriber, #341)
[Link] (1 responses)
Posted Jun 26, 2023 14:20 UTC (Mon)
by farnz (subscriber, #17727)
[Link]
Sure, but I was responding to the idea that "[no]one is claiming RedHat should not be able to distribute any code they wrote themselves under any terms they like". They are very definitely restricted in the terms they can use to distribute code they wrote themselves, as part of the GPL's mechanism for building a software commons.
Posted Jun 24, 2023 22:47 UTC (Sat)
by NZheretic (guest, #409)
[Link] (33 responses)
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.
When you consider how many business, organisations, governmental services & just people use services hosted on CENTOS clones.
The main problem is that OEMs test & even validate server/workstation/desktop/laptop hardware for both Microsoft & RedHat OSs on the OEM provided hardware, under agreements which MAY have caveats that effect competition.
Currently you can get around this by when you purchase, lease or collocate OEM hardware originally purchased with the NO-Operating-System option or more likely second hand, but if the hardware has been tested with Red Hat Enterprise Linux it should work as expected under CENTOS clones.
It opens the market to other providers as does Telecom Network Neutrality. IBM's decision to limit source access under any licence limiting redistribution significantly changes the market and should be investigated by the FTC and other competition monitoring agencies in the EU & worldwide.
Posted Jun 24, 2023 22:55 UTC (Sat)
by NZheretic (guest, #409)
[Link]
Posted Jun 24, 2023 23:19 UTC (Sat)
by pizza (subscriber, #46)
[Link] (31 responses)
Just because someone provided something to you for free of charge for a time, doesn't mean they are legally (or morally) obligated to continue doing so in perpetuity.
Posted Jun 24, 2023 23:25 UTC (Sat)
by NZheretic (guest, #409)
[Link] (21 responses)
Posted Jun 24, 2023 23:47 UTC (Sat)
by pizza (subscriber, #46)
[Link] (20 responses)
One of the many differences here is that the telecom industry has *never* provided anything free of charge. They also have a long, public history of double or even triple-dipping and acting in very bad faith.
So, please enlighten us as to why you or I or anyone other than Red Hat's paying customers are entitled to, in perpetuity and at zero cost, the software and services that Red Hat provides. And then explain how that doesn't apply to the software you have written.
Please.
Posted Jun 25, 2023 1:38 UTC (Sun)
by NZheretic (guest, #409)
[Link] (19 responses)
However ANY business decision that when implemented would significantly impact the market as a whole rightly deserves the full attention of Antitrust authorities, especially if the effect is world wide. ( The EU needs to look into this ASAP ).
CentOS ( released 14 May 2004 ) & Scientific Linux were created by government agencies, under the terms of the GPL & other open source licences, not based on Debian sources or other Linux distributions but based upon Red Hat Enterprise Linux sources because of the major issues of hardware comparability with off the shelf server hardware.
As I have pointed out "The main problem is that OEMs test & even validate server/workstation/desktop/laptop hardware for both Microsoft & RedHat OSs on the OEM provided hardware, under agreements which MAY have caveats that effect competition."
For the same hardware compatibility reason CentOS became the de facto distribution in countless VPS, cloud services, businesses & governmental organisations, who choose to support their deployments either internally or through third parties.
There has been a distinct advantage to Red Hat from the ubiquity of CentOS widespread deployment. It has remained the leading paid provider of services for the Linux platform & also collects and deploys many patches for fixes to its own Red Hat Enterprise distribution contributed by other companies & users of CentOS based distributions. These advantages were so significant that when the original CentOS maintainers began having difficulty keeping up with Red Hat patches, they folded the project into Red Hat itself.
Later Red Hat's subsequent removal of the stable distribution of CentOS rebadging it as CentOS Stream led to the inevitable creation of forks of the original CentOS kept tracked to Red Hat's Enterprise Linux Release.
https://itheresies.blogspot.com/2005_04_01_archive.html
As for the software I have written over the last three decades on behalf of my former employers, almost all of it has just been used internally although plenty of patches I have have added were contributed back to upstream open source projects under my former employers discretion.
Posted Jun 25, 2023 10:04 UTC (Sun)
by tuna (guest, #44480)
[Link] (4 responses)
Or they could just use CentOS Stream.
Posted Jun 25, 2023 10:20 UTC (Sun)
by NZheretic (guest, #409)
[Link] (3 responses)
Posted Jun 25, 2023 13:50 UTC (Sun)
by pbonzini (subscriber, #60935)
[Link] (2 responses)
Posted Jun 25, 2023 14:31 UTC (Sun)
by NZheretic (guest, #409)
[Link] (1 responses)
Posted Jun 25, 2023 16:55 UTC (Sun)
by pbonzini (subscriber, #60935)
[Link]
Posted Jun 25, 2023 10:36 UTC (Sun)
by nim-nim (subscriber, #34454)
[Link] (9 responses)
First, when you upstream, you will often work with someone whose salary is paid by Red Hat or one of its partners from money earned in the RHEL ecosystem.
Second, you severely undervalue the difficulty of maintaining something like RHEL. You need people able and willing to fix all the bits that go in RHEL, all year round, for a decade or so. It’s not a scratch your itch dev endeavour, where you write things on your own time, then go on holidays, then move to another project or bit of code because you’re fed up with the original one. You can not depend on specific deadlines like in an internal project, every single hour of the year is always critical for one of customers of RHEL. Getting that amount of sustained unglamorous work done takes big money (because people will accept doing unglamorous work for compensation).
Third,
> CentOS & Scientific Linux were created by government agencies
What those agencies did was take Red Hat work, and pay people to add and maintain a few components not present in RHEL, with a few fixes right and left. They never actually replicated the bulk of what Red Hat did. And they got fed up by this little effort soon enough, leading to CentOS & Scientific Linux demise.
In *theory*, it would save a lot of money to government agencies, big medium and small businesses, to finance a foundation charged with maintaining an alternative to RHEL. Hell in *theory* ISVs and IHVs could finance such a consortium themselves for a lot less money than they pay Red Hat, Google or Microsoft (but ISVs and IHVs have no interest in maintaining anything long term, they need the platform to exist for product launch and not much longer, and ISVs and IHVs compete with one another, so they are perpetually anxious about financing something that may benefit competition more than themselves).
In *practice* getting an awful lot of people and entities to agree among themselves in the name of paying less means BIG BUREAUCRACY. As in inefficiencies, infighting, high risk of getting stuck at some point because someone at some stage tried to avoid paying his dues. It took *years* for those people to agree on a way to pay *one* person, Linus Torvalds, a modest salary.
If it was *that* easy to make people work together no controversy would ever happen in Debian (haha), Canonical would not exist (people would have politely told Shuttleworth he was not needed) and RHEL’s marketshare would be zero. And Debian members love this stuff, they’re not a beancounter-ridden agency or business who would not care less about the software side.
Agencies and big business (who practice this kind of stuff all year round in the UN for example) are well aware of this difficulty. Which is why when they bitch about RHEL charges they’re not arguing about setting up a foundation they are arbitrating between giving their money to Red Hat, Microsoft, Amazon or Google (and sometimes get a few years of free ride before being forced to pay someone else some money).
Trying to set up a RHEL alternative is ridiculously easy, take the public Fedora or Centos stream sources, rebuild (hell you can even pay a one-time RHEL subscription if you want). Sustaining this effort without Red Hat doing most of the work for you, and convincing ISVs and IHVs to bet on your long term existence and performance, is ridiculously hard.
Posted Jun 25, 2023 10:39 UTC (Sun)
by nim-nim (subscriber, #34454)
[Link]
Which is why BTW appeal to antitrust laws has no legal legs to stand on. The barrier to competitor entry is effectively nil. There are just no competitor willing to bet the amount of money necessary to make the whole thing sustainable and self-financing.
Posted Jun 25, 2023 14:04 UTC (Sun)
by NZheretic (guest, #409)
[Link] (7 responses)
Those statements wouldn't be so galling if Red Hat was the sole or even majority contribute to the open source base Red Hat includes in distribution.
It's like you have not even bothered to read the original article
Also you utterly fail to address the point I have make repeatedly
Red Hat has a long history of not sending all the Red Hat Enterprise Kernel patches it applies the stock Linux kernel to Linus to incorporate into the stock kernel code.
Red Hat itself has forked upstream projects like MySQL & CUPS for inclusion in its distribution when the upstream developer has changed the project licence to impose further restrictions. Shouldn't the rest of us have the same right to do the same with code developed under GPL by the community?
Posted Jun 25, 2023 16:27 UTC (Sun)
by pizza (subscriber, #46)
[Link] (5 responses)
By that metric there are *zero* "majority" contributors to the Linux kernel.
Meanwhile, for every kernel version since approximately forever, LWN has broken down the top companies contributing to the Linux kernel. Red Hat has been at or near the top of that list for a *long* time, and RHEL subscriptions have funded all of that.
> The issue is ongoing as new processors & hardware is being released constantly & will become an even more significant problem with the increasing deployment of newer APUs & other application acceleration hardware rolled into upcoming CPUs, motherboards & IO cards.
Huh? All of this work is being done in the upstream kernels, not within the likes of RHEL. If you truly want bleeding-edge stuff you're going to have to use bleeding-edge software and distributions, not "stable enterprise" stuff that's obsolete before it ever ships.
> Red Hat has a long history of not sending all the Red Hat Enterprise Kernel patches it applies the stock Linux kernel to Linus to incorporate into the stock kernel code.
First, that article is a decade old. Second, that article doesn't say what you claim -- It talks about RHEL kernel sources combining all patches into a single file, not that that there are parts of it "not sent to Linus", or establish any sort of "history" of bad behavior. Red Hat has *always* shipped the complete corresponding source code for all GPL components to their customers and everyone else who receives binaries from them.
(Incidentally, *every* major distribution out there has out-of-tree patches in it. Linus and his lieutenants are infamously picky in what they accept, and sometimes you need to ship fixes or features before they are in a state mainline will accept. Red Hat also has a strict upstream-first policy, which means all new features are developed upstream first, and they won't ship (ie backport and support) any feature that hasn't first landed upstream.
> Red Hat itself has forked upstream projects like MySQL & CUPS for inclusion in its distribution when the upstream developer has changed the project licence to impose further restrictions.
Um, the original MySQL developer forked MySQL, not Red Hat, and pretty much everyone switched over to the new fork. CUPS was forked by OpenPrinting/Linux Foundation, not becaue of licensing issues, but because upstream (ie Apple) has long stopped caring about supporting anything other than current MacOS platforms and stripped out a lot of code that the Linux printing stack still needed. (Also, CUPS didn't "impose further restrictions" with their license change; they switched from GPLv2-only to Apache licensing, which strictly speaking is *incompatible* with GPLv2-only stuff. GPLv3 is compatible with ASL2, so that (and GPLv2+ stuff) wasn't affected)
Posted Jun 26, 2023 4:58 UTC (Mon)
by joib (subscriber, #8541)
[Link] (4 responses)
Posted Jun 26, 2023 13:40 UTC (Mon)
by pizza (subscriber, #46)
[Link] (3 responses)
Do you have a citation for that?
Because this isn't documented in the LICENSE file of either CUPS repository [1], nor is it mentioned in the handful of source files I just looked at, which all seem (only) say: 'Licensed under Apache License v2.0 See the file "LICENSE" for mode information.
[1] Apple CUPS or OpenPrinting CUPS
Posted Jun 26, 2023 13:47 UTC (Mon)
by joib (subscriber, #8541)
[Link] (2 responses)
>
> In addition, if you combine or link compiled forms of this Software with
Posted Jun 26, 2023 13:59 UTC (Mon)
by pizza (subscriber, #46)
[Link] (1 responses)
Thank you.
But it's not clear which files, if any, this NOTICE applies to -- Because all of the source files still only mention ASLv2 and the LICENSE, with no mention of the exception.
(Also, looking at the git history, the exception was added in 2019, nearly two years after the ASL2 relicensing...)
Posted Jun 26, 2023 14:07 UTC (Mon)
by joib (subscriber, #8541)
[Link]
Might actually be a good reason for a bug report, I agree with you the situation is unclear.
Posted Jun 26, 2023 6:09 UTC (Mon)
by nim-nim (subscriber, #34454)
[Link]
And has anyone ever seen such an agreement Linux-side ? And how would such an agreement stand given that the software parts are all eventually published (nvidia aside which is an nvidia decision Red Hat disagrees with) so it would be mightily hard to hide anything special. The worst that you can say about new Red Hat arrangements is that in some cases sources are not published before Red Hat publishes the corresponding binaries, which is above and beyond what most OSS licensing requires (the whole of RHEL is treated as a GPL product secret building sauce included even though it embarks a lot of components with more lenient licensing).
OEM work with Red Hat because they are not a charity, if working with a few big players is sufficient to address the market why should they expend money working with small fishes ? Their time is valuable too you know.
Customers buy Red Hat because they know it will be there to fix things where their business-critical systems would go titsup (home owners have no such requirements which is why the Linux desktop never flourished, people do not see the point of paying someone for reliable youtube viewing).
> Those statements wouldn't be so galling if Red Hat was the sole or even majority contribute to the open source base Red Hat includes in distribution.
That’s irrelevant. You will pay a plumber an harm and a leg on week ends even though the parts he uses have been conceived by someone else, are readily available in hardware supermarkets, there are lots of online tutorials etc. You will pay an arm and a leg because you want things fixed *now*, he is available, you have no trust in your ability to fix things quickly yourself, and the über scientists that calculated the best materials and gaskets to use are not there (and are quite happy not to be there and deal with customer moods during their day off). And some people will blame the plumber for extortionate galling prices even though the hardware supermarket is this way and everyone else can see they could easily take up plumbing to correct the situation.
Posted Jun 25, 2023 12:13 UTC (Sun)
by kleptog (subscriber, #1183)
[Link] (1 responses)
Let's not get carried away here. The threshold is that it has to lead sufficient market distortion that pricing mechanisms no longer work correctly. RedHat is working in a highly competitive market, with low vendor lock-in, anyone can cancel their subscription at any time without significant consequences. No-one is going out of business by this decision, Rocky & Alma Linux by their own admission will be continuing just fine, even if the product they produce is slightly different.
My reading of Kuhn article is that it's primarily concerned that it's no longer possible to verify that RedHat is actually GPL compliant. I can understand from SFC's view, this is a bad thing, but I'm really failing to see what harm this is causing anyone else (other than more work for Alma & Rocky Linux).
> If the users of CentOS clones cannot access the same source then they will be forced to join together with upstream open source developers, vendors of all sorts & even antitrust authorities to force open equitable hardware vendor information access & create another single source distribution outside of the control of Red Hat & IBM.
How is this different from any other Linux distribution? No-one's arm is being twisted to force them to use RedHat. Posted Jun 29, 2023 11:28 UTC (Thu)
by madhatter (subscriber, #4665)
[Link] (1 responses)
I'd not heard that before, and don't believe it to be true. Could you elaborate?
Posted Jul 4, 2023 6:18 UTC (Tue)
by ceplm (subscriber, #41334)
[Link]
Posted Jul 9, 2023 13:09 UTC (Sun)
by FallenKell (guest, #165983)
[Link] (8 responses)
People keep saying this like it is a defense in this situation. Correct, they are not legally (or morally) obligated to continue offering the source code in "perpetuity". However, the GPL requires that it be made as long as that entity is themselves continuing to use the software and/or modify it. And if they can not agree to that, they are in violation of the GPL and not entitled to the software in the first place in order to make the changes that they have made.
Red Hat did not write the many of these packages. They do however, take these packages, contribute to them upstream, but also use them internally as a packaged product that they distribute and provide a support level agreement to end users. This is a great service to many who would not otherwise take the risk of using software that does not have support for bug fixes. But the GPL does not let Red Hat just keep the modifications they make to that software to themselves, but requires that those are also distributed to anyone who requests it, not just a direct paying customer for their support agreements. The GPL doesn't allow that.... The GPL says the following:
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,
4. You may not copy, modify, sublicense, or distribute the Program except as expressly provided under this License. Any attempt otherwise to copy, modify, sublicense or distribute the Program is void, and will automatically terminate your rights under this License. However, parties who have received copies, or rights, from you under this License will not have their licenses terminated so long as such parties remain in full compliance.
Now, look closely at the above, especially 3b. Notice the "give ANY third party" (emphasis added to the word "any"). This doesn't mean only those with a support agreement with Red Hat. It means anyone can ask for the source code from Red Hat and they need to provide it (for 3 years). Each modification/version that Red Hat makes or incorporates in the software they provide of the GPL'ed software is subject to this.
Posted Jul 9, 2023 13:40 UTC (Sun)
by pizza (subscriber, #46)
[Link] (7 responses)
No, the GPL's source code clauses only kick in for acts of *distribution*. Actual "use" is effectively unlimited and perpetual, and that includes making your own (non-distributed) derivatives.
> But the GPL does not let Red Hat just keep the modifications they make to that software to themselves, but requires that those are also distributed to anyone who requests it, not just a direct paying customer for their support agreements. The GPL doesn't allow that....
Uh, the GPL allows you to keep all of your changes private. It only attaches requirements upon *distribution* of copies, be they modified or un-modified; source or binary. Additionally, it does not unconditionally require that you distribute your changes to whomever asks -- as your quoting of the GPL text clearly states!
> 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: [emphasis mine]
Red Hat achieves compliance primarily through clause (a), but also through a written offer (ie clause (b)) that entitles anyone to get a copy of the precise source code that corresponds with the specific binaries in question, for $5.
I'm sorry, but I'm going to take the word of the FSF and the SFC over random internet commentators that what RH is doing complies with the letter (and the spirit!) of the GPL. Indeed, GPLv3's section 6 makes this explicit:
"The requirement to provide Installation Information does not include a requirement to continue to provide support service, warranty, or updates for a work that has been modified or installed by the recipient, or for the User Product in which it has been modified or installed."
In other words, you get source code, RH can drop support/updates, and the GPLv3 (which surely embodies the "spirit" of the GPL) is perfectly fine with that.
Posted Jul 9, 2023 18:57 UTC (Sun)
by Wol (subscriber, #4433)
[Link] (6 responses)
> No, the GPL's source code clauses only kick in for acts of *distribution*. Actual "use" is effectively unlimited and perpetual, and that includes making your own (non-distributed) derivatives.
More than that, the GPL itself only kicks in for acts of distribution, iirc.
And, even worse from the GP's pov, the GPL explicitly contradicts him - does not the GPL itself say "Use of the software is outside the scope of the GPL"?
Cheers,
Posted Jul 10, 2023 11:05 UTC (Mon)
by pizza (subscriber, #46)
[Link] (5 responses)
FYI, It also kicks in for _modification_ as well. To quote GPLv3 section 9:
"You are not required to accept this License in order to receive or run a copy of the Program. [...] However, nothing other than this License grants you permission to propagate or modify any covered work. These actions infringe copyright if you do not accept this License. Therefore, by modifying or propagating a covered work, you indicate your acceptance of this License to do so."
So you have to _accept_ the GPL's terms in order to modify something covered by it, but the GPL places no obligations/restritions on you if you never actually distribute a modified (or indeed, an unmodified) copy.
Posted Jul 10, 2023 12:29 UTC (Mon)
by anselm (subscriber, #2796)
[Link] (4 responses)
The problem here is that modifying somebody else's copyrighted code is not something you get to do, under the defaults of copyright law. You need separate permission to do this, which the GPL provides, independently of whether you plan to distribute your modifications. There is nothing in the GPL, however, which forces you to make the source to your modifications available to anyone as long as you never distribute modified binaries to a third party.
Posted Jul 10, 2023 12:54 UTC (Mon)
by Wol (subscriber, #4433)
[Link] (3 responses)
You can modify / deface a book, and pass it on without needing the copyright holder's permission, provided you haven't actually copied the original text.
To what extent that covers running a "defaced" copy of the original program is open to argument.
But as soon as you distribute it, all that is irrelevant. Either (a) you're distributing the one (defaced) copy you received, or (b) you're making copies. In case (a) the recipient gets all the rights and responsibilities you originally had and you're left with nothing, or case (b) the GPL bites.
Cheers,
Posted Jul 10, 2023 13:59 UTC (Mon)
by anselm (subscriber, #2796)
[Link] (2 responses)
The rules are different for physical objects (like books or CDs) vs. “digital content”, such as software you download. If you obtain a copy of a copyrighted work as a physical object (book, CD, USB thumb drive, …), you get to dispose of that particular object as you please (including defacing it, selling it on, etc.), but your ownership of the copy doesn't let you make copyright decisions concerning the original work (such as making and selling more copies, or commissioning a movie based on (the content of) a book). The legal doctrine is called “copyright exhaustion”.
OTOH, whether copyright exhaustion applies to digital copies of a work is unclear. For example, if you download a musical recording as an MP3 file, according to copyright law you don't get to sell that recording to someone else, because that sale would result in the creation of an extra copy (even if you later remove your own copy of the file), and the creation of extra copies remains the copyright holder's prerogative. The same reasoning would apply to “defacing” an MP3 file – this would usually result in unauthorised copies being produced, and hence not be allowed, modulo the “fair use”-type provisions that exist in certain jurisdictions. (It has been long established that, e.g., the fact that a piece of software must be copied from secondary storage into RAM in order to execute it is irrelevant as far as copyright is concerned, but that of course doesn't give you blanket permission to make extra copies in order to “deface” it.)
Posted Jul 10, 2023 15:07 UTC (Mon)
by Wol (subscriber, #4433)
[Link] (1 responses)
I think copyright law has changed ... which is how you can buy eg OEM copies of Windows and stuff.
European law now explicitly lets you sell on digital copies, on condition you destroy your original copy. I don't know the details, but I do remember something of the sort a good few years ago.
I know MS is unhappy, but if they discover you are selling on OEM copies, all they can do is refuse to do any further business with you (that's how I've obtained most of my recent copies of Windows).
Cheers,
Posted Jul 11, 2023 11:03 UTC (Tue)
by kleptog (subscriber, #1183)
[Link]
So I was thinking of writing something similar yesterday but figured I'd add sources for this claim... and came up blank. In fact, I found the opposite, namely the Tom Kabinet case before the ECJ which ruled that if you offer a site that allows people to download a copy of an e-book that that counts as distribution, even if you claim you're deleting your copy directly after the download. It doesn't help that in the EU software copyright and other copyrights are not handled the same way, see [1]
At a national level, similar cases where people selling an ebook to someone else by physically handing over media containing the ebook however have ruled the other way. Software copyright is regulated under the Software directive, and e-books under the InfoSoc directive. If you buy an MS Windows installation CD secondhand, MS cannot deny you downloading updates just because you weren't the first owner.
I think this is the reason why so many software businesses are moving over to subscription models because by offering a time-limited service, resale can simply by prohibited by contract law rather than relying on copyright law. Just like with Netflix & Spotify, since you never buy it, it can't be resold either.
[1] https://academic.oup.com/grurint/article/69/5/489/5854748
There were a couple of comments in response to the original post (e.g., here on LWN, on Hacker News, and on the Fedora devel list) claiming that there is / will be no loss of complete corresponding source - ,just that they won't be on git.centos.org.
Kuhn: A Comprehensive Analysis of the GPL Issues With the Red Hat Enterprise Linux (RHEL) Business Model
These were (and are) not actually the RHEL source releases — rather, they appear to be primarily a testing ground for what might appear in RHEL later.
", is at odds with the claim on devel@, "CentOS Stream is a rebuild of RHEL. It
is a rebuild of exactly RHEL sources taken from the same git tree as RHEL builds take those sources. It is not a middle - it is RHEL.
" And the claim in the HN comment, "95% [...] of the platform will match [...] versions available in CentOS Stream and their RHEL counterparts, there are some packages that will not due to the way they are developed.
" isn't really in agreement with either of them. Which is it? (For the 5% of packages, are those the ones at gitlab.com/redhat/centos-stream/src, including a public kernel repo?)
Kuhn: A Comprehensive Analysis of the GPL Issues With the Red Hat Enterprise Linux (RHEL) Business Model
Kuhn: A Comprehensive Analysis of the GPL Issues With the Red Hat Enterprise Linux (RHEL) Business Model
Kuhn: A Comprehensive Analysis of the GPL Issues With the Red Hat Enterprise Linux (RHEL) Business Model
Kuhn: A Comprehensive Analysis of the GPL Issues With the Red Hat Enterprise Linux (RHEL) Business Model
Kuhn: A Comprehensive Analysis of the GPL Issues With the Red Hat Enterprise Linux (RHEL) Business Model
Kuhn: A Comprehensive Analysis of the GPL Issues With the Red Hat Enterprise Linux (RHEL) Business Model
Kuhn: A Comprehensive Analysis of the GPL Issues With the Red Hat Enterprise Linux (RHEL) Business Model
Kuhn: A Comprehensive Analysis of the GPL Issues With the Red Hat Enterprise Linux (RHEL) Business Model
Kuhn: A Comprehensive Analysis of the GPL Issues With the Red Hat Enterprise Linux (RHEL) Business Model
Kuhn: A Comprehensive Analysis of the GPL Issues With the Red Hat Enterprise Linux (RHEL) Business Model
Kuhn: A Comprehensive Analysis of the GPL Issues With the Red Hat Enterprise Linux (RHEL) Business Model
Kuhn: A Comprehensive Analysis of the GPL Issues With the Red Hat Enterprise Linux (RHEL) Business Model
Kuhn: A Comprehensive Analysis of the GPL Issues With the Red Hat Enterprise Linux (RHEL) Business Model
Kuhn: A Comprehensive Analysis of the GPL Issues With the Red Hat Enterprise Linux (RHEL) Business Model
Kuhn: A Comprehensive Analysis of the GPL Issues With the Red Hat Enterprise Linux (RHEL) Business Model
Kuhn: A Comprehensive Analysis of the GPL Issues With the Red Hat Enterprise Linux (RHEL) Business Model
Kuhn: A Comprehensive Analysis of the GPL Issues With the Red Hat Enterprise Linux (RHEL) Business Model
Kuhn: A Comprehensive Analysis of the GPL Issues With the Red Hat Enterprise Linux (RHEL) Business Model
Kuhn: A Comprehensive Analysis of the GPL Issues With the Red Hat Enterprise Linux (RHEL) Business Model
Kuhn: A Comprehensive Analysis of the GPL Issues With the Red Hat Enterprise Linux (RHEL) Business Model
CentOS was nearly dead when RH acquired it
CentOS was nearly dead when RH acquired it
CentOS was nearly dead when RH acquired it
CentOS was nearly dead when RH acquired it
CentOS was nearly dead when RH acquired it
CentOS was nearly dead when RH acquired it
CentOS was nearly dead when RH acquired it
CentOS was nearly dead when RH acquired it
Kuhn: A Comprehensive Analysis of the GPL Issues With the Red Hat Enterprise Linux (RHEL) Business Model
Kuhn: A Comprehensive Analysis of the GPL Issues With the Red Hat Enterprise Linux (RHEL) Business Model
Kuhn: A Comprehensive Analysis of the GPL Issues With the Red Hat Enterprise Linux (RHEL) Business Model
Kuhn: A Comprehensive Analysis of the GPL Issues With the Red Hat Enterprise Linux (RHEL) Business Model
Kuhn: A Comprehensive Analysis of the GPL Issues With the Red Hat Enterprise Linux (RHEL) Business Model
The AGPL is also unusable for most real use cases. Suppose OpenSSL or GnuTLS switches to the AGPL. How are you going to offer me source when I connect to your server with a TLS client? Would it even suffice to write an RFC to add a special extension to the ServerHello to offer a link to source code, if you know that no other software implements that RFC? I don't think you have any argument that the AGPL wouldn't require you to offer source in this case:
Kuhn: A Comprehensive Analysis of the GPL Issues With the Red Hat Enterprise Linux (RHEL) Business Model
Notwithstanding any other provision of this License, if you modify the Program, your modified version must prominently offer all users interacting with it remotely through a computer network (if your version supports such interaction) an opportunity to receive the Corresponding Source of your version by providing access to the Corresponding Source from a network server at no charge, through some standard or customary means of facilitating copying of software.
I think it was a mistake to make the requirement by default, rather than activating it only if the software already has this mechanism. This is how the GPL handles a notice requirement:
Kuhn: A Comprehensive Analysis of the GPL Issues With the Red Hat Enterprise Linux (RHEL) Business Model
d) If the work has interactive user interfaces, each must display
Appropriate Legal Notices; however, if the Program has interactive
interfaces that do not display Appropriate Legal Notices, your
work need not make them do so.
It means that the developer can only exercise this additional restriction after spelling out how, exactly, compliance should look like. This would not eliminate all problems with the AGPL, but it's a big step.
Kuhn: A Comprehensive Analysis of the GPL Issues With the Red Hat Enterprise Linux (RHEL) Business Model
Kuhn: A Comprehensive Analysis of the GPL Issues With the Red Hat Enterprise Linux (RHEL) Business Model
Kuhn: A Comprehensive Analysis of the GPL Issues With the Red Hat Enterprise Linux (RHEL) Business Model
Kuhn: A Comprehensive Analysis of the GPL Issues With the Red Hat Enterprise Linux (RHEL) Business Model
How does their generous, un-refusable offer of employment to various key members of the CentOS community compare to the scale of their funding of other developer positions? How many developer roles could they have funded for the cost of dismantling the CentOS project?
Kuhn: A Comprehensive Analysis of the GPL Issues With the Red Hat Enterprise Linux (RHEL) Business Model
Kuhn: A Comprehensive Analysis of the GPL Issues With the Red Hat Enterprise Linux (RHEL) Business Model
Kuhn: A Comprehensive Analysis of the GPL Issues With the Red Hat Enterprise Linux (RHEL) Business Model
Two words:
It's time to stop letting GPL violations slide. It's time to enforce the GPL.
> It needs to happen. Punish them for doing this to free software.
Two words:
Two words:
Two words:
> 1) this is not just Red Hat's idea, I even found an article from 2006 (https://lwn.net/Articles/178550/) where the FSF said they were fine with this
Two words:
Two words:
Where's the violation?
Wol
Where's the violation?
Where's the violation?
Wol
I don't think the GPL works the way you're reading it. If it did, it would make the "further restrictions" paragraph meaningless. The paragraph in full says,
Where's the violation?
You may not impose any further restrictions on the exercise of the rights granted or affirmed under this License. For example, you may not impose a license fee, royalty, or other charge for exercise of rights granted under this License, and you may not initiate litigation (including a cross-claim or counterclaim in a lawsuit) alleging that any patent claim is infringed by making, using, selling, offering for sale, or importing the Program or any portion of it.
How would the "you may not impose a license fee" clause have any effect if you read "impose" to mean by force? There is, I believe, a general view that words and phrases in contracts should be interpreted in a way that makes them mean something. Is there any case in which a license fee or royalty could be "imposed" in this interpretation, except perhaps by a government, or is this a meaningless sentence?
Where's the violation?
> Bad example. the GPLv2 specifically says that for the corresponding source code, you can't charge more than the incremental cost of duplication/distribution.
Where's the violation?
Where's the violation?
Wol
> So the GPL (a contract between the distributor and the copyright holder) cannot place obligations on a third party providing support services (and vice versa).
Where's the violation?
Where's the violation?
Wol
Where's the violation?
Where's the violation?
Where's the violation?
Wol
Where's the violation?
Kuhn: A Comprehensive Analysis of the GPL Issues With the Red Hat Enterprise Linux (RHEL) Business Model
Kuhn: A Comprehensive Analysis of the GPL Issues With the Red Hat Enterprise Linux (RHEL) Business Model
Wol
Kuhn: A Comprehensive Analysis of the GPL Issues With the Red Hat Enterprise Linux (RHEL) Business Model
all I'm seeing here is a bunch of alleged FLOSS guys being freeloaders and worse.
If Red Hat offers no value to you, then why do you want it?Kuhn: A Comprehensive Analysis of the GPL Issues With the Red Hat Enterprise Linux (RHEL) Business Model
Kuhn: A Comprehensive Analysis of the GPL Issues With the Red Hat Enterprise Linux (RHEL) Business Model
Kuhn: A Comprehensive Analysis of the GPL Issues With the Red Hat Enterprise Linux (RHEL) Business Model
Kuhn: A Comprehensive Analysis of the GPL Issues With the Red Hat Enterprise Linux (RHEL) Business Model
Kuhn: A Comprehensive Analysis of the GPL Issues With the Red Hat Enterprise Linux (RHEL) Business Model
Kuhn: A Comprehensive Analysis of the GPL Issues With the Red Hat Enterprise Linux (RHEL) Business Model
https://www.jeffgeerling.com/blog/2023/dear-red-hat-are-y...
https://itheresies.blogspot.com/2006_07_01_archive.html
https://www.ftc.gov/news-events/news/press-releases/2006/...
The Trillian Project : Proof of SCO's actions
Posted Jun 12, 2003 15:57 UTC (Thu) by NZheretic (guest, #409)
IBM's action is particularly upsetting givin it is 20 years since ...
Kuhn: A Comprehensive Analysis of the GPL Issues With the Red Hat Enterprise Linux (RHEL) Business Model
Kuhn: A Comprehensive Analysis of the GPL Issues With the Red Hat Enterprise Linux (RHEL) Business Model
Kuhn: A Comprehensive Analysis of the GPL Issues With the Red Hat Enterprise Linux (RHEL) Business Model
Why
The issue is ongoing as new processors & hardware is being released constantly & will become an even more significant problem with the increasing deployment of newer APUs & other application acceleration hardware rolled into upcoming CPUs, motherboards & IO cards.
Even direct business competitors, such as Oracle's Linux distribution, chose to base off of CentOS exactly for the same reason.
There is now a significant market based upon both providing software & services upon that platform.
IBM's decision to limit the distribution of the sources by customer licences DIRECTLY impacts that existing market.
"No vendor or open source software developer can block development for any substantial period of time without the risk of the development being taken over by a descendant of the same project -- it's called evolution."
Which, IMHO is a bigger risk to IBM's bottom line future profits from Red Hat. If the users of CentOS clones cannot access the same source then they will be forced to join together with upstream open source developers, vendors of all sorts & even antitrust authorities to force open equitable hardware vendor information access & create another single source distribution outside of the control of Red Hat & IBM.
Upstreaming is almost always easier than internal fork maintaining.
Why
Why
Why
Why
Since it is both that has been offered by the finally released Red Hat Enterprise Linux & the CentOS ( pre-stream ) clones.
Why
Why
Why
Why
> What those agencies did was take Red Hat work, and pay people to add and maintain a few components not present in RHEL, with a few fixes right and left.
However Red Hat & IBM are not even the majority contributors to the Linux Kernel itself.
https://lwn.net/Articles/923410/
https://www.linuxfoundation.org/resources/publications/li...
https://project.linuxfoundation.org/hubfs/Reports/2020_ke...
"From 2007 to 2019" Red Hat supplied only 8.9% of commits & IBM 3.79%
Comprehensive Analysis of the GPL Issues With the Red Hat Enterprise Linux (RHEL) Business Model by Bradley M. Kuhn
https://sfconservancy.org/blog/2023/jun/23/rhel-gpl-analy...
As I have pointed out "The main problem is that OEMs test & even validate server/workstation/desktop/laptop hardware for both Microsoft & RedHat OSs on the OEM provided hardware, under agreements which MAY have caveats that effect competition."
The issue is ongoing as new processors & hardware is being released constantly & will become an even more significant problem with the increasing deployment of newer APUs & other application acceleration hardware rolled into upcoming CPUs, motherboards & IO cards.
https://www.theregister.com/2011/03/04/red_hat_twarts_ora...
So despite Red Hat is not the major contributor to the Linux Kernel project, its OEM & hardware vendor relationship agreements mean that some particular patches it applies to the Stock Kernel are necessary for competing Linux distributions to interoperate with said hardware and operate in the market.
Why
> "From 2007 to 2019" Red Hat supplied only 8.9% of commits & IBM 3.79%
Why
Why
Why
> -- CUPS Exceptions to the Apache 2.0 License --
>
> As an exception, if, as a result of your compiling your source code, portions
> of this Software are embedded into an Object form of such source code, you
> may redistribute such embedded portions in such Object form without complying
> with the conditions of Sections 4(a), 4(b) and 4(d) of the License.
> software that is licensed under the GPLv2 ("Combined Software") and if a
> court of competent jurisdiction determines that the patent provision (Section
> 3), the indemnity provision (Section 9) or other Section of the License
> conflicts with the conditions of the GPLv2, you may retroactively and
> prospectively choose to deem waived or otherwise exclude such Section(s) of
> the License, but only in their entirety and only with respect to the Combined
> Software.
Why
Why
Why
Why
Why
Why
Kuhn: A Comprehensive Analysis of the GPL Issues With the Red Hat Enterprise Linux (RHEL) Business Model
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.)
Kuhn: A Comprehensive Analysis of the GPL Issues With the Red Hat Enterprise Linux (RHEL) Business Model
Kuhn: A Comprehensive Analysis of the GPL Issues With the Red Hat Enterprise Linux (RHEL) Business Model
Wol
Kuhn: A Comprehensive Analysis of the GPL Issues With the Red Hat Enterprise Linux (RHEL) Business Model
Kuhn: A Comprehensive Analysis of the GPL Issues With the Red Hat Enterprise Linux (RHEL) Business Model
Kuhn: A Comprehensive Analysis of the GPL Issues With the Red Hat Enterprise Linux (RHEL) Business Model
Wol
Kuhn: A Comprehensive Analysis of the GPL Issues With the Red Hat Enterprise Linux (RHEL) Business Model
Kuhn: A Comprehensive Analysis of the GPL Issues With the Red Hat Enterprise Linux (RHEL) Business Model
Wol
Kuhn: A Comprehensive Analysis of the GPL Issues With the Red Hat Enterprise Linux (RHEL) Business Model