Not logged in
Log in now
Create an account
Subscribe to LWN
Pencil, Pencil, and Pencil
Dividing the Linux desktop
LWN.net Weekly Edition for June 13, 2013
A report from pgCon 2013
Little things that matter in language design
It's not so simple
Posted Mar 1, 2011 22:18 UTC (Tue) by dskoll (subscriber, #1630)
That is not the issue. The issue is that Red Hat's kernel patches are works derived from a GPL-licensed work. They must, therefore, be GPL-licensed. This means that Red Hat customers can redistribute the patches under the GPL. Red Hat does not dispute this.
Instead, Red Hat works around the GPL by saying "If you exercise your rights, then we will punish you." This means Red Hat customers effectively cannot exercise their rights (or if they do, they need to do it anonymously to avoid retribution). That's unethical, even if it's legal, and I hope that Red Hat is suitably punished in the marketplace.
Posted Mar 2, 2011 5:57 UTC (Wed) by AndreE (subscriber, #60148)
We can both come up with extreme cases supporting the legitimacy or illegitimacy of this decision. I might suggest that Red Hat has no obligation to provide support to entities that just repackage their efforts under different logos, although they DO have obligations to respect the GPL when distributing code to all subscribers.
Posted Mar 2, 2011 6:11 UTC (Wed) by dlang (✭ supporter ✭, #313)
this obligation is based on the fact that most of 'their code' is not actually theirs, it's code from other people who let them use it on the condition that they let others use it (and derived works) as well.
RedHat has traditionally made it easy for people to make rebranded distros by keeping all their branding fairly nicely isolated.
they would be perfectly within their rights to stop doing so, no longer provide broken out patches for anything, and start including trademarked logos embedded in the source files to make it harder for people to strip the trademarked branding out.
and there may even be technical arguments for doing exactly this in the final build code version (and no, I don't buy the argument that a series of patches is the "preferred means of modification" patches aren't edited by humans, they are a way of transmitting changes from one entity to another).
If that is what they were doing, I would be silent, or supporting their right to do so (while not necessarily agreeing that it's a good idea to do so)
Posted Mar 2, 2011 6:41 UTC (Wed) by paulj (subscriber, #341)
Think very carefully about defending RedHat here. While RedHat generally get Free Software and are reasonably trust-worthy, and we might feel like cutting them slack, there are plenty of other Linux distributors who don't. Particularly in the embedded world, if you can even get (all) the source, it's usually a giant tarball. To the extent such distributors keep patches separated out internally, users who buy such devices *should* be able to get at those patches. It's not a massive issue yet, because usually the changes they make are small enough that diffing is still tractable - but that need not always remain the case.
1. Even if they've apparently acquired some amount of middle-management that doesn't and may not be, according to daniel (which, if correct, makes for a long-term worry the community should have for RedHat: some of those middle-managers may progress to top-level management one day).
Posted Mar 2, 2011 7:33 UTC (Wed) by dlang (✭ supporter ✭, #313)
yes, I know that there are people who edit and write patch files directly. I also know a person who taught himself C from the K&R book by compiling the examples and then reading the machine code that resulted (a long time mainframe systems guy), such people are very much the exception and are not what we base expectations on :-)
I wouldn't expect to require patches, or git trees any more than I would require a someone who used a proprietary compiler to compile GPL source code into a binary provide me with a copy of the compiler because that is what I would need to recreate the binary I got from that person.
so I have no problem with someone just providing one tarball of the result instead of broken out patches (I may have concerns about why someone is doing this, especially if they used to do something more useful, but that's not concerns over what is being done, but rather why they are doing it)
while I think it would be nice to get a git tree of the patches, deciding that such a thing is a requirement gets very ugly very quickly (what if they use a proprietary version control system instead of git? for example?)
Posted Mar 2, 2011 7:59 UTC (Wed) by paulj (subscriber, #341)
I actually agree with you in your caution about drawing firm lines. However, I'd argue such caution should go /both/ ways. Not only should be cautious about concluding that publishing changesets is a GPL requirement, but we should also be cautious about concluding that only publishing the aggregated-together sources and NOT the changesets is sufficient to comply with the GPL. I'm not sure myself where the line is, or what principle can be drawn other than "decide on a case-by-case basis", but I do think that in cases where there clearly is such a large amount of information contained in the deltas that /not/ publishing them effectively frustrates anyone trying to replicate the work, and that the publisher retains a significant advantage by having its own internal work-flow still be based on those deltas, that then there is a strong case to be made that the published source no longer is in preferred form...
Posted Mar 2, 2011 9:06 UTC (Wed) by airlied (subscriber, #9104)
just because there is a git tree somewhere I can access if I want it doesn't change the fact that I was given a tarball which wasn't in what you are calling the preferred form.
Posted Mar 2, 2011 10:24 UTC (Wed) by maks (subscriber, #32426)
The point beeing that linus doesn't really hide his git tree on kernel.org, whereas RH does. I'm pretty sure that you know that they didn't before, as up to RH 6.0 beta all patches are visible.
Wow. Talk about fogetting history.
Posted Mar 2, 2011 15:17 UTC (Wed) by khim (subscriber, #9252)
The point beeing that linus doesn't really hide his git tree on kernel.org, whereas RH does.
Well, Linus did that for a few years. It was not possible to get meta-information from bikeeper.com without agreeing to pretty onerous terms. Note that some developers refused to accept such terms - but none tried to imply that what Linus and other were doing is breach of the GPL!
Sorry, but this ship sailed long ago.
Posted Mar 2, 2011 16:59 UTC (Wed) by paulj (subscriber, #341)
Posted Mar 2, 2011 10:41 UTC (Wed) by pboddie (subscriber, #50784)
You may say it's a punishment, I might suggest it's protecting their business. And I still don't see where in the GPL this is prevented, although I will admit reading yours and some other points have made me think of things differently.
I don't care about Red Hat's business, but I do care about GPL compliance, so let's look at that aspect. To those who receive binaries (as part of their subscription), Red Hat also make the corresponding sources available, albeit in a form that others (who additionally have access to that software) may not prefer. In addition, Red Hat also appear to make the patches available on the condition that these are not redistributed, with the penalty for breaking this condition being that the offending subscriber's subscription is terminated and that they will receive no more patches.
Now, in the context of upholding the terms of the GPL, Red Hat appear to provide the corresponding sources to the binaries being distributed, so they aren't violating the GPL in this respect. Meanwhile, the patches distributed separately, whilst potentially being considered derived works of GPL-licensed work by other authors, still presumably come with all the privileges conferred by the GPL: you may still redistribute them, but Red Hat may then decide not to share any further patches with you.
Clearly, the GPL doesn't make anyone promise that they will continue to share new updates and revisions to a piece of software that has already been shared, so Red Hat can probably get away with making such continued sharing conditional on the "good behaviour" of subscribers. You can even turn this on its head and say that Red Hat only promises to share one revision's worth of patches but may continue to do so on the basis of such "good behaviour".
Having said all this, the divisive and isolating effect such policies might have, disempowering recipients of software and making them mere consumers, arguably work against the spirit of Free Software.
Posted Mar 2, 2011 15:36 UTC (Wed) by nevyn (subscriber, #33129)
You have the _right_ to buy a single support contract, and then sell support contracts yourself for CentOS/SL/OEL and log all your problems against RH. Red Hat have the right to refuse your business.
You may feel RH is being "mean" for not letting you screw them over, and you are free to have that opinion (but that doesn't mean others will agree with you).
Copyright © 2013, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds