GRsecurity violating GPLv2 themselves by prohibiting redistribution

Posted Jun 1, 2016 19:28 UTC (Wed) by rahulsundaram (subscriber, #21946)
In reply to: GRsecurity violating GPLv2 themselves by prohibiting redistribution by jspaleta
Parent article: Grsecurity stable patches to be limited to sponsors

Ah, right. I am not following recent changes very closely. You could use http://git.centos.org/ instead of srpms I guess. The primary difference in my mind is the public availability of patches.

GRsecurity violating GPLv2 themselves by prohibiting redistribution

Posted Jun 1, 2016 20:12 UTC (Wed) by jspaleta (subscriber, #50639) [Link] (14 responses)

well... grsecurity is still making patches available as part of their testing branch right? As stated in the announcement. I'm currently assuming that this patchset superset of what is in their official production releases to customers, and the production ready releases are some culled subset based on some sort of internal QA process.

So it looks very similar to the RH/CentOS sources. Its not clear to me that you can reproduce exactly what RedHat ships from the CentOS sources. You can get all the patches RH commits to the source tree..yes... but what is in the CentOS sources could easily be a superset of what is actually QA'd and shipped in RH srpms.

Again this looks really similar.

-jef

GRsecurity violating GPLv2 themselves by prohibiting redistribution

Posted Jun 1, 2016 20:34 UTC (Wed) by rahulsundaram (subscriber, #21946) [Link] (6 responses)

> Its not clear to me that you can reproduce exactly what RedHat ships from the CentOS sources.

Well, it is ABI and API compatible and afaik, there isn't real source changes aside from branding and minor configuration. So I am not really sure it is the same situation.

GRsecurity violating GPLv2 themselves by prohibiting redistribution

Posted Jun 1, 2016 20:37 UTC (Wed) by mjg59 (subscriber, #23239) [Link] (5 responses)

What difference does public source availability make here? If they're distributing under 3(a) then there's no obligation to provide source to the general public.

GRsecurity violating GPLv2 themselves by prohibiting redistribution

Posted Jun 1, 2016 21:01 UTC (Wed) by rahulsundaram (subscriber, #21946) [Link] (4 responses)

They can be compliant with the license but have a different end result for the general public compared to RHEL. That is the conversation.

GRsecurity violating GPLv2 themselves by prohibiting redistribution

Posted Jun 1, 2016 21:10 UTC (Wed) by mjg59 (subscriber, #23239) [Link] (3 responses)

The conversation was about whether what they were doing was a GPL violation or not. Red Hat's behaviour seems like the obvious comparison in the absence of any difference that's relevant to the license conditions.

GRsecurity violating GPLv2 themselves by prohibiting redistribution

Posted Jun 1, 2016 21:27 UTC (Wed) by rahulsundaram (subscriber, #21946) [Link] (2 responses)

This subthread of the conversation is about whether the situation is similar to RHEL since this was a question posted earlier in the thread. I was responding to that specifically.

GRsecurity violating GPLv2 themselves by prohibiting redistribution

Posted Jun 1, 2016 21:28 UTC (Wed) by mjg59 (subscriber, #23239) [Link] (1 responses)

…from the perspective of whether it's a GPL violation or not.

GRsecurity violating GPLv2 themselves by prohibiting redistribution

Posted Jun 1, 2016 22:22 UTC (Wed) by rahulsundaram (subscriber, #21946) [Link]

I wasn't reading it the same way. I was just answering the question on whether this is different from RHEL.

GRsecurity violating GPLv2 themselves by prohibiting redistribution

Posted Jun 1, 2016 20:42 UTC (Wed) by zdzichu (subscriber, #17118) [Link] (6 responses)

From my understanding, public patcheset is _subset_ of paid patchset. Paid version has more features.
GRSecurity is threating to revoke access to paid (more featureful) version for people who would like to use license's (GPL) features to share paid patchset with others.

GRsecurity violating GPLv2 themselves by prohibiting redistribution

Posted Jun 1, 2016 20:48 UTC (Wed) by Felix (guest, #36445) [Link] (2 responses)

still from a license perspective (IANAL) this shouldn't matter. The GPL requires that all receivers of a binary (e.g. paying customers) also get the source code under the terms of the GPL. It seems (see RHEL) as if it is legal not to renew support contracts in case the customer shares the source under the GPL.

Red Hat is still pretty helpful as they share some form of their source code publicly but that should matter with regards to the GPL.

I have my own gripes with grsecurity but I fail to where the GPL violation is with regards to the OP.

GRsecurity violating GPLv2 themselves by prohibiting redistribution

Posted Jun 1, 2016 21:32 UTC (Wed) by mjg59 (subscriber, #23239) [Link] (1 responses)

> The GPL requires that all receivers of a binary (e.g. paying customers) also get the source code under the terms of the GPL.

This is slightly inaccurate in a way that tends to cause confusion. When you perform commercial distribution under GPLv2, you have two options:

1) Provide the source code alongside the binaries
2) Provide the source code to anyone who asks, whether they got binaries or not

In this case it's basically irrelevant because (as far as my understanding goes) they're providing the source code itself to customers, and so GPLv2 section 3 doesn't apply.

GRsecurity violating GPLv2 themselves by prohibiting redistribution

Posted Jun 2, 2016 8:22 UTC (Thu) by paulj (subscriber, #341) [Link]

Right, but this isn't about whether the vendor is required to make these things available to Joe Public, but whether the vendor can then restrict their customers from exercising their GPL rights to redistribute the source onward by making them choose between support and their GPL rights.

GRsecurity violating GPLv2 themselves by prohibiting redistribution

Posted Jun 1, 2016 21:54 UTC (Wed) by spender (guest, #23067) [Link] (2 responses)

This is not true whatsoever. The publicly available test patches always contain the latest features and research. But I suppose these are the "understandings" a person would come to when they get their information from lying internet trolls. The particular lie you're referring to involves someone complaining about the stable patches having a version of the size_overflow GCC plugin that is more "stable" (fewer false positives) because it also has much less code coverage. The only reason for this is that the test patches, being based off the latest Linux kernel, always have the latest (sometimes experimental) security features. In this case the size_overflow plugin received a large update recently in the test patches that allowed it to follow data flow through structure fields for use in detecting size-related integer overflows.
Only in the free software "community" would jerks complain about getting the latest security advances for free.

Please stop blindly repeating misinformation.

-Brad

GRsecurity violating GPLv2 themselves by prohibiting redistribution

Posted Jun 2, 2016 6:22 UTC (Thu) by zdzichu (subscriber, #17118) [Link]

I'm sorry if I my knowledge of grsecurity patchsets was wrong. I did not meant to spread misinformation.

GRsecurity violating GPLv2 themselves by prohibiting redistribution

Posted Jun 2, 2016 9:50 UTC (Thu) by nix (subscriber, #2304) [Link]

Only in the free software "community" would jerks complain about getting the latest security advances for free.

Boy oh boy, you haven't been paying attention to the amount of whining that comes from proprietary software's users much.