|
|
Subscribe / Log in / New account

White paper: Vendor Kernels, Bugs and Stability

White paper: Vendor Kernels, Bugs and Stability

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

To clarify further, this comment from that previous story lays it out precisely:

https://lwn.net/Articles/430192/

"- The kernel tarball inside the srpm is created from a git tree that is only accessible to Red Hat engineers.

- The orders to do this, to make it harder to rebuild the kernel with and without patches, and to make it harder to extract specific patches from the Red Hat kernel came from the top. This is with the knowledge of, and by the order of, the CEO: Jim Whitehurst."


to post comments

White paper: Vendor Kernels, Bugs and Stability

Posted May 17, 2024 21:15 UTC (Fri) by Cyberax (✭ supporter ✭, #52523) [Link] (15 responses)

> "- The kernel tarball inside the srpm is created from a git tree that is only accessible to Red Hat engineers.

By the same token, Bash is not free software. Its releases are made as giant git commit dumps: https://git.savannah.gnu.org/cgit/bash.git/commit/?id=886...

White paper: Vendor Kernels, Bugs and Stability

Posted May 18, 2024 21:27 UTC (Sat) by rschroev (subscriber, #4164) [Link] (13 responses)

But AFAICS the complete Bash tree is publicly available on Savannah, in conflict with the Red Hat kernel case where the full git tree is only available to Red Hat engineers.

White paper: Vendor Kernels, Bugs and Stability

Posted May 18, 2024 23:06 UTC (Sat) by Cyberax (✭ supporter ✭, #52523) [Link] (12 responses)

> But AFAICS the complete Bash tree is publicly available on Savannah

Yes, and that tree (I linked to it) only has giant dumps. Just like RedHat.

White paper: Vendor Kernels, Bugs and Stability

Posted May 18, 2024 23:23 UTC (Sat) by mb (subscriber, #50428) [Link] (11 responses)

> Just like RedHat.

No.
RedHat is not the author of the majority of the code.

The authors can do whatever they like to their code.
Downstream distributors can't.

White paper: Vendor Kernels, Bugs and Stability

Posted May 18, 2024 23:25 UTC (Sat) by Cyberax (✭ supporter ✭, #52523) [Link] (10 responses)

The maintainers of Bash don't have exclusive copyright to it, they still need to obey the GPL.

If giant tree dumps are not the preferred form, then Bash is arguably violating the GPL.

White paper: Vendor Kernels, Bugs and Stability

Posted May 18, 2024 23:35 UTC (Sat) by mb (subscriber, #50428) [Link] (9 responses)

>The maintainers of Bash don't have exclusive copyright to it

I think they pretty much do, due to FSF Copyright assignment rules.

White paper: Vendor Kernels, Bugs and Stability

Posted May 18, 2024 23:53 UTC (Sat) by Cyberax (✭ supporter ✭, #52523) [Link] (7 responses)

So... FSF is still violating its own license?

White paper: Vendor Kernels, Bugs and Stability

Posted May 20, 2024 8:58 UTC (Mon) by paulj (subscriber, #341) [Link] (6 responses)

The licensor is not bound by a licence that places obligations only on licensees.

White paper: Vendor Kernels, Bugs and Stability

Posted May 20, 2024 9:34 UTC (Mon) by Wol (subscriber, #4433) [Link] (5 responses)

It's called "hypocrisy".

You know, that thing that totally destroys the credibility of our "moral guardians".

Cheers,
Wol

White paper: Vendor Kernels, Bugs and Stability

Posted May 20, 2024 10:51 UTC (Mon) by paulj (subscriber, #341) [Link] (4 responses)

It is also quite possible that the "preferred form for modification" differs across different contexts. For one set of licensors and licensees it may be one form, for another set another.

White paper: Vendor Kernels, Bugs and Stability

Posted May 20, 2024 12:38 UTC (Mon) by pbonzini (subscriber, #60935) [Link] (3 responses)

Even in the one case that is precisely defined in the license itself?

White paper: Vendor Kernels, Bugs and Stability

Posted May 20, 2024 12:46 UTC (Mon) by paulj (subscriber, #341) [Link] (2 responses)

What do you mean exactly?

If you mean "For an executable work, complete source code means ..." - that's defining the complete source code, but not the preferred form for modifications.

You can have the complete source code, but not have it in the preferred form for modification.

White paper: Vendor Kernels, Bugs and Stability

Posted May 20, 2024 13:54 UTC (Mon) by smurf (subscriber, #17840) [Link] (1 responses)

The "preferred form of modification" was, and is, a text file. Or a directory tree with a large heap of 'em.

True, the preferred form of keeping track of your modifications, distributing them, etc.etc.etc., once was patches and tar files; now it's git and pulling commits. The problem is that the GPL doesn't talk about any of that. It merely requires "a" medium commonly used for software exchange. Not "the medium everybody else who's contributing to this particular piece of source code is using".

So for better or worse, you can appeal to common sense and interoperability and the equivalent of sportsmanship and whatnot and I'll be the first person to be argue right along with you. But the GPL? sorry you pour cold water on your fire but you can't use it to demand git trees from anybody.

Disclaimer: IMHO and IANAL and all that.

White paper: Vendor Kernels, Bugs and Stability

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

You can say what you want, but the GPL deliberately does not define what "preferred form" means. And the "For an executable work, ..." part doesn't change that, because it it self refers to "source code" - it clarifies that the executable work includes the "source code" for X, Y and Z. And "source code" means "the preferred form for modifications".

You may indeed argue that the preferred form is a text file.

However, if you are a company that has deliberately stripped away context that you yourself use for hosting and modifying said source code as part of your commercial operation, and you have made that deliberate act in order to frustrate others who also wish to modify said source code, then I - if it mattered to me and I were a copyright holder - could well argue to a court that the form you have provided is clearly not the form you prefer to use yourself for making modifications, and that you have therefore violated the licence I gave you.

E.g., I - as your upstream - could well be trying to follow along with what you're doing to my code, so that I can cherry-pick the good bits to integrate back into the code. Your deliberate obfuscation, done to keep for yourself the preferred form of modifications and hence frustrate others from picking out what you changed, I would argue as being clearly against the wording of the licence.

The form you prefer to use internally, versus the form you chose to release, would be prima facie evidence of your failure to honour the licence.

Who would win, who knows. But I don't think your position would be 100% safe.

White paper: Vendor Kernels, Bugs and Stability

Posted May 19, 2024 0:01 UTC (Sun) by bluca (subscriber, #118303) [Link]

I don't think bash does copyright assignments, I've sent patches in the past and they were merged, and I do not remember signing anything

White paper: Vendor Kernels, Bugs and Stability

Posted May 19, 2024 7:27 UTC (Sun) by gioele (subscriber, #61675) [Link]

> By the same token, Bash is not free software. Its releases are made as giant git commit dumps: https://git.savannah.gnu.org/cgit/bash.git/commit/?id=886...

Bash's repository has two main branches:

* `master` (<https://git.savannah.gnu.org/cgit/bash.git/log/>), that follows the historical 1-mega-patch-per-release paradigm, and
* `devel` (<https://git.savannah.gnu.org/cgit/bash.git/log/?h=devel>), where development is carried out using more modern piece-wise commits.


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