Do-not-distribute terms [LWN.net]

Do-not-distribute terms

Posted Apr 28, 2017 15:10 UTC (Fri) by dsommers (subscriber, #55274)
In reply to: Do-not-distribute terms by PaXTeam
Parent article: No more grsecurity test patches

> > There are no restrictions put on the source code and it is freely available through the channels Red Hat have chosen.

> are you saying that things have changed back since https://lwn.net/Articles/430098/ ?

Nope. And the kernel source code which is used to build RHEL kernel packages is fully available today as it was back then.

>> [grsec] seem to provide a restriction on what you can do with the source code[...]
>
> vs.
>
>> [grsec] will not restrict you from exercising your rights on the code itself as defined in the GPL.
>
> confuses me. are we restricting 'what you can do with the source code' or not? ;)

Well, when you cut out half the sentence, it gets confusing. By adding the missing part, it helps:

« [...] if you want to make use of their service.»

to post comments

Do-not-distribute terms

Posted Apr 28, 2017 18:42 UTC (Fri) by PaXTeam (guest, #24616) [Link] (5 responses)

> Nope.

are you saying that they would still terminate the support contract if a customer publicly redistributed their kernel source code in the form of individual patches? if so then why did you claim that there were "no restrictions put on the source code"?

> By adding the missing part, it helps:

it does not which is why i justapoxed your two contradicting statements that both talked about our service. first you claimed restrictions on the *source code* (emphasis by you) then you claimed that there weren't any. which is it then? and once you also answer the above question, why is RH's 'restriction' on the right side whereas ours isn't?

Do-not-distribute terms

Posted Apr 28, 2017 21:18 UTC (Fri) by dsommers (subscriber, #55274) [Link] (4 responses)

> are you saying that they would still terminate the support contract if a customer publicly redistributed their kernel
> source code in the form of individual patches? if so then why did you claim that there were "no restrictions put on
> the source code"?

There are *no* restrictions on the source RPMs which are used to build the kernel RPM. That is what I claim. There is nothing in the GPL anywhere which defines the format or granularity of how the source code is to be distributed. It just says the source code used to produce object code or executable format is to be made available.

The customer portal may have (I have not used it, only heard claims that it exists) a source code browser. How the source code is presented is unknown to me, is not relevant to me. To me the full, unrestricted access to the source code which produces the binary RPMs is my interest point. That source browser is a service which have its own EULA. The EULA you can read for yourself here: https://access.redhat.com/help/terms/ ... And this *service* may have restrictions to how you use the *service*. That does not imply that there is a limitation to what you can do with the GPLed code put inside a source RPM.

> it does not which is why i justapoxed your two contradicting statements that both talked about our service. first you claimed restrictions on the *source code* (emphasis by you) then you claimed that there weren't any. which is it then?

The kernel source code is GPLed. If you ship a derived work of the kernel (which I consider the grsec patchset to be), it must be GPLed - according to the GPL license. So I ask you instead: What happens if one of your users redistribute that derived work?

> And once you also answer the above question, why is RH's 'restriction' on the right side whereas ours isn't?

Because Red Hat does not restrict redistribution of the source code used to build the binary RPMs. The source RPMs are fully and freely available, no strings attached, no limitations imposed - as long as you follow the license of the source RPM. Again, that source RPM is what is needed to build the binary RPMs you install on your system.

Do-not-distribute terms

Posted Apr 28, 2017 22:50 UTC (Fri) by PaXTeam (guest, #24616) [Link] (3 responses)

> There are *no* restrictions on the source RPMs[...]

you're changing the subject now as you made claims about generic 'source code' before not just SRPMs. this makes no sense to me since you were comparing "the Red Hat case" (of tying their service to customers' not exercising their rights to redistribute broken out kernel patches, not SRPMs) to our case. why you keep bringing up SRPMs which are unrestricted (AFAIK) is beyond me, that's not at all the subject of the discussion. but if you want to go with the SRPM case, let me ask you this: what will happen if a customer replaces the monolithic patch in the kernel SRPM with the broken out series and redistributes that? are they permitted to do it? does Red Hat terminate their contract?

> And this *service* may have restrictions to how you use the *service*.

if you read the EULA you linked to it says in the 'Term and Termination' section that:

> Your right to access Red Hat Content expires automatically when you no longer have valid subscriptions for Red Hat products.

now my understanding is that you lose that subscription (and thus access to the portal) when you redistribute the broken out kernel patches. your 'nope' seems to have confirmed to me that it was your understanding as well. do you agree with this or did you mean something else? if you agree then you can't claim that there're no restrictions on the source code as clearly some form of it is restricted (which happens to be very important if you're interested in more than mere recompilation, see the original LWN article).

> > first you claimed restrictions on the *source code* (emphasis by you)
> > then you claimed that there weren't any. which is it then?
> The kernel source code is GPLed.[...]

this doesn't answer my question at all. so one more time: do you claim that we put restrictions on the *source code* or not? yes/no please. if yes, do elaborate as i'm sure some kernel copyright holders will want to know about it.

> What happens if one of your users redistribute that derived work?

it entirely depends on their contract (which i'm not privy to as it's Brad's business, not mine), but you can always negotiate one and you'll see the terms.

> The source RPMs are fully and freely available, no strings attached, no limitations imposed - as long as you follow the license of the source RPM.

no limitations imposed? so my question above reduces to this: does a customer have the right to replace the monolithic kernel patch with the broken out series in the kernel SRPM? assuming yes, do they have the right to redistribute that SRPM? assuming yes, what will Red Hat's response be? will they terminate the support contract or not?

Do-not-distribute terms

Posted Apr 29, 2017 0:32 UTC (Sat) by dsommers (subscriber, #55274) [Link] (2 responses)

> but if you want to go with the SRPM case, let me ask you this: what will happen if a customer replaces the monolithic patch in the kernel SRPM with the broken out series and redistributes that? are they permitted to do it? does Red Hat terminate their contract?

I can not give an authoritative answer here, as I am in no position or role to represent Red Hat and their view points. But if you put the efforts of splitting up that patch by finding the relevant commits in Linus' kernel git tree and making it build ... As a layman, I see no reason why that should cause an issue if you redistribute that. But IANAL and neither a Red Hat representative. So you will have to ask them or a lawyer.

But I struggle to see why the patching Red Hat does is so important to you. GPL does not impose any preferred format, granularity of how to come to a certain result. All the GPL says is that the source code must be made available, which Red Hat does through their SRPM files. If SRPM is an issue for you, you can extract the cpio archive inside it and unpack the tar ball and build the pieces together manually. And you can redistribute that source code freely without any restrictions and fear of implications - as long as you stay aligned with the license of the source code.

> this doesn't answer my question at all. so one more time: do you claim that we put restrictions on the *source code* or not? yes/no please. if yes, do elaborate as i'm sure some kernel copyright holders will want to know about it.

I honestly don't know if you put restrictions or not. If looking purely at the source code and only on that, you basically are not allowed to do so by the GPL, so I hope you are not doing that. But looking at it in a broader context, it is really not clear to me at all if the end result is a restriction or not. Which is why I asked what would happen if one of your customers would do just that; to gain a better understanding.

The reason is that there might be someone being willing to argue (most likely lawyers) that *if* there are some kind of negative consequences by distributing your derived work, you are _implicitly_ revoking a freedom initially provided by the GPL license. But that is purely a speculation from my side.

And that scenario is really not comparable at to what Red Hat does. Because they do provide the complete source code used to build the object and executables used on a system, without any restrictions using their preferred distribution format (yes, SRPM) - thus Red Hat users and customers don't need to fear what could happen later on if they redistribute that source code. But you seem to try to twist that into that Red Hat is obliged to provide the granular development process of that source code, while the GPL does not and have never required that.

Do-not-distribute terms

Posted Apr 29, 2017 8:35 UTC (Sat) by PaXTeam (guest, #24616) [Link] (1 responses)

> I can not give an authoritative answer here [...]

then why did you say that the Red Hat kernel patch situation discussed in the LWN link i gave you has not changed since? do you know what that situation is at all?

> But if you put the efforts of splitting up that patch by finding the relevant commits in Linus' kernel git tree [...]

that is not at all the Red Hat situation so i'm not sure what you've been discussing all along. what did happen was simple: Red Hat used to put a kernel patch series into their kernel SRPM instead of one big monolithic patch or a fully pre-patched tree. both satisfy the GPL but they aren't equivalent in other ways. then one day Red Hat decided to replace the patch series in their kernel SRPM with a monolithic patch (or a pre-patched tree, doesn't matter) *and* stop distributing their kernel patch series to the geneal public. instead, they made that series available to their paying customers only *and* changed their service terms to 'restrict' (your term, not mine) the distribution of that source code (again, your terms): they stipulated that it'd be a breach of those terms (and thus result in service termination) if the customer did distribute that patch series to non-subscribers ('source code'). you said that this 1. was fine for 'the Red Hat case', 2. is not a restriction on that source code, 3. is a restriction on our source code if we did this, 4. thus it's not ok for us to do this. that is a contradiction there that you have yet to resolve.

> I honestly don't know if you put restrictions or not.

vs.

> They seem to provide a restriction on what you can do with the source code if you want to make use of their service.

so do you know something or do you not know something?

> But you seem to try to twist that into that Red Hat is obliged to provide the granular development process of that source code[...]

i did not say that at all, quite the contrary in fact. what you did say was however that it was fine for Red Hat to terminate their support contract if a customer redistributed their broken out kernel patches ('source code' in your terms) but it is not fine for us to do the same. you haven't addressed this contradiction so far.

Do-not-distribute terms

Posted Apr 29, 2017 17:01 UTC (Sat) by mathstuf (subscriber, #69389) [Link]

Are you saying that your customers can redistribute the non-broken out patches for grsecurity? Without consequences for their subscription? If so, I see no contradiction here. If you had a "higher ground" to argue from about the single-patch versus broken-out-patches that Red Hat does, I can see why you'd argue about this, but I see more fundamental issues here.