SoylentNews is people
SoylentNews
Grsecurity is a patch for the Linux kernel which, it is claimed, improves its security. It is a derivative work of the Linux kernel which touches the kernel internals in many different places. It is inseparable from Linux and can not work without it. it would fail a fair-use test (obviously, ask offline if you don’t understand). Because of its strongly derivative nature of the kernel, it must be under the GPL version 2 license, or a license compatible with the GPL and with terms no more restrictive than the GPL. Earlier versions were distributed under GPL version 2.
Currently, Grsecurity is a commercial product and is distributed only to paying customers. My understanding from several reliable sources is that customers are verbally or otherwise warned that if they redistribute the Grsecurity patch, as would be their right under the GPL, that they will be assessed a penalty: they will no longer be allowed to be customers, and will not be granted access to any further versions of Grsecurity. GPL version 2 section 6 explicitly prohibits the addition of terms such as this redistribution prohibition.
By operating under their policy of terminating customer relations upon distribution of their GPL-licensed software, Open Source Security Inc., the owner of Grsecurity, creates an expectation that the customer’s business will be damaged by losing access to support and later versions of the product, if that customer exercises their re-distribution right under the GPL license. This is tantamount to the addition of a term to the GPL prohibiting distribution or creating a penalty for distribution. GPL section 6 specifically prohibits any addition of terms. Thus, the GPL license, which allows Grsecurity to create its derivative work of the Linux kernel, terminates, and the copyright of the Linux Kernel is infringed. The contract from the Linux kernel developers to both Grsecurity and the customer which is inherent in the GPL is breached.
(Score: 5, Touché) by requerdanos on Thursday July 06 2017, @01:35PM (8 children)
The Grsecurity folks seem very mature and experienced in their kernel security measures, but alarmingly less so in other ways: Their argument is not that they simply refuse to comply on general principle--it's a very specific principle that "those who do the work should be getting paid for it." Their stand appears to be based on doing what they believe is right, not on trying to get away with doing wrong.
They complain that they made some GPL'd software, and then they got frustrated and decided to stop publicly distributing that software when other people built upon it and profited from that. This represents at a minimum a serious misunderstanding of the GPL.
They argued that they were putting in the work to make the patches, paying hosting on the servers to put the patches up for download, and doing all the really hard things, and other people who were not paying them money, were taking their software and using it and packaging it usefully and doing other profitable (but sometimes dodgy) things with it in a way that did not make them any money--and that because they put in the work to make the product, they should be getting the money.
I believe it's important to note, about their principled stand for what they believe is right, that in their talking about who put in all the hard work to build their product and who therefore should get paid, they didn't mention the estimated three billion dollars [blogspot.com] worth of labor that went into the Linux kernel itself, which their product is a nifty but relatively minor derivative of in terms of SLOC in Linux vs. their patches, nor did they mention any payments they made because of these heartfelt beliefs to, say, the Linux Foundation [linuxfoundation.org].
Science fiction writer Murray Leinster wrote [google.com] along these lines in the 1950s:
They certainly have every right to stop paying for hosting to assist other people who are profiting from their hard work, but under the GPL they don't have the right to forbid others from doing so.
(Score: 2) by kaszz on Thursday July 06 2017, @01:57PM
Which leaves the question as to when someone will sue Grsecurity? And who will do it? Who funds it?
If they aren't nice we can offer to send poettering to "help" .. :p
(Score: 0) by Anonymous Coward on Thursday July 06 2017, @02:17PM
" Their argument is not that they simply refuse to comply on general principle--it's a very specific principle that "those who do the work should be getting paid for it." Their stand appears to be based on doing what they believe is right, not on trying to get away with doing wrong."
Then they should not be touching GPL'ed software. End of story.
(Score: 3, Insightful) by Thexalon on Thursday July 06 2017, @05:55PM (5 children)
If they want to do that, they can make their own proprietary stuff. They can't take GPL'd stuff and redistribute it in the way they're doing.
I've noticed, as a general habit, that principles often follow self-interest. In GRSecurity's case, I have to think that Upton Sinclair's Law might have something to do with it: "It is extremely difficult to get a man to understand something when his salary depends on his not understanding it."
The only thing that stops a bad guy with a compiler is a good guy with a compiler.
(Score: 2) by requerdanos on Thursday July 06 2017, @06:33PM
Or make really hardened, security-filled BSD kernels.
(Score: 0) by Anonymous Coward on Thursday July 06 2017, @07:17PM (3 children)
1. You're arguing a practical & moral position ("those who do the work should be getting paid for it") against a legal polemic (under the terms of the GPL...). If violating the GPL means more devs get paid fairly for their work, then so be it. After all, the copyright law the GPL hacks around just to get some collaborative work done is inherently flawed so the GPL can't be expected to work perfectly for everything and everybody.
2. For companies like Red Hat that control the mainlining process, there's far more money to be made from keeping the kernel insecure and on a Microsoft-esque continues service&maintenance patch-cycle then actually addressing security issues at the design level in a constructive way. They have, and they will reject mainlining attempts of features that compete against their own off-tree patches. So, GRSec going away simply means a bigger company will take over and will have even more power and influence then GRSec to keep things the way they are. And if they can't keep the patches off-tree, they'll shim them with some modular design just like nVidia did for graphics so they can sell special security blobs to their private clients.
GRSec are like private security: Making them illegal won't miraculously make the police less corrupt and useless. But fixing the police will drive most private security firms out-of-business.
(Score: 4, Interesting) by Thexalon on Thursday July 06 2017, @08:14PM (2 children)
The GPL has a practical and moral position, as well as the law, behind it. It goes like this: "Software can be duplicated nearly for free, so it is best viewed not as a product but as a public body of knowledge. When you make a new discovery, it is your responsibility to put it out to the public so the body of public knowledge expands and becomes more useful."
Nonsense. Devs get paid to work on GPL'd software all the time. Some examples:
- People that work for Red Hat and IBM and such and get paid to work on improving Linux.
- People who are employed as developers or admins for a company who have to dig into a problem, find and make the fix, and contribute a patch or documentation upstream so everyone else that has the same problem doesn't have to duplicate the work. They got paid by their company.
- People who get short-term contracts to add a feature to a GPL'd package that wasn't there before but is useful to their client, who then contributes the new feature upstream.
All those devs got paid for their work. None of them did what GRSecurity did, of taking but refusing to give back. As a sibling poster pointed out, if GRSecurity wanted to play by the rules, they could have done so with BSD.
Red Hat does not control the "mainlining" process. Linus Torvalds does, and he works for the Linux Foundation. I don't know where you got the impression that Red Hat has veto power, but they've never had veto power over what goes into the mainline Linux kernel.
The only thing that stops a bad guy with a compiler is a good guy with a compiler.
(Score: 0) by Anonymous Coward on Thursday July 06 2017, @09:42PM
Redhat does not have such direct power over kernel. But tries, over and over, and goes with as much indirect control as it gets. Userspace is becoming more and more RH controlled, as discussed in a recent story. https://soylentnews.org/article.pl?sid=17/07/03/1232216 [soylentnews.org]
With kernel, the minions tried to push kdbus. https://igurublog.wordpress.com/2015/05/04/kdbus-systemds-kid-cousin-come-to-stay/ [wordpress.com] (outdated article, but "photo" of how it was two years ago)
Linus disliked how it was done and said no. Other kernel devs also raised multiple tech points. And so far it seems the kdbus is sleeping, or more probably dead just like HAL. Now the plan is bus1. https://en.wikipedia.org/wiki/D-Bus#KDBUS [wikipedia.org] It seems RH has plans half done for when the current one fails. https://github.com/bus1/bus1/blob/master/ipc/bus1/main.c [github.com] "Copyright (C) 2013-2016 Red Hat, Inc."
RH, putting the C of Corporate in FOSS. Don't worry, sooner or later it will have a C. And probably no F.
(Score: 3, Informative) by Arik on Thursday July 06 2017, @09:47PM
However they do clearly have tremendous influence, and it's not being used for good.
If laughter is the best medicine, who are the best doctors?