5 ms·
It's not DRM, the entire check basically amounts to "if (strcmp(license, "GPL") != 0)", where "license" is a user supplied string.
by cycloptic 6y ago
It's not DRM, the entire check basically amounts to "if (strcmp(license, "GPL") != 0)", where "license" is a user supplied string.
- userbinator 6y agoDRM is DRM regardless of how trivial it is to bypass. What you should really be asking yourself is why such code even exists, since it is very much against the spirit of free software. Linux(s) has the right to not accept contributions, but to effectively get in the way of others who do want to make the changes despite them being perfectly acceptable and perhaps even encouraged by the GPL just seems very wrong to me.
- pritambaral 6y ago> What you should really be asking yourself is why such code even exists I think TFA makes that abundantly clear. Repeating here for your benefit: "Symbols exported as GPL-only by the kernel are made unavailable to proprietary modules, but there has always been a bit of a loophole in how this is enforced. "Hellwig's patch does not entirely close this loophole, but it makes exploiting it a bit harder. "This episode, where a proprietary module helped send a significant development project in the wrong direction and makes it nearly impossible to implement this functionality in a way that works with all GPUs, demonstrates one of the reasons why the development community sees those modules as being harmful. > since it is very much against the spirit of free software. I fail to see how this is even remotely the case. Or do you consider copyleft licenses to be "against the spirit of free software"? > ... and perhaps even encouraged by the GPL The point of the patch is, literally, to help enforce the GPL. From TFA: "With this patch applied, any module that imports symbols from a proprietary module is itself marked as being proprietary, denying it access to GPL-only symbols. If the shim module has already accessed GPL-only symbols by the time it gets around to importing symbols from the proprietary module, that import will not be allowed." Linking to a proprietary module should make your code proprietary too. If you're proprietary, you shouldn't be able to link against GPL code anyway. Isn't _that_ the point of copyleft?
- userbinator 6y agoI fail to see how this is even remotely the case. Or do you consider copyleft licenses to be "against the spirit of free software"? Actively making it harder for people to modify software for their own use is definitely against the spirit of free software! Copyleft has nothing to do with that, and is only about distribution of your modifications. The point of the patch is, literally, to help enforce the GPL. Once again, the GPL places restrictions on public distribution, not private use/modification/etc. It seems there is this insanity where some people want to split the world in half between "free" and "non-free", and such things are entirely ridiculous in reality. If they had their way I'm sure we wouldn't even be allowed to talk to them if we had ever used proprietary software at all. IMHO such antagonism is really bad for free software too. It reminds me of what Stallman did with GCC... and look how well that turned out (Clang etc.) From TFA: "With this patch applied, any module that imports symbols from a proprietary module is itself marked as being proprietary, denying it access to GPL-only symbols. If the shim module has already accessed GPL-only symbols by the time it gets around to importing symbols from the proprietary module, that import will not be allowed." Your code is running in kernel mode, which already means you can jump, call, and modify whatever you damn well want to! This is why I view such silly exercises as needless bureaucracy (and complexity). If official Linux wants to keep proprietary code out of the kernel, that's their right, but don't go out of your way to fight everyone else. It's my computer, I get to run whatever code I want to. Isn't that what free software is about...?
- cycloptic 6y ago>Actively making it harder for people to modify software for their own use This is not what is happening, you're still free to modify the Linux kernel in any way you want.
- pritambaral 6y ago> ... for people to modify software for their own use > ... private use/modification/etc > It's my computer, I get to run whatever code I want to. The patch changes none of that. The patch doesn't prevent you from disabling this restriction on your private builds. It seems you still don't get the purpose of the patch. It is not designed to make _your_ private use difficult. It is designed to make _public_ contribution attempts like TFA that waste everyone's time again and again easy to push back against. TFA is not the first time something like this has happened. The kernel devs have repeatedly had to tell people off from trying to add proprietary-dependent or for-proprietary modules into the kernel. Adding a switch for GPL-and-non-GPL mixing makes that explicit and easy to catch. > If they had their way I'm sure we wouldn't even be allowed to talk to them if we had ever used proprietary software at all. I don't know where this antagonism comes from, but it seems like you're missing the point. Try to look at the posting from their point-of-view. It wasn't that the poster used some proprietary software on their own, but that they forced said proprietary software on every reviewer on the mailing list. Surely, you understand the distinction?
- cycloptic 6y ago>since it is very much against the spirit of free software I'm not sure what you mean. This is a check that (among other things) helps downstream users avoid violations of the GPL, which is a free software license.
- hvis 6y agoIt is basically an automated check to flag modules that obviously violate GPL.