GPLv2§2(a) does not say what you think it says

Posted Nov 5, 2024 21:17 UTC (Tue) by bkuhn (subscriber, #58642)
In reply to: Prominent notices by comex
Parent article: The OpenWrt One system

> I am … trolling

🙄 … Yes, you are. I wrote on this issue extensively 13 years ago:

https://ebb.org/bkuhn/blog/2011/03/11/linux-red-hat-gpl.html

The text of GPLv2 hasn't changed in the meantime — to my knowledge.

to post comments

GPLv2§2(a) does not say what you think it says

Posted Nov 6, 2024 10:33 UTC (Wed) by paulj (subscriber, #341) [Link] (9 responses)

The text of the GPLv2 can stay unchanged, but the practical requirements of meeting it can easily change, given the GPLv2 refers to customary practice wrt software interchange.

The customary practices of the software industry have changed greatly since the GPL was written.

Personally, I'd love to see a court come along and kick the backside of the various people who insist that the GPL distribution requirements are set in stone, and hence a tarball suffice. It's as daft as arguing that because mailing out tape with a tar file was acceptable in the 80s that it's acceptable today.

GPLv2§2(a) does not say what you think it says

Posted Nov 6, 2024 12:34 UTC (Wed) by pizza (subscriber, #46) [Link] (5 responses)

> Personally, I'd love to see a court come along and kick the backside of the various people who insist that the GPL distribution requirements are set in stone, and hence a tarball suffice.

The tarball _is_ the "complete corresponding source code."

The git commit history is _not_.

End of story.

GPLv2§2(a) does not say what you think it says

Posted Nov 6, 2024 12:37 UTC (Wed) by pizza (subscriber, #46) [Link]

Adding to this, the "git history" can _easily_ contain things that (a) the organization does not have the legal right to redistribute, and (b) has nothing to do with the GPLv2 software in question.

GPLv2§2(a) does not say what you think it says

Posted Nov 6, 2024 13:14 UTC (Wed) by paulj (subscriber, #341) [Link] (3 responses)

The tarball is not, these days, the source code in the form preferred for making modifications. If you have:

1. A git repo, that you and your organisation use for working on

2. A tarball made from 1 with git archive

And you try tell me that the /latter/ is the preferred form for you or anyone else, then I say you are simply lying (possibly cause your business model depends on it).

GPLv2§2(a) does not say what you think it says

Posted Nov 6, 2024 13:31 UTC (Wed) by pizza (subscriber, #46) [Link] (2 responses)

> And you try tell me that the /latter/ is the preferred form for you or anyone else, then I say you are simply lying (possibly cause your business model depends on it).

I'm going to take the FSF's word over yours.

Or are you accusing the FSF of violating their own licenses, possibly because "their business model" depends on it?

GPLv2§2(a) does not say what you think it says

Posted Nov 6, 2024 13:43 UTC (Wed) by paulj (subscriber, #341) [Link] (1 responses)

If you have a reference to somewhere where the FSF defines source code as something different to the "preferred form of the work for modifications", I'd be interested to read that. Regardless, the term "source code" is explicitly defined in that way in the GPL text itself - if there's some pronouncement on some obscure web page somewhere, that probably doesn't matter.

Further, again, it's explicitly defined in a way that allows the meaning to be context (including temporal) specific.

GPLv2§2(a) does not say what you think it says

Posted Nov 6, 2024 16:04 UTC (Wed) by pizza (subscriber, #46) [Link]

I can comply with your interpretation by supplying at tarball that contains a git repo with a single commit -- The complete corresponding source code to the binary I'm distributing. I am under no obligation to supply the source code to binaries I did not distribute, nor am I under any obligation to distribute any/all prior versions of the source code. [1] [2]

...Or are you arguing that everyone should be forced to publish every private intermediate draft or edit, even if there was no external distribution of anything (binaries or source)? Is git squashing and rebasing now verboten?

[1] I make a minor change to Linux to support my hardware. Should I also have to distribute all 3GB of Linux's upstream git history? What about upstream's pre-git history all the way back to 1991? If the answer is different, why,? What's the cutoff? one version? Five versions? One year of history? five years of history? What if I don't use *your* preferred VCS at all? Can I comply by supplying a SoS, Perforce, or Bitkeeper repository (that you may not be able to legally access because you worked on a competing VCS in violation of the Bitkeeper license)?
[2] Overly pedantic folks can argue that one needs to include "prominent notices" saying the date of your modifications (GPLv3 5(a) ) -- But you don't have to enumerate your specific changes, and the "date" can just be when you publicly published them in the modified work. Still, you can achieve both by your tarball'd git repo having two commits; the first being the unmodified upstream source code, and the second containing all of your changes.

GPLv2§2(a) does not say what you think it says

Posted Nov 6, 2024 15:55 UTC (Wed) by ballombe (subscriber, #9523) [Link]

> The customary practices of the software industry have changed greatly since the GPL was written.

SCCS (1973) <https://en.wikipedia.org/wiki/Source_Code_Control_System>
RCS (1982) <https://en.wikipedia.org/wiki/Revision_Control_System>
CVS (1986) <https://en.wikipedia.org/wiki/Concurrent_Versions_System>
GPLv2 (1991)

So at the time the GPL v2 was drafted, version control system were already in use by professional developers,
including by the GNU project (which released RCS as GPLv1 before GLPv2 was published).

GPLv2§2(a) does not say what you think it says

Posted Nov 7, 2024 12:49 UTC (Thu) by bkuhn (subscriber, #58642) [Link]

> The text of the GPLv2 can stay unchanged, but the practical requirements of meeting it can easily change, given the GPLv2 refers to customary practice wrt software interchange.

GPLv2 refers to “customarily” only in GPLv2§3(a). Indeed …
…
> It's as daft as arguing that because mailing out tape with a tar file was acceptable in the 80s that it's acceptable today.

… no one (particularly, not me) was arguing in this thread that 8mm tape (or other software delivery methods common in the 1980s and 1990s) are still “customarily used for software interchange”.

We were talking about GPLv2§2(a), not GPLv2§3(a).

And, FWIW, I've been doing GPL enforcement and compliance as my primary work activity since 1997, and I have never seen anyone argue before that you have to interpret GPLv2§2(a) using the language in GPLv2§3(a). I'm open-minded to it, as it is common for one part of an agreement to influence interpretation of other parts, but there are lot of dots to connect to make a successful argument that the wording of GPLv2§3(a) somehow influences GPLv2§2(a) — and you've not connected those dots.

GPLv2§2(a) does not say what you think it says

Posted Jan 19, 2025 9:55 UTC (Sun) by Wol (subscriber, #4433) [Link]

> Personally, I'd love to see a court come along and kick the backside of the various people who insist that the GPL distribution requirements are set in stone, and hence a tarball suffice.

Well, If I can't be assed to use a VCS (some people don't), and my standard backup practice is a tarball (ie I'm a dinosaur, which is true but in my case not THAT true), then a tarball is the only choice.

The end user does not get to dictate to the developer what working practices they use. If the developer says "here is a copy of my working directory as backed up when I gave you the binary", then that's what you get!

And if the developer says "I've only got mobile pay-as-you-go internet and posting a CD is cheaper" then you have to negotiate a price for sending it by email or whatever.

At the end of the day, pretty much the only come-back the user has against the developer is "you're not allowed to treat ME DIFFERENTLY with the INTENT of causing pain".

Cheers,
Wol