Introducing RedPatch (Ksplice Blog)

Posted Nov 14, 2012 20:58 UTC (Wed) by paulj (subscriber, #341)
In reply to: Introducing RedPatch (Ksplice Blog) by Cyberax
Parent article: Introducing RedPatch (Ksplice Blog)

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.