| |||||||||||||
Red Hat and the GPLRed Hat and the GPLPosted Mar 9, 2011 10:38 UTC (Wed) by pbonzini (subscriber, #60935)In reply to: Red Hat and the GPL by dark Parent article: Red Hat and the GPL
> 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.
(Log in to post comments)
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.
|
|||||||||||||