| |||||||||||||
Heh...Heh...Posted Mar 2, 2011 16:41 UTC (Wed) by dskoll (subscriber, #1630)In reply to: Heh... by khim Parent article: Red Hat's "obfuscated" kernel source
The difference between the GPL's granting of rights and Red Hat's subscription service is this: The GPL is a license, not a contract. Red Hat's subscription agreement is a contract. You pay Red Hat for support, and in return they give you support. But they also include a landmine in the contract: You are forced to give up rights you'd normally have even in the absence of the support contract. (For example, if Red Hat's segregated kernel patches magically landed in my mailbox, it would be perfectly legal for me to redistribute them under the GPL even though I'm not a Red Hat customer.) Red Hat's contract adds additional restrictions to the GPL which IMO is a GPL violation. Try this thought experiment: If Red Hat's contract said: "If you take advantage of the rights under the GPL to redistribute our patches, you agree to pay Red Hat software one billion dollars", then that would clearly be a severe restriction on redistribution. All that's in dispute is the degree of restriction (which is basically the money you've spent on the support contract.) The existence of an additional restriction cannot be disputed and this violates the GPL.
(Log in to post comments)
What rights? Posted Mar 2, 2011 19:54 UTC (Wed) by khim (subscriber, #9252) [Link] You are forced to give up rights you'd normally have even in the absence of the support contract. In the absence of the support contract you have no access to patches in question so you can not distribute them. For example, if Red Hat's segregated kernel patches magically landed in my mailbox, it would be perfectly legal for me to redistribute them under the GPL even though I'm not a Red Hat customer. If you can prove that patches arrived in your mailbox from source other then RedHat's site (for example from kernel.org site) you are still free to distribute them. If Red Hat's contract said: "If you take advantage of the rights under the GPL to redistribute our patches, you agree to pay Red Hat software one billion dollars", then that would clearly be a severe restriction on redistribution. Sure. This will be like patent license: no matter how you've gotten the patches you are forbidden to excercise your rights. RedHat's agreement only restricts distribution of meta-information. You are free to strip meta-information and distribute raw source/patches. In fact if the meta-information comes from third-party source and not from RedHat you are free to distribute that too - but you must prove that it indeed come from different source. The existence of an additional restriction cannot be disputed and this violates the GPL. Sorry, but no. It's said quite explicitly: this Appendix is not intended to interfere with your rights under those individual licenses. If you can prove that you had the right to distribute something under terms of GPL then you are in the free. Just remember that while software included in patches is GPL-licensed different commit messages, ACKs and NAKs are not. And they may even be peceived as trade secrets. You will need pretty good lawer to properly cleanup the patches from RedHat's web site, but you can distribute the source code itself - RedHat does not interfere with that.
What rights? Posted Mar 2, 2011 20:18 UTC (Wed) by dskoll (subscriber, #1630) [Link] In the absence of the support contract you have no access to patches in question so you can not distribute them. No, that's untrue. Someone with a support contract could (legally) mail me the patches, and I could redistribute them in the absence of a support contract with Red Hat. The person who sent me the patches might be in hot water with Red Hat, but I wouldn't be. If you can prove that patches arrived in your mailbox from source other then RedHat's site (for example from kernel.org site) you are still free to distribute them. Nope. Even if I obtained the patches from Red Hat, I can still distribute them because they are GPL'd (being derived products created from a GPL'd work.) RedHat's agreement only restricts distribution of meta-information. Are you claiming that Red Hat's patches are not derived from a GPL'd work? I don't think even Red Hat claims that. Sorry, but no. It's said quite explicitly: this Appendix is not intended to interfere with your rights under those individual licenses. But it absolutely does interfere with those rights. How can you claim it does not? You will need pretty good lawer to properly cleanup the patches from RedHat's web site Why do you think that? Are you claiming that the patches Red Hat distributes to its customers are not derived from a GPL'd work? Just remember that while software included in patches is GPL-licensed different commit messages, ACKs and NAKs are not. And they may even be peceived as trade secrets. I am not talking about commit messages. I am referring to the individual kernel patches that Red Hat does make available (only) to its customers (supposedly) under the GPL.
Once again... Posted Mar 3, 2011 10:39 UTC (Thu) by khim (subscriber, #9252) [Link] But it absolutely does interfere with those rights. How can you claim it does not? I'm not claiming that. RedHat does. I don't think you've read the whole thing. Basically RedHat says the following: See? It does not interfere with your GPL rights - but it shifts the separation issue on your side. You must prove that you have the right to distribute anything - and if you'll do a single error... well, your support contract is no longer valid and that's that. Why do you think that? Are you claiming that the patches Red Hat distributes to its customers are not derived from a GPL'd work? They contain mix of the GPLed code and non-GPLed code. For example a lot of files in Documentation subdirectory are not derived works of kernel (even if they are distributed in the same tarball - see "mere aggregation" clause). This means that the fact that patch applies to Linux kernel is not enough to clear you: you must review each and every patch and decide what parts of it are GPL-derived and what parts are not GPL-derived. This is quite non-trivial amount of work.
Once again... Posted Mar 3, 2011 12:02 UTC (Thu) by dskoll (subscriber, #1630) [Link] I'm not claiming that. RedHat does. Red Hat is full of crap if it claims that. If you think Red Hat is using the threat of lawyers to stop people from distributing the patches ("Our lawyers are always ready to discuss your proof in the court of law."), then that's even worse. That throws a huge chill over collaborative kernel development. Even I don't think Red Hat is that bad; I believe they won't actually sue anyone for distributing the patches. This means that the fact that patch applies to Linux kernel is not enough to clear you: you must review each and every patch and decide what parts of it are GPL-derived and what parts are not GPL-derived. If you believe that's what Red Hat is doing, then it's even worse that what I'm claiming it's doing. If what you say is true, then Red Hat is deliberately blocking collaborative kernel development and adding legal threats to its arsenal against anyone using its patches. Do you think that's in the spirit of the GPL?
RedHat had not invented anything Posted Mar 4, 2011 17:52 UTC (Fri) by khim (subscriber, #9252) [Link] If you think Red Hat is using the threat of lawyers to stop people from distributing the patches ("Our lawyers are always ready to discuss your proof in the court of law."), then that's even worse. That throws a huge chill over collaborative kernel development. Even I don't think Red Hat is that bad; I believe they won't actually sue anyone for distributing the patches. If they'll sue or not remains to be seen. But they reserve the right to do so - like Microsoft reserves the right to do so (WRT Mono). If you believe that's what Red Hat is doing, then it's even worse that what I'm claiming it's doing. If what you say is true, then Red Hat is deliberately blocking collaborative kernel development and adding legal threats to its arsenal against anyone using its patches. Do you think that's in the spirit of the GPL? Well, it's good question. Probably not. But... FSF itself developed GNU programs (like emacs or gcc) behind the closed doors for years. When the programs were released they were released as tarballs only - access to the VCS was restricted even fater that. Of course they have not threatened you with lawers and when EGCS project decided to fork GCC they they allowed them to take patches from private tree, but it happened when developers convinced RMS to conduct this experiment, not when they decided that they have unalienable right to publish them...
|
|||||||||||||