Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

This is a quite interesting case from a legal standpoint. IANAL but my 5 cents are:

* If it's true that Samsung distributed this driver as part of the Linux kernel source code tree then it is arguably a derivative work of the Linux kernel.

* If so then these two sections of the GPL seem relevant:

> 4. You may not copy, modify, sublicense, or distribute the Program except as expressly provided under this License. Any attempt otherwise to copy, modify, sublicense or distribute the Program is void, and will automatically terminate your rights under this License. However, parties who have received copies, or rights, from you under this License will not have their licenses terminated so long as such parties remain in full compliance.

> 6. Each time you redistribute the Program (or any work based on the Program), the recipient automatically receives a license from the original licensor to copy, distribute or modify the Program subject to these terms and conditions. You may not impose any further restrictions on the recipients' exercise of the rights granted herein. You are not responsible for enforcing compliance by third parties to this License.

* I'm not absolutely sure what that means for rxrz. Section 6 seems to imply that rxrz may have a license to the driver, and that that license is indeed the GPL. On the other hand section 4 seems to imply that the redistribution to rxrz was "void". Does that mean rxrz does not have the rights under section 6?

If I where rxrz I would at least toy with this idea: a) wait for the DMCA take down notice, b) challenge it claiming to have a license under section 6 of the GPL and c) hope that Samsung does not have the nerve to go to court and risk a decision that would clarify that their license to the Linux kernel has been irreversibly revoked. :)

But where does that leave us concerning legality? Is it clear that what rxrz has done is illegal?



>> If it's true that Samsung distributed this driver as part of the Linux kernel source code tree then it is arguably a derivative work of the Linux kernel.

Did Samsung really distribute the source if it was published by accident by one employee?

Even if they did, it's under a proprietary license and it's not clear that proprietary kernel modules are necessarily derivative works, they are commonplace.

Even if they are derivative that may make Samsung in violation of the GPL but not actually make their code covered (these are be separate issues).

And even if they are in violation, this usually has to be challenged by a copyright holder, not simply by a recipient of the binaries. And that's if rxrv even received any binaries...

Section 6 is interesting there - "Each time you redistribute the Program (or any work based on the Program), the recipient automatically receives a license from the original licensor to copy, distribute or modify the Program subject to these terms and conditions."

I could see a lawyer arguing that the "Program" in clause 1 and 2 are the same, but if you distribute a work based on the Program the recipient automatically receives a license from the original licensor to copy, distribute or modify the Program itself but not the work based on the Program, as that is not enumerated in clause 2.

And this is before we even get into the patent violations that any use of such code involves.


> Even if they did, it's under a proprietary license and it's not clear that proprietary kernel modules are necessarily derivative works, they are commonplace.

True, proprietary kernel modules are commonplace, and not necessarily derivative works. But you very rarely see proprietary drivers "in-tree" (that is where the source code file is placed into the Linux kernel source code tree and built as part of the kernel build process). I remember reading an argument by Torvalds that any driver built in that way is a derivative work of the kernel (even if it is built into a module) but unfortunately I can't find it now.

> Even if they are derivative that may make Samsung in violation of the GPL but not actually make their code covered (these are be separate issues).

Mmm... I'm not entirely sure... Normally I'm a "separate issues" kind of guy, but here I'm hesitating...

To make this interesting let's say Samsung has distributed to rxrz in binary form and that the driver is a derivative work. Then the driver is part of the Program distributed to rxrz under the GPL and Samsung has granted rxrz this right (as per section 1 of the GPLv2):

"You may copy and distribute verbatim copies of the Program's source code as you receive it, in any medium, provided that you conspicuously and appropriately publish on each copy an appropriate copyright notice and disclaimer of warranty; keep intact all the notices that refer to this License and to the absence of any warranty; and give any other recipients of the Program a copy of this License along with the Program."

Isn't that exactly what rxrz has done? :) Why would rxrz not be allowed to argue that in court? I agree that normally the issues are separate, but in my mind the GPL ties them together in this case. I'm not saying that rxrz is right, but it's not entirely clear-cut to me.


> If it's true that Samsung distributed this driver as part of the Linux kernel source code tree then it is arguably a derivative work of the Linux kernel.

Other companies use binary blobs in the Linux Kernel by using a GPL-compatible shim driver.

Samsung would be in violation of the GPL if they do not publish the source to the SHIM in a compatible license, but that would imply nothing about the binary blob.

Disclaimer: I'm not even sure whether they use the shim workaround in this case.


Usually that thin layer of source code is under a proprietary license as well. The main reason to have it is actually not legal but technical: distributing kernel modules in binary form (.ko) separately from the kernel itself is a pain in the arse (bordering on impossible) since they depend on the exact version of the kernel and in some cases even the build config (e.g. skbuff size may depend on #ifdefs).




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

Search: