White paper: Vendor Kernels, Bugs and Stability

Posted May 17, 2024 21:44 UTC (Fri) by jra (subscriber, #55261)
In reply to: White paper: Vendor Kernels, Bugs and Stability by pbonzini
Parent article: White paper: Vendor Kernels, Bugs and Stability

Whether this is GPL compatible is subject to serious debate. Here for example:

https://sfconservancy.org/blog/2023/jun/23/rhel-gpl-analy...

People of good conscience (and I certainly include you in this) can have different opinions on this matter.

White paper: Vendor Kernels, Bugs and Stability

Posted May 17, 2024 21:54 UTC (Fri) by pbonzini (subscriber, #60935) [Link] (5 responses)

The Conservancy blog post is about the RHEL business model, and not at all about whether the kernel patches are split or not. As should be obvious from it not containing any of the words "commit", "split", "patch", "kernel", "2011", "tree", "git".

Also, the Conservancy blog post does not really debate the fact that the RHEL business model complies with the GPL. Rather, it complains about the difficulty of *verifying* from the outside that Red Hat does indeed comply in practice and not only on paper. I think it's a reasonable complaint, especially from the point of view of an entity like Conservancy—and considering that the nuances of free software licensing are not obvious to all of the employees on Red Hat, on neither the engineering side nor the sales side.

That said, it's also not a standard to which many companies are held, and perhaps that's a point of honor for Red Hat. :)

White paper: Vendor Kernels, Bugs and Stability

Posted May 17, 2024 22:16 UTC (Fri) by jra (subscriber, #55261) [Link] (4 responses)

> That said, it's also not a standard to which many companies are held, and perhaps that's a point of honor for Red Hat. :)

That's a really good point, and one to which I wholeheartedly agree. I *do* expect better of Red Hat. As I have often said, I have many Red Hat engineering friends and a great respect for the engineering talent and prowess of Red Hat.

It disappoints me greatly to see Red Hat moving away from the ethos of improving the availability of Free Software, hiding git trees from other engineers, and generally seeming to move away from open collaboration.

Still, I believed in Google Open Source too, and look where that got me :-) :-).

White paper: Vendor Kernels, Bugs and Stability

