LWN: Comments on "Grsecurity stable patches to be limited to sponsors"

GRsecurity violating GPLv2 themselves by prohibiting redistribution

flussence — Thu, 02 Jun 2016 20:53:18 +0000

>Don't feed the trolls
I have absolutely no reservations about putting aside my flame grilling to emphasise this.

That's definitely him, the way those messages are crafted sticks out like a sore thumb.

GRsecurity violating GPLv2 themselves by prohibiting redistribution

nix — Thu, 02 Jun 2016 09:50:13 +0000

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.

GRsecurity violating GPLv2 themselves by prohibiting redistribution

paulj — Thu, 02 Jun 2016 08:22:28 +0000

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

zdzichu — Thu, 02 Jun 2016 06:22:01 +0000

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

anselm — Thu, 02 Jun 2016 01:00:44 +0000

The GPL governs the conditions under which you're allowed to distribute the code, and the support contract governs the conditions under which grsecurity is prepared to provide you with support and updates for the code. The two are completely separate legal agreements that deal with different services, and there is no magic connection between the two.

This means that the support contract does not impinge on your rights under the GPL. The GPL gives you the right to take the grsecurity source code (which is provided under the GPL) and pass it on to whomever you wish as long as you do it within the confines of the GPL. But whether you like it or not, if the support contract contains language to that effect, it is absolutely grsecurity's privilege to cancel it if they catch you passing on their code. This is a support issue and has no bearing on the GPL; if your support contract is cancelled, you still get to use and distribute the code that you already have under the GPL, even though you forfeit the right to support and further updates. The GPL doesn't care.

In summary, however distasteful and contrary to the spirit of Linux software development it may seem to some, the grsecurity folks are under no obligation to give anyone anything for free. If you don't like their behaviour or the terms of their support contract, don't buy their stuff.

GRsecurity violating GPLv2 themselves by prohibiting redistribution

rahulsundaram — Wed, 01 Jun 2016 22:22:12 +0000

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

spender — Wed, 01 Jun 2016 22:01:48 +0000

Don't feed the trolls -- these ridiculous allegations are from one person only. I believe this particular troll to be the well-known MikeeUSA (he uses many fake names and posts under many different usernames):
http://geekfeminism.wikia.com/wiki/MikeeUSA
http://geekfeminism.wikia.com/wiki/Debian_and_LinuxChix_h...
https://geekfeminism.org/2009/10/08/psa-mikeeusas-hate-sp...
https://soylentnews.org/article.pl?sid=15/09/07/040206

etc etc. He was quite vocal last year and for whatever reasons seems to have cropped up again just recently with posts today on LKML and then on reddit, with the same delusions and completely incorrect ideas about the GPL.

-Brad

GRsecurity violating GPLv2 themselves by prohibiting redistribution

spender — Wed, 01 Jun 2016 21:54:00 +0000

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

mjg59 — Wed, 01 Jun 2016 21:32:41 +0000

> 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

mjg59 — Wed, 01 Jun 2016 21:28:01 +0000

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

GRsecurity violating GPLv2 themselves by prohibiting redistribution

rahulsundaram — Wed, 01 Jun 2016 21:27:09 +0000

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

mjg59 — Wed, 01 Jun 2016 21:10:26 +0000

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

rahulsundaram — Wed, 01 Jun 2016 21:01:22 +0000

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

Felix — Wed, 01 Jun 2016 20:48:02 +0000

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

zdzichu — Wed, 01 Jun 2016 20:42:01 +0000

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

mjg59 — Wed, 01 Jun 2016 20:37:08 +0000

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

rahulsundaram — Wed, 01 Jun 2016 20:34:09 +0000

> 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

jspaleta — Wed, 01 Jun 2016 20:12:17 +0000

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

rahulsundaram — Wed, 01 Jun 2016 19:28:42 +0000

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

jspaleta — Wed, 01 Jun 2016 18:48:45 +0000

I thought the red hat was no longer publicly making available signed srpms, post acquisition of CentOS....
ref: http://ftp.redhat.com/pub/redhat/linux/enterprise/7Client...

And... its not clear to me that support customers can publicly share the signed srpms available via the customer portal without breaching the terms of the support contract. I think things changed in the rhel7 timeframe. You might want to double check how the support contract terms intersect with the signed srpm redistribution now. I think because they are "signed" srpms, they are treated the same way as the signed binaries in terms of support contract value add, with the same contract breach conditions if someone redistributes them publically.

I can't find rhel kernel srpms for example. I can certainly find CentOS kernel srpms, and I can rebuild unsigned srpms from the referenced git repository...but official, signed, red hat srpms for rhel7... are not publically available afaict...which corroborates the idea that support contract doesn't allow them to be redistributed. So at present the GRsecurity situation may be more similar than you have stated in the previous post.

-jef

GRsecurity violating GPLv2 themselves by prohibiting redistribution

rahulsundaram — Wed, 01 Jun 2016 16:49:30 +0000

> How is that different from a RHEL contract - which is assumed to be GPL compliant?

Red Hat provides srpms which includes the source of all patches. So GRsecurity policy appears to be different if the patches are never available to non-customers. SFC or FSF would need to be contacted if a GPL violation is suspected.

GRsecurity violating GPLv2 themselves by prohibiting redistribution

Felix — Wed, 01 Jun 2016 16:40:10 +0000

> There are allegations that GRsecurity has gone way beyond just not publicly distributing their patches. Now it seems GRsecurity is threatening their customers with a non-renewal of their support contract if the customers in turn redistribute the patches:

How is that different from a RHEL contract - which is assumed to be GPL compliant?

GRsecurity violating GPLv2 themselves by prohibiting redistribution

nealmcb — Wed, 01 Jun 2016 16:14:09 +0000

There are allegations that GRsecurity has gone way beyond just not publicly distributing their patches. Now it seems GRsecurity is threatening their customers with a non-renewal of their support contract if the customers in turn redistribute the patches:

https://lists.ubuntu.com/archives/ubuntu-devel-discuss/20...
https://lists.ubuntu.com/archives/ubuntu-devel-discuss/20...
https://lists.ubuntu.com/archives/ubuntu-devel-discuss/20...

Are any customers (or prospective customers) willing to confirm this and help us protect the underlying GPLv2 protection of the kernel, by sharing any written agreements from GRsecurity that may violate GPLv2 section 6 or 7, or re-distributing and if necessary suing?

Grsecurity stable patches to be limited to sponsors

RCL — Sun, 20 Sep 2015 16:49:35 +0000

> So.. you're saying that my customers can't sell *what they're already selling* because it incorporates software that is not BSD based? Or are you saying that I can't sell the software *that I'm already selling* because it's not BSD-based?

I am saying that with licenses other than GPL, you could find ways to be better protected from someone repackaging and selling your software while adding little or no value to it at all.

I guess selling GPL software can work for certain markets where software itself is not the key component of the solution, but I fail to see how complicated software that requires extensive R&D (like https://www.youtube.com/watch?v=3ugVuyCXjss) could be developed under that model in a sustainable way.

But I agree it's time to end this discussion. Have a nice day.

Grsecurity stable patches to be limited to sponsors

pizza — Sun, 13 Sep 2015 18:50:25 +0000

>> They don't do it out of altruism; they do it because this approach leads to a greater ROI than their alternatives. In the process, they benefit, I benefit, and everyone else benefits in the form of a greater, more useful, body of software.

> Exactly, but they would be better off opening it on BSD terms, because that way they can still sell the final product.

So.. you're saying that my customers can't sell *what they're already selling* because it incorporates software that is not BSD based? Or are you saying that I can't sell the software *that I'm already selling* because it's not BSD-based?

As I said at the outset, you're entitled to your own opinions, but you're not entitled to your own facts. Good day.

Enough?

corbet — Sun, 13 Sep 2015 18:28:41 +0000

OK, so comparing the FSF to the Taliban might not constitute a proper, technical invocation of Godwin's Law, but it's getting pretty close. Maybe it's about time for this discussion to wind down?

Grsecurity stable patches to be limited to sponsors

RCL — Sun, 13 Sep 2015 18:03:14 +0000

Indeed, these products tend to be both commercial and proprietary. E.g. feature requests in clang are addressed more readily by particular vendors that provide a flavor of it and only then bubble up upstream. __attribute__((optnone)) is a good example.

Grsecurity stable patches to be limited to sponsors

RCL — Sun, 13 Sep 2015 17:46:08 +0000

> I'll repeat myself yet again -- the FSF takes pains to state that folks are free to chose whatever license they want for their own software. They strongly believe that many of those choices are unethical, do their best to present a compelling case, and put their money where their mouth is by writing a considerable body of software via methods they consider ethical.
> Ignoring the false equivalacies with the NRA, you're still claiming that advocating for something somehow forces or imposes it upon you. By that same token, what you are I are writing here is also fanatical imposition or coercion.

No; I am saying that FSF is advocating for destroying our trade, and that destructive angle puts them on the same shelf as NRA, Taliban and such. They sincerely believe that somehow limiting the contractual freedom that exists between software vendor and software user, the freedom that allows you to license software in a way that provides a sustainable monetary feedback and prevents your users from re-releasing it with little to no effort, will somehow make the software more "free".

Gladly, FSF were largely unsuccessful in their crusade against "proprietary" software.

> Ah, I am beginning to see the underlying flaw in your assumptions -- The bulk of software market consists of stuff that is not sold to the general public. Most programmers are employed writing or customizing software for internal, non-public use (eg business middleware, stuff to power web services, internal IT stuff, and the like).

I frankly question that - even if you argue that the most software is not sold in retail, it is still being licensed to its customers in a way that provides a monetary reward for making the software itself available, and not just services around it. E.g. when you license a business-to-business software you will have a per-seat and/or per-user pricing (sometimes per-CPU or per-core).

That changes nothing for the purposes of our discussion since GPL would not allow such an arrangement. GPL makes it impossible for you to get money (in a sustainable way, excluding donations and sponsorship) for writing the software itself, so it is destructive to our core trade.

> LOLwut? You just said that "Linux the kernel" is mostly commercial, yet every single one of those contributing vendors incorporates GPL code into their products, which they presumably sell for a profitable amount of money. On the same token, all of my former employers have sold products incorporating GPL code -- and have had no difficulty complying with the license terms while making a buck or three.

Commercial developers around the kernel do not "sell" the kernel at large, they sell services built around the OS. A few that do sell the OS themselves (Red Hat, Google, firmware vendors), jump through hoops to satisfy GPL and would be happier if the kernel was BSD-licensed.

> Also, where do you think said BSD code comes from? The same arguments you are making against writing/releasing copyleft stuff applies even more so to writing/releasing any source code at all, preculding the very existence of BSD-licensed source code.

No. There is still value in making your code open to others for reviews and improvements. Companies do open up their code base for this reason; however, BSD and custom licenses allow you to regulate how much of the code base you prefer to be developed in-house and how much you want to make open.

> They don't do it out of altruism; they do it because this approach leads to a greater ROI than their alternatives. In the process, they benefit, I benefit, and everyone else benefits in the form of a greater, more useful, body of software.

Exactly, but they would be better off opening it on BSD terms, because that way they can still sell the final product.

> You fail to see that those freedoms are equivalent -- they enable enthusiasts to become amateurs, and enable amateurs to become professionals. My own career is demonstration that this is not a theoretical benefit -- My involvement in copyleft software has directly led to all but one of my day jobs.

You sound as if GPL were the only means to achieve it. Before and after GPL companies made their code available to hobbyists for many reasons, including evangelism of their technology. If GPL were to die today, nothing would change in that regard - you would still be able to hack on OS kernels (Darwin), improve compilers or mod your favorite games. Copyleft is not an enabler of that; vice versa, it makes your intellectual property vulnerable to someone who will simply repackage your effort.

Grsecurity stable patches to be limited to sponsors

rahulsundaram — Sun, 13 Sep 2015 17:41:51 +0000

>I am quite often on a receiving end of commercial products. Escalating issues with the vendor works way far more often than it does with FOSS.

Did you mean proprietary products here? FOSS != non-commercial.

Grsecurity stable patches to be limited to sponsors

RCL — Sun, 13 Sep 2015 17:16:46 +0000

Working feedback to vendor is more important than one-time guarantees.

Grsecurity stable patches to be limited to sponsors

RCL — Sun, 13 Sep 2015 17:15:16 +0000

I am quite often on a receiving end of commercial products. Escalating issues with the vendor works way far more often than it does with FOSS.

Of course, this may depend on the company size and I suspect that if I were escalating issues as a singular end user and not in my employer's name they might have been prioritized differently, but that is expected: end users outnumber developers 99 to 1, no project - FOSS or commercial - can address all their needs at the same priority (and, no, most users cannot fix the issue by themselves in a FOSS product).

So in practice: with commercial products you have at least some feedback mechanism, while with FOSS, if you cannot fix the issue yourself (which may be because you simply don't have time, not just because you lack skills), you won't see the fix in reasonable time.

Most of the bugs I filed against FOSS products (SDL being an exception) are still open. They might have been fixed in practice, but there's no QA pipeline in place to verify that for each new release; unlike commercial vendors, FOSS don't seem to have resources to conduct regular bug scrubs.

Grsecurity stable patches to be limited to sponsors

RCL — Sun, 13 Sep 2015 17:01:09 +0000

Indeed, I cannot find any public references as to what they use for compiling Android, however I see inclusion of clang in the NDK and switch of some Google software to it as a clear indication of the direction.

Also, lldb is being preferred to gdb, for which I was able to find a public reference: http://tools.android.com/tech-docs/android-ndk-preview

Grsecurity stable patches to be limited to sponsors

pizza — Sun, 13 Sep 2015 12:07:26 +0000

> That is exactly why I said what I said: I will believe it when distributions move. Because they will move to using CLANG the day it is actually, technically better than GCC.

Clang is already technically superior than GCC for many purposes -- Most prominently being its considerable advantage over GCC in C++ compile times (for roughly equivalent code size and performance). LLVM/Clang is also a much nicer codebase to work with, with a more modular internal structure, and is much easier to embed. This opens up entire classes of uses that are nearly impossible to do with GCC -- the fact that pretty much every graphics stack (F/OSS or otherwise) now uses LLVM to compile shaders and whatnot is a testament to that.

I know there are several efforts in play to utilize Clang by the major distributions, but that effort is focused more on uncovering subtle bugs that just happen to be hidden by what basically amounts to a compiler monoculture, and to a lesser extent finding ways in which Clang can be improved. There is no real desire to get rid of/replace GCC outright (outside of the big commercial concerns that are pumping so much money into LLVM, that is. You really must ask yourself why they're doing this, and what it means for you as a developer and/or an end-user..).

While I'm personally glad LLVM/Clang exists and has matured so rapidly, I'm disappointed that so much of the "enthusiasm" surrounding it is solely due to its licensing allowing proprietization and rabid hatred of anything to do with the FSF and its GPL. In doing so, they are enthusiastically acting against their own long-term interests, and proud of it.

Grsecurity stable patches to be limited to sponsors

jospoortvliet — Sun, 13 Sep 2015 06:54:02 +0000

You might not be aware of this but the people USING tools at big companies and open source communities are all 'professionals'. The difference is that decisions in Debian and other distributions are MADE by these professionals, while the decisions at G/A/F/M and so on are made by their management, usually for reasons that have little to do with quality, performance or anything like that.

That is exactly why I said what I said: I will believe it when distributions move. Because they will move to using CLANG the day it is actually, technically better than GCC. Unlike Apple, Google and others who would move for business reasons or reasons related to sales, relationships between individuals within the companies and so on. If you have been exposed to decision making in large companies you would know, for sure...

Grsecurity stable patches to be limited to sponsors

oldtomas — Fri, 11 Sep 2015 11:20:21 +0000

> It looks to me like they are not just trying to control modifications to the patches, but also any other [p]atches applied to the same code [...]

As far as I understand it -- no. They are just trying to control the use of their trademark (which I think is understandable).

Wind River can take the code and patch it all the way to Times Square and back (courtesy of the GPL), but they aren't allowed to say "lookee, grsecurity inside" (strictly speaking it isn't). That sounds pretty sane to me?

Grsecurity stable patches to be limited to sponsors

lsl — Tue, 08 Sep 2015 17:36:32 +0000

> Most importantly, commercial products are being QA'd since they come with guarantees

What kind of software comes with guarantees that are actually worth a shit?

Grsecurity stable patches to be limited to sponsors

nye — Mon, 07 Sep 2015 16:49:39 +0000

I was wondering about that too. It is specifically talking about the Chrome build for Android though, and it seems like a reasonable - if not particularly safe - assumption that it's built using the NDK and can therefore be used to infer something about the NDK, maybe.

Grsecurity stable patches to be limited to sponsors

pizza — Mon, 07 Sep 2015 14:39:11 +0000

> It is unreasonable to expect everyone to regularly update their versions, GPL'd or BSD'd, or contribute their patches upstream. This is another point that makes GPL moot - do you really need a tarball with some 2.4.x kernel used by someone in their firmware, heavily hacked to match their custom hardware? What value does that bring?

I agree that's unreasonable to expect everyone to regularly update things. I also agree that upstreaming may or may not make commercial sense based on the ROI (FWIW it usually does in the long run, but hardly any commercial enterprise concerns themselves with the long run any more...)

However, putting aside the legal requirement for full corresponding source to a shipped binary Linux kernel image, having a proper source tarball means that *someone else* can upstream or support things long after the manufacturer has lost interest. This includes not only new features, but fixing security vulnerabilities.

This kind of thing is the entire premise of DD-WRT, OpenWRT, Cyanogen, and countless other efforts that tend to result in a far superior product to what was orginally shipped, and is effectively impossible without the source code for the supposedly-open bits.

Your "makes the GPL moot" assertion is actually one of the strongest arguments of why the GPL's copyleft ideals are a pragmatic thing in practice.

Grsecurity stable patches to be limited to sponsors

pizza — Mon, 07 Sep 2015 14:26:19 +0000

>> And last I checked, Android's NDK still uses GCC
> Matter of time; they switched: https://www.phoronix.com/scan.php?page=news_item&px=M...

Um, I respectfully suggest you actually read the articles you reference.

That article says that now google uses LLVM to compile *CHROME* for production release builds. It does not apply to the rest of ChromeOS (aka heavily customized Gentoo), nor does it apply to Android.

Grsecurity stable patches to be limited to sponsors

pizza — Mon, 07 Sep 2015 14:24:14 +0000

> Most importantly, commercial products are being QA'd since they come with guarantees,

HAHAHAHAHA

I can tell you've never been on the receiving end of any commercial product.