| |||||||||||||
Red Hat and the GPLRed Hat and the GPLPosted Mar 9, 2011 10:06 UTC (Wed) by dark (subscriber, #8483)Parent article: Red Hat and the GPL
One could argue that those methods do provide the source code, but it certainly isn't in a form preferred by anyonenor does it adhere to the "medium customarily used for software interchange" requirement.This in itself indicates that "preferred form" must refer to more than the choice of medium. Clause 3 already requires that source code must be presented on a medium customarily used for software interchange, so cuneiform tablets are right out. There would be no need for the "preferred form" definition if that is all it meant. As for VCSes: I think there's not necessarily an equivalence between what Red Hat does with the kernel and what most projects do. The ordinary use of a version control system is to keep track of older versions of the code, and these older versions are not used to produce the binary. They are not needed for "complete source code" because the tip of your VCS already has "all the source code for all modules it contains". That's if you use the VCS as an archive. But if you're using your VCS as a patch queue, where the whole queue evolves as you make modifications, then the patch queue itself is the preferred form of your work. Now, I don't know if Red Hat does this. I don't know their workflow. But the difference can be illustrated with a simple question: if Red Hat engineers discover that one of their patches has a problem and needs to be fixed, do they fix it by committing another patch to the head of that branch? Or do they edit the patch and then rebase? In the former case, they're just using their VCS to track their history of changes. In the latter case, the evolving branch is their source code.
(Log in to post comments)
Red Hat and the GPL Posted Mar 9, 2011 10:19 UTC (Wed) by airlied (subscriber, #9104) [Link]
describing the RHEL kernel has a patch queue is totally wrong.
Its a fork of the Linus kernel and is maintained nearly the same way, no rebase, linear development.
Red Hat and the GPL Posted Mar 9, 2011 10:50 UTC (Wed) by dark (subscriber, #8483) [Link] Well in that case I see no GPL issue with distributing the latest version as a single tarball.
Red Hat and the GPL Posted Mar 9, 2011 10:38 UTC (Wed) by pbonzini (subscriber, #60935) [Link]
> if Red Hat engineers discover that one of their patches has a problem and needs to be fixed, do they fix it by committing another patch to the head of that branch?
Yes, at least in the case of the kernel. Other packages may be handled differently.
Red Hat and the GPL Posted Mar 9, 2011 14:37 UTC (Wed) by vonbrand (subscriber, #4458) [Link] This is ludicrous. How can the fact that somebody does a Preferred form for "building, studying and modifying" just isn't the same as for doing archaeology.
Red Hat and the GPL Posted Mar 9, 2011 21:10 UTC (Wed) by branden (subscriber, #7029) [Link]
"This is ludicrous. How can the fact that somebody does a git rebase make that the preferred form for the code suddenly isn't a tarball anymore?"
Well-stated. I don't know why so many people keep dragging the VCS issue into things.
The complaint was *not* "Red Hat doesn't make their git trees public!"
Why do people insist on pretending as if it was?
It is possible for Red Hat to distribute the kernel SRPMs in a form which unambiguously satisfied the letter and spirit of the GPL without exposing their git trees to the public. How do we know that? Because until recently, they'd spent years doing it.
People are not asking for the moon here.
Red Hat and the GPL Posted Mar 9, 2011 21:36 UTC (Wed) by dark (subscriber, #8483) [Link] Well I wasn't talking about access to the VCS at all. I was talking about publication of the patch queue. If the patch queue as a whole is the thing that you modify and that changes over time, then that's the source. It would even make sense to check the patches into a VCS so that you get meta-patches to track the changes, which is something I've seen done.However this doesn't seem to apply to the RHEL kernel so it's just hypothetical.
|
|||||||||||||