Garrett: Oracle continue to circumvent EXPORT_SYMBOL_GPL()
Garrett: Oracle continue to circumvent EXPORT_SYMBOL_GPL()
Posted May 12, 2014 22:15 UTC (Mon) by khim (subscriber, #9252)In reply to: Garrett: Oracle continue to circumvent EXPORT_SYMBOL_GPL() by dskoll
Parent article: Garrett: Oracle continue to circumvent EXPORT_SYMBOL_GPL()
Now, as to whether (Linux Kernel + shim + D-Trace) is a derived work of (Linux Kernel)…
…is irrelevant since such combination is never distributed. “Kernel + shim” and “D-Trace” are distributed as separate entities and are only ever combined by end user when the whole thing is started and the act of running the Program is not restricted. They are similar to “Linux kernel + GlibC + Adobe Flash” or to “Linux kernel + Bionic + Chrome” in that regard. The only relevant question is: what's the status of “D-Trace”? Is it, indeed, separate, independent entity which is only tied to the “Kernel + shim” via well-defined interface (similarly to how GlibC or Bionic are tied to kernel) or is it, in fact, small piece of the larger work which can not be considered in isolation?
Posted May 12, 2014 23:46 UTC (Mon)
by dskoll (subscriber, #1630)
[Link] (8 responses)
You are going round in circles. Shipping kernel + shim + D-Trace is not mere aggregation; the GPL is clear that such a shipped work is a derived work because dynamic linking does not give you a get-around-the-GPL-free card.
Your example with Adobe Flash and GlibC is not relevant because GlibC
is LGPL-licensed, not GPL-licensed, and because GlibC is permitted to use
Linux system calls without being GPL-licensed.
Posted May 13, 2014 1:04 UTC (Tue)
by khim (subscriber, #9252)
[Link] (7 responses)
Well, sure. You repeatedly explain that the sky is green (because it's “obvious”, “there are no doubt”, “is written so explicitly”) and I refute you insinuations and say that it's “not obvious”, “there is doubt” and “it's not what's written”. And here we go on yet another turn. GPL does not mention neither dynamic nor static linking. You are mixing it with LGPL. What does mention dynamic and static linking is GPL FAQ. And what does it say about them? Right. This: If the modules are included in the same executable file, they are definitely combined in one program. If modules are designed to run linked together in a shared address space, that almost surely means combining them into one program. IOW: if you are using static linking then GPL most definitely covers everything, if you are using some kind of dynamic linking then it may not be applicable. Sky still is not green, sorry. Right. But just why GlibC is permitted to use Linux system calls without being GPL-licensed? Here is text of the license. Try to find "system calls", "linux", or anything like it. It's just not there. You may point out to the clarification which Linus added eons ago to it's copy of COPYING file. This will be a good point, but well, it's just a clarification, it's not part of the license. Some files explicitly say “see the file COPYING in the main directory of the Linux distribution for more details”, but these are rare. Many more say that “you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation”—and of course “GNU General Public License as published by the Free Software Foundation” does not say anything about syscalls. Which means that while note in Linus copy of the COPYING file will be considered it will only be considered as part of the evidence, not as part of the license. And what it'll show with crystall-clear clarity is the fact that at least some Linux copyright holders believe that you could in fact combine two pieces of software—GPLed and non-GPLed ones, but when exactly could you do will need to be determined by court. Which will also have a clear words from FSF (who've written the GPL license, rememeber) that say that it's hard but possible to have two dynamically linked pieces of software which still could be considered independent works. You see? No matter how hard you wish to call sky green, it's still blue, not green. Close but no cigar.
Posted May 13, 2014 14:02 UTC (Tue)
by dskoll (subscriber, #1630)
[Link] (2 responses)
Answer me this: Why did the Linux kernel developers invent the entire EXPORT_SYMBOL_GPL() machinery if their intent was not to require modules that use GPL-only symbols to be licensed under the GPL?
Posted May 13, 2014 14:04 UTC (Tue)
by dskoll (subscriber, #1630)
[Link] (1 responses)
I wish I could edit posts, but I'll have to follow up. Please see
this message from Linus Torvalds.
Posted May 13, 2014 16:39 UTC (Tue)
by khim (subscriber, #9252)
[Link]
Posted May 13, 2014 14:07 UTC (Tue)
by dskoll (subscriber, #1630)
[Link] (3 responses)
This will be a good point, but well, it's just a clarification, it's not part of the license.
To quote Linus Torvalds:
... Intent matters a LOT. ... Common sense makes a lot of difference, and DWIM is not just possible, but it's the only thing that matters.
Posted May 13, 2014 16:53 UTC (Tue)
by khim (subscriber, #9252)
[Link] (2 responses)
Indeed. Except (as usual) you misinterpret everything again. This about it: we have two different, separate ways to export symbols: But here is the catch: just how are these high-level Now you come along and basically claim: intent matters! If “kernel gods” are creating module which uses Sorry, but this argument is so bizzare it's not even funny. If kernel developers can do that then obviously Oracle can do that, too: they are bound by the same GPL rules, after all. Sorry, but you've once again failed to show just why sky is green.
Posted May 13, 2014 18:06 UTC (Tue)
by niner (subscriber, #26151)
[Link]
Posted May 13, 2014 18:48 UTC (Tue)
by dskoll (subscriber, #1630)
[Link]
You are missing the point completely. Please read Linus's post carefully, especially the part about "lawyers" and "willful infringement".
I can't tell if you're deliberately trying to be obtuse or are simply dense, but either way I'm not posting again on this topic because it would be counter-productive.
Garrett: Oracle continue to circumvent EXPORT_SYMBOL_GPL()
Garrett: Oracle continue to circumvent EXPORT_SYMBOL_GPL()
You are going round in circles.
The GPL is clear that such a shipped work is a derived work because dynamic linking does not give you a get-around-the-GPL-free card.
Your example with Adobe Flash and GlibC is not relevant because GlibC is LGPL-licensed, not GPL-licensed, and because GlibC is permitted to use Linux system calls without being GPL-licensed.
Garrett: Oracle continue to circumvent EXPORT_SYMBOL_GPL()
Garrett: Oracle continue to circumvent EXPORT_SYMBOL_GPL()
Post from Linus Torvalds makes perfect sense. Indeed if you'll just create a dummy shim which just reexports Garrett: Oracle continue to circumvent EXPORT_SYMBOL_GPL()
_GPL symbols without modifications then this will most likely lead to the copyright violation. But this is not what DTrace shim is doing. It's pretty non-trivial (even if some functions are are trivial) and it's easy to believe that will act as an effective boundary between GPLed part and non-GPLed part.
Garrett: Oracle continue to circumvent EXPORT_SYMBOL_GPL()
Garrett: Oracle continue to circumvent EXPORT_SYMBOL_GPL()
EXPORT_SYMBOL() and EXPORT_SYMBOL_GPL(). Why do we even have these different ways in the first place? Because some functions are internal and are too tightly tied to kernel, they could not be used without creating a derived work (or so kernel developers believe) while some other functions can be used in such a way. Otherwise that difference would make no sense.EXPORT_SYMBOL()-exported functions are really implemented? Do they have separate in-kernel subsystem which only ever uses EXPORT_SYMBOL()-exported functions and never used EXPORT_SYMBOL_GPL()-exported functions? Of course not: many internal kernel modules use EXPORT_SYMBOL_GPL()-exported functions and then expose some higher-level functions via EXPORT_SYMBOL(). That's normal, that's just how things are done. You take internal, unstable ABI, wrap it out into a more stable, less convoluted ABI and then export it. Easy and simple.EXPORT_SYMBOL_GPL()-exported functions and then exports EXPORT_SYMBOL()-exported functions then everything is fine and cool. But if lowly Oracle dares to do the same… oh, that's totally different kettle of fish. It's absolutely forbidden, no need to even think about that! Violation, violation, violation, totally wrong, sky is falling!
The difference is that the kernel developers are the actual copyright holders who decided in the first place which symbols are EXPORT_SYMBOL and which are EXPORT_SYMBOL_GPL. So yes indeed, they have some more rights there.
In addition the kernel developers did not just sue some company for reimplementing a public API. A part of this discussion you seem to persistently ignore.
Garrett: Oracle continue to circumvent EXPORT_SYMBOL_GPL()
Garrett: Oracle continue to circumvent EXPORT_SYMBOL_GPL()