[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Why does no one care that Brad Spengler of GRSecurity is blatantly violating the intention of the rightsholders to the Linux Kernel?



On Tue, Jun 20, 2017 at 7:12 AM, deloptes <deloptes@gmail.com> wrote:
> Richard Stallman wrote:

I don't think you should assume RMS is monitoring the debian list.

>> I am not trying to study the GRsecurity case because (0) it's
>> complicated, and it would take a lot of time to think about, (1) the
>> FSF has no say in the matter (it is about Linux) and (2) I don't think
>> the copany would heed whatever I might say.
>
> Could you explain why it should be complicated?

I don't want to pretend to be answering for Mr. Stallman, but I have done
a small bit of reading now that I see Bruce Perens is taking the time to
get involved.

> GPL states the rights
> obtained should be passed to the recipient, so the recipient should be
> allowed to redistribute the code (IMO) even if he/she is paying for
> improvements.
>
> It would be really nice if GRSec could help improve the kernel security in
> some way acceptable by and for the benefit of all. I don't think someone
> wants to punish them for what they are doing. It would be better to have
> mutual benefit if possible as the GPL does not prohibit modifying and
> redistributing the code and demanding a fee, it however does guarantee the
> right to redistribute is passed to the recipient, which is not the case
> here.

GRSecurity has posted their complaints here:

https://grsecurity.net/announce.php

They have a point, although bending the rules is not a good way to make
your point, in general. (And I'll note that they seem to be thinking they are
following RedHat's example here. At this point I'm more than half inclined
to think they might be following RedHat's example, for what that's worth.)

TheReg's recent article

https://www.theregister.co.uk/2017/04/26/grsecurity_linux_kernel_freeloaders/

indicates they think they might know which large, well-heeled, well-
financed major embedded industry player provided the straw that broke
GRSecurity's camel's back. But it is not just one player. The entire
embedded industry does not seem to understand how their products
came to be or how their future products will come to be.

That said, GRSecurity needs to find a different way to seek redress.

And someone in the community needs to find them a lawyer who will
take their case.

The GPL is a gentlemen's agreement.

When the members of the market refuse to behave like gentlemen, it
destroys the value of the agreement. It makes the agreement useless.

It will also destroy the market, so the moneyed players who are not
paying their fair share back into supporting the "small players" are
basically shortening the life-span of their own companies -- cutting
off their own noses to spite their faces, as we used to say.

I am personally not impressed with GRSecurity's hubris. Their tech
is only impressive in that it sort of helps make up a little bit for the
serious lacks in the security of every major CPU available today,
but especially the ones from Intel. So they do make a contribution,
or have until recently.

If the OP wants to solve this problem, (s)he has done enough
rabble-rowsing this way. He needs to start asking everyone he
knows if they know a good lawyer willing to work on contingency.
The rest of us who are concerned probably should, as well.

Or, perhaps, GRSecurity should go to one of the crowdfunding
sites. Or maybe someone could start a new crowdfunding site to
specialize in providing legal relief for the small guy. (Not sure how
that would work.)

(Yeah, I am willing to name and shame Intel here. If our civilization
survives the next two decades, our children will remember Intel's
processors with the same phrase that Ralph Nader made popular
relative to the auto industry. Who can compete when Intel refuses
to pay the price of making CPUs that are unsafe at progressively
higher speeds?)

-- 
Joel Rees

One of these days I'll get someone to pay me
to design a language that combines the best of Forth and C.
Then I'll be able to leap wide instruction sets with a single #ifdef,
run faster than a speeding infinite loop with a #define,
and stop all integer size bugs with my bare cast.
http://defining-computers.blogspot.com/2017/06/reinventing-computers.html

More of my delusions:
http://reiisi.blogspot.com/2017/05/do-not-pay-modern-danegeld-ransomware.html
http://reiisi.blogspot.jp/p/novels-i-am-writing.html


Reply to: