Hacker News new | past | comments | ask | show | jobs | submit login

It's a shady workaround to the kernel itself being shady with which symbols get marked GPL.



Marking symbols as GPL is not shady.


For the symbols where use of them does not imply that the code is derivative of the kernel, it is shady.

See also kernel_fpu_begin


Code which links against the kernel is derivative as far as the GPL is concerned.


That's obviously not true when you consider code that was ported from other architectures.

Unless you mean specifically how the GPL is written, but the GPL doesn't get to decide what's derivative, copyright does.

And if that was solidly true, why isn't every symbol marked GPL?


I don't understand what porting from other architectures has to do with anything. If Linux has some code for amd64, and then Linux developers port that code to aarch64, why would the aarch64 code be different from a licensing perspective than the amd64 code?

I don't know why they have non-GPL symbols. My understanding is that they could have marked every symbol as GPL. There's presumably some desire to allow limited closed-source drivers. You'd have to ask someone involved or find some writings from someone who knows. Maybe Google can help.


I'm taking about a kernel module being ported from something other than Linux. With minimal changes.

Changing some entry points won't make it a derived work.


Doesn't the existence of the LGPL negate your argument? It is the GPL with a linking exception, colloquially.


LGPL sets out better, clearer boundaries. And it allows some things that might arguably be derived code, while the GPL would hedge much closer to that line. So it has a use.

Also FSF tends to overstate the importance of linking.




Consider applying for YC's Spring batch! Applications are open till Feb 11.

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: