Exactly. They wrote a Linux kernel module and are distributing a Linux kernel with said module. It doesn't matter where the copyright resides, the module became GPL-licensed when they distributed a Linux-derived work.
Printable View
Can you point me to another system with anywhere near as many open source drivers as Linux?
And on the flipside Linux has helped the *BSD's by requiring open source drivers as lots of BSD drivers have been reverse engineered from Linux driver source code. Source code which would not have been available had it not been for the Linux kernel developers hard stance on binary blobs.
Reverse engineering against source code is _much_ easier than reverse engineering against a binary black box.
If you implement both sides of an interface then it's not a derived work which is something Oracle vs Google showed, on the other hand if the Linux kernel which is GPL licenced is one side of the interface then unless explicitly stated otherwise it will be a derivative work.
You just answered a longstanding question that I had. Thanks.
I suggest that you read what the OpenBSD developers have to say about Linux and device drivers:
http://www.openbsd.org/papers/brhard2007/mgp00024.html
Something that is fairly interesting is that the OpenBSD developers appear to have written a disproportionately large number of reverse engineered drivers, some of which have found their way into Linux. When I say that they did reverse engineering, I mean blobs, not source code. Anyone who claims that people reverse engineer source code has no clue what reverse engineering is, yourself included.
With that said, Linux drivers rarely find their way into *BSD operating systems because of restrictive licensing. The only real exceptions to this are Linux graphics drivers, which are often MIT licensed.
Dave, the act of linking does not violate the GPL. The act of distributing something that is linked does. Also, could you define what linking means in this context? As far as I have seen, nothing anyone would associate with a traditional linker seems to be done against the kernel binary until the module is loaded. I did a quick test with a Hello World module:
It looks like ld does linking, but the only thing of the kernel's that it appears to use is a little linker script, which is arguably part of the toolchain:Code:make -C /lib/modules/3.6.6/build SUBDIRS=/tmp/module modules
make[1]: Entering directory `/usr/src/linux-3.6.6'
test -e include/generated/autoconf.h -a -e include/config/auto.conf || ( \
echo >&2; \
echo >&2 " ERROR: Kernel configuration is invalid."; \
echo >&2 " include/generated/autoconf.h or include/config/auto.conf are missing.";\
echo >&2 " Run 'make oldconfig && make prepare' on kernel src to fix it."; \
echo >&2 ; \
/bin/false)
mkdir -p /tmp/module/.tmp_versions ; rm -f /tmp/module/.tmp_versions/*
make -f scripts/Makefile.build obj=/tmp/module
gcc -Wp,-MD,/tmp/module/.hello.o.d -nostdinc -isystem /usr/lib/gcc/x86_64-pc-linux-gnu/4.6.3/include -I/usr/src/linux-3.6.6/arch/x86/include -Iarch/x86/include/generated -Iinclude -include /usr/src/linux-3.6.6/include/linux/kconfig.h -D__KERNEL__ -Wall -Wundef -Wstrict-prototypes -Wno-trigraphs -fno-strict-aliasing -fno-common -Werror-implicit-function-declaration -Wno-format-security -fno-delete-null-pointer-checks -O2 -m64 -march=core2 -mno-red-zone -mcmodel=kernel -funit-at-a-time -maccumulate-outgoing-args -fstack-protector -DCONFIG_AS_CFI=1 -DCONFIG_AS_CFI_SIGNAL_FRAME=1 -DCONFIG_AS_CFI_SECTIONS=1 -DCONFIG_AS_FXSAVEQ=1 -DCONFIG_AS_AVX=1 -pipe -Wno-sign-compare -fno-asynchronous-unwind-tables -mno-sse -mno-mmx -mno-sse2 -mno-3dnow -mno-avx -Wframe-larger-than=2048 -Wno-unused-but-set-variable -fno-omit-frame-pointer -fno-optimize-sibling-calls -g -pg -Wdeclaration-after-statement -Wno-pointer-sign -fno-strict-overflow -fconserve-stack -DCC_HAVE_ASM_GOTO -DMODULE -D"KBUILD_STR(s)=#s" -D"KBUILD_BASENAME=KBUILD_STR(hello)" -D"KBUILD_MODNAME=KBUILD_STR(hello)" -c -o /tmp/module/hello.o /tmp/module/hello.c
if [ "-pg" = "-pg" ]; then if [ /tmp/module/hello.o != "scripts/mod/empty.o" ]; then /usr/src/linux-3.6.6/scripts/recordmcount "/tmp/module/hello.o"; fi; fi;
(cat /dev/null; echo kernel//tmp/module/hello.ko;) > /tmp/module/modules.order
make -f /usr/src/linux-3.6.6/scripts/Makefile.modpost
scripts/mod/modpost -i /usr/src/linux-3.6.6/Module.symvers -I /tmp/module/Module.symvers -o /tmp/module/Module.symvers -S -w -s
gcc -Wp,-MD,/tmp/module/.hello.mod.o.d -nostdinc -isystem /usr/lib/gcc/x86_64-pc-linux-gnu/4.6.3/include -I/usr/src/linux-3.6.6/arch/x86/include -Iarch/x86/include/generated -Iinclude -include /usr/src/linux-3.6.6/include/linux/kconfig.h -D__KERNEL__ -Wall -Wundef -Wstrict-prototypes -Wno-trigraphs -fno-strict-aliasing -fno-common -Werror-implicit-function-declaration -Wno-format-security -fno-delete-null-pointer-checks -O2 -m64 -march=core2 -mno-red-zone -mcmodel=kernel -funit-at-a-time -maccumulate-outgoing-args -fstack-protector -DCONFIG_AS_CFI=1 -DCONFIG_AS_CFI_SIGNAL_FRAME=1 -DCONFIG_AS_CFI_SECTIONS=1 -DCONFIG_AS_FXSAVEQ=1 -DCONFIG_AS_AVX=1 -pipe -Wno-sign-compare -fno-asynchronous-unwind-tables -mno-sse -mno-mmx -mno-sse2 -mno-3dnow -mno-avx -Wframe-larger-than=2048 -Wno-unused-but-set-variable -fno-omit-frame-pointer -fno-optimize-sibling-calls -g -pg -Wdeclaration-after-statement -Wno-pointer-sign -fno-strict-overflow -fconserve-stack -DCC_HAVE_ASM_GOTO -D"KBUILD_STR(s)=#s" -D"KBUILD_BASENAME=KBUILD_STR(hello.mod)" -D"KBUILD_MODNAME=KBUILD_STR(hello)" -DMODULE -c -o /tmp/module/hello.mod.o /tmp/module/hello.mod.c
ld -r -m elf_x86_64 -T /usr/src/linux-3.6.6/scripts/module-common.lds --build-id -o /tmp/module/hello.ko /tmp/module/hello.o /tmp/module/hello.mod.o
make[1]: Leaving directory `/usr/src/linux-3.6.6'
I would also appreciate it if you would explain how we have an uproar concerning this particular vendor when we have heard relatively little complaint about the numerous other vendors that have been doing this far longer. To cite a specific example, anyone shipping Linux devices using broadcom hardware. If you would prefer, you could talk about this in the context of graphics. There are plenty of Android devices out there with binary graphics drivers being shipped with the kernel. Why is there no uproar over that? Are they not in violation?Code:/*
* Common module linker script, always used when linking a module.
* Archs are free to supply their own linker scripts. ld will
* combine them automatically.
*/
SECTIONS {
/DISCARD/ : { *(.discard) }
__ksymtab : { *(SORT(___ksymtab+*)) }
__ksymtab_gpl : { *(SORT(___ksymtab_gpl+*)) }
__ksymtab_unused : { *(SORT(___ksymtab_unused+*)) }
__ksymtab_unused_gpl : { *(SORT(___ksymtab_unused_gpl+*)) }
__ksymtab_gpl_future : { *(SORT(___ksymtab_gpl_future+*)) }
__kcrctab : { *(SORT(___kcrctab+*)) }
__kcrctab_gpl : { *(SORT(___kcrctab_gpl+*)) }
__kcrctab_unused : { *(SORT(___kcrctab_unused+*)) }
__kcrctab_unused_gpl : { *(SORT(___kcrctab_unused_gpl+*)) }
__kcrctab_gpl_future : { *(SORT(___kcrctab_gpl_future+*)) }
}
100% true.
While that statement is true by itself, that's not the issue here.
The code in question was developed for the Linux kernel, is a Linux kernel module, runs in kernel space, has no use whatsoever without the Linux kernel, and is distributed with a Linux kernel. That makes it a derived work, and as such they agreed to abide by the terms of the Linux kernel license, the GPLv2, which requires that derived works be available under a license compatible with GPLv2.
Yeah I was only trying to show people why nvidia don't get sued (not distributing a linked object), they actually don't distribute any objects build with kernel headers, they have the user build the files that touch the kernel headers locally. When some distros tried to bypass this and ship a kernel and the final linked nvidia binary, they got told to stop. So yes distributing a linked thing is what triggers the GPL violation. Exactly what consitutes linking is also a bit of lawyer consulation. Currently accepted theory is that creating a kernel module you can load into a running kernel is linking it, again good lawyers might get judges to see things another way.
So the thing is yes there are lots of GPL violators out there, but not as bad as you imply. You'd be surprised how many of the android graphics stacks have fully open source kernel drivers, even if they aren't upstream, they are still released under the GPL, and there are a lot of people doing GPL violation works with those companies in secret.
The reason this one is bigger is (a) it was on lkml, (b) the company alleged to violate also happen to maintain a GPL fork of their code, (c) the company in question stonewalled any polite inquiries in private, (d) it was on lkml. (d) it got into phoronix.
Generally with GPL violations the organisation doing the investigation and the organisation doing the violatiing, talk in private a lot first, and some agreement is hammered out, occasionally it goes to court.
At a guess this one will probably go into the background, until
one of:
a) some rights holder decides to pursue it, whether that be SFLC, Red Hat, or anyone else who holds kernel copyrights
b) the company just releases the source to the bits they didn't before.
Dave.
The module DID NOT become GPL-licensed, this is a part of the anti-GPL "viral" FUD. You can't relicense other people's code.
What happened is that they violated the GPL at the moment they shipped a combined work which included GPL software. Their options at that point are:
- Stop distributing the thing immediately and lose the right to distribute GPL software in the future, or
- GPL the code they distributed
I had to read this 5 times or so to understand what you are talking about. Simply put, Syke worded it a bit ambiguously and he actually meant "It doesn't matter where the copyright resides, the module must become GPL-licensed when they distribute a Linux-derived work, or else they violate the GPL." No need to make a fuss like that, this is not FUD. Also, there was no relicensing of others' code mentioned anywhere - the module is theirs.