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
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."
Posted May 17, 2024 21:15 UTC (Fri)
by Cyberax (✭ supporter ✭, #52523)
[Link] (15 responses)
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...
Posted May 18, 2024 21:27 UTC (Sat)
by rschroev (subscriber, #4164)
[Link] (13 responses)
Posted May 18, 2024 23:06 UTC (Sat)
by Cyberax (✭ supporter ✭, #52523)
[Link] (12 responses)
Yes, and that tree (I linked to it) only has giant dumps. Just like RedHat.
Posted May 18, 2024 23:23 UTC (Sat)
by mb (subscriber, #50428)
[Link] (11 responses)
No.
The authors can do whatever they like to their code.
Posted May 18, 2024 23:25 UTC (Sat)
by Cyberax (✭ supporter ✭, #52523)
[Link] (10 responses)
If giant tree dumps are not the preferred form, then Bash is arguably violating the GPL.
Posted May 18, 2024 23:35 UTC (Sat)
by mb (subscriber, #50428)
[Link] (9 responses)
I think they pretty much do, due to FSF Copyright assignment rules.
Posted May 18, 2024 23:53 UTC (Sat)
by Cyberax (✭ supporter ✭, #52523)
[Link] (7 responses)
Posted May 20, 2024 8:58 UTC (Mon)
by paulj (subscriber, #341)
[Link] (6 responses)
Posted May 20, 2024 9:34 UTC (Mon)
by Wol (subscriber, #4433)
[Link] (5 responses)
You know, that thing that totally destroys the credibility of our "moral guardians".
Cheers,
Posted May 20, 2024 10:51 UTC (Mon)
by paulj (subscriber, #341)
[Link] (4 responses)
Posted May 20, 2024 12:38 UTC (Mon)
by pbonzini (subscriber, #60935)
[Link] (3 responses)
Posted May 20, 2024 12:46 UTC (Mon)
by paulj (subscriber, #341)
[Link] (2 responses)
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.
Posted May 20, 2024 13:54 UTC (Mon)
by smurf (subscriber, #17840)
[Link] (1 responses)
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.
Posted May 20, 2024 14:36 UTC (Mon)
by paulj (subscriber, #341)
[Link]
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.
Posted May 19, 2024 0:01 UTC (Sun)
by bluca (subscriber, #118303)
[Link]
Posted May 19, 2024 7:27 UTC (Sun)
by gioele (subscriber, #61675)
[Link]
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
White paper: Vendor Kernels, Bugs and Stability
White paper: Vendor Kernels, Bugs and Stability
White paper: Vendor Kernels, Bugs and Stability
White paper: Vendor Kernels, Bugs and Stability
RedHat is not the author of the majority of the code.
Downstream distributors can't.
White paper: Vendor Kernels, Bugs and Stability
White paper: Vendor Kernels, Bugs and Stability
White paper: Vendor Kernels, Bugs and Stability
White paper: Vendor Kernels, Bugs and Stability
White paper: Vendor Kernels, Bugs and Stability
Wol
White paper: Vendor Kernels, Bugs and Stability
White paper: Vendor Kernels, Bugs and Stability
White paper: Vendor Kernels, Bugs and Stability
White paper: Vendor Kernels, Bugs and Stability
White paper: Vendor Kernels, Bugs and Stability
White paper: Vendor Kernels, Bugs and Stability
White paper: Vendor Kernels, Bugs and Stability
* `devel` (<https://git.savannah.gnu.org/cgit/bash.git/log/?h=devel>), where development is carried out using more modern piece-wise commits.
