That's makes no sense - just see the comments where people wanting access to an actual git repository. The floppy drive and even the pure CD-ROM drive are essentially arcane, I still have essentially unused computers with these so I should be able to ask for source code on a floppy or cd-rom as that my 'preferred form' for those computers but I need online access for day to day computers.
I am not misunderstanding, just pointing out the stupidity of that line of argument because the GPL does not go into any definition of it. So if the 'preferred form' of source is patches, then we must always get the original plus all patches. Of course that means no distributed revision control systems such as git for distribution. (Yes I know git can create and apply patches but it is more correct just to push and pull.)
This means that anyone distributing GPL code is in violation of the GPL
Posted Mar 10, 2011 15:57 UTC (Thu) by paulj (subscriber, #341)
[Link]
Actually, the GPL does say you should be able to get source on a "medium customarily used for software interchange", which floppies may once have satisfied. Note that your individual situation doesn't alone determine it.
However, we're discussing a different part of the GPL.
If the preferred form were original plus patches, than that's indeed what would have to be distributed, as you say. I don't see how that means git can't be used though. Indeed, a git repository made available IS a form of distribution, just as much as placing a tarball in a folder accessible via HTTP is (some people have argued a git repo is "content storage", and hence somehow different to distribution, which seems an incorrectly restrictive view) - indeed, the git repository is a much BETTER form of distribution.
Another important point. Preferences are perfectly capable of changing, particularly as technology does. Just because 10+ years ago the vast majority of developers preferred to trade big tarballs of the source, with history restricted to a ChangeLog file, does not mean that they prefer it today. As the state of the art in SCMs changed, developers/maintainers now tend to use the likes of 'git pull' rather than ftp'ing a tarball from tsx-11 or sunsite (or buying a walnut creek CD set).
Just as floppies today almost certainly no longer meet the "custom medium" requirement because of change, even though they once did, so it is perfectly possible for source form requirements to evolve from tarballs to a git repo. The habits and expectations of GPL software developers/maintainers do not have to be static.
Note Carefully: Even if that were so, that does NOT mean all GPL projects would HAVE TO all switch from tarballs to (e.g.) git repos together. It's perfectly possible for different communities and different projects to have different standards for preferred forms of sources.
The problem with what RedHat have done is that it's difficult for anyone to argue with a straight face that kernel developers prefer not to have the history *today* (that Linus once distributed only tarballs is somewhat irrelevant, when he's been distributing full history with releases for at least a decade - note that the GPL does NOT require that the format for the history be itself in a non-proprietary format).
Note Carefully 2: No one person can say what the preferred form is. It presumably depends on consensus.
This means that anyone distributing GPL code is in violation of the GPL
Posted Mar 10, 2011 16:37 UTC (Thu) by branden (subscriber, #7029)
[Link]
Yes. This.
The "preferred form for modification" varies in time and space.
We know what the preferred form for the Linux kernel is because major distributors like Debian and--until recently--Red Hat supplied it.
This means that anyone distributing GPL code is in violation of the GPL
Posted Mar 10, 2011 17:18 UTC (Thu) by paulj (subscriber, #341)
[Link]
And can vary between upstream development and vendor packagers. Preferred form can be a tarball for one, and tarball+patches for the other, in theory.
Course, wrt Linux, if *all* the kernel copyright holders don't have a problem with packagers not distributing the history of their fork, then there's not a problem.