Introducing RedPatch (Ksplice Blog)

Posted Nov 10, 2012 9:52 UTC (Sat) by lkundrak (subscriber, #43452)
In reply to: Introducing RedPatch (Ksplice Blog) by Cyberax
Parent article: Introducing RedPatch (Ksplice Blog)

This is what puzzles me.

So, is it that a development history in between two GPL-licensed trees is not licensed by GPL? Or is the patch file not considered a derived work of the tree itself? Or am I completely missing the point?

I could not find conditions for use or redistribution of the patch files on Red Hat web site.

Introducing RedPatch (Ksplice Blog)

Posted Nov 10, 2012 10:02 UTC (Sat) by Cyberax (✭ supporter ✭, #52523) [Link] (16 responses)

You can redistribute publicly accessible RedHat patches under the GPL, no problem. However, RedHat exploits a clever trick here.

Oracle can redistribute the information about individual patches in RHEL, however they obtain it (by subscribing to RHEL, for example). But they can do it exactly once.

Because publishing the patches terminates the contract between RHEL and Oracle. And without a contract it's illegal to access the RHEL systems that carry patch information.

Introducing RedPatch (Ksplice Blog)

Posted Nov 10, 2012 10:34 UTC (Sat) by boklm (guest, #34568) [Link] (2 responses)

Does the contract allow sending the patches to a 3rd person that will redistribute the patches ?

Introducing RedPatch (Ksplice Blog)

Posted Nov 10, 2012 13:51 UTC (Sat) by khim (subscriber, #9252) [Link]

Yes and no. You can distribute it, no problem (patches are GPLed, after all), but contract is terminated in this case (and can not be renewed).

Introducing RedPatch (Ksplice Blog)

Posted Nov 10, 2012 14:14 UTC (Sat) by bahomet (guest, #87773) [Link]

That most likely would work with a covet 3rdparty.

However, what Oracle aims at and RH tries to prevent is:
- neither access to the knowledge base meant by the patches
(that's fairly accomplished by an RHN subscription)
- nor a crusade for making this knowledge base public
- rather, making a business that builds on this knowledge base

... for which Oracle would need an authentic public distribution of that
knowledge base, and that's exactly what RH stopped to give out.

RedPatch is a clever trick though -- while Oracle cannot publicly use the original knowledge base, it's certainly possible for them to reverse engineer it from public sources and arrive at a freely usable by-and-large equivalent of the original.

Introducing RedPatch (Ksplice Blog)

Posted Nov 10, 2012 13:26 UTC (Sat) by cyanit (guest, #86671) [Link] (1 responses)

Why is that an issue?

Surely Oracle can afford to either incorporate a new company or pay a new individual every time RedHat updates their kernel, subscribe to RHEL with it, release the patches, and then terminate the contract.

Also, couldn't that contract term be construed as an additional restriction on the patches, and thus a violation of the GPL by RedHat?

Introducing RedPatch (Ksplice Blog)

Posted Nov 10, 2012 13:49 UTC (Sat) by khim (subscriber, #9252) [Link]

This only works in countries where it's easy to bribe court to look the other way. In any sane country after few repeats all the lawsuits will be connected together and there will be looong investigation which will try to see if Oracle instigated these repeated violations in some way.

Think recent Apple in UK fiasco. Apple was pretty sure that since they found clever way to issues non-apology without violating a letter of law they were in the clear. Court was not amused.

Introducing RedPatch (Ksplice Blog)

Posted Nov 14, 2012 2:02 UTC (Wed) by Lennie (subscriber, #49641) [Link] (10 responses)

So basically this is kind of like adding extra terms or conditions to the GPL ? Which isn't allowed by the GPL.

So how do they do that ?

Introducing RedPatch (Ksplice Blog)

Posted Nov 14, 2012 2:51 UTC (Wed) by Cyberax (✭ supporter ✭, #52523) [Link] (9 responses)

They're not adding anything additional to the GPL.

Oracle would be totally free to redistribute patches they receive from RHEL subscription. However, nothing in the GPL forces RH to continue providing Oracle with further patches - that's not a question of copyright.

FSF had decided that it's legal quite a time ago.

Introducing RedPatch (Ksplice Blog)

Posted Nov 14, 2012 20:58 UTC (Wed) by paulj (subscriber, #341) [Link] (8 responses)

Where the GPL applies RedHat do however have to provide sources to any 3rd party though (given they distribute in binary only form in at least some situations). Which they do, hence CentOS.

Regarding the patches: Either the GPL applies to these patches, in which case RedHat must supply them to any 3rd party, and the RHEL contract makes no odds. Alternatively, the patches are not supplied because of GPL obligations, in which case this discussion above about the GPL and contract re the patches has been moot.

You can't get around the GPL "binary-distribution: supply preferred source to any 3rd party condition" via support contracts, just to be clear.

Introducing RedPatch (Ksplice Blog)

Posted Nov 15, 2012 5:22 UTC (Thu) by Cyberax (✭ supporter ✭, #52523) [Link] (6 responses)

Again, wrong. GPL forces you to supply source code if you distribute a product to a some other entity.

GPL does NOT force you to distribute it in the first place. For example, I might have some personal code under the GPL. I can give it to you and say: "If you distribute this code to someone else, I won't give you any more of my code". That's totally legal under the GPL and it's what RedHat is doing.

Introducing RedPatch (Ksplice Blog)

Posted Nov 15, 2012 6:31 UTC (Thu) by raven667 (subscriber, #5198) [Link]

That doesn't seem exactly right. RedHat isn't withholding any code from anybody, that are just distributing their kernel changes as a single patch and aren't providing an annotated changelog publicly. If you want the changelog and annotated individual change sets then you can be a subscriber, a subscription that can be terminated. The code is under the GPL, the bug tracker data is not.

IIts kind of silly as well because in most cases the individual change sets are also submitted and integrated into the mainline kernel. I don't know how many changes are only made in customer facing redhat kernels that aren't upstream, if any. Its probably hard to tell automatically because the same bug fix or feature might be coded slightly differently between different kernel versions

Introducing RedPatch (Ksplice Blog)

Posted Nov 15, 2012 8:52 UTC (Thu) by paulj (subscriber, #341) [Link] (4 responses)

If you're distributing personal code, then you're not subject to the GPL. Nothing you do with that code can violate the GPL, for you're not reliant on GPL right to distribute the work (though, it may make it hard or impossible for others to exercise the GPL rights you say you're giving them). RedHat are largely distributing other peoples' code, exercising GPL rights given to them, a different situation.

Distributing under the GPL *does* force you to distribute the source, if you distribute the work at all. Further, if at any point you distribute in binary-only form, then you are obliged to provide source to *any* 3rd party, for a specified period. This obligation, once incurred, can not be terminated.

Anyway, the point I wanted to make was more about the patches, and whether RedHat making split-out kernel patches available had anything to do with honouring their GPL commitments. If it does, then RedHat should be providing those split-out patches to *any 3rd party*, and if they do not do this then they are in breach of the GPL.

Introducing RedPatch (Ksplice Blog)

Posted Nov 15, 2012 8:58 UTC (Thu) by Cyberax (✭ supporter ✭, #52523) [Link]

> Distributing under the GPL *does* force you to distribute the source, if you distribute the work at all.

Can you please read this article again?

RedHat distributes source code of all patches. Under the GPL. You can get a RHEL subscription and you'll get access to them. Under the GPL.

You can then take these patches and re-distribute them. That's not a problem at all, you're totally free to do it. Under the GPL.

However, RedHat will revoke your access to the RHEL repository should you do this. I.e. they won't give you any further updates - neither in binary form nor in source-code form.

> If it does, then RedHat should be providing those split-out patches to *any 3rd party*
Can you provide a reference to that in the GPL? I'm under impression that GPL kicks in during the moment of distribution only.

Introducing RedPatch (Ksplice Blog)

Posted Nov 24, 2012 5:12 UTC (Sat) by steffen780 (guest, #68142) [Link] (2 responses)

"Further, if at any point you distribute in binary-only form, then you are obliged to provide source to *any* 3rd party, for a specified period."

Are you sure about this? Unless I'm severely mistaken the GPL requires you to make the sources available to the party/parties to whom you shipped GPLd stuff. It does not require you to make anything available to anyone else.

Introducing RedPatch (Ksplice Blog)

Posted Nov 24, 2012 5:29 UTC (Sat) by mjg59 (subscriber, #23239) [Link] (1 responses)

3(b) requires that you provide a written offer valid for any third party if you only distribute binaries. You can avoid that requirement by distributing under 3(a) instead (ie, provide binary *and* source simultaneously)

Introducing RedPatch (Ksplice Blog)

Posted Nov 25, 2012 1:18 UTC (Sun) by steffen780 (guest, #68142) [Link]

My bad, so I was severely mistaken.

Introducing RedPatch (Ksplice Blog)

Posted Nov 15, 2012 15:35 UTC (Thu) by jschrod (subscriber, #1646) [Link]

Where is it stated in the GPL that patches (internal intermediate results) must be published?

AFAIU, the source must be published, but not the internal commits that lead to that source. And the kernel source is published, as srpm.

FTR: I'm neither connected to RH, nor do I use RHEL or Oracle's dist privately or at my company. I think RH's policy concerning kernel source distribution is ethically wrong, but not illegal.