Follow Slashdot stories on Twitter

 



Forgot your password?
typodupeerror

Comment Re:Please Read The Entire Statement (Score 1) 474

I just copied Eben again this morning, as I'd received a copy of the Grsecurity Stable Patch Access Agreement, which I had not previously had in hand. I also included another link to my article. No word from Eben yet.

While the user may not be responsible for the sins of the distributor, this is only the case after the distributor successfully conveys the GPL to the user upon the work. I contend that the distributor never had the right to convey the GPL to the user at all upon an infringing derivative work, and that a direct grant by the kernel developers to the user is thus never triggered.

Also, keep in mind that if the user does successfully receive the GPL on a work, they must be fully in compliance (section 4) for the GPL to continue. If the "sins" of the distributor are repeated by the user, the user is not in compliance. The point here is that the user need not pay for a "sin" which they do not repeat, nor may the distributor perform a deliberate action which terminates the user's GPL rights unless the user repeats that action.

When the user receives the infringing derivative work, and when the user applies the patch, they inherit the previous infringement from the distributor. The GPL does not wash clean that infringing status for the user.

Comment Re:Please Read The Entire Statement (Score 2) 474

No. Merely purchasing the existing combination of code does not provide the required right and ability to supervise or control the infringing activity. You are well outside the bounds of your expertise, and it shows.

In this case, it's the reverse. I understand how the software is applied (this is why I'm an expert witness in demand) and you're out of your expertise, sorry. The customer applies the patch. That gives them control of the infringing activity.

Those portions of the original work have been licensed to the customers by the GPLv2 sec 6. The license to those portions of the original work cannot be terminated per GPLv2 sec 4. The customer is also expressly licensed to make such a combination by GPLv2 sec. 2 so long as they do not publish or distribute the combined work.

Weren't you going to ask Eben about this? Why don't you do so, and get back to me. I still don't believe they're licensed.

By the way, I got the Grsecurity agreement. They actually put down in writing how they restrict the customer's GPL rights.

Comment Re:Please Read The Entire Statement (Score 1) 474

Because the GPL doesn't apply to the infringing derivative work, as it terminated when it was not complied with, and Open Source Security, Inc. doesn't have a right to license it to others or to apply the GPL to it. So, the customers have a work with no valid license and the kernel developers own the only remedy that would permit its legal use.

If the customers had the GPL on that work, distribution might be relevant. They don't. Also keep in mind that distribution is not the only thing you can do to violate the GPL. You can create a derivative work that is in violation even before distribution.

Comment Re:Please Read The Entire Statement (Score 2) 474

Which means that the original developers cannot properly sue the customers for infringement or breach of contract concerning use of the Linux kernel. Check. You've now admitted that there's no basis for liability absent a customer's own violation of the GPL.

I admitted no such thing. And telling me what I admitted, when I haven't, is a rhetorical trick, not argument.

Grsecurity is an unlicensed derivative work and it's owned in part by the kernel developers because it necessarily includes portions of the original work. The GPL does not apply to it at all. The fact that the user has the GPL for some other copy of a Linux kernel does not license the infringing derivative work to the user. Nor does it grant Open Source Security Inc. the ability to convey the GPL for that work.

But the original developers do not own Grsecurity's modifications.

Actually, they do! Not the whole thing, but the derivative work necessarily incorporates a significant portion of the original work, and this is definitely true for the patch format used. The GPL doesn't apply to that copy as its terms were not honored, and OSS never had a right to convey the GPL originally on that copy. A GPL conveyed by someone else for another copy of Linux does not apply to the infringing derivative work. Grsecurity has no right to distribute it at all. The Linux kernel developers own the only remedy that will make its legal use possible.

Termination of the kernel license to Grsecurity does not affect the rights of their customers, or any other users, per GPLv2 secs. 4 and 6.

It does indeed if Grsecurity never had the right to convey the GPL on that work to the users in the first place. You can't convey it on a derivative work without a license from the owners of the work it was derived from. Grsecurity did not have that license because they did not comply with it.

