|
|
Subscribe / Log in / New account

Changing CentOS in mid-stream

Changing CentOS in mid-stream

Posted Dec 10, 2020 19:15 UTC (Thu) by pbonzini (subscriber, #60935)
In reply to: Changing CentOS in mid-stream by eutopiafound
Parent article: Changing CentOS in mid-stream

This has *nothing* to do with IBM.


to post comments

Changing CentOS in mid-stream

Posted Dec 11, 2020 6:54 UTC (Fri) by mebrown (subscriber, #7960) [Link] (9 responses)

Red Hat has wanted to kill CentOS for *years* as they dont seem to understand the path that many orgs take to becoming a RHEL customer is through CentOS. But I'm fairly sure the order to actually stick the knife in came from somebody at IBM.

Changing CentOS in mid-stream

Posted Dec 11, 2020 7:37 UTC (Fri) by pbonzini (subscriber, #60935) [Link]

If that conviction makes you feel better, who am I to dispute that...

Changing CentOS in mid-stream

Posted Dec 13, 2020 20:38 UTC (Sun) by sjj (guest, #2020) [Link] (7 responses)

I believe RH actually knows their customers better than random internet commenters do.

Changing CentOS in mid-stream

Posted Dec 17, 2020 23:22 UTC (Thu) by daniel (guest, #3181) [Link] (6 responses)

If Redhat knows its customers well then why did they imagine they would be content with flipping the basic Centos premise from stability to adventure?

Changing CentOS in mid-stream

Posted Dec 25, 2020 22:31 UTC (Fri) by jospoortvliet (guest, #33164) [Link] (5 responses)

Centos users aren't customers. Customers are people that pay you money for the work you do for them. Those customers were perhaps asking red hat why their competitors got access to the same software workout paying for it, gaining an advantage. That isn't something you want your customers to ask.

Changing CentOS in mid-stream

Posted Feb 4, 2021 14:17 UTC (Thu) by emailstorbala (guest, #144622) [Link] (4 responses)

Redhat users pays for the support. The product is an open source and hence it is rebranded as Centos (so is Oracle Linux and Scientific Linux). Kernel, filessystem, packages are all created and maintained by upstream.

So technically a customer who has paid money is paying for an issue case support and not for the RHEL itself. And support types differ and it payment also differs.

Changing CentOS in mid-stream

Posted Feb 4, 2021 14:28 UTC (Thu) by pizza (subscriber, #46) [Link] (3 responses)

> Kernel, filesystem, packages are all created and maintained by upstream.

This is _not_ the case for RHEL (and its derivatives..)

Red Hat packages everything shipped in RHEL, and shoulders all of the maintenance work.

Upstreams only tend to care about RHEL (and backporting fixes to decade-old releases) when Red Hat is paying their salaries. (which, to be fair, they do quite a lot of!)

Changing CentOS in mid-stream

Posted Feb 4, 2021 20:33 UTC (Thu) by mathstuf (subscriber, #69389) [Link] (2 responses)

Note that Red Hat also gets packages certified for use by FIPS and for within SCIF infrastructure ("secure rooms"). For these cases, it is many times a *specific build* that is certified; a rebuild is *not* certified (I don't think Reproducible Builds factors into it; that may be considered sufficient for most, but these checkbox security things tend not to care about the bits as much as the color of the bits[1]).

[1]https://ansuz.sooke.bc.ca/entry/23

Changing CentOS in mid-stream

Posted Feb 5, 2021 6:35 UTC (Fri) by Cyberax (✭ supporter ✭, #52523) [Link] (1 responses)

To be fair, if you care about FIPS and have a SCIF, you probably can pay for RHEL licenses out of your paperclip budget.

Changing CentOS in mid-stream

Posted Feb 5, 2021 14:29 UTC (Fri) by mathstuf (subscriber, #69389) [Link]

Well, NIST 800 is making FIPS an easy go-to for checkbox compliance. And a SCIF could be had at companies of all sizes; it really depends on the projects and data they're working on.

Changing CentOS in mid-stream

Posted Dec 11, 2020 10:34 UTC (Fri) by mbanck (subscriber, #9035) [Link] (132 responses)

If you are saying this had been decided already before the IBM acquisition, would that not imply that Red Hat announced CentOS8 (which was after the acquisition I believe) knowing full well the support timeline was a lie and was going to be changed down the road?

Changing CentOS in mid-stream

Posted Dec 11, 2020 12:50 UTC (Fri) by pbonzini (subscriber, #60935) [Link]

> If you are saying this had been decided already before the IBM acquisition

That's not what I am saying. I'm saying that people are reading too much into these news. However I like my job and therefore I'm not sure how much of what I know I can say publicly. :)

Changing CentOS in mid-stream

Posted Dec 11, 2020 19:08 UTC (Fri) by joib (subscriber, #8541) [Link] (130 responses)

It seems that RH themselves never actually committed to that. From a discussion on another forum:

> as best I understand this right now, what happened here was basically a cock-up. Someone in the CentOS community, assuming everything for CentOS 8 would be the same as before (which was a perfectly reasonable assumption), put the 2029 EOL date on a wiki page. From there it made its way to some other places, including the official download page, where it was present for a while. I don't know the ins and outs of exactly who added it where when, but it seems like it was never actually *intended* - we never meant to declare CentOS 8 support would run till 2029 because this whole thing was under consideration. But it did, mistakenly, get out there. Speaking personally I agree it sucks that we had that date up and it's now being changed.

Changing CentOS in mid-stream

Posted Dec 12, 2020 17:51 UTC (Sat) by LightDot (guest, #73140) [Link] (129 responses)

I'm personally not buying this. You're planning such a major change and don't check what is being told to the users?

At the very least, communication between Red Hat decision makers and the Red Hat's own CentOS team was lacking, the communication towards the CentOS users even more.

The choice of words here "we’ve informed the CentOS Project Governing Board that we are shifting our investment fully from CentOS Linux to CentOS Stream" leaves little doubt as to who decided for whom, and when, doesn't it?

Changing CentOS in mid-stream

Posted Dec 12, 2020 19:08 UTC (Sat) by Wol (subscriber, #4433) [Link]

> At the very least, communication between Red Hat decision makers and the Red Hat's own CentOS team was lacking, the communication towards the CentOS users even more.

You're assuming that Red Hat were involved. The whole point of COMMUNITY is that there are senior CentOS people OUTSIDE of IBM/RH, and it could easily have come from there. In fact, from another post, it sounds like it probably did.

Cheers,
Wol

Changing CentOS in mid-stream

Posted Dec 12, 2020 20:04 UTC (Sat) by pizza (subscriber, #46) [Link] (127 responses)

> The choice of words here "we’ve informed the CentOS Project Governing Board that we are shifting our investment fully from CentOS Linux to CentOS Stream" leaves little doubt as to who decided for whom, and when, doesn't it?

Yes and no.

The CentOS Board was free to tell Red Hat to go pound sand. But that would likely result in CentOS-the-project ceasing to exist altogether, because CentOS was in dire straits before Red Hat acquired the CentOS team and dumped a ton of extra resources into it. Since then, Red Hat has continued to provide nearly all of the funding and resources for CentOS-the-project.

Putting together and maintaining "Classic CentOS" is a _lot_ of unglamorous, tedious work, even when completely piggybacking on top of RHEL's source packages. Hardly anyone was willing to do any of this work before; and that's only shrunk since then.

(The common thread here seems to be the highly naive expectation that _someone else_ will indefinitely perform (and/or pay for) the very tedious work involved in maintaining glacially-stable distributions for commercial use..)

Meanwhile, Red Hat's investment into CentOS has made it _much easier_ for third parties to come along and recreate "Classic CentOS" -- all development is now completely in the open, including the tooling used to put everything together. Instead of packages being developed in private and dumped over the wall every six months, it's all out in the open using a CI model. Thanks to CentOS Stream, now anyone can act like Oracle and claim they're better than RHEL because they ship Red Hat's work before Red Hat does.

Changing CentOS in mid-stream

Posted Dec 12, 2020 23:00 UTC (Sat) by nknight (subscriber, #71864) [Link] (123 responses)

It’s already happening. CloudLinux announced they’re going to expose their build infrastructure to allow the community to maintain a new RHEL clone. All Red Hat has done is ensure they no longer have any control at all.

Changing CentOS in mid-stream

Posted Dec 13, 2020 0:06 UTC (Sun) by pizza (subscriber, #46) [Link] (27 responses)

> All Red Hat has done is ensure they no longer have any control [of CloudLinux's RHEL clone] at all.

Um, except for the fact that it's a RHEL clone. Which means it needs to closely copy whatever Red Hat does. Which means that Red Hat still has near-total control over what goes into CloudLinux's offering. After all, if it diverges, then it's no longer a RHEL clone.

After all, the entire point of using "RHEL clones" is to piggyback on top of the obscene amount of engineering and QA work that Red Hat puts into making RHEL "stable".

Changing CentOS in mid-stream

Posted Dec 14, 2020 7:36 UTC (Mon) by nknight (subscriber, #71864) [Link] (26 responses)

CentOS was very clearly treated as a funnel into paid RHEL. Now CloudLinux has control of that funnel and the loyalty of users, and gets to push them towards its own offerings. Expect it to diverge indeed - I doubt RHEL or CentOS will be at all relevant in five years.

Changing CentOS in mid-stream

Posted Dec 14, 2020 12:22 UTC (Mon) by pizza (subscriber, #46) [Link] (24 responses)

> Expect [Oracle Linux] to diverge indeed - I doubt RHEL or CentOS will be at all relevant in five years.

I will believe this when Oracle's investment into "Oracle Linux" crosses the 9 digit threshold. Or at least when Oracle's contributions to Linux (be it the kernel or any significant stack) make it into the top ten for mulitple release cycles.

Oracle Linux (especially its pricing model) is only viable today because Oracle relies on Red Hat to do the overwhelming majority of the engineering effort.

Changing CentOS in mid-stream

Posted Dec 15, 2020 0:19 UTC (Tue) by nknight (subscriber, #71864) [Link] (23 responses)

Oracle and CloudLinux have nothing to do with each other.

Changing CentOS in mid-stream

Posted Dec 15, 2020 2:48 UTC (Tue) by pizza (subscriber, #46) [Link] (22 responses)

> Oracle and CloudLinux have nothing to do with each other.

Whoops, I stand corrected; I conflated the two.

The thing is, my point is even stronger with respect to CloudLinux -- While Oracle is generally a crappy corporate player, they _do_ invest money into upstream Linux, and employ a lot of engineering talent. If CloudLinux is to become anything other than JustAnotherRHELClone (ie successfully "fork" RHEL in a way that makes RHEL irrelevent, as you suggest will happen within five years) they're going to have to substantially step up their sustained investment, which also implies coming up with a way to pay for that investment.

Changing CentOS in mid-stream

Posted Dec 16, 2020 0:00 UTC (Wed) by nknight (subscriber, #71864) [Link] (21 responses)

They just did. Seriously, the consisten theme I see from Red Hat and it’s defenders is a lack of awareness of what’s going on *anywhere* in the FOSS community, including RH’s corner of the community. The same lack of awareness that led to killing CentOS in the first place. Your arguments may be valid from Red Hat’s perspective, but that perspective is fatally flawed. We do *not* match your mental model of us.

Changing CentOS in mid-stream

Posted Dec 16, 2020 0:59 UTC (Wed) by pizza (subscriber, #46) [Link] (20 responses)

> Seriously, the consisten theme I see from Red Hat and it’s defenders is a lack of awareness of what’s going on *anywhere* in the FOSS community,

You seem to completely lack the awareness that if Red Hat goes away, all of these "Free RHEL rebuilds" go away too, because putting together (and providing a decade's worth of support for) what ClearLinux is mechanically cloning costs a hell of a lot more than a million dollars.

Look at LWN's "top Linux contributors" pages going back, well, forever. Red Hat is consistently #2 in the Kernel, and is a dominant funder for many (most?) of the plumbing layers (toolchains, sound, graphics, general desktop, multiple server-focused middleware stacks, virtualization, etc etc) -- a total of $668.5 million on R&D efforts in FY2019 alone, all of which went into publicly-released Free (or Open Source) Software. RHEL subscriptions paid for all of that.

So be careful what you wish for.

> We do *not* match your mental model of us.

Who is this "us" you speak of? Choosing beggars that seem to believe that they're somehow entitled to tell others what work they should be doing? (For free!)

Yeah, this change in CentOS sucks, no two ways about it. It affects me too; fortunately the uses I have for CentOS are just fine with the CentOS stream model. But I'm not going to trash Red Hat for making that change, because they owe me nothing. Instead, I will say "thank you for continuing to provide, and integrate/test/support all of this Free Software" because whether or not I actually use RHEL/CentOS/Fedora, I still heavily benefit from Red Hat's ongoing investments, and want to see them continue.

Changing CentOS in mid-stream

Posted Dec 16, 2020 1:09 UTC (Wed) by nknight (subscriber, #71864) [Link] (19 responses)

They used their economic power to hijack a community brand and kill its purpose less than a year after publicly affirming their commitment to it and its roadmap. I'm going to trash them for their dishonesty the same I would anyone else.

Changing CentOS in mid-stream

Posted Dec 16, 2020 1:30 UTC (Wed) by pizza (subscriber, #46) [Link] (18 responses)

> They used their economic power to hijack a community brand

*snort* It was not a "community brand", it was owned by the founders of CentOS. There was no "hijacking" either; CentOS could have politely told Red Hat to get lost. (And if they had, CentOS probably wouldn't have survived another year, not because of reprisals, but because the CentOS folks were already quite burnt out and were having major problems getting code/updates shipped)

Meanwhile, Red Hat's "economic power" is the only reason CentOS (and Scientific Linux, and Oracle Linux, and ClearLinux) ever existed to begin with. Ya know, that whole "binary RHEL rebuild" thing.

Changing CentOS in mid-stream

Posted Dec 16, 2020 3:31 UTC (Wed) by nknight (subscriber, #71864) [Link] (17 responses)

Keep justifying your defeatism and Red Hat worship to yourself however you like. I’m done entertaining you.

Changing CentOS in mid-stream

Posted Dec 16, 2020 3:43 UTC (Wed) by pizza (subscriber, #46) [Link] (16 responses)

> Keep justifying your defeatism and Red Hat worship to yourself however you like.

Um, you're the one being all negative here, but whatever...

> I’m done entertaining you.

I'm sorry you feel that way.

Changing CentOS in mid-stream

Posted Dec 16, 2020 9:40 UTC (Wed) by nknight (subscriber, #71864) [Link] (15 responses)

Dude, really? *Really?* Of course I'm negative. You think I should show *positivity* for a change I want *reversed*? WTF? If I had no hope that Red Hat would make a change for the better, I would never have spoken up to begin with, never told them what a catastrophic effect it's having on us. I'm done speaking up on it now, because it's obvious it won't change, but for a few days I held out hope. Now it's fucking gone. Happy?

Changing CentOS in mid-stream

Posted Dec 17, 2020 23:27 UTC (Thu) by daniel (guest, #3181) [Link] (14 responses)

Welcome to APT, it's nice here. There's a supportive community here. There's actual community here.

Changing CentOS in mid-stream

Posted Dec 17, 2020 23:48 UTC (Thu) by mathstuf (subscriber, #69389) [Link] (12 responses)

You've left a number of apt-praise comments here, so I'll just pick this one to reply to.

As an outsider, every time I interact with the apt suite of tools I find myself confused and searching the Internet because I can't remember which tool I need to install to answer my query or even ask a simple `--help` about. It makes me really happy to have dnf as a frontend to my package management. Maybe someone could write a simple dnf-like tool in front of dpkg and finally kill off the apt mess, but who knows. That still wouldn't help alleviate the nightmares about trying to untangle dpkg creation tools and recipes and am much happier with .spec files, but that's a different thing.

(FWIW, I started with Fedora Core 5 using apt-rpm until yum was useful enough to ignore it.)

Changing CentOS in mid-stream

Posted Dec 18, 2020 1:42 UTC (Fri) by Cyberax (✭ supporter ✭, #52523) [Link] (10 responses)

> As an outsider, every time I interact with the apt suite of tools I find myself confused and searching the Internet because I can't remember which tool I need to install to answer my query or even ask a simple `--help` about.
There's one tool you need to know: apt (and apt-file). It can do everything.

There's no need for dpkg shenanigans.

Changing CentOS in mid-stream

Posted Dec 18, 2020 14:54 UTC (Fri) by zlynx (guest, #2285) [Link] (9 responses)

What, really?

Just yesterday I needed to know what had installed the file /etc/OpenCL/vendors/mesa.icd

The command to find that on Ubuntu is "dpkg -S /etc/OpenCL/vendors/mesa.icd". On Fedora it is "rpm -qf /etc/OpenCL/vendors/mesa.icd"

I don't think "apt" or "dnf" handles that at all.

There are actually a lot of things the higher level apt or dnf commands don't do.

Changing CentOS in mid-stream

Posted Dec 18, 2020 15:15 UTC (Fri) by rahulsundaram (subscriber, #21946) [Link] (7 responses)

> I don't think "apt" or "dnf" handles that at all.

This isn't true for dnf. yum/dnf has whatprovides and if you don't have the package installed and want to query against the repository metadata, you can use dnf repoquery (with yum, repoquery was a separate tool shipped as part of yum-utils).

Changing CentOS in mid-stream

Posted Dec 18, 2020 15:35 UTC (Fri) by amacater (subscriber, #790) [Link] (6 responses)

If apt doesn't do it, apt-file certainly does.

Many Red Hat users have got used to using dnf/yum - in the case of yum, that's a third party contribution to Red Hat.

dpkg -S queries at the same level as a raw rpm command

apt will do much of what you want. In some circumstances, you might want apt-file. apt-cache search foo is also useful and apt-cache is included in apt. [First came deity, then apt-get, then aptitude with a superior solver for package dependencies, then apt - the name goes back to Wed, 4 Mar 1998 19:58:33 +0000 (GMT) and the corresponding post on the debian-devel-mailing list - https://lists.debian.org/debian-devel/1998/03/msg00332.html ]

[For the curious, there was apparently a point at which Red Hat considered adopting something other than RPM right back at the beginning. Of the surviving distributions: Slackware is first, a few months later is Debian, a couple of months later is Red Hat and SUSE is an independent entity out of Jurix. And, for the purists: Debian packaging and Red Hat packaging are largely equivalent when all's said and done. A Debian package can be stripped apart using cpio and tar - an rpm requires a specific binary to do this if I remember rightly.]

Changing CentOS in mid-stream

Posted Dec 18, 2020 16:23 UTC (Fri) by rahulsundaram (subscriber, #21946) [Link] (2 responses)

> Many Red Hat users have got used to using dnf/yum - in the case of yum, that's a third party contribution to Red Hat.

That's an odd way to phrase it given that it wasn't a contribution to the company as such, just happens to be an open source project not originating from any particular vendor like the vast majority of the distribution and I am not sure why it is relevant.

In any case, for the record, Seth Vidal who was the primary developer of Yum (and a key contributor to CentOS for that matter) and was an active direct contributor to Fedora during the time that Yum became default in Fedora (and subsequently RHEL, derived from Fedora adopted it) and was an employee of Red Hat for several years while working on Yum among other things till he passed away.

Some more backstory: https://www.linuxfoundation.org/blog/2013/07/in-memoriam-...

Changing CentOS in mid-stream

Posted Dec 18, 2020 17:14 UTC (Fri) by amacater (subscriber, #790) [Link] (1 responses)

Only really that I knew that Yum concept basically came from outside Red Hat - Yellow Dog Linux, then - and is alien to fundamental RPM - it's an add on.. I was trying to demonstrate the difference between fancy front ends and the most fundamental package ordering/dependency resolving "thing" - dpkg for Debian and RPM for Red Hat and derived distributions. (And yes, RPM has had a couple more rewrites and a change to lower case: dpkg was rewritten a few times in 1994 but is essentially the same since then).

There's not a lot to choose between them, as I wrote: I've had someone complain at me that it was harder to check signatures of packages in Debian because Debian signs the package manifest - but, meh, apt[-get|itude] checks that for you automatically and will whinge at you if the package list is out of date.

Changing CentOS in mid-stream

Posted Dec 18, 2020 18:29 UTC (Fri) by rahulsundaram (subscriber, #21946) [Link]

> Only really that I knew that Yum concept basically came from outside Red Hat - Yellow Dog Linux, then - and is alien to fundamental RPM - it's an add on

To be more accurate, YUP is from Yellow Dog. Yum although it shares some history with YUP is significantly different and originated from Duke university with Seth Vidal as the primary developer. Technically, similar to dpkg vs Apt. As you noted, just a higher level tool - I consider this as a package manager vs higher level dependency resolver (in Dnf - there are multiple libraries that handle different aspects and the resolver logic is part of libsolv - Originating from Opensuse). In Debian, there have been different resolvers in the past (Smart for example - Canonical at one point was considering making it the default resolver for Ubuntu).

Changing CentOS in mid-stream

Posted Dec 18, 2020 22:53 UTC (Fri) by Wol (subscriber, #4433) [Link]

> a couple of months later is Red Hat and SUSE is an independent entity out of Jurix.

If I remember my SuSE history correctly, it started a few months before Red Hat as a Slackware derivative. Then they rebased it on Jurix, before starting to use rpm as their packaging solution.

Cheers,
Wol

Changing CentOS in mid-stream

Posted Dec 29, 2020 16:06 UTC (Tue) by jwilk (subscriber, #63328) [Link] (1 responses)

> A Debian package can be stripped apart using cpio and tar

It's ar, not cpio: https://manpages.debian.org/deb.5

Changing CentOS in mid-stream

Posted Dec 30, 2020 18:23 UTC (Wed) by anselm (subscriber, #2796) [Link]

RPM packages are basically cpio archives with a header attached in front. There's an rpm2cpio program that will remove the header so the rest can be fed to cpio.

Changing CentOS in mid-stream

Posted Dec 18, 2020 19:54 UTC (Fri) by Cyberax (✭ supporter ✭, #52523) [Link]

> Just yesterday I needed to know what had installed the file /etc/OpenCL/vendors/mesa.icd
You can use "apt-file search /etc/OpenCL/vendors/mesa.icd". It optionally can search for it in the remote repositories.

Changing CentOS in mid-stream

Posted Dec 18, 2020 2:12 UTC (Fri) by mpr22 (subscriber, #60784) [Link]

The ones you are likely to need (and their man pages) are all part of package "apt", which is Essential: yes (i.e. all users and packagers are allowed to assume it is present on a "normal" Debian system", so

apropos 'apt(-.*|)\>'

should do the trick.

Don't bother with the APT User Guide in package "apt-doc", though. As far as I can tell, it's desperately undermaintained.

Changing CentOS in mid-stream

Posted Dec 18, 2020 1:13 UTC (Fri) by Wol (subscriber, #4433) [Link]

Well, as someone who avoids apt-based distros like the plague, I doubt I'll be joining your community. That's fine, if you're happy there then all well and good.

Remember, what floats my boat may well sink yours, and vice versa.

My main package management tool is emerge, and there's a good community for me there, too ... :-)

Cheers,
Wol

Changing CentOS in mid-stream

Posted Dec 15, 2020 6:36 UTC (Tue) by pbonzini (subscriber, #60935) [Link]

> CentOS was very clearly treated as a funnel into paid RHEL

I am curious how you get that impression, because it couldn't be further from truth.

Changing CentOS in mid-stream

Posted Dec 13, 2020 11:47 UTC (Sun) by johannbg (guest, #65743) [Link] (94 responses)

> All Red Hat has done is ensure they no longer have any control at all.

That makes no sense Red Hat always has direct control over the trademark it owns and related products including the ability to end them thus it has indirect control over any derivatives that are based strictly on those same products as well.

A good example of this is when Red Hat made the poor management choice and sacrificed it's ethical values for profit when it started to obfuscate it's source code release in an attempt to make business harder for downstream consumers of RHEL's source code that rebranded, rebuild, and redistribute it.

Changing CentOS in mid-stream

Posted Dec 13, 2020 12:33 UTC (Sun) by pbonzini (subscriber, #60935) [Link] (83 responses)

> started to obfuscate it's source code release

What do you mean?

Changing CentOS in mid-stream

Posted Dec 13, 2020 12:51 UTC (Sun) by johannbg (guest, #65743) [Link] (82 responses)

I'm pretty sure you are already aware of this but back in the day, to counter the fact that Oracle had a better sales strategy and or sales people, Red Hat management got the bright idea of making things harder for everyone by shipping its RHEL 6 kernel source as one big tarball, without breaking out the patches ( as opposed to coming up with a better sales strategy than Oracle ).

Changing CentOS in mid-stream

Posted Dec 13, 2020 13:50 UTC (Sun) by pbonzini (subscriber, #60935) [Link] (44 responses)

Ah, that one; I had forgotten. Yes, that one was done because of Oracle but it's really much ado about nothing.

For one, due to the sheer amount of patches in the RHEL kernel the process was starting not to scale. Every six months thousands and thousands of patches are applied. Just applying all the patches from an RPM would take several hours.

Second, no one in the CentOS community had even noticed that, for the ability for the community to rebuild was not affected at all. The whole thing came up when some Debian engineers went looking for kernel patches in RHEL6's 2.6.32 kernel to fix a bug. Well, they could have asked the upstream maintainer perhaps, since he worked for Red Hat: in the last couple years I have helped several times with backports for various processor erratas back to 3.14 or so.

Third, that's not obfuscation. There's countless open source projects that are developed within closed doors, with new releases consisting of code drops from a private repo to GitHub. Instead Red Hat is doing *all* development upstream first and providing the list of commits (99% of which apply with zero conflicts given how closely the RHEL8 kernel tracks upstream). Talk about double standards...

Changing CentOS in mid-stream

Posted Dec 14, 2020 7:37 UTC (Mon) by nknight (subscriber, #71864) [Link] (43 responses)

No one believes this excuse because we all know you’re tracking the patches internally. All you’re doing is hiding information that already exists.

Changing CentOS in mid-stream

Posted Dec 14, 2020 13:52 UTC (Mon) by pbonzini (subscriber, #60935) [Link] (42 responses)

Internally we have a git tree, yes. We haven't used RPMs with manually-tracked patches for years.

Changing CentOS in mid-stream

Posted Dec 14, 2020 22:13 UTC (Mon) by paulj (subscriber, #341) [Link] (33 responses)

And so that git tree is the preferred form for modifications.

Changing CentOS in mid-stream

Posted Dec 15, 2020 6:51 UTC (Tue) by pbonzini (subscriber, #60935) [Link] (32 responses)

People remember only "preferred form for making modifications", but forget that:

1) that is nothing more than the definition of "source code", which is the actual term used by the GPL. Source code has a week known meaning in the industry that does not include the history.

2) the GPL also says that "for an executable work, complete source code means all the source code for all modules it contains, plus any associated interface definition files, plus the scripts used to control compilation and installation of the executable" again with no reference to the history

3) "making modifications" does not require a git tree (ever done a shallow clone?). "Debugging", "identifying changes for the purpose of porting them to a different derivative", "collaborating with other people in the same organization" are not activities that the GPL talks about.

That said I am not sure how CentOS Stream will handle kernel changes. Maybe the git tree will be public after all, I don't know. The list of patches already is.

Changing CentOS in mid-stream

Posted Dec 15, 2020 7:57 UTC (Tue) by nknight (subscriber, #71864) [Link] (1 responses)

You have just gone from saying it's too much of a burden to arguing you don't legally have to. Do you truly not see the problem here?

Changing CentOS in mid-stream

Posted Dec 15, 2020 10:03 UTC (Tue) by pbonzini (subscriber, #60935) [Link]

No, I was replying to a comment that moved the goalposts from obfuscating code to *alleging* a GPL violation that simply isn't there. End of my replies on this topic, anyway.

Changing CentOS in mid-stream

Posted Dec 15, 2020 9:17 UTC (Tue) by paulj (subscriber, #341) [Link] (29 responses)

The term source code is defined within the GPL (v2 and v3):

"The source code for a work means the preferred form of the work for making modifications to it."

That is the literal licence text.

Is it /possible/ to make modifications without the information of what patches were applied to the stock linux kernel source? Of course! Just as it was /possible/ for people to make modifications to NVidia's obfuscated C X11 driver back in the day. Just as it is /possible/ to make modifications to the binary object code, either with a hex editor or by disassembling the code and editing the assembly code. These are all /possible/.

However, that's not the bar the licence sets. The licence sets the bar at "preferred" - precisely because Stallman anticipated that otherwise some would try work around the GPL with obfuscation.

You and your technical colleagues at RedHat clearly prefer using the git form, with the information of each 'modification' to the stock kernel code preserved, so as to make it easier to shuffle, update, re-order, drop, and work with all the changes. That is the preferred form.

The form you release has deliberately had that information stripped, so as to obfuscate it, and make it harder for others to work with.

Changing CentOS in mid-stream

Posted Dec 15, 2020 9:25 UTC (Tue) by paulj (subscriber, #341) [Link] (7 responses)

Oh, and note I didn't mention history. I reference the information about the fixes and changes that were made to the stock kernel.

Your src.rpm form has the ability - indeed was /designed/ - to convey the original code and each change separately (the source and "patches") in a way that preserved this critical information. RedHat long created src.rpms of the kernel (from some other SCM I think) with the stock kernel code as the source, and the changes as patches. RedHat deliberately chose to collapse the source, and remove that information - critical to the preferred form for working with that code - to disadvantage others.

You could either publish the git, or (again) split out the source and each change as a patch in the src.rpm.

Changing CentOS in mid-stream

Posted Dec 15, 2020 11:10 UTC (Tue) by paulj (subscriber, #341) [Link] (6 responses)

Oh, and if that src.rpm format doesn't scale, and hence the git version is the only /workable/ way to deal with that information, well... Refer to the definition of "source code" in the licence you're obliged to follow again.

Changing CentOS in mid-stream

Posted Dec 15, 2020 13:52 UTC (Tue) by pbonzini (subscriber, #60935) [Link] (5 responses)

I'm pretty sure that Red Hat employs better lawyers than you (and me). So all I can say is "well, that's just like, your opinion, man".

Changing CentOS in mid-stream

Posted Dec 17, 2020 23:58 UTC (Thu) by daniel (guest, #3181) [Link] (4 responses)

What about the spirit of the license, does that matter or is that just my opinion?

Changing CentOS in mid-stream

Posted Dec 18, 2020 0:12 UTC (Fri) by rahulsundaram (subscriber, #21946) [Link] (3 responses)

> What about the spirit of the license, does that matter or is that just my opinion?

Who is going to determine what the "spirit" of the license is and how is that going to be enforced?

A license is a legal agreement. If something is not covered explicitly by the terms of the license that it is intended to cover, that is just a bug and should be fixed. Having clarity within the license is more effective than attempting to attach unspecified terms outside of it.

Changing CentOS in mid-stream

Posted Dec 18, 2020 1:11 UTC (Fri) by pizza (subscriber, #46) [Link] (1 responses)

> If something is not covered explicitly by the terms of the license that it is intended to cover, that is just a bug and should be fixed.

And then that bug-fixed version of the license will get rejected by those intentionally taking advantage of the gray areas in the old license, while accusing its creators as being clueless zealots who are out of touch with what businesses need from "modern" software development.

Changing CentOS in mid-stream

Posted Dec 18, 2020 1:42 UTC (Fri) by rahulsundaram (subscriber, #21946) [Link]

>And then that bug-fixed version of the license will get rejected by those >intentionally taking advantage of the gray areas in the old license

...Which is fine. Arguably this already happened with GPLv2 and GPLv3. The old and new versions have clear delineations and the choices are transparent to everyone as opposed to talking about the nebulous spirit of the license which really can mean anything from "The author of the license thinks this way" to "the project using the license thinks it should be interpreted this way" to "this person in LWN who is connected to neither wishes the license has this expanded interpretation although the plain reading of the license doesn't really say that". It is not the job of a software license to mandate healthy best practices around a community. If that was the case, even GNU wouldn't past that test given that bash git changelog has a lot of tarballs checked in directly on a routine basis.

Changing CentOS in mid-stream

Posted Dec 18, 2020 1:17 UTC (Fri) by Wol (subscriber, #4433) [Link]

> Who is going to determine what the "spirit" of the license is and how is that going to be enforced?

The musings/writings of (people within) the FSF is a good determinant of the GPL. If the wording of a licence is not clear a Judge has two options - to interpret it in favour of the defendant(s), or to interpret it in the light of explanatory text by the authors. Both are valid approaches.

And I think, in UK courts, Judges have been known to read Hansard and use the contents thereof to ignore the explicit black letter of the law on the basis that "MPs were misled when asked to vote on it".

Cheers,
Wol

Changing CentOS in mid-stream

Posted Dec 15, 2020 14:24 UTC (Tue) by pizza (subscriber, #46) [Link] (4 responses)

> However, that's not the bar the licence sets. The licence sets the bar at "preferred" - precisely because Stallman anticipated that otherwise some would try work around the GPL with obfuscation.

No, that clause was intended to ensure source code was supplied in an easily-machine-readable/modifiable form, as opposed to, say, delivered on reams of paper where it would first need to be OCR'd.

( https://lwn.net/Articles/431651/ )

Changing CentOS in mid-stream

Posted Dec 15, 2020 14:36 UTC (Tue) by paulj (subscriber, #341) [Link] (3 responses)

The paper v CDROM motivation would be addressed by "medium customarily used for software interchange" condition, if distributing the source code separately.

Note that today, git might be considered that medium. The source code on that medium defined as having to be in the "preferred form for making modifications".

Obfuscated source - i.e. sources with information removed (so as to frustrate others) - is not source code, as the GPL requires it.

Changing CentOS in mid-stream

Posted Dec 15, 2020 16:23 UTC (Tue) by pizza (subscriber, #46) [Link] (2 responses)

> Note that today, git might be considered that medium.

No, "medium" refers to something physical. Paper, tape, compact disc, or even the internet. How those bits are organized on that medium doesn't matter as long as that _medium_ is "machine readable" and "customarily used for software interchange".

(And yes, in the early days of the FSF/GNU, distributing software on machine-readable paper was very much still a thing!)

> Obfuscated source - i.e. sources with information removed (so as to frustrate others) - is not source code, as the GPL requires it.

But revision history is not source code, and the GPL covers *source code* only.

So yes, deliberate obfuscating the source code is a no-no, but how is distributing one big patch vs 100 smaller patches "obfuscating" the source code?

The GPL does not require revision control or any associated metadata with change history beyond "complete corresponding source code" is supplied for stuff distributed in binary form -- ie everything needed to recreate the distributed binaries. If you're distributing stuff purely in source code form, then you can supply the complete original work (modified or not), a random ten-line snippet, or anything in between, and deliver it etched into a slab of granite.

And while the GPL requires that any changed files "carry prominent notices stating you changed the files and the date of any change", note that applies at time of *distribution* -- it doesn't matter that I modified file1.c on 2020-11-20 and file 2.c on 2020-11-25, only that I publicly distributed my modified version of both on 2020-12-01, and a patch file clearly shows what was modified, and the "when" is "the timestamp of the patch file"

And before you say that a patch file doesn't satisfy that requirement, because it lies outside the files themselves, I should point out that revision control doesn't either, as that what/when change metadata is also not part of the actual files.

Changing CentOS in mid-stream

Posted Dec 15, 2020 16:50 UTC (Tue) by paulj (subscriber, #341) [Link] (1 responses)

You're just wrong on the definition of medium. A network can be a medium. HTTP over the internet can be a medium. Air can be a medium. Light can be a medium. Quantum entanglement can be a medium.

I think it pretty obvious how collapsing and removing information about the constitution of code obfuscates it - be it by a compiler transforming C code into object code; or a RedHat src.rpm building system turning a series of commits in a git tree into one big blog of a patch.

The wording in the licence is "preferred form", and there is a simple test: Would the RedHat engineers prefer to work with the collapsed big-patch, or with the broken-out patches? The answer to that is obvious, given how RedHat engineers work.

Changing CentOS in mid-stream

Posted Dec 15, 2020 17:26 UTC (Tue) by pizza (subscriber, #46) [Link]

> You're just wrong on the definition of medium. A network can be a medium. HTTP over the internet can be a medium. Air can be a medium. Light can be a medium. Quantum entanglement can be a medium.

In other words, by virtue of their use of HTTP over the internet, Red Hat is using "a medium customarily used for software interchange" to distribute their complete corresponding source code.

> I think it pretty obvious how collapsing and removing information about the constitution of code obfuscates it - be it by a compiler transforming C code into object code; or a RedHat src.rpm building system turning a series of commits in a git tree into one big blog of a patch.

Please stop bringing up the red herring of distributing [partially] compiled sources, because (1) everyone agrees that is an explicit GPL violation, and (2) RH has never done that.

What's being "obfuscated" are the sequence and history of individual changes. The *source code* is the same either way.

Meanwhile, it's been nearly a decade since RH made this change -- see https://lwn.net/Articles/432012/ -- and nothing new has transpired since. You don't have to like what RH is doing. That's fine, a lot of others feel the same way (including our fine LWN editor). However, it is _not_ a GPL violation -- unless you are also arguing that most of what's available on gnu.org is violating the GPL as well. Say what you will about RH, but I trust that the FSF knows how follow their own license.

Changing CentOS in mid-stream

Posted Dec 15, 2020 20:28 UTC (Tue) by madscientist (subscriber, #16861) [Link] (15 responses)

It cannot be that a source code repository is/was considered "the preferred form" in the context of the GPL, because for quite a few years the GNU project itself never published source code repositories. Before the advent of CVS and a public server to host it, individual developers maintained the source on their local systems via RCS or even SCCS.... or maybe not even with any tool at all, just with multiple subdirectories and archived copies of source!

It was not required that people publish their local RCS or SCCS repositories to comply with the GPL: they simply published source tarballs, same as appears now on the ftp.gnu.org site.

Even today I don't think the GNU project requires development of all its software to be performed in a publicly-accessible SCM, and if not to publish the contents of the SCM repository when making releases. Of course, it's moot these days because all GNU projects I'm aware of do it anyway, out of convenience.

Changing CentOS in mid-stream

Posted Dec 15, 2020 22:31 UTC (Tue) by paulj (subscriber, #341) [Link] (14 responses)

Read carefully. I did not argue the revision history /has/ to be part of the preferred form (though, it can't hurt).

That aside, what is preferred can change over time. Things that were preferred in the 80s and 90s need not be (and are unlikely to be, in tech) preferred in the 2020's. And the GPL drafting seems to have been careful to explicitly specify the forms and technologies, no doubt to future-proof it.

Changing CentOS in mid-stream

Posted Dec 18, 2020 0:01 UTC (Fri) by daniel (guest, #3181) [Link] (13 responses)

The revision history would certain be preferred by the vast majority of developers, compared to the unadorned code. Few tasks are more tedious than reverse engineering the patches a distro has applied to upstream source.

Changing CentOS in mid-stream

Posted Dec 18, 2020 10:44 UTC (Fri) by farnz (subscriber, #17727) [Link] (12 responses)

I'm not sure I agree with you, in the context of what the GPL is intended to enable.

While you would prefer the full revision history if you're trying to unpick why the distro did something, that's not something the GPL requires - only identification of the changes, and the ability for a recipient to make further changes. One big patch meets both of those requirements; you can clearly see what Red Hat got from upstream, and what changes Red Hat applied, and you can make further changes yourself.

Changing CentOS in mid-stream

Posted Dec 18, 2020 11:23 UTC (Fri) by paulj (subscriber, #341) [Link] (11 responses)

The GPL requires the "preferred form of the work for making modifications to it".

You're hitting a bug in some Free Software you're using, and you want to fix it. You go to the project's website. They have 'make dist' tarballs, and they have a git repository.

Which will you prefer to download, to make your modifications?

Changing CentOS in mid-stream

Posted Dec 18, 2020 11:28 UTC (Fri) by paulj (subscriber, #341) [Link] (9 responses)

Now, say this Free Software is a kernel from a vendor. They have a git repo, with all the changes as commits; and they have another file that has the stock kernel source, and all their changes munged into one patch.

You want to figure out which of their changes from stock is the problem. You might want to bisect through all the changes, to find the problem change, so you can fix it.

Which form would you prefer to start with?

Changing CentOS in mid-stream

Posted Dec 18, 2020 11:34 UTC (Fri) by farnz (subscriber, #17727) [Link] (7 responses)

Now you've changed from what the GPL requires - it does not require the upstream to make it easy for me to identify which change is problematic, only that I can identify changes from the version my upstream received, and modify it.

If I want to fix-forward, then the version with stock kernel and all their changes is just fine - I don't need to know which change is problematic, I need to know what the bug is and fix it there. I only need to identify the problem change if I simply want to undo some of my upstream's changes but not all of them, and the GPL does not require upstream to make it easy for me to do that, as long as I can comfortably edit and rebuild the work as I received it.

Changing CentOS in mid-stream

Posted Dec 18, 2020 11:39 UTC (Fri) by paulj (subscriber, #341) [Link] (6 responses)

I havn't changed anything. I've asked a question.

The GPL defines source code as "preferred form for modifications" - deliberately framed that way to remain general and be apply across technologies, and across time as tools and preferences change.

Asking questions about how developers work today, what they prefer to have in doing that work - within the confines of what the distributor has available - seems the correct way to me to figure out what "preferred form" should mean.

Changing CentOS in mid-stream

Posted Dec 18, 2020 11:45 UTC (Fri) by farnz (subscriber, #17727) [Link] (5 responses)

If I am modifying the code, then I want the code as a whole on my filesystem - the output of `tar x` or similar. Revision control history is not something I need or usually want to make modifications to code.

You changed from making modifications to finding bugs introduced by modifications that my upstream made. In that situation, I'd like revision control history, as part of identifying the bug, not as part of modifying the code. Once I've identified the bug, I'll go back to the final form I was given and fix that.

Changing CentOS in mid-stream

Posted Dec 18, 2020 12:53 UTC (Fri) by paulj (subscriber, #341) [Link] (4 responses)

Well, I don't know where the line is. I think an argument can be made that, if the distributor has gone to trouble of implementing a system to keep track of the upstream source and each change made to it, and that system is well capable of exporting that information (while stripping non-code stuff, like customer/ticket meta-data), then that might be the more preferred form. Certainly, if that distributor further goes to extra effort to /remove/ that information...

Flip it around: Say you're a distributor of other people's copyleft software. You have a git tree tracking changes.

Do you want to try dance on pins to argue that the workflow that is the easiest (and practical - given scaling) for you, is somehow not preferable for others, and acceptable within the licence, trying to justify nformation-striping you added to frustrate competitors?

Or do you just export that git tree (with whatever git filter), to make sure you accommodate others, and err on the side of staying clearly within the licence?

Changing CentOS in mid-stream

Posted Dec 18, 2020 13:21 UTC (Fri) by farnz (subscriber, #17727) [Link] (3 responses)

But I use such a system, not to track the code, but to allow multiple people to work together on the code without conflicting. The VCS is a side-effect of that, used while I'm producing the work to allow several modifications to happen in parallel while providing me with a way to integrate them together into a final form that I release to my customers.

FWIW, when I worked somewhere that *did* distribute other people's copyleft software, every lawyer we dealt with said that the maximum the licence demanded was a tarball from my upstream, and a diff that could be applied with my changes to get to the modified version we shipped.

So, you can dance on pins trying to stretch the licence to require my development workflow to be shipped with my modified code, or you can stay clearly within the licence.

Changing CentOS in mid-stream

Posted Dec 18, 2020 15:40 UTC (Fri) by farnz (subscriber, #17727) [Link] (2 responses)

And, as an aside while you're thinking about where stretching this goes, my preferred form for modification of code is downloaded to the filesystem of a fast machine with a decent 32" monitor attached and an editor set up to my preferences. I use that for every modification I make, including the ones I have that are in the upstream Linux kernel.

A VCS is entirely optional for modifying code, given a decent editor with good undo facilities and auto-commenting of lines. It makes it much, much easier to share my modifications with people, and to track what is the code I got from upstream versus what I've modified, but I do not use the VCS as part of actually modifying the code. In contrast, I do use the fast computer, the editor, and the monitor as part of actually modifying code - I've never made a kernel modification without a monitor and an editor of my choice.

Changing CentOS in mid-stream

Posted Dec 18, 2020 17:38 UTC (Fri) by paulj (subscriber, #341) [Link] (1 responses)

The preferences of the distributor are more germane to the point, particularly where the distributor seeks to deny the same to others.

If monitors were specific to software source code, and you needed a very specific monitor unique to a code-base in order to modify it, and it was typical in software for proprietary vendors of code-base to sell such monitors along with source-code; and if someone created a copyleft licence that required all the tools to be passed along to those the redistributed the code to; then yes... maybe you could require people to supply monitors.

However, in this world, the hardware is usually general, and the general hardware is usually not supplied. So, that's a super-hypothetical world.

The GPLv3 does require the tools - other than general-purpose - to be supplied as part of the source code.

Changing CentOS in mid-stream

Posted Dec 18, 2020 17:57 UTC (Fri) by farnz (subscriber, #17727) [Link]

But the VCS is also a general purpose tool, like a monitor, and when it comes to modifying code (e.g. to add support for a new printer type), I have no interest in what's in the VCS, whereas I do have a deep interest in having decent tools for actually making my changes. Indeed, if you give me the choice between my current monitor and a distribution tarball of the code, or a monitor half the area (a 22" or so) and full VCS history for a project I want to modify, I'll take the tarball and my current monitor every single time.

While I don't work at Red Hat, I suspect the same is true of their engineers too - full VCS history is nice, but good tools are far more important if you're modifying the code.

Changing CentOS in mid-stream

Posted Dec 18, 2020 12:16 UTC (Fri) by farnz (subscriber, #17727) [Link]

And note that the ideal form for identifying their bug so I can fix it is not just the full revision history, but also full access to all the people involved in writing the changes so that I can talk to them about what they did, why they did it, and what the interactions with other changes are.

Taking your interpretation at face value, I could argue that because that's my preferred form of the code for fixing bugs, I have a right to your time if you distribute code to me (directly or indirectly). The GPL limits it to my preferred form for making modifications, and when I'm modifying code, I do that via a working copy and an editor, not via a VCS of some form.

Changing CentOS in mid-stream

Posted Dec 18, 2020 11:29 UTC (Fri) by farnz (subscriber, #17727) [Link]

The `make dist` tarballs. That gets me something that's close to what I'm actually using to start from, and has handled a lot of the details of whatever build system the project uses already - so there's less work for me in getting to the point where I can build their code and run with it.

This changes if I want to contribute the fix back, but it's the desire to contribute that pushes me to the extra hassle of the git tree, not details of how I'd fix the problem.

Changing CentOS in mid-stream

Posted Dec 14, 2020 23:58 UTC (Mon) by nknight (subscriber, #71864) [Link] (7 responses)

Publish the git tree. Problem solved. Or are you ashamed of what you’re doing in that tree?

Changing CentOS in mid-stream

Posted Dec 15, 2020 0:54 UTC (Tue) by Cyberax (✭ supporter ✭, #52523) [Link] (6 responses)

It might contain sensitive metadata (like client names).

Changing CentOS in mid-stream

Posted Dec 15, 2020 8:04 UTC (Tue) by nknight (subscriber, #71864) [Link] (2 responses)

I've never heard a single Red Hat employee make that argument in the years this has been at issue, only third parties. The only thing that could have such information is the commit summaries. Everything else is going to get published anyway per the GPL.

If Red Hat can't get their developers not to shove client names into commit messages (seriously? this would get you *immediately* escorted off the premises at many companies with sensitive clientele), well, just another reason not to trust them.

Changing CentOS in mid-stream

Posted Dec 15, 2020 10:01 UTC (Tue) by Cyberax (✭ supporter ✭, #52523) [Link] (1 responses)

It's common to add ticket numbers and messages to commits.

Changing CentOS in mid-stream

Posted Dec 15, 2020 23:51 UTC (Tue) by nknight (subscriber, #71864) [Link]

Ticket numbers are largely irrelevant, and again, in other companies, confidential information is kept out of bug summaries, partly for exactly this reason. In particularly sensitive cases, developers don’t even have direct access to customer reports, much less know who the customers are. The information is filtered before it ever gets to them.

A source tree of the Linux kernel of such importance is going to be seen by a *lot* of people over time, not all of whom are going to be vetted or trustworthy. If this were the concern, Red Hat would have much deeper problems.

Changing CentOS in mid-stream

Posted Dec 15, 2020 11:08 UTC (Tue) by paulj (subscriber, #341) [Link] (2 responses)

I don't think "Oops, we added sensitive information to the code" lets one ignore the conditions of a copyright licence, which one is obliged to follow.

They'd have to remove that information, in whatever way.

Changing CentOS in mid-stream

Posted Dec 15, 2020 23:17 UTC (Tue) by Cyberax (✭ supporter ✭, #52523) [Link] (1 responses)

I think that during the last round of obfuscation (when RH switched to providing one giant kernel patch) the consensus was that it's OK from the legal standpoint?

Changing CentOS in mid-stream

Posted Dec 18, 2020 0:04 UTC (Fri) by daniel (guest, #3181) [Link]

Is merely adhering to the letter of the law enough for a supposedly community focused organization?

Changing CentOS in mid-stream

Posted Dec 13, 2020 14:15 UTC (Sun) by pizza (subscriber, #46) [Link] (36 responses)

> to counter the fact that Oracle had a better sales strategy and or sales people,

Come on.

Oracle's sales strategy in this case could be best summed up as "We're selling Red Hat's stuff for cheaper than Red Hat sells it."

Which they could easily do because they were relying on Red Hat to perform all of the actual development/engineering work.

(Yes, Oracle's strategy is a bit more nuanced than this, but at the end of they day, they take RHEL, rebuild it, and sell support packages along with "value add" like better integration with Oracle's other offerings.)

Changing CentOS in mid-stream

Posted Dec 13, 2020 16:09 UTC (Sun) by johannbg (guest, #65743) [Link] (35 responses)

Regardless of what the sales strategy is ( good or bad ) from a competitor(s), you counter that by coming up with a better sales strategy not by bringing that problem onto the technical level and or into the pipeline to solve it. That's just bad management and does no one good including your own internal developers.

Anyway the big irony in Red Hat's management deciding to solve a broken sales strategy by obfuscation their source code and expecting that competing company would change its business practice ( Yeah like Larry "lawnmower" Ellis would suddenly grow a conscience ) as a result of that, is that Red Hat's entire business model is built around taking advantage of the openness of thousands of Free Software developers.

Does Red Hat contribute back to communities yes but does it contribute back in a reasonable proportion with the profit it makes profiting of the open source community and it's contributors well that is an material for an entire news article *wink* *wink* *nudge* *nudge*

Changing CentOS in mid-stream

Posted Dec 15, 2020 14:45 UTC (Tue) by paulj (subscriber, #341) [Link] (34 responses)

Exploitation of free software developers is something the GPL unfortunately allows.

There are many companies at this, by various means. Some directly exploitative, taking free software of others and selling it with improvements they do not release back (or release only with great delay), and/or even with portions they will never release the code for. Others indirectly exploitative, by taking free software of others and profiting from it but - as you point at - largely not contributing back with support (employment, say) for those who supplied them with the software.

I think we need next-generation copyleft licences, to address this. Licenses that give users their freedom, but that also empower the actual authors of Free Software and shield the authors better from the parasitical tendencies of corporations - which the current GPL allows.

Changing CentOS in mid-stream

Posted Dec 15, 2020 17:52 UTC (Tue) by mpr22 (subscriber, #60784) [Link] (32 responses)

> Some directly exploitative, taking free software of others and selling it with improvements they do not release back (or release only with great delay), and/or even with portions they will never release the code for.

Those are violations of the GPL, and thus tortious (or even criminal) conduct for which the exploiter can be pursued by the copyright holder in a court of law.

(Yes, this is expensive. No, that expensiveness is not something that can be remedied by redrafting the licence on your software. Fixing that requires the assistance of legislators, not just lawyers.)

Changing CentOS in mid-stream

Posted Dec 15, 2020 19:09 UTC (Tue) by paulj (subscriber, #341) [Link] (31 responses)

Well, proving it can be near impossible.

There is at least one company who a) I know has improvements to software I have helped write; b) State they discharge their GPL obligations by giving the source to their customers with their binaries (i.e., they do not avail of the "offer to any 3rd party" clause in the GPL); d) Yet we never ever could get these improvements. I don't want to go into too much detail, but I strongly suspect side-contracts must be in place that penalise any of their customers if they publish or further distribute these changes to the GPL software.

Another example is the rise of large "cloud" companies, which are not in the business of distributing software. They are massive users of Free Software, and they often make fixes and improvements to that Free Software - but they are under no obligation to give those changes back, as they do not distribute. Some are good, and give back; others view these changes as a competitive advantage and are secretive even about what changes they made - never mind giving the changes back!

I would like a copyleft that completely barred private discharge of the source obligation to solve the first issue, and the second issue seems to me like it could only be fixed with some kind of clause requiring that modifications be made public, based on some reasonable condition to avoid requiring every speculative or dead-end change to have to be made public. E.g., perhaps require that any modifications that are put into use be made available publicly, always.

As for addressing expense, from talking to legal types, I think there may be non-legislative changes to licence text that could be made to make it easier to take action against violaters. E.g., in a number of jurisdictions one can only claim for demonstrable damages, so a licence that explicitly specified a monetary cost for use outwith the copyleft terms (e.g., X% of revenue of any controlling entity of the violator?) could make the licence easier to enforce. This could be done with a meta-licence, I guess - but it would be more universal and less hassle/confusing for developers if it was specified in the same licence.

Changing CentOS in mid-stream

Posted Dec 15, 2020 20:50 UTC (Tue) by Wol (subscriber, #4433) [Link] (30 responses)

> There is at least one company who a) I know has improvements to software I have helped write; b) State they discharge their GPL obligations by giving the source to their customers with their binaries (i.e., they do not avail of the "offer to any 3rd party" clause in the GPL); d) Yet we never ever could get these improvements. I don't want to go into too much detail, but I strongly suspect side-contracts must be in place that penalise any of their customers if they publish or further distribute these changes to the GPL software.

Note that their claim (b) - if true - IS a full and complete discharge of their responsibilities. The GPL does NOT entitle random 3rd parties (including other copyright holders) to request copies of other peoples' source.

It entitles CUSTOMERS to receive a copy of the source. If that copy is not provided when customers receive the binary it is *then* that the "random 3rd party" rule kicks in on the assumption that the original customer may have further distributed the binaries.

And you could well be right with your suspicions in (d), but I suspect that is a breach of neither the letter nor the spirit of the GPL :-(

Cheers,
Wol

Changing CentOS in mid-stream

Posted Dec 15, 2020 22:35 UTC (Tue) by paulj (subscriber, #341) [Link] (24 responses)

Well, indeed, they may well have found a nice way around the GPL. That is why I think we need a copyleft licence that fixes that loophole. This is a deficiency.

I think by banning wholly private discharge of the source code distribution obligation. I.e., I would want a licence that obliges the GPL licensee to make the source available to all, if to any, always.

Changing CentOS in mid-stream

Posted Dec 15, 2020 23:31 UTC (Tue) by Wol (subscriber, #4433) [Link] (19 responses)

> I think by banning wholly private discharge of the source code distribution obligation. I.e., I would want a licence that obliges the GPL licensee to make the source available to all, if to any, always.

Which is COMPLETELY AGAINST the spirit of the GPL.

The whole point of the GPL is to protect *users* against an *abusive upstream*. You are said upstream. The GPL is there to protect your users *against you*. Sorry.

Cheers,
Wol

Changing CentOS in mid-stream

Posted Dec 16, 2020 0:05 UTC (Wed) by paulj (subscriber, #341) [Link] (18 responses)

The GPL exists to protect users' freedom.

The GPL does not exist to allow parasitic corporations to exploit Free Software developers, taking their code and making money of it with effectively-proprietary modifications to their customers, restricting the distribution of those modifications through side-contracts.

If you think those corporations need protecting, we're just going to have fundamentally disagree. And I think you're no friend of Free Software.

Changing CentOS in mid-stream

Posted Dec 16, 2020 0:26 UTC (Wed) by Wol (subscriber, #4433) [Link] (17 responses)

That corporation is YOUR USER. The GPL therefore exists to protect that corporation AGAINST YOU.

You clearly don't understand what the Free Software Foundation thinks is "Free Software", nor what is the intent of the GPL.

The GPL has NEVER been a "friend of the software developer" - if that's what you want you need the BSD licence.

I repeat - that corporation is your *downstream* *user*. The GPL is there to protect *downstream*!

Cheers,
Wol

Changing CentOS in mid-stream

Posted Dec 16, 2020 10:32 UTC (Wed) by paulj (subscriber, #341) [Link] (16 responses)

I have no interest in having parasitic corporations, who actively seek to exploit the Free Software developers who gave them software, and to lock-in users, as my downstreams. Such corporations are bad for the users, bad for the developers, bad for the community around a project, and bad for Free Software generally.

I really do not care about the interests of such parasites, and I'd like to find a copyleft licence that discourages such parasites, to the benefit of the rest of the community.

And I don't see a problem with a copyleft licence protecting the interests of Free Software developers, as long as it still protects the freedom of users.

Changing CentOS in mid-stream

Posted Dec 16, 2020 11:57 UTC (Wed) by pizza (subscriber, #46) [Link] (13 responses)

> And I don't see a problem with a copyleft licence protecting the interests of Free Software developers, as long as it still protects the freedom of users.

As Wol pointed out, "parasitic corporations" are still "users", so what you are saying is that "I want some uses/users to have more rights/freedoms than others".

Changing CentOS in mid-stream

Posted Dec 16, 2020 12:16 UTC (Wed) by paulj (subscriber, #341) [Link] (12 responses)

Which is perfectly fine.

The GPL already excludes users who want to keep modifications they distribute to others proprietary. The problem is that some corporates have found a way to /effectively/ keep their modifications proprietary, while (arguably) staying technically within the law - by placing their restrictions on /other/ users in side-contracts.

These users are already outside of the spirit of the GPL, as far as I'm concerned. They are taking freedoms away from others. I have no time or sympathy for them. I will be glad to see that loophole closed off in future copyleft licences.

Changing CentOS in mid-stream

Posted Dec 16, 2020 12:24 UTC (Wed) by paulj (subscriber, #341) [Link] (9 responses)

And note carefully, the GPL maximises certain benefits for /all/ users, by /removing/ certain freedoms and replacing them with obligations - via the lever of copyright law. The spirit of copyleft is perfectly OK with that (given that we are stuck with copyright as it is).

If you're a Free Software developer that things there should be /no/ restriction on freedoms for users, then go and use a BSD licence. You (and your users) won't get the benefits that copyleft can bring. And that's a subjective decision, and that's fine.

Changing CentOS in mid-stream

Posted Dec 16, 2020 16:41 UTC (Wed) by Wol (subscriber, #4433) [Link] (8 responses)

> And note carefully, the GPL maximises certain benefits for /all/ users, by /removing/ certain freedoms and replacing them with obligations - via the lever of copyright law

You quite clearly have never bothered to read the GPL properly. The pre-amble states that yes, it does place obligations ON THE DEVELOPERS. The following is taken from clause 0 of the GPLv2

> Activities other than copying, distribution and modification are not covered by this License; they are outside its scope. The act of running the Program is not restricted, and the output from the Program is covered only if its contents constitute a work based on the Program (independent of having been made by running the Program). Whether that is true depends on what the Program does.

While this does not explicitly cover the case of some one/thing who is both a downstream and an upstream, I think it is quite clear that the intent of this section (and of the rest of the licence) is to re-iterate the fact that downstream owes NO OBLIGATION WHATSOEVER to upstream. This is the - intentional - reversal of the normal state of affairs where downstream needs permission from upstream to do anything even as little as wiping its nose despite paying through its nose for the privilege...

That's why I said "if you want freedom FOR THE DEVELOPERS you need the BSD licence". The GPL frees your users from any obligation to you. If you don't like it, tough, that's what it is intended to achieve.

Cheers,
Wol

Changing CentOS in mid-stream

Posted Dec 16, 2020 17:13 UTC (Wed) by paulj (subscriber, #341) [Link] (7 responses)

[Not sure this "upstream" / "downstream" terminology is useful. I know the GPLv3 uses it - but the notion that Free Software is an acyclic relationship is limiting, and doesn't recognise one of the great benefits of copyleft of mutual benefit - see below. I'll use it just cause you are.]

The intent of the GPL is to ensure the downstream has all the rights its upstream received. That is, the downstream /must/ be free to be able to distribute the changes onward. And that includes back to the original source!

I.e. the original upstream can *also* be a further-downstream - the benefits of Free Software are intended to extend to the original developer, as much as to any other users. It's a two-way street (but the parasites want to skew that street to themselves). So you are just wrong that the upstream-and-downstream has no obligation to its upstream, for the whole idea of copyleft is that a downstream of that upstream-and-downstream ought to be able to supply the changes back to the original upstream, and hence make the original upstream a downstream of the upstream-and-downstream as well as an upstream.

Copyleft intended to guarantee that freedom for the "downstream", by imposing obligations on the "upstream-and-downstream" intermediary - which reduce the freedom of that "upstream-and-downstream" inter-mediary.

That some think they have a found a way to prevent their downstreams from exercising the rights that the original upstream - the copyright holder - wanted all downstreams to be able to exercise, is a problem that I would like to see fixed.

The BSD isn't useful here to the original upstream. The BSD licence has its uses, but this scenario isn't one of them.

Changing CentOS in mid-stream

Posted Dec 16, 2020 17:30 UTC (Wed) by pizza (subscriber, #46) [Link] (5 responses)

> the whole idea of copyleft is that a downstream of that upstream-and-downstream ought to be able to supply the changes back to the original upstream

"ought to be able" is not the same as "must"

> That some think they have a found a way to prevent their downstreams from exercising the rights that the original upstream - the copyright holder - wanted all downstreams to be able to exercise, is a problem that I would like to see fixed.

For what it's worth, I agree with you. I just don't think this addressable/fixable from within the scope of a copyright license.

Ultimately this is a question of freedom of association -- "Sure, you're completely free to pass on these modified GPL sources; that's your right. But if you do that, I'll exercise my right to stop doing business with you."

Changing CentOS in mid-stream

Posted Dec 16, 2020 17:41 UTC (Wed) by paulj (subscriber, #341) [Link] (4 responses)

And they can continue to exercise that freedom of association.

They should just not be able to use it to prevent others from exercising their copyleft rights to distribute. And that can be done easily by just making it a general requirement (with reasonable exceptions to address ability to do R&D in private, desert island residents and dissidents) to make source available, so that it ceases to be a tool to control others with.

In this day of a plethora of places that will host Free Software source for free, it's easy to make code available, and it's reasonable to generally require those who modify Free Software to do so.

Changing CentOS in mid-stream

Posted Dec 16, 2020 17:54 UTC (Wed) by pizza (subscriber, #46) [Link] (2 responses)

> They should just not be able to use it to prevent others from exercising their copyleft rights to distribute.

Private contracts are used to place far more onerous conditions on things far more basic and important than copyleft software; what makes software so special here?

For example, as part of my severance package from the last gig, there was an anti-disparagement clause. If I trashed-talked my former employer within a certain period of time, I'd have to return the money they paid me. I was free to say no, and trash my employer all I wanted, but instead I voluntarily entered into a contract that restricted my freedom of speech and used that money to pay off some debts.

Should this "Waiving my rights to X in exchange for certain considerations" sort of contract be made illegal? (if yes, why? If no, how X == free speech materially different from "X == redistribution of copyleft software"?)

Changing CentOS in mid-stream

Posted Dec 17, 2020 12:26 UTC (Thu) by paulj (subscriber, #341) [Link] (1 responses)

Your employment contract doesn't really involve the software of others.

The copyright holder can't stop others exercising their freedom of association either.

The copyright holder can however require that the obligation to distribute modifications to the source be broader, such that others can not wield freedom of association as a weapon to restrict copyleft rights.

And if such parasitic companies don't like that, they're still perfectly free to not use that software. The authors are free to choose their licence for their software, and others are free to make their own decisions.

Changing CentOS in mid-stream

Posted Dec 17, 2020 13:20 UTC (Thu) by pizza (subscriber, #46) [Link]

> Your employment contract doesn't really involve the software of others.

Oh, yes it does; if I make use of or incorporate certain software in my last two jobs, I can be terminated on the spot.

> The copyright holder can't stop others exercising their freedom of association either.

Their attempts to create "ethical licenses" certainly do; under "field of use restrictions"

> The copyright holder can however require that the obligation to distribute modifications to the source be broader, such that others can not wield freedom of association as a weapon to restrict copyleft rights.

The actual "software" has no rights or permissions -- only "persons" do. I (or my employer), as a "person", have the permission granted by the software's author (ie the license) to redistribute that copyleft software. I can chose not to do so for any reason -- Because I don't like you. Because it's Tuesday. Because I promised my mother that I wouldn't. Because I signed a contract with my employer/supplier/whatever to not do so. And so forth.

What you are asking is for the license to unconditionally force/compel folks to redistribute the software to unrelated third parties. There are significant practical and legal problems with that. I'm not saying it's impossible, just that it's going to take a lot of care to draft, and the resulting license will probably see even less use than the AGPL -- Which is already considered so toxic that it's only significant use is as a deliberate poison pill.

Changing CentOS in mid-stream

Posted Dec 16, 2020 20:24 UTC (Wed) by Wol (subscriber, #4433) [Link]

> And they can continue to exercise that freedom of association.

And you are showing your inability to follow a logical argument. If I rely on that company's software (never mind that some of it is your GPL software), I cannot afford for *them* to follow *their* right to freedom of association, and refuse to associate with me.

I have entered into a - supposedly mutual - beneficial arrangement with them, and neither of us wishes to jeopardise it. You are an outsider to that agreements, and by agreeing to the GPL you surrendered any rights you may have had. If you don't like it, it's your right to refuse to associate with the GPL.

It is a fundamental requirement of the free market, that people are not coerced into doing business with people they would rather avoid. This is what's wrong with modern "free market" capitalism, where the big players are free to buy, force out of business, or otherwise destroy their smaller competitors and force customers to do business with them. In this particular case, unfortunately that company does not want to do business with you, and their customers do not want to antagonise them.

YOU SAID the GPL requires you to pass on all the rights you received. But you are objecting to this company exercising those self-same rights that you received and passed on.

Cheers,
Wol

Changing CentOS in mid-stream

Posted Dec 16, 2020 19:21 UTC (Wed) by Wol (subscriber, #4433) [Link]

> The intent of the GPL is to ensure the downstream has all the rights its upstream received. That is, the downstream /must/ be free to be able to distribute the changes onward. And that includes back to the original source!

And that includes the freedom NOT to distribute changes back to the original source.

You're arguing with your heart, not your head. And that way leads to disaster ... "The road to hell is paved with good intentions". You've already assumed (from no evidence whatsoever) that I am opposed to what you want. I'm not. Just like many other people here, my head tells me you can't have it. Doesn't mean I don't wish we could :-)

"Man proposes. Nature opposes". What you want is not achievable. Not without tying logic up in a granny knot and bashing it over the head with a rolling pin.

Cheers,
Wol

Changing CentOS in mid-stream

Posted Dec 16, 2020 16:27 UTC (Wed) by Wol (subscriber, #4433) [Link] (1 responses)

> These users are already outside of the spirit of the GPL, as far as I'm concerned. They are taking freedoms away from others. I have no time or sympathy for them. I will be glad to see that loophole closed off in future copyleft licences.

So you want to discriminate between users - which is FORBIDDEN by the *concept* of copyleft. You won't - can't - find a copyleft licence that agrees with you. (Oh - and as I pointed out - the GPLv3 not only did not attempt to close that loophole, it quite deliberately opened it even wider!)

And those same users you have no sympathy for includes a LOT of hardware vendors - if you hadn't noticed, a lot of kernel developers feel similarly to you. The *problem* is that, as soon as you have the sort of licence *you* desire, the practical consequence will be that linux is sidelined and becomes completely irrelevant.

Sadly, sometimes practicality has to trump idealism, or the idealists will become irrelevant sighing winds in the desert :-(

Cheers,
Wol

Changing CentOS in mid-stream

Posted Dec 16, 2020 16:53 UTC (Wed) by paulj (subscriber, #341) [Link]

Yes, I want to discriminate between users who'd like to make changes, distribute those to customers and deny them to the rest of the community - for their competitive advantage. Which is a type of discrimination the GPL /already/ has!

Some users think they've found a loophole, that is against the spirit of the GPL and copyleft. (And I completely disagree with you that the spirit of copyleft /intentionally/ allows for corporates to restrict re-distribution of modifications by their downstreams - that's absurd, the entire point of copyleft is to ensure the recipients get the right to distribute!).

I don't get your point about hardware vendors. If you mean the likes of graphics vendors with closed blobs, they may well be in direct violation of the GPL already - that's not the case I'm talking about.

I sense I'm down a rabbit hole with you.

Changing CentOS in mid-stream

Posted Dec 16, 2020 13:04 UTC (Wed) by mpr22 (subscriber, #60784) [Link] (1 responses)

What about parasitic natural persons?

Changing CentOS in mid-stream

Posted Dec 16, 2020 13:23 UTC (Wed) by paulj (subscriber, #341) [Link]

Less concerned about those. The scope of what 1 natural person can do is limited, compared to corporations.

So I'd be happy to exempt natural persons from some obligations designed to tackle an issue that manifests itself mostly with corporations. If a reasonable balance of obligations and wording can be found that doesn't need to distinguish between natural persons and other bodies, that's fine too.

Changing CentOS in mid-stream

Posted Dec 16, 2020 1:08 UTC (Wed) by pabs (subscriber, #43278) [Link] (3 responses)

Banning private source distribution would fail Debian's dissident and desert island tests. It would discriminate against dissidents collaborating amongst themselves under a totalitarian regime. It would discriminate against people living on a desert island collaborating amongst themselves with no access to the wider Internet. As the Internet fragments into national networks, it might even become impossible to comply with in the future.

Mandatory upstream distribution and its problems

Posted Dec 16, 2020 1:31 UTC (Wed) by bkuhn (subscriber, #58642) [Link]

The issue of mandatory upstream distribution of source changes to copylefted software has been a hotly debated topic since I first got involved in copyleft licensing policy and drafting in the late 1990s. The two primary positions within this debate have been outlined well already in this thread.

I think most copyleft theorists believe that modifiers (modulo the danger situations with dissidents that pabs identified) have a moral obligation to make generally useful improvements available to the general public. The problem, and this goes back to the points pabs raised, is how to draft policy that respects the privacy rights of some types of modifications while assuring that truly generally useful changes that the world deserves, morally speaking, can be codified into a copyleft license.

Much of this debate reminds me more recently of the so-called “Ethical License” initiatives. In those initiatives, its proponents argue that since there are immoral things done by companies with software (such as helping USA's ICE lock children up in cages) that the licenses are not ethical if they don't prevent that.

The flaw in the logic is the idea that every moral and social problem that relates to software can be fixed with its license. Having spent years enforcing copyleft licenses and drafting them, I've concluded that you have to be selective how you use the tool of copyleft. And, it's not that I'm just critical of new ideas: I'd argue that GPLv2§2(a) is a great example of a well-intentioned clause meaning to get to a good policy outcome that is just annoying to comply with in practice. We should all comply with it because it's required, but I would never include that clause or one like it again in a future copyleft license.

Similarly, when I hear people clamoring for features for copyleft licenses, I worry about future-proofing. It's hard to do. Anyway, I encourage anyone who wants to talk about real-world drafting of copyleft to join the copyleft-next project.

Changing CentOS in mid-stream

Posted Dec 16, 2020 10:38 UTC (Wed) by paulj (subscriber, #341) [Link] (1 responses)

I think you could ban private discharge, while protecting the dissident, and avoiding criminalising Robinson Crusoe.

The obligation to distribute generally could be to the greatest extent reasonable, subject to any external restrictions on distribution. So the desert island denizen, as long as they make available to anyone else on the island, would be fine.

The dissident can be protected by exempting any person (not corporation) from the obligation, where doing so would put lives at risk of oppression.

Changing CentOS in mid-stream

Posted Dec 16, 2020 13:05 UTC (Wed) by mpr22 (subscriber, #60784) [Link]

In legal speak, the term you probably want is "natural person". The unqualified term "person" includes companies of all kinds.

Changing CentOS in mid-stream

Posted Dec 16, 2020 0:20 UTC (Wed) by Wol (subscriber, #4433) [Link] (4 responses)

> If that copy is not provided when customers receive the binary it is *then* that the "random 3rd party" rule kicks in

Actually, version 3 of the GPL makes this intent even clearer - the wording of v2 effectively made the vendor *force* the source onto the user. Under v3, if the vendor merely makes the source *available* (by, for example, providing a download link) it stops the "random 3rd party" rule from kicking in.

In other words, if I point my users at a *private* *intranet* site, so long as they have access to said private site at the time I supply the binaries, then I can pull that source download site AT ANY TIME.

Cheers,
Wol

Changing CentOS in mid-stream

Posted Dec 25, 2020 19:12 UTC (Fri) by sammythesnake (guest, #17693) [Link] (3 responses)

The GPL v3 requires "a written offer, valid for at least three years..." (section 6b) to provide the source, so they can't shut down the server within at least that period unless they want to offer CDs or the like as an alternative

Three years might be an interminable age or a blink of the eye depending on the circumstances, though.

Changing CentOS in mid-stream

Posted Dec 25, 2020 20:01 UTC (Fri) by sfeam (subscriber, #2841) [Link]

Yet another example of how GPL3 is unusable in practice. Talks about overreaching!

Changing CentOS in mid-stream

Posted Dec 27, 2020 1:13 UTC (Sun) by Wol (subscriber, #4433) [Link] (1 responses)

Just a quick response, I haven't checked, but I'm pretty damn certain that 6(b) is an ALTERNATIVE clause. If you comply with 6(a) (or 6(c), (d) etc if they exist), then there is NO requirement to comply with 6(b).

In other words, you must comply with clause 6, but you can choose between (a) or (b) (or (c) or (d) or whatever).

Cheers,
Wol

Changing CentOS in mid-stream

Posted Dec 27, 2020 1:16 UTC (Sun) by Wol (subscriber, #4433) [Link]

Just checked, I AM right.

Comply with (a) OR (b) OR (c) OR (d) OR (e).

Your choice - if you want to ignore 6(b) that's perfectly fine so long as you comply with one of the others.

Sheesh - talk about people not being able to understand plain simple English ... (or American :-)

Cheers,
Wol

Changing CentOS in mid-stream

Posted Dec 15, 2020 20:48 UTC (Tue) by joib (subscriber, #8541) [Link]

> Exploitation of free software developers is something the GPL unfortunately allows.

> There are many companies at this, by various means. Some directly exploitative, taking free software of others and selling it with improvements they do not release back (or release only with great delay), and/or even with portions they will never release the code for. Others indirectly exploitative, by taking free software of others and profiting from it but - as you point at - largely not contributing back with support (employment, say) for those who supplied them with the software.

There are, of course, licenses which provide monetary compensation to the developers, but those are called proprietary, not open source. The universe is, for better or worse, under no obligation to give money to you or me as a reward for writing free software.

> I think we need next-generation copyleft licences, to address this. Licenses that give users their freedom, but that also empower the actual authors of Free Software and shield the authors better from the parasitical tendencies of corporations - which the current GPL allows.

In a way, I completely agree with that. GPLv3 is in many ways fine, but doesn't go nearly far enough to protect e.g. against service providers. But it also seems to me a quixotic quest. GPLv3, modest improvement to GPLv2 as it was, already caused a schism in the GPL-using community, many of which explicitly chose to stay with GPLv2-only. Not to mention AGPL, which is regarded as outright poison by many. And a hypothetical GPLv4 which would close the "service provide loophole", would probably look like an even stronger version of AGPLv3. I think very few would jump on that train.

The other approach is maybe to take a step back and think about what we're actually trying to achieve, and whether there are other more fruitful avenues to get what we want. If we want devices that we own, and can tinker with, maybe pushing for Right to Repair type legislation, including the ability to boot our own code instead of the manufacturer signed one? And push for open specified protocols, so we can replace the original manufacturer black box software with our own?

But those are more legal or political changes. Getting out in the street protesting, lobbying etc. is certainly uncomfortable, but OTOH maybe the alternative idea of enacting social change by coding away in our basements was always an impossible dream anyway.

Changing CentOS in mid-stream

Posted Dec 14, 2020 7:45 UTC (Mon) by nknight (subscriber, #71864) [Link] (9 responses)

Red Hat just crapped all over the community for the third time in its history, and this time hurt paying customers who relied on their explicit promises *to us personally*. How long do you really think it will be before we pull a MariaDB and not just rebuild but outright fork and take the community with us?

Good news for Red Hat is they can just shut down CentOS outright in five years. Nobody will care anymore.

Changing CentOS in mid-stream

Posted Dec 14, 2020 12:42 UTC (Mon) by pizza (subscriber, #46) [Link] (8 responses)

> Red Hat just crapped all over the community for the third time in its history, and this time hurt paying customers who relied on their explicit promises *to us personally*.

You keep repeating this, but that doesn't make it true.

Again, what promise has Red Hat broken *to its paying customers*? And how exactly did they "personally" break them?

(Because "Broken promises" to "paying customers" is also known as a "breach of contract" which is legally actionable)

> How long do you really think it will be before we pull a MariaDB and not just rebuild but outright fork and take the community with us?

MariaDB was a *developer* revolt; in other words, those who were doing most of the work left, and continued doing the work under a new umbrella. The general userbase followed because Oracle (yes, that same Oracle that is being held up as the Savior of CentOS users) largely let MySQL wither on the vine.

Meanwhile, you want to Fork CentOS? That's easy! Just figure out a source of sustained funding to pay a bunch of full-time engineers to maintain and develop things that no volunteer would ever choose to do on their own (plus pay for obscene amounts of bandwidth) and convince the general userbase that being incompatible with RHEL is okay.

Changing CentOS in mid-stream

Posted Dec 14, 2020 23:57 UTC (Mon) by nknight (subscriber, #71864) [Link] (7 responses)

Red Hat’s sales drones have been pointing customers concerned about costs of full RHEL deployments to CentOS for many years, even long before Red Hat “acquired” CentOS. They wouldn’t even consider negotiating with us on RHEL costs.

Fool me thrice...

Changing CentOS in mid-stream

Posted Dec 15, 2020 2:38 UTC (Tue) by pizza (subscriber, #46) [Link] (6 responses)

So... RH salescritters were trying to help out their customers by suggesting ways to save money. Fairly standard stuff.

But you still haven't provided an example of one of a "broken promise" Red Hat that made made "personally" and "explicitly" to one of their paying customers.

Changing CentOS in mid-stream

Posted Dec 15, 2020 7:54 UTC (Tue) by nknight (subscriber, #71864) [Link] (5 responses)

Direct quote from sales drone: "We maintain it for ten years."

Changing CentOS in mid-stream

Posted Dec 15, 2020 14:14 UTC (Tue) by pizza (subscriber, #46) [Link] (4 responses)

So, what does your RH Sales rep tell you now?

(...Or have you not actually asked?)

Changing CentOS in mid-stream

Posted Dec 15, 2020 23:56 UTC (Tue) by nknight (subscriber, #71864) [Link] (3 responses)

Points me at options for paying Red Hat more money and evades direct questions. Are you really surprised?

Changing CentOS in mid-stream

Posted Dec 16, 2020 0:17 UTC (Wed) by pizza (subscriber, #46) [Link] (2 responses)

> Points me at options for paying Red Hat more money and evades direct questions. Are you really surprised?

Nope. But... that's not a broken promise. That's not having any good answers.

Changing CentOS in mid-stream

Posted Dec 16, 2020 1:12 UTC (Wed) by nknight (subscriber, #71864) [Link]

You may not hold people to their words, I, however, do. Trust is vital to society's functioning, and not holding economic actors to their word leads to a breakdown of trust.

Changing CentOS in mid-stream

Posted Dec 16, 2020 1:15 UTC (Wed) by nknight (subscriber, #71864) [Link]

I have been assuming you've already read this, since literally everyone else has since this news broke, but if you really don't understand where we're coming from, look at this blog post:

https://blog.centos.org/2019/07/ibm-red-hat-and-centos/

"Our mission, governance, and objectives remain the same. We will continue to execute the existing project roadmap. Red Hat associates will continue to contribute to the upstream in the same ways they have been. And, as always, we will continue to help upstream projects be successful and contribute to welcoming new members and maintaining the project.

We will do this together, with the community, as we always have."

Changing CentOS in mid-stream

Posted Dec 13, 2020 18:31 UTC (Sun) by LightDot (guest, #73140) [Link] (2 responses)

> The CentOS Board was free to tell Red Hat to go pound sand.

To what effect?

Red Hat controls CentOS entirely, doesn't it? Including the copyright over the CentOS name. All they could have done is resign and walk away, without changing anything as a consequence.

Basically Red Hat actually pulled the embrace extend extinguish maneuver here, although I'm 110% certain that it was never the intention and it actually pains me to see this phrase mentioned in connection with Red Hat.

I've been looking at the various online comments, from those very moderate to those over the top, and summarizing that, and my personal concerns, I'd say that the majority of the damage is caused by drastically changing the CentOS 8 as-we-know-it EOL, after the wide spread adoption, combined with the CentOS Stream 8 shortened lifespan.

Changing CentOS in mid-stream

Posted Dec 16, 2020 5:44 UTC (Wed) by pizza (subscriber, #46) [Link] (1 responses)

> Basically Red Hat actually pulled the embrace extend extinguish maneuver here, although I'm 110% certain that it was never the intention and it actually pains me to see this phrase mentioned in connection with Red Hat.

It does look that way, but.. I think it's actually more nuanced than that. If you go back to the original "Red Hat is acqu-hiring CentOS" announcements and press releases from early 2014, they laid out a long-term vision that looks pretty darn close to the new/currentFedora -> ELN -> CentOS Stream -> RHEL tiered development model that Red Hat has embraced.

It is not debatable that CentOS was in bad shape prior to Red Hat (effectively) taking it over. While it's highly likely that if not Red Hat, someone else would have come along, it's not debatable that CentOS was not sustainable in its former form, and it's also not disputable that under Red Hat's "ownership" CentOS has flourished, and with everyone -- including RHEL, CentOS, all the other "RHEL clones" and their end-users -- heavily benefiting. RHEL has gone from being developed entirely behind closed doors to fully in the open, with open tooling that any sufficiently motivated third party can deploy to generate their own rebuilds. This represents a huge leap beyond what RHEL and CentOS were using previously. External entities/communities can actually meaningfully participate in development of new features instead of simply accepting/rebuilding whatever Red Hat threw over the wall every six months. Indeed, if folks are so inclined, they can actually ship stuff before it ends up in a Red Hat release! Sure, Red Hat dominates the new process just as they were before, but they were (and still are) doing the vast majority of the actual engineering and QA work; of course they're going to put that into what they consider to be most relevant for their overall business needs.

It took an entire RHEL release cycle to implement that original vision and build the open tooling to support it. RHEL/CentOS8 is the result, and they're now moving to the next phase of what they said they were intending to do nearly seven years ago. So sure, the Embrace and Extend bits are there, but have they actually Extinguished anything?

Sure, the discontinuing of the classic CentOS model is disappointing -- but nothing lasts forever. I think the real question is: Are folks are better off now than they were in 2014? It's hard to argue that they are not; at worst it's about the same,with folks wanting a "Free RHEL rebuild" having to step up and volunteer their time/money to make it happen in a sustainable manner, something that they were failing to do in the pre-RH CentOS days. But, thanks to all of the tooling and process improvements that Red Hat paid for, the amount of sheer thankless drudgery that is needed to produce a modern RHEL-clone/rebuild (eg Oracle Linux, ClearLinux, and RockyLinux, and whatever else comes along) has been vastly reduced.

But all that said, all of those rebuilders will still be following Red Hat's coat tails, because at the end of the day, Red Hat continues to invest more into RHEL (and by proxy, all of its clones) than everyone else combined, probably by a factor of 2-3x. This is why I feel that ClearLinux (or whatever) isn't going to make RHEL irrelevant -- RH is only in its dominant position because it invests so much (into all of the various ecosystems' upstreams, not just RHEL itself) -- In other words, it's not because of any inherent superiority of RH or RHEL, but because RH is undertaking (and/or underwriting) such a large proportion of the overall effort.

In order for someone else to rise to that level of prominence, they have to out-invest Red Hat. Which requires a pretty large chunk of sustained funding, to the tune of literally hundreds of millions of dollars a year. I laud ClearLinux for their $1M pledge, but it is simply delusional to think that level of investment will somehow render RHEL (and by proxy, RH) "irrelevant".

> I'd say that the majority of the damage is caused by drastically changing the CentOS 8 as-we-know-it EOL.

Yeah, I agree. If the shortened CentOS-as-we-know-it EOL was actually the intent all along (and to be honest, it does seem that way based on the historical record) then this is really a textbook case of one hand not knowing what the other hand was intending.

Changing CentOS in mid-stream

Posted Dec 16, 2020 11:20 UTC (Wed) by amacater (subscriber, #790) [Link]

In terms of rebuilders and folk building on Red Hat's labour: Where does Amazon Linux fit into this? From memory and their web pages, it's designed to be binary compatible with Red Hat Enterprise Linux and CentOS as far as possible. Again, I believe that Amazon put large effort into Xen a while ago, so their kernels may be Xen optimised and patched accordingly.

Colleagues suggested - "well, we can just move to Amazon Linux - it's free" but https://aws.amazon.com/amazon-linux-2/faqs/ suggests that the only Linux currently is in the form of virtual machines if you want to run Amazon Linux on premises and there is no support. Out of the frying pan into the fire.

The new AWS Graviton 64 bit ARM instances are probably not running CentOS. Is there anybody with an authoritative viewpoint on this?

We already know from comments further up the stack that FB are apparently using CentOS Streams. Enquiring minds would like to know.


Copyright © 2025, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds