GrSecurity Linux Kernel To Focus More On Performance This Year

[phoronix]

Phoronix: GrSecurity Linux Kernel To Focus More On Performance This Year

The GrSecurity patches to the Linux kernel have long focused on security enhancements but this year they are said to be taking on a larger focus of performance optimizations...

http://www.phoronix.com/scan.php?page=news_item&px=GrSecurity-Performance-2020

[tildearrow]

GrrrrrrrrrSecurity

Grrrrrrrrrrrrrrrr :l
More like the benefit is none...

[OneTimeShot]

Michael - Please stop posting information about GrSecurity. They do not deserve the free publicity.

They are GPL violators, and so are their customers. End of. I was hoping that Bruce Perens had bankrupted them, but it looks as though the scum are still around.

[ThiagoCMC]

So, I'm not a lawyer but, aren't they GPL violators? If yes, how can they still be around!?

[skeevy420]

GPL Violator or not, I don't support or use services that don't have a clear pricing model. "You have to contact us for pricing" is one shady business practice.

[CommunityMember]

I was hoping that Bruce Perens had bankrupted them

As I recall, it was only a quarter million dollar settlement for legal fees. Not likely to bankrupt the company.

[tchiwam]

I did implement their patches on top of Gentoo selinux and it did make a good difference. If the patches are made available to the customers I guess it's GPL compatible ?

[CommunityMember]

So, I'm not a lawyer but, aren't they GPL violators?

The needle GRSecurity is trying to thread is that they are not required to do business with anyone under the GPL, so it is a business decision, and not a GPL violation, by GRSecurity as to whom to sell their patches to (only those that agree to not redistribute the patches are deemed to be worthy of getting and maintaining a license by GRS). While there are many that believe that violates at least the spirit of the GPL, the question is whether that is a technical violation of the GPL as those companies never intended to redistribute their modified (by GRS patches) kernel, so would never be subject to the GPL source redistribution requirements. As I recall the details, Parens said it was his opinion it was a violation, which is where the lawsuit by GRS started because it threatened their business model. Some future court case would need to make the determination of an actual GPL violation, and until then, we have a lot of people with opinions.

[Guest]

Based on the GPL, GrS cannot legally forbid any of their clients from redistributing the patches. That would be a violation of GPL, and hence copyright law.

I am not a lawyer, that's just my understanding of how it works.

[reavertm]

Let me add my non-lawyer take on this (in post number 222, ha!).

GRS sells patches that are based on GPL-licensed kernel software. GRS patches are licensed with proprietary license.

If GRS patches are in Unified Diff format (git diff, format-patch, ...) then they contain up to three line context around GRS modification. Example for some unrelated patch:

index d081fb2880a0..82cf1da2ff12 100644
--- a/sound/pci/hda/hda_eld.c
+++ b/sound/pci/hda/hda_eld.c
@@ -360,7 +360,7 @@ static void hdmi_print_pcm_rates(int pcm, char *buf, int buflen)
 
       for (i = 0, j = 0; i < ARRAY_SIZE(alsa_rates); i++)
               if (pcm & (1 << i))
-                       j += snprintf(buf + j, buflen - j,  " %d",
+                       j += scnprintf(buf + j, buflen - j,  " %d",
                               alsa_rates[i]);
 
       buf[j] = '\0'; /* necessary when j == 0 */

That context is GPL-licensed kernel source.
Therefore, selling any context-based patches of the kernel constitutes selling GPL-licensed code that is protected from redistribution without source publication -> GPL violation.