| |||||||||||||
Red Hat and the GPLRed Hat and the GPLPosted Mar 10, 2011 11:24 UTC (Thu) by dwmw2 (subscriber, #2063)In reply to: Red Hat and the GPL by mjg59 Parent article: Red Hat and the GPL
"Back when people sent patches directly to Linus and he just released tarballs, was he violating the GPL?"It's important to remember that there is a clear distinction between upstream, and a modified version or fork. Tarballs are a perfectly sane way for upstream releases to happen. But I think that every competent open source developer, when they're not trying to twist things to make a point, will agree: When releasing a modified code base which is based on some upstream project, it is definitely preferable to release that in the form of original + patches, rather than as a monolithic tarball of the whole damn mess.
(Log in to post comments)
Red Hat and the GPL Posted Mar 10, 2011 12:47 UTC (Thu) by mjg59 (subscriber, #23239) [Link]
It's also preferable for an upstream maintainer to provide new releases in a manner that allows people to bisect patch history. I don't understand the distinction you're drawing.
Red Hat and the GPL Posted Mar 10, 2011 14:43 UTC (Thu) by paulj (subscriber, #341) [Link]
The distinction he was drawing is pretty widely understood really, embodied fairly concretely as it is by the difference between the sources distributed by Linus for the Linux kernel (upstream) and those distributed by RedHat as the sources for the kernel RPM previously (to choose one example amongst many). It's not hard to grasp really. ;)
Red Hat and the GPL Posted Mar 10, 2011 18:48 UTC (Thu) by martinfick (subscriber, #4455) [Link]
To make this argument you'd have to be able to define upstream, which I suspect that you cannot actually do in a satisfactory way. Red Hat in many ways is acting as an upstream for their long term kernels.
|
|||||||||||||