Heh... [LWN.net]

Heh...

Posted Mar 2, 2011 15:41 UTC (Wed) by khim (subscriber, #9252)
In reply to: Huh? by dskoll
Parent article: Red Hat's "obfuscated" kernel source

In the absence of the GPL, you would have no right whatsoever to link libreadline against your app, nor could you distribute it.

Right. But you have the right to demand per-copy royalties, etc. All these privileges given to you by copyright law, you know. For your program, not for readline.

The GPL grants you rights under certain conditions.

Yes. But these conditions are quite interesting: surrender the privileges you usually have - then enjoy the benefits. That's the point of copyleft.

Red Hat's patches that it distributes to paying customers are clearly GPLd and can be distributed under the terms of the GPL.

Sure.

But you can't get the patches unless you agree to the subscription agreement.

Exactly: service agreement gives you rights under certain conditions. Without service agreement you can not even look on patches, let alone distribute them.

Therefore, Red Hat is adding restrictions to the GPL.

How come? You can distribute patches using the GPL - noone disputes this right. Just like nobody disputes your privilege for per-copy royalties. But if you want to enjoy benefits of service agreement (access to the patchlist, for example) you must agree not to exercise your privileges. Actually it's even more generous then GPL: GPL forces you to give up your privileges forever, while service agreement will only bind you temporarily.

to post comments

Heh...

Posted Mar 2, 2011 16:41 UTC (Wed) by dskoll (subscriber, #1630) [Link] (5 responses)

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.

What rights?

Posted Mar 2, 2011 19:54 UTC (Wed) by khim (subscriber, #9252) [Link] (4 responses)

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] (3 responses)

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] (2 responses)

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:
1. You have no right to distribute anything you are downloading from our servers.
2. But if you know that some open-source license gives you such right and can prove that then you are in the clear.
3. Our lawyers are always ready to discuss your proof in the court of law.

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] (1 responses)

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...