Red Hat and the GPL
Posted Mar 9, 2011 10:06 UTC (Wed) by dark
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.
to post comments)