Posted May 18, 2024 0:43 UTC (Sat) by Wol (subscriber, #4433) [Link] (3 responses)

Thing is, if you look at WHY Red Hat did it, it was in direct response to an attack on their financial stability. It's all very well saying they should abide by a higher standard, but if that puts them on a suicide course, what on earth do you expect them to do?

Cheers,
Wol

White paper: Vendor Kernels, Bugs and Stability

Posted May 18, 2024 4:51 UTC (Sat) by jra (subscriber, #55261) [Link] (1 responses)

Well they did it because of Oracle. Do you think ruining their source releases in that way really had much impact on what Oracle did or how successful Oracle was with Oracle Linux ? Personally I don't. It did, however, break their reputation with the Open Source community in other ways.

Reacting due to fear often leads to the wrong response.

White paper: Vendor Kernels, Bugs and Stability

Posted May 18, 2024 8:53 UTC (Sat) by Wol (subscriber, #4433) [Link]

> Reacting due to fear often leads to the wrong response.

And investigating before reacting (I don't know whether RH did, but they took their time reacting) often leads to surprising conclusions and actions.

(I'm currently working as a business analyst. It's my job to react to events like this. And I'm expected to have a good justification for my reactions.)

People often confuse cause and effect. Or blame something totally irrelevant. If RH determined that Oracle's actions were causing serious damage to their bottom line, then they had to do something about it - regardless of the cost. If you really are facing an existential threat, you're not going to care about your reputation.

(And as others have said, I totally agree that it's nice that RH are held to a higher standard than others, but I also think that's unfair! :-)

Cheers,
Wol

White paper: Vendor Kernels, Bugs and Stability

Posted May 20, 2024 9:00 UTC (Mon) by paulj (subscriber, #341) [Link]

One may have sympathy for RedHat in that, however that still does not give them permission to deliberately withhold the source code in the form they prefer for modifications.

White paper: Vendor Kernels, Bugs and Stability

Posted May 17, 2024 22:00 UTC (Fri) by Wol (subscriber, #4433) [Link] (6 responses)

Given that there is no guarantee that stuff even USES some sort of version control, by demanding a full version control you are placing obligations on people releasing free software.

Given that "dumping the source over the wall" is perfectly okay for projects without source control, except not popular with recipients, you are now getting into the legally extremely hairy situation where what is perfectly okay for one project, but allegedly illegal for another ...

Do we really want to go down that rabbit hole?

Cheers,
Wol

White paper: Vendor Kernels, Bugs and Stability

Posted May 17, 2024 22:20 UTC (Fri) by jra (subscriber, #55261) [Link] (4 responses)

Times change. And the meaning of "complete and corresponding source code in the preferred form of the work" has changed with it.

I remember the days of throwing tarballs on an ftp site (and indeed did so myself :-). But these days that really isn't how collaboration is done.

Git is king, for better or worse (better, IMHO). A git tree really is the preferred form of the work these days (or insert distributed source code control system of your choice for more obscure projects).

White paper: Vendor Kernels, Bugs and Stability

Posted May 17, 2024 22:32 UTC (Fri) by pbonzini (subscriber, #60935) [Link] (1 responses)

But the license says "preferred form for modification". The line is very clearly placed by the license which even has an example for executables. That example does not cover understanding past development, collaborating on further development, or receiving continued support.

If the meaning has changed, then no one is distributing GPLd software commercially and complying with the supposed new meaning. Which to me is a pretty good sign that the meaning has not changed, and that's for good reasons.

White paper: Vendor Kernels, Bugs and Stability

Posted May 18, 2024 9:31 UTC (Sat) by smurf (subscriber, #17840) [Link]

Problem is, "source code" is a bunch of files. The preferred form of modification is still those files which one edits/compiles/debugs, git or no git.

Yes, you cannot use the kernel source in any meaningful way without git these days. Unfortunately, that's not covered by the GPLv2, just like Tivofication isn't (and that one is a far worse problem). You need the GPLv3 for that – which the kernel cannot and will not transition to.

Thus while yes there's a moral / good practices / be-nice-to-the-community obligation to provide the git archive, legally? almost certainly not.

White paper: Vendor Kernels, Bugs and Stability

Posted May 19, 2024 16:46 UTC (Sun) by Wol (subscriber, #4433) [Link]

> Times change. And the meaning of "complete and corresponding source code in the preferred form of the work" has changed with it.

Why?

> I remember the days of throwing tarballs on an ftp site (and indeed did so myself :-). But these days that really isn't how collaboration is done.

And this is called pushing your views down other peoples throats. (Personally, I think even doing "on your own" development benefits from version control, BUT IT'S NOT MY PLACE TO TELL OTHER PEOPLE WHAT TO DO!)

What's that advice I've come across before? "You think you're a sensible, rational human being. When you disagree with someone, you should assume they are sensible and rational too. So any disagreement must be down to you having a different set of facts from them. At which point, how do you know it's not YOU who've got the facts wrong."

Face it, even today there are people who don't/won't use version control. Even today there are people (especially sole copyright holders) who will throw a tarball over the fence and say "This will compile and work, I'm done". If that was acceptable in the past, it has still to be acceptable today. And if it's acceptable today, why is it acceptable for some and not others?

You can say it's not being a good citizen, not being fair (I don't know if I'd agree with you), but if it's in reaction to someone else playing dirty and not being a good citizen, then I'd much rather you went after the *real* culprit, the cuckoo in the nest, not the victim trying to make the best of a bad job. It's called "blame the victim", don't cha know...

>Git is king, for better or worse (better, IMHO). A git tree really is the preferred form of the work these days (or insert distributed source code control system of your choice for more obscure projects).

And for those people who don't use version control (beyond datestamped backups) ???

Cheers,
Wol

White paper: Vendor Kernels, Bugs and Stability

Posted May 21, 2024 9:18 UTC (Tue) by jamesh (guest, #1159) [Link]

You are essentially arguing that it isn't enough to distribute the source code corresponding to the binaries, but that the source code to all previous versions is also required. That seems like it'd be a problem for far more than just RHEL kernel packages. Off the top of my head:

Many pieces of software have changed license at some point in their history. A distro might be happy with the current license but not the old one. Do they need to distribute all the versions released under the bad license now?
A number of packages in Debian modify the upstream source tarballs to remove files with licenses that don't meet their guidelines. If they were required to distribute a git tree with history linking back to upstream, that'd include the problem files.
Some projects have been accused of plagiarism and removed the offending code, but it remains in the version control history.

There are open source licenses that require that you split out patches from the upstream release (e.g. the QPL), but the GPL is not one of them.

White paper: Vendor Kernels, Bugs and Stability

Posted May 20, 2024 9:05 UTC (Mon) by paulj (subscriber, #341) [Link]

That there may exist an upstream GPL project whose upstream releases consist of tarballs with many changes aggregated, does not release RedHat from their obligations to release the code in the form preferred for modification. And if RH internally are tracking GPL source code by distinct changesets against base versions than that is _at least_ RedHat's preferred form for modification, and for RH to deliberately withhold that form because they know /others/ would also prefer the code _in that form_ would then be an *obvious* GPL violation.

Good they made the kernel code available in the preferred form again. It still stinks they ever thought playing those tricks was acceptable.