4 ms·

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

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.
- peterwwillis 9y ago
  Distribute changes, it's all GPL. Don't distribute changes, it's whatever you want it to be. This does not change depending on how "distinct" your change is.
  - cyphar 9y ago
    I'd argue that the code is always GPL, it's just that if you don't distribute it then the GPL doesn't have any restrictions.
derefr 9y ago
> You don't even have to accept the terms of the GPL just to run the program. Why do so many pieces of FOSS software—especially in their Windows or macOS distributions—have clickwrap that makes me accept the GPL to install them? Are they just misinformed?
- dragonwriter 9y ago
  > Why do so many pieces of FOSS software—especially in their Windows or macOS distributions—have clickwrap that makes me accept the GPL to install them? Are they just misinformed? Misinformed, or just using installer tools that have a slot for an EULA, so they just stick whatever license applies to the software even if it is expressly not intended to be a use license in without thought.

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.
peterwwillis 9y ago
Distribute changes, it's all GPL. Don't distribute changes, it's whatever you want it to be. This does not change depending on how "distinct" your change is.
- cyphar 9y ago
  I'd argue that the code is always GPL, it's just that if you don't distribute it then the GPL doesn't have any restrictions.

derefr 9y ago

> You don't even have to accept the terms of the GPL just to run the program. Why do so many pieces of FOSS software—especially in their Windows or macOS distributions—have clickwrap that makes me accept the GPL to install them? Are they just misinformed?

dragonwriter 9y ago
> Why do so many pieces of FOSS software—especially in their Windows or macOS distributions—have clickwrap that makes me accept the GPL to install them? Are they just misinformed? Misinformed, or just using installer tools that have a slot for an EULA, so they just stick whatever license applies to the software even if it is expressly not intended to be a use license in without thought.