Changing CentOS in mid-stream

Posted Dec 15, 2020 14:36 UTC (Tue) by paulj (subscriber, #341)
In reply to: Changing CentOS in mid-stream by pizza
Parent article: Changing CentOS in mid-stream

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.