Hacker News Reader

Comment by gbuk2013 | Hacker News Reader

gbuk2013

Of course you can.

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.

View on HN

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

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

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.

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.

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.

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

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

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?

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.

grsecurity's patch set is significantly more involved than a single module.

Reply on news.ycombinator.com