Do-not-distribute terms [LWN.net]

Do-not-distribute terms

Posted Apr 29, 2017 0:32 UTC (Sat) by dsommers (subscriber, #55274)
In reply to: Do-not-distribute terms by PaXTeam
Parent article: No more grsecurity test patches

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

to post comments

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.