Stories
Slash Boxes
Comments

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: 3, Insightful) by Thexalon on Thursday July 06 2017, @05:55PM (5 children)

    by Thexalon (636) on Thursday July 06 2017, @05:55PM (#535800)

    "those who do the work should be getting paid for it."

    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.
    Starting Score:    1  point
    Moderation   +1  
       Insightful=1, Total=1
    Extra 'Insightful' Modifier   0  
    Karma-Bonus Modifier   +1  

    Total Score:   3  
  • (Score: 2) by requerdanos on Thursday July 06 2017, @06:33PM

    by requerdanos (5997) Subscriber Badge on Thursday July 06 2017, @06:33PM (#535824) Journal

    "those who do the work should be getting paid for it."

    If they want to do that, they can make their own proprietary stuff.

    Or make really hardened, security-filled BSD kernels.

  • (Score: 0) by Anonymous Coward on Thursday July 06 2017, @07:17PM (3 children)

    by Anonymous Coward on Thursday July 06 2017, @07:17PM (#535836)

    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)

      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.

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

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

        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?