Changing CentOS in mid-stream

Posted Dec 18, 2020 11:28 UTC (Fri) by paulj (subscriber, #341)
In reply to: Changing CentOS in mid-stream by paulj
Parent article: Changing CentOS in mid-stream

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.