Denied. You have not explained how Grsecurity cannot license its own modifications under the GPL, nor how anyone other than Grsecurity could sue users for using those modifications. You have admitted that customers and users are licensed to use the Linux kernel even if Grsecurity is not. You will have to admit that users can modify the Linux kernel if they so choose, even using non-GPLv2 modifications, so long as they do not publish or distribute the result (GPLv2 secs. 2 and 3).

OK, this one is too much. Look, I know that lawyers will try to fool the other side to win an argument. I've had it happen before. It's not going to make me accept your argument. I explained clearly where Grsecurity could not license its infringing derivative work. You're being silly to contend that anyone can license an infringing derivative work to someone else without a lot more permission than the GPL contains.

To reiterate, the customer has been licensed by the original developers for the original kernel and by Grsecurity for the modifications.

The infringing derivative work was never licensed to the customers, because Grsecurity never had a right to license it to anyone. The copies of the kernel that are under the GPL came to the customer another way, if they have any, and the fact that the user has the GPL from someone else on another copy does not automatically license the infringing derivative work to the customer.

A contributory infringer is "[o]ne who knowingly induces, causes or materially contributes to copyright infringement, by another but who has not committed or participated in the infringing acts him or herself, may be held liable as a contributory infringer if he or she had knowledge, or reason to know, of the infringement."

They have now been informed that there's a good chance of risk of contributory infringement and to check with their counsel. It's public knowledge now. They're paying for copies. That's how they become a contributory infringer.

How does the customer induce, cause, or contribute to copyright infringement by another by merely using Grsecurity's product? For that matter, how does a customer breach the GPL merely by using Grsecurity's product?

By knowingly entering in a contract to acquire an infringing derivative work.

Comment Re: Linus on Grsecurity (Score 1) 474

Tridge used telnet to get to the Bitkeeper server port, and typed "HELP". That was the great crime!

Most people who understand this believe that Larry over-reacted.

My personal conclusion was that Larry made things much worse for himself with his own behavior. I hope he learned something and is doing better now.

Comment Re:Please Read The Entire Statement (Score 2) 474

OK, if you're a real lawyer, I have no problem arguing law with you. I've won against folks who were admitted to the supreme court before.

The license granted to the customer certainly has not terminated.

The customer has that license for the kernel. They do not have that license for Grsecurity, because Grsecurity's license to the kernel terminated, and Grsecurity did not have the right to grant the GPL to the customer for an infringing derivative work. If Grsecurity was an independent work rather than derivative, it would have been different.

This belongs to a class of arguments I see very frequently, in which the defendant has not complied with the GPL but repeatedly offers the language of the GPL in their defense as if they get to cherry-pick the terms they like.

Sure, refer it to Eben. He's already been copied and has so far not chosen to differ. Richard chose not to be involved because he felt Grsecurity would not listen to him, and he has bigger fish to fry.

Comment Re:Not related to their mark (Score 1) 474

I think there is lots of room for people to make security patches to the kernel, and for them to do them one at a time and get the kernel team to accept them. They belong in the mainline, not a patch.

If they need some special subsystem to support them, they should put that in the form of as small a patch as possible, get the kernel team to accept that, and then to make individual patches that make use of that facility.

In contrast, Grsecurity is a big patch built up over years, and I hear not always a careful one.

It is difficult to get the kernel team to accept things. That is not a misfeature. They set really high standards, not just that the code works but that it's easy to read and review, is modular and does not put dirty fingers all over the kernel, and is well-architected according to the esthetic style of the kernel developers. Not everything meets those standards, and because there's an esthetic style it's sometimes down to personal style of the programmer and not everyone fits. But that's still not a misfeature.

Slashdot Top Deals

"It says he made us all to be just like him. So if we're dumb, then god is dumb, and maybe even a little ugly on the side." -- Frank Zappa

Working...