5 ms·

>The OEMs ought to send these upstream, but don't want to. Isn't this a rampant GPL violation? Why do we put up with this? We are about to lose the war for ge

by dTal 10y ago

>The OEMs ought to send these upstream, but don't want to. Isn't this a rampant GPL violation? Why do we put up with this? We are about to lose the war for general purpose computing due to insufficient GPL enforcement.

JumpCrisscross 10y ago
> Why do we put up with this? Who is "we"? As in, who will pay the lawyers?
deleted 10y ago
[deleted]
syshum 10y ago
Software Freedom Conservancy has been saying this for a long time, most the Kernel Devs, Linux Foundation, etc all seem to want to treat the Linux Kernel more like BSD than GPL. They do not want to piss of their corporate masters..
kristoffer 10y ago
No it's not a "rampant" violation. Some people believe it is a violation and some not. Linus Torvalds being one who thinks its's fine. See e.g. https://lkml.org/lkml/2006/12/14/218 https://lkml.org/lkml/2006/12/14/218
- giancarlostoro 10y ago
  From the link: > But if the module was written for other systems, and just ported to Linux, and not using our code, then it's very much debatable whether it's actually a "derived work". Interfaces don't make "derived works" per se. Interesting, wonder where this puts Android's Dalvik VM (is the VM called this too? I don't remember). Edit: Not sure what the JVM Dalvik is based on is licensed as though.
michaelt 10y ago
Isn't this a rampant GPL violation? Eh, it could just be that there isn't sufficient overlap in the incentives of the vendors and upstream. For example, an OEM can bash out low quality code which is hard to maintain, secure in the knowledge that they'll only have to maintain it for the year or two that phone is getting updates, and it won't have to survive any big kernel updates or be compatible with anything that isn't on the phone. Upstream, on the other hand, wants to maintain device support forever so they want good quality code that they can get through kernel updates with a minimum of fuss, and they can't accept anything that breaks existing code. So upstream won't accept the OEM's shitty patch, and the OEM won't pay for the engineering time to make patches that upstream will accept.
NoGravitas 10y ago
In a lot of cases, the OEMs publish their kernel source, with their drivers and changes, so it's not a GPL violation. But it takes a tremendous amount of work to get that kind of thing into the mainline kernel, not least because of the atrocious quality of a lot of OEM kernel code. And the incentives are absolutely not there to get them to do it. (Of course, some OEMs absolutely do violate the GPL, and then there's also the issue of binary drivers and blobs that violate the spirit but not the letter.)
drewg123 10y ago
Dealing with the upstream linux community is a painful, time-consuming process. A lot of hardware vendors would rather just not bother, and release their source code to maintain GPL compliance, but never attempt to upstream anything because the process is so time consuming, with little to no immediately apparent upside. This is especially true if they are a parts supplier with a handful of large customers who don't care about upstream support.

by dTal 10y ago

JumpCrisscross 10y ago

> Why do we put up with this? Who is "we"? As in, who will pay the lawyers?

deleted 10y ago

[deleted]

syshum 10y ago

Software Freedom Conservancy has been saying this for a long time, most the Kernel Devs, Linux Foundation, etc all seem to want to treat the Linux Kernel more like BSD than GPL. They do not want to piss of their corporate masters..

kristoffer 10y ago

No it's not a "rampant" violation. Some people believe it is a violation and some not. Linus Torvalds being one who thinks its's fine. See e.g. https://lkml.org/lkml/2006/12/14/218 https://lkml.org/lkml/2006/12/14/218

giancarlostoro 10y ago
From the link: > But if the module was written for other systems, and just ported to Linux, and not using our code, then it's very much debatable whether it's actually a "derived work". Interfaces don't make "derived works" per se. Interesting, wonder where this puts Android's Dalvik VM (is the VM called this too? I don't remember). Edit: Not sure what the JVM Dalvik is based on is licensed as though.

michaelt 10y ago

Isn't this a rampant GPL violation? Eh, it could just be that there isn't sufficient overlap in the incentives of the vendors and upstream. For example, an OEM can bash out low quality code which is hard to maintain, secure in the knowledge that they'll only have to maintain it for the year or two that phone is getting updates, and it won't have to survive any big kernel updates or be compatible with anything that isn't on the phone. Upstream, on the other hand, wants to maintain device support forever so they want good quality code that they can get through kernel updates with a minimum of fuss, and they can't accept anything that breaks existing code. So upstream won't accept the OEM's shitty patch, and the OEM won't pay for the engineering time to make patches that upstream will accept.

NoGravitas 10y ago

In a lot of cases, the OEMs publish their kernel source, with their drivers and changes, so it's not a GPL violation. But it takes a tremendous amount of work to get that kind of thing into the mainline kernel, not least because of the atrocious quality of a lot of OEM kernel code. And the incentives are absolutely not there to get them to do it. (Of course, some OEMs absolutely do violate the GPL, and then there's also the issue of binary drivers and blobs that violate the spirit but not the letter.)

drewg123 10y ago

Dealing with the upstream linux community is a painful, time-consuming process. A lot of hardware vendors would rather just not bother, and release their source code to maintain GPL compliance, but never attempt to upstream anything because the process is so time consuming, with little to no immediately apparent upside. This is especially true if they are a parts supplier with a handful of large customers who don't care about upstream support.