5 ms·

How does this work at a licensing level? GRSecurity are patches to the Linux kernel right? Can you distribute patches for a GPL licensed software without the

How does this work at a licensing level? GRSecurity are patches to the Linux kernel right? Can you distribute patches for a GPL licensed software without the patches themselves being GPL?

gbuk2013 9y ago
Of course you can. https://01.org/linuxgraphics/gfx-docs/drm/admin-guide/tainted-kernels.html https://01.org/linuxgraphics/gfx-docs/drm/admin-guide/tainte... Edit: --- Good point about the distinction between adding modules modifying existing source. It is an interesting question, actually and I haven't been able to find an authoritative answer on the subject. A patch is a description of changes that would be made to a work, if they were made. Does it trigger the licence before it is applied to the source tree? On the other hand to generate a patch you would require the original source (even if you write it by hand you would still have to look at the source to determine line numbers). An you will probably have some bits of the source in your diff, but they are not being used for anything other than position information.
- chamakits 9y ago
  Ah I see. So as long as they don't distribute the patch together with the GPL base codebase, they are good. Does that sound right?
  - peterwwillis 9y ago
    This only applies to LKMs which use non-GPLv2-only symbols. If you change half the kernel, you are creating a derivative work, and it is therefore GPLv2.
- lvh 9y ago
  grsecurity's patch set is significantly more involved than a single module.
- mrsteveman1 9y ago
  That's not the same thing at all. The 'P' taint flag exists because upstream kernel maintainers aren't interested in dealing with bug reports where the bug may have been caused by proprietary code loaded by end users, which often can't be examined or copied even for the purpose of discussing the bug. Total waste of time, so the flag makes those cases obvious to anyone reading the bug report. The user can be told upfront to remove the proprietary code and try to reproduce the bug again. End users can combine proprietary code with GPL code if they want to, because end users aren't bound by the GPL unless and until they distribute something covered by it. You don't even have to accept the terms of the GPL just to run the program[1]. A company distributing a proprietary module for the kernel may or may not be violating the GPL, depending on what it does and who you ask. In contrast to the module stuff, GRSecurity is a set of patches to very low level parts of the Linux kernel itself. It could never be licensed in a way that prevented the patch set or the resulting patched kernel source/binaries from being covered and distributed under the GPLv2. If that were the case, the kernel would effectively not be covered by the GPL at all. [1] https://www.gnu.org/licenses/gpl-2.0.en.html#section5 https://www.gnu.org/licenses/gpl-2.0.en.html#section5
  - mnarayan01 9y ago
    > It could never be licensed in a way that prevented the patch set or the resulting patched kernel source/binaries from being covered and distributed under the GPLv2. If that were the case, the kernel would effectively not be covered by the GPL at all. Is this true? I would think that as long as your "new" code is sufficiently distinct from the stuff you're replacing, you'd be fine distributing a non-GPL patch (at least if it's e.g. purely positional to elide context related issues). The result of applying the patch would not be distributable, but I'd think the patch itself would be fine.
    - jordigh 9y ago
      The FSF's position that I have heard is that these modules, e.g. the nvidia module, is a GPL violation that the Linux maintainers have no desire to prosecute. In the FSF's opinion it's likely that a judge would say that user-does-the-link is subterfuge to try to get around copyleft. On the other hand, seeing how everyone turns their back on you when you do try to prosecute GPL violations (e.g. SFC and the VMWare GPL lawsuit), I can see why the Linux maintainers don't try to enforce their copyleft. It certainly doesn't help that the Linux foundation is almost entirely run by companies that do not want the GPL to have teeth.
0xbadcafebee 9y ago
The kernel remains GPLv2, so the standard licensing issues apply: you can make changes, but if you distribute the changes, you have to provide an offer to distribute the source to the changes (and follow through with it). Those changes are then licensed under GPLv2 as well. LKMs are an exception, where code which does not use GPLv2-only symbols can remain a proprietary binary blob. (GRsec is too tightly wound into the kernel to be an LKM)
geofft 9y ago
grsec has had a commercial program for a while. The way these things tend to work is "It's GPL, but if you redistribute it publicly we terminate your subscription with no refund." (I think RHEL binaries work the same way, for instance.) The reason for companies to pay is to get reliable updates for new versions, so that they can avoid hiring a bunch of people in-house to build / forward-port things. So usually this incentive works. Now that grsec is completely unavailable without a paid subscription, either source or binary, it'd be interesting to see if the incentive holds up, or whether someone wants to burn a subscription to get a version out to the public. I imagine that they're cautious about who they allow to sign up as a customer.
- bubblethink 9y ago
  RHEL binaries are, well, binaries. A patchset like grsec is source. I don't think RHEL restricts source redistribution, which they seem to release publicly anyway.
- cryptarch 9y ago
  Is the commercial version (still) GPL'd, though? You say "burn a subscription", does that mean you assume the patchsets are earmarked? And wouln't simply... two subscriptions and a diff fix that?

How does this work at a licensing level? GRSecurity are patches to the Linux kernel right? Can you distribute patches for a GPL licensed software without the patches themselves being GPL?

gbuk2013 9y ago

Of course you can. https://01.org/linuxgraphics/gfx-docs/drm/admin-guide/tainted-kernels.html https://01.org/linuxgraphics/gfx-docs/drm/admin-guide/tainte... Edit: --- Good point about the distinction between adding modules modifying existing source. It is an interesting question, actually and I haven't been able to find an authoritative answer on the subject. A patch is a description of changes that would be made to a work, if they were made. Does it trigger the licence before it is applied to the source tree? On the other hand to generate a patch you would require the original source (even if you write it by hand you would still have to look at the source to determine line numbers). An you will probably have some bits of the source in your diff, but they are not being used for anything other than position information.

chamakits 9y ago
Ah I see. So as long as they don't distribute the patch together with the GPL base codebase, they are good. Does that sound right?
- peterwwillis 9y ago
  This only applies to LKMs which use non-GPLv2-only symbols. If you change half the kernel, you are creating a derivative work, and it is therefore GPLv2.
lvh 9y ago
grsecurity's patch set is significantly more involved than a single module.
mrsteveman1 9y ago
That's not the same thing at all. The 'P' taint flag exists because upstream kernel maintainers aren't interested in dealing with bug reports where the bug may have been caused by proprietary code loaded by end users, which often can't be examined or copied even for the purpose of discussing the bug. Total waste of time, so the flag makes those cases obvious to anyone reading the bug report. The user can be told upfront to remove the proprietary code and try to reproduce the bug again. End users can combine proprietary code with GPL code if they want to, because end users aren't bound by the GPL unless and until they distribute something covered by it. You don't even have to accept the terms of the GPL just to run the program[1]. A company distributing a proprietary module for the kernel may or may not be violating the GPL, depending on what it does and who you ask. In contrast to the module stuff, GRSecurity is a set of patches to very low level parts of the Linux kernel itself. It could never be licensed in a way that prevented the patch set or the resulting patched kernel source/binaries from being covered and distributed under the GPLv2. If that were the case, the kernel would effectively not be covered by the GPL at all. [1] https://www.gnu.org/licenses/gpl-2.0.en.html#section5 https://www.gnu.org/licenses/gpl-2.0.en.html#section5
- mnarayan01 9y ago
  > It could never be licensed in a way that prevented the patch set or the resulting patched kernel source/binaries from being covered and distributed under the GPLv2. If that were the case, the kernel would effectively not be covered by the GPL at all. Is this true? I would think that as long as your "new" code is sufficiently distinct from the stuff you're replacing, you'd be fine distributing a non-GPL patch (at least if it's e.g. purely positional to elide context related issues). The result of applying the patch would not be distributable, but I'd think the patch itself would be fine.
  - jordigh 9y ago
    The FSF's position that I have heard is that these modules, e.g. the nvidia module, is a GPL violation that the Linux maintainers have no desire to prosecute. In the FSF's opinion it's likely that a judge would say that user-does-the-link is subterfuge to try to get around copyleft. On the other hand, seeing how everyone turns their back on you when you do try to prosecute GPL violations (e.g. SFC and the VMWare GPL lawsuit), I can see why the Linux maintainers don't try to enforce their copyleft. It certainly doesn't help that the Linux foundation is almost entirely run by companies that do not want the GPL to have teeth.

0xbadcafebee 9y ago

The kernel remains GPLv2, so the standard licensing issues apply: you can make changes, but if you distribute the changes, you have to provide an offer to distribute the source to the changes (and follow through with it). Those changes are then licensed under GPLv2 as well. LKMs are an exception, where code which does not use GPLv2-only symbols can remain a proprietary binary blob. (GRsec is too tightly wound into the kernel to be an LKM)

geofft 9y ago

grsec has had a commercial program for a while. The way these things tend to work is "It's GPL, but if you redistribute it publicly we terminate your subscription with no refund." (I think RHEL binaries work the same way, for instance.) The reason for companies to pay is to get reliable updates for new versions, so that they can avoid hiring a bunch of people in-house to build / forward-port things. So usually this incentive works. Now that grsec is completely unavailable without a paid subscription, either source or binary, it'd be interesting to see if the incentive holds up, or whether someone wants to burn a subscription to get a version out to the public. I imagine that they're cautious about who they allow to sign up as a customer.

bubblethink 9y ago
RHEL binaries are, well, binaries. A patchset like grsec is source. I don't think RHEL restricts source redistribution, which they seem to release publicly anyway.
cryptarch 9y ago
Is the commercial version (still) GPL'd, though? You say "burn a subscription", does that mean you assume the patchsets are earmarked? And wouln't simply... two subscriptions and a diff fix that?