Do-not-distribute terms [LWN.net]

Do-not-distribute terms

Posted Apr 28, 2017 11:16 UTC (Fri) by epa (subscriber, #39769)
In reply to: Do-not-distribute terms by farnz
Parent article: No more grsecurity test patches

That's exactly my point. It says that if you exercise your rights under the GPL, then... (insert consequence here). If this is compatible with the GPL then it's hard to see how the GPL can be enforced at all in practice. You could receive a copy of gcc subject to a contract which says you can modify the source code, but if you do so then you agree to pay $1000 in licensing fees for each line of code changed. (Or upon payment of a sum upfront, which is then refunded in part each month depending on your compliance with the conditions.) And so on.

The GPL (version 2) says "You may not impose any further restrictions on the recipients' exercise of the rights granted herein." If that is to have any meaning at all, it must mean that you may not impose consequences on recipients who exercise those rights, or put them on a "naughty list" depending on whether they do so.

If not, you can get round any requirement not to impose restrictions. Congress may make no law restricting freedom of speech but it could quite easily raise taxes and then pay everyone a tax rebate conditional on whether they keep quiet. After all, it is just the extra tax rebate that is withdrawn, not your right to free speech...

to post comments

Do-not-distribute terms

Posted Apr 28, 2017 12:34 UTC (Fri) by dsommers (subscriber, #55274) [Link] (9 responses)

«The GPL (version 2) says "You may not impose any further restrictions on the recipients' exercise of the rights granted herein." If that is to have any meaning at all, it must mean that you may not impose consequences on recipients who exercise those rights, or put them on a "naughty list" depending on whether they do so.»

But that is the crux of it all. The freedom on the GPLed software isn't restricted in these scenarios. You are absolutely free to do what you want with that software. But the relation to a service provider who provides a distribution channel for the GPLed code, will also have an independent contract where conditions for the service is defined. If one of the parties violates that independent contract, that have consequences for the service and not the software itself.

Which means, you as a customer will have a different customer experience with the service provider if do not violate the service agreement vs if you violate the agreement.

In the Red Hat case, IMO, they are on the right side. There are no restrictions put on the source code and it is freely available through the channels Red Hat have chosen. There exists no software without a source code of some kind. If you choose to redistribute the source RPMs, you are free to do so under the same conditions the license of the source code is based upon. This should further not cause any implications to the services you have subscribed to with Red Hat.

It is tempting to consider the argument that a binary version of a source code being a derived work. IANAL, but I believe that is a misinterpretation of «derived work». My understanding of derived work is that you have made a new software with a modified functional behaviour, where you have based these changes on an existing code base. Since it is also possible (though it will demand quite some efforts) to build basically an identical binary - from a functional context - based on the source code, then it is not a derived work. What will differ is timestamps saved into the binary files, which causes no functional difference - hence no derived work. This rebuild may be redistributed without any restrictions and it should not violate any service agreement with Red Hat. It is not their object code or executable result you distribute.

There is also nothing in the GPL which demands that the compiled (binary) result (object code or executable form) of a software must be made available. But it goes all the way to state that the source code used to create the object or executable code must be made available if you distribute the object code or executable result. And you may not impose any additional restrictions on that source code if being redistributed.

In the gresec case it is quite different. They seem to provide a restriction on what you can do with the source code if you want to make use of their service. Since, IMO, the GPL is focused on the source code, this tangents the issue you found in the GPL. However, they can probably go free from this too. As grsec will then cancel the service agreement you have with them, but will not restrict you from exercising your rights on the code itself as defined in the GPL. Whether this holds in court or not, entirely depends on the legalese in the service agreement you have with grsec. Not how the GPL is interpreted. It might be possible to argue that such a clause of the service agreement don't hold water because it restricts a freedom you have been granted in the products license you have received via this service agreement. But again, that all comes down to the wording and interpretation of the service agreement, not GPL itself. Regardless, the consequences of breaking the service agreement with grsec is a different customer experience with grsec, not the GPLed code.

Do-not-distribute terms

Posted Apr 28, 2017 14:13 UTC (Fri) by PaXTeam (guest, #24616) [Link] (7 responses)

> 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/ ?

also this:

> [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? ;)

Do-not-distribute terms

Posted Apr 28, 2017 15:10 UTC (Fri) by dsommers (subscriber, #55274) [Link] (6 responses)

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

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.

Do-not-distribute terms

Posted Apr 30, 2017 10:31 UTC (Sun) by Wol (subscriber, #4433) [Link]

> It is tempting to consider the argument that a binary version of a source code being a derived work. IANAL, but I believe that is a misinterpretation of «derived work».

IANAL too, but (time stamps etc excepted) as a mathematician I would actually argue that the source and binaries are the SAME work.

Failure to understand this point by the legal system is part of why the legal protection of software is such a mess ... :-)

Cheers,
Wol