Slash Boxes

SoylentNews is people

posted by n1 on Thursday July 06 2017, @11:39AM   Printer-friendly
from the to-hell-with-gpl dept.

Bruce Perens warns of potential contributory infringement and breach of contract risk for customers of GRSecurity:

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.

Original Submission

This discussion has been archived. No new comments can be posted.
Display Options Threshold/Breakthrough Mark All as Read Mark All as Unread
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
  • (Score: 4, Interesting) by Thexalon on Thursday July 06 2017, @08:14PM (2 children)

    by Thexalon (636) on Thursday July 06 2017, @08:14PM (#535850)

    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...).

    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."

    If violating the GPL means more devs get paid fairly for their work, then so be it.

    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.

    2. For companies like Red Hat that control the mainlining process

    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.

    Alcohol makes the world go round ... and round and round.
    Starting Score:    1  point
    Moderation   +2  
       Interesting=1, Informative=1, Total=2
    Extra 'Interesting' Modifier   0  
    Karma-Bonus Modifier   +1  

    Total Score:   4  
  • (Score: 0) by Anonymous Coward on Thursday July 06 2017, @09:42PM

    by Anonymous Coward on Thursday July 06 2017, @09:42PM (#535892)

    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. []

    With kernel, the minions tried to push kdbus. [] (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. [] It seems RH has plans half done for when the current one fails. [] "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

    by Arik (4543) on Thursday July 06 2017, @09:47PM (#535894) Journal
    RedHat does not have veto power, you're correct.

    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?