Garrett: Oracle continue to circumvent EXPORT_SYMBOL_GPL()

[Posted May 12, 2014 by corbet]

Matthew Garrett takes Oracle to task for using shim functions to gain access to GPL-only kernel functions in its GPL-incompatible DTrace module. "Of course, as copyright holders of DTrace, Oracle could solve the problem by dual-licensing DTrace under the GPL as well as the CDDL. The fact that they haven't implies that they think there's enough value in keeping it under an incompatible license to risk losing a copyright infringement suit. This might be just the kind of recklessness that Oracle accused Google of back in their last case."

Garrett: Oracle continue to circumvent EXPORT_SYMBOL_GPL()

Posted May 12, 2014 9:10 UTC (Mon) by khim (subscriber, #9252) [Link] (39 responses)

IANAL, but I don't really see what the hoopla is all about. If I understand correctly D-Trace for Linux is implemented as two related modules:

One (presumably GPLed) module which exports some kind of “stable tracing ABI” and
D-Trace itself which is under CDDL and can be used with any kernel which exports aforementioned “stable tracing ABI”.
“Stable tracing ABI” itself is obviously used by both modules, but since Oracle is the copyright owner it could license it on both CDDL and GPL terms.

Then Oracle relies on the “mere aggregation” clause of the GPL to explain how these two can be distrubuted together. Now, it just so happened that one function in the aforementioned “stable tracing ABI” called dtrace_gethrtime currently can be implemented by a simple call to internal kernel function called ktime_get. This is very fortunate for Oracle and makes first module simpler, but does not materially change anything: if future version of kernel will be changed and function ktime_get will disappear (or will be changed sufficiently enough to not fulfull requirements of “stable tracing ABI”) then dtrace_gethrtime will become 1000-lines function instead of current one-liner. It'll not affect second module at all.

For that scheme to work the best way will be documentation for the aforementioned “stable tracing ABI”. The fact that it's not formally documented is more worrying to me than the fact that some pieces of it are implemented by just one call to internal kernel function.

Garrett: Oracle continue to circumvent EXPORT_SYMBOL_GPL()

Posted May 12, 2014 10:16 UTC (Mon) by farnz (subscriber, #17727) [Link] (37 responses)

The hoopla is because Oracle is claiming in its case against Google that the two works are in some way derived works of each other due to the common API. Mere aggregation doesn't protect you in that case - you have derived works, and the GPL requires that if something is a derived work of a GPL'd project, it must also be GPL'd itself. So far, nothing to get worked up about, just big corporations playing big company games.

However, Oracle has previously also suggested in court that Google was reckless in choosing to use a Java-compatible API for Android, despite Google's reasoned belief that it was doing so legally. If Google was reckless in using Oracle's API, then surely Oracle is as reckless if not worse in using such a shim to attempt to avoid issues with copyright law? It's this bit that's triggered the hoopla.

Garrett: Oracle continue to circumvent EXPORT_SYMBOL_GPL()

Posted May 12, 2014 10:54 UTC (Mon) by khim (subscriber, #9252) [Link] (36 responses)

If Google was reckless in using Oracle's API, then surely Oracle is as reckless if not worse in using such a shim to attempt to avoid issues with copyright law?

Why? In D-Trace case of “mere aggregation” “stable tracing ABI” itself is distributed by Oracle and is [presumably] licensed under both GPL and CDDL licenses, so what's the problem? Oracle have never tried to use Linux kernel's ABI directly with D-Trace (or so the claim goes). On the contrary: it created totally separate ABI specifically for the use with D-Trace! Yes, one function of that API have been mapped to one internal kernel function, but that's mere happenstance (or so the claim goes).

Garrett: Oracle continue to circumvent EXPORT_SYMBOL_GPL()

Posted May 12, 2014 11:18 UTC (Mon) by hirnbrot (guest, #89469) [Link] (30 responses)

>licensed under both GPL and CDDL licenses, so what's the problem?

(IANAL and all that)

Since GPL and CDDL are mutually exclusive, you can

a) Use a gpl work with a gpl work

b) Use a cddl work with a cddl work

but not use a gpl work with a cddl work.

Multi-licensing lets you (the recipient) choose between two licenses.

So, in this case, you can either

a) Use d-trace with the shim, choosing the cddl

b) Use the shim with the linux kernel, choosing the gpl

But you can't use both (which would be needed to get it to, you know, work).

That's if this case of multiple licenses is even possible - if the shim is a derivative work of the linux kernel (which I strongly suspect, given that it adapts perfectly to the linux in-kernel API), then it needs to be licensed under the GPL.

Garrett: Oracle continue to circumvent EXPORT_SYMBOL_GPL()

Posted May 12, 2014 14:11 UTC (Mon) by khim (subscriber, #9252) [Link] (28 responses)

I still don't understand what's your problem.

I take GPLed works (shim and “stable tracing ABI”), combine them and kernel, everything is fine.
I take CDDLed works (D-Trace and “stable tracing ABI”), combine them together, everything is fine.
I can ship both pieces since they are not tied to each other, the act of running the Program is not restricted, which means it's Ok to do, too.

Where the problem comes from?

If you want to claim that somehow I could not license the same piece under two different, incompatible licenses, then this is not even close to being true: the whole history of copyright is littered by examples of such licensing. Most books are licensed under different terms in UK, US and Australia, and India, for example. Licenses given to TV companies are totally different from licenses for cinemas. There are literally thousands of examples where the same thing is licensed under different, often incompatible, licenses.

Garrett: Oracle continue to circumvent EXPORT_SYMBOL_GPL()

Posted May 12, 2014 14:21 UTC (Mon) by JohnLenz (guest, #42089) [Link] (1 responses)

I'm no lawyer, but my interpretation of the problem is that while old versions of dtrace were not derivatives of the kernel, the versions of dtrace that use the shim are actually derivatives of the kernel, and therefore the only way Oracle can distribute that version of dtrace which uses the shim is if the license is GPL compatible. The reasoning for why the dtrace which uses the shim is a derivative is because some of functions in the shim are just re-exporting kernel symbols with a new name (and not EXPORT_SYMBOL_GPL). The linked article gives the example of high resolution timers, where the shim function just calls the kernel function and so the existence of the shim function is only to get around the EXPORT_SYMBOL_GPL restrictions.

Certianly dtrace which does not call the shim is not a derivative and Oracle can do what they want with it, but the dtrace which calls the shim is a derivative, so even if Oracle distributes dtrace and the shim separately, dtrace would need to be GPL compatible.

Garrett: Oracle continue to circumvent EXPORT_SYMBOL_GPL()

Posted May 12, 2014 14:40 UTC (Mon) by khim (subscriber, #9252) [Link]

Please read comments to the article, too. If your module only uses EXPORT_SYMBOL symbols then it does not automatically mean that your module is not derived work, but it's true when used in other directions, too: the mere use of EXPORT_SYMBOL_GPL symbol does not make your code a derived work (after all most other symbols eventually use symbols marked as EXPORT_SYMBOL_GPL after few layers of indirection). Apparently ktime_get is marked as EXPORT_SYMBOL_GPL not because it does something kernel-intimate by itself. No. It's because for effective use it needs some other supporting functions which can not be used without embedding these inline functions which come from kernel (and thus are GPLed) into your module. And these functions are indeed embedded… into a shim. Which is GPLed. The “stable tracing ABI” then can be used without embedding anything like that into your CDDL-licensed (or even proprietary) module. I still don't see what's your problem, sorry.

Garrett: Oracle continue to circumvent EXPORT_SYMBOL_GPL()

Posted May 12, 2014 15:11 UTC (Mon) by dskoll (subscriber, #1630) [Link] (25 responses)

I don't believe you can use shims to get around GPL requirements. This is covered here in the FSF's Frequently Asked Questions about GNU Licenses page.

Garrett: Oracle continue to circumvent EXPORT_SYMBOL_GPL()

Posted May 12, 2014 16:18 UTC (Mon) by khim (subscriber, #9252) [Link] (24 responses)

Read the previous question in the very some FAQ you've cited.

Thats why “stable tracing ABI” (theoretically supportable by other kernels besides Linux) is important in the scheme outlined above: it basically separates D-Trace module and kernel and makes them effectively independent parts. This is similar to NDISwrapper: it injects modules in the kernel address space, true, but these modules are, nonetheless, separate creations which have nothing to do with Linux kernel whatsoever.

Garrett: Oracle continue to circumvent EXPORT_SYMBOL_GPL()

Posted May 12, 2014 17:11 UTC (Mon) by dskoll (subscriber, #1630) [Link] (23 responses)

I read that question. I don't think that the D-Trace module and the kernel "communicate at arms length". I think that once you install D-Trace into the kernel, they are "effectively a single program" in the sense intended by the GPL.

NDISwrapper is a different case. The final combining of the Linux kernel and the proprietary network driver is done by the end-user. This combined system is never redistributed by the end-user; it's merely used by the end-user.

The GPL places no restrictions on combining GPL'd software and proprietary software. It only kicks in if you attempt to distribute such a combination.

Garrett: Oracle continue to circumvent EXPORT_SYMBOL_GPL()

Posted May 12, 2014 17:37 UTC (Mon) by khim (subscriber, #9252) [Link] (22 responses)

I think that once you install D-Trace into the kernel, they are "effectively a single program" in the sense intended by the GPL.

It does not matter what happens when you run the program. GPL explicitly states that the act of running the Program is not restricted and nobody distributes this combination.

NDISwrapper is a different case. The final combining of the Linux kernel and the proprietary network driver is done by the end-user. This combined system is never redistributed by the end-user; it's merely used by the end-user.

D-Trace is in the same boat. The only difference is that it's distributed on the same CD (or DVD) as the appropriate kernel. Will that make the whole combination illegal or nor in the important question. And that will depend on the properties of the “stable tracing ABI”: if it's well-defined enough to make these two pieces essentially separate then “mere aggregation” clause is automatically applicable. If not, then yes, Oracle is in trouble. I doubt anyone will say for sure if “stable tracing ABI” is well-defined enough without actual visit to the court.

Garrett: Oracle continue to circumvent EXPORT_SYMBOL_GPL()

Posted May 12, 2014 18:07 UTC (Mon) by dskoll (subscriber, #1630) [Link] (18 responses)

I see what you're getting at... you're claiming that distributing D-Trace with the kernel is "mere aggregation". I don't buy it. Otherwise, you could say distributing a proprietary piece of software as a shared library is "mere aggregation" even if every time you run the software, it dynamically links the proprietary piece into a GPL'd program.

I think that it would take a court decision to determine whether or not this is "mere aggregation".

Garrett: Oracle continue to circumvent EXPORT_SYMBOL_GPL()

Posted May 12, 2014 18:35 UTC (Mon) by sfeam (subscriber, #2841) [Link] (16 responses)

"Otherwise you could say..."
You can indeed say that, and many people would agree with that statement. Let us stipulate that the proprietary license is OK with the distribution. If it is only the dynamic linking that arguably creates a derived work, since that is done by the end user and not by the distributor the GPL doesn't forbid it either. The "mere aggregation" clause is only relevant if the creation of a derived work happens prior to distribution.

Garrett: Oracle continue to circumvent EXPORT_SYMBOL_GPL()

Posted May 12, 2014 19:39 UTC (Mon) by dskoll (subscriber, #1630) [Link] (14 responses)

You can indeed say that, and many people would agree with that statement

Those people would most likely lose a lawsuit. See this issue's section in the GPL FAQ

The GPL v2.0 says: "This General Public License does not permit incorporating your program into proprietary programs. If your program is a subroutine library, you may consider it more useful to permit linking proprietary applications with the library. If this is what you want to do, use the GNU Lesser General Public License instead of this License."

The GPL v3.0 says: The "Corresponding Source" for a work in object code form means all the source code needed to generate, install, and (for an executable work) run the object code and to modify the work, including scripts to control those activities. However, it does not include the work's System Libraries, or general-purpose tools or generally available free programs which are used unmodified in performing those activities but which are not part of the work. For example, Corresponding Source includes interface definition files associated with source files for the work, and the source code for shared libraries and dynamically linked subprograms that the work is specifically designed to require, such as by intimate data communication or control flow between those subprograms and other parts of the work.

Garrett: Oracle continue to circumvent EXPORT_SYMBOL_GPL()

Posted May 12, 2014 19:48 UTC (Mon) by khim (subscriber, #9252) [Link] (13 responses)

Let's not pretend to be a lawers and try to predict outcome of the lawsuit. There are GPL FAQ but there are clarification from Linux developers, too which explicitly says: This copyright does *not* cover user programs that use kernel services by normal system calls - this is merely considered normal use of the kernel, and does *not* fall under the heading of "derived work".

If system calls interface (arguably designed by kernel developers and included with kernel) act as a “derived work” boundary for the purpose of GPL enforcement then why another, similar, boundary can not be created by another explicit and well-defined ABI boundary?

Various FAQs tend to have less weigth than words for actual copyright holders.

Garrett: Oracle continue to circumvent EXPORT_SYMBOL_GPL()

Posted May 12, 2014 20:31 UTC (Mon) by dskoll (subscriber, #1630) [Link] (12 responses)

If system calls interface ... act as a "derived work" boundary for the purpose of GPL enforcement then why another, similar, boundary can not be created by another explicit and well-defined ABI boundary?

Another similar boundary could indeed be created. But it was not. Presumably, the kernel developers selected "normal system calls" as a boundary for a very good reason, and also presumably they omitted to mention internal kernel functions as a boundary for another very good reason.

Garrett: Oracle continue to circumvent EXPORT_SYMBOL_GPL()

Posted May 12, 2014 21:29 UTC (Mon) by khim (subscriber, #9252) [Link] (11 responses)

But CDDL-copyrighted module does not use internal kernel functions directly! So why are you trying to misinterpret the whole thing as if they do that?

Garrett: Oracle continue to circumvent EXPORT_SYMBOL_GPL()

Posted May 12, 2014 22:06 UTC (Mon) by dskoll (subscriber, #1630) [Link] (10 responses)

Again: You cannot circumvent the GPL by inventing a permissively-licensed shim between your proprietary code and someone else's GPL'd code if the resulting work is considered by the courts to be a derived work from the GPL'd code.

You cannot work around the law with technological tricks.

Now, as to whether (Linux Kernel + shim + D-Trace) is a derived work of (Linux Kernel)... that's a matter of opinion. I think it is, but no-one can know for sure unless it's settled in court.

Garrett: Oracle continue to circumvent EXPORT_SYMBOL_GPL()

Posted May 12, 2014 22:15 UTC (Mon) by khim (subscriber, #9252) [Link] (9 responses)

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?

Garrett: Oracle continue to circumvent EXPORT_SYMBOL_GPL()

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.

Garrett: Oracle continue to circumvent EXPORT_SYMBOL_GPL()

Posted May 13, 2014 1:04 UTC (Tue) by khim (subscriber, #9252) [Link] (7 responses)

You are going round in circles.

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.

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.

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.

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.

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.

Garrett: Oracle continue to circumvent EXPORT_SYMBOL_GPL()

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?

Garrett: Oracle continue to circumvent EXPORT_SYMBOL_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.

Garrett: Oracle continue to circumvent EXPORT_SYMBOL_GPL()

Posted May 13, 2014 16:39 UTC (Tue) by khim (subscriber, #9252) [Link]

Post from Linus Torvalds makes perfect sense. Indeed if you'll just create a dummy shim which just reexports _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()

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.

Garrett: Oracle continue to circumvent EXPORT_SYMBOL_GPL()

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: 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.

But here is the catch: just how are these high-level 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.

Now you come along and basically claim: intent matters! If “kernel gods” are creating module which uses 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!

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.

Garrett: Oracle continue to circumvent EXPORT_SYMBOL_GPL()

Posted May 13, 2014 18:06 UTC (Tue) by niner (subscriber, #26151) [Link]

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()

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()

Posted May 12, 2014 19:41 UTC (Mon) by khim (subscriber, #9252) [Link]

Distribution (== contents of a CD, DVD or a box) includes both D-Trace and kernel thus by definition it's either a compilation or a derived work. If “mere aggregation” clause does not work then it's obviously because it's a derived work and thus can not be distributed.

Garrett: Oracle continue to circumvent EXPORT_SYMBOL_GPL()

Posted May 20, 2014 22:07 UTC (Tue) by rich0 (guest, #55509) [Link]

Otherwise, you could say distributing a proprietary piece of software as a shared library is "mere aggregation" even if every time you run the software, it dynamically links the proprietary piece into a GPL'd program.

Sure, what's wrong with that? Nothing in the GPL says you can't call a piece of code which isn't licensed under the GPL. Every time I run a program from bash I do that all the time. Linking to something doesn't create a derived work. After you're done reading this post you should go read page 5 of Starship Troopers! Did I just violate Heinlein's copyright? Is this post a derived work of Starship Troopers, simply because I referenced an exported symbol from it (a page number)?

Garrett: Oracle continue to circumvent EXPORT_SYMBOL_GPL()

Posted May 12, 2014 18:17 UTC (Mon) by bfields (subscriber, #19510) [Link] (2 responses)

And that will depend on the properties of the “stable tracing ABI”: if it's well-defined enough to make these two pieces essentially separate then “mere aggregation” clause is automatically applicable.

I'm not an expert at all, but this strikes me as a pretty permissive take on the "mere aggregation" clause. See e.g. this GPLv2 FAQ, or take another look at the surrounding license language.

Garrett: Oracle continue to circumvent EXPORT_SYMBOL_GPL()

Posted May 12, 2014 19:53 UTC (Mon) by khim (subscriber, #9252) [Link] (1 responses)

Even in your FAQ: if modules are designed to run linked together in a shared address space, that almost surely means combining them into one program.

“Almost surely” does not mean “always”. And if ABI was specifically and carefully designed to make sure that two modules don't act as one program even if they share the address space… no, situation is not as clear cut as you want to portray it. Not clear-cut at all.

Garrett: Oracle continue to circumvent EXPORT_SYMBOL_GPL()

Posted May 12, 2014 22:09 UTC (Mon) by dskoll (subscriber, #1630) [Link]

It's pretty clear-cut. The (shim + D-Trace) is completely non-functional. However, (Linux + shim + D-Trace) is a very functional program. I cannot see how anyone can claim that the combination of (Linux + shim + D-Trace) is not a derived work of the Linux kernel.

The kernel maintainers do AFAIK permit proprietary kernel modules providing such modules don't use GPL-only symbols. If the kernel maintainers intended to allow proprietary modules to use any kernel symbol at all, then why on earth would they have created the GPL-only symbol machinery?

Garrett: Oracle continue to circumvent EXPORT_SYMBOL_GPL()

Posted May 12, 2014 16:26 UTC (Mon) by nye (subscriber, #51576) [Link]

So, there are three components:

1) Linux
2) DTrace
3) This shim they're talking about

And there is one underlying assumption: that the shim uses use copyrightable APIs from both Linux and DTrace, ie. that the interface on both 'sides' is so implementation-specific that it must be considered derivative of that implementation (as MJG asserts is true of the Linux <-> shim side).
Note: It might be reasonably argued that the API defined between DTrace and the shim is sufficiently abstracted that the shim should not be considered a derivative work of DTrace, but I shall not make that argument here.

Clearly, neither Linux nor DTrace are in any way derivative works of the other - they were developed entirely independently.

The shim, however, must (based on our assumption) be derivative works of both. If you or I were to make or distribute such a shim, it would be illegal, since it would have to honour both the GPL and the CDDL, which are mutually incompatible.

But note that, as the copyright holder, Oracle is not required to adhere to the license for DTrace; they can create derivative works under whatever license they like since they can't violate their own copyrights on DTrace. They can distribute Linux and the shim under the GPL, and they can distribute DTrace under whatever license they like, since it is derivative of neither of the other two components.

Hence, so long as the shim is GPL (or compatible, such that the resulting combination of Linux and the shim can be GPL), Oracle would appear to be in the clear, with the 'unfortunate' side effect that it is probably illegal (if our assumption holds true) for anyone else to redistribute it.

Garrett: Oracle continue to circumvent EXPORT_SYMBOL_GPL()

Posted May 12, 2014 13:29 UTC (Mon) by farnz (subscriber, #17727) [Link] (1 responses)

And Oracle's claim in their case against Google is that such behaviour is never "mere happenstance"; it's reckless of an organisation to let it happen at all, and shows that an organisational culture lacks proper respect for copyright.

Now, I happen to think that such a claim is hyperbole at best, but for Oracle to be making such claims about Google, then doing something similar themselves is not a good place to be in.

Garrett: Oracle continue to circumvent EXPORT_SYMBOL_GPL()

Posted May 12, 2014 14:22 UTC (Mon) by khim (subscriber, #9252) [Link]

And Oracle's claim in their case against Google is that such behaviour is never "mere happenstance"; it's reckless of an organisation to let it happen at all, and shows that an organisational culture lacks proper respect for copyright.

They are talking about names of variables and functions, not about the math involved. Math is often the same because, you know, it's a math, there are relatively few ways to do the same thing. But names… that's different kettle of fish: very rarely two independently written pieces of code will use the same name for the same things. Thus indeed it'll be strange to accidentally see the same names in “stable tracing ABI” and in “kernel ABI”. But dtrace_gethrtime and ktime_get have only two common English words in common - and they don't even come in the same order, so what's your problem?

Think about it this way: math is uncopyrightable because, well, it's “law of nature”. But actual text of the theorem is very much copyrightable. If someone proves the same theorem independently using their own terms and names then both authors often are regarded as original discoverers: people don't see anything wrong with that. But if someone borrows text of the theorem as whole and tries to publish it under their own name then it's called “plagiarism”, can lead to huge amount of stink, and people usually aren't ready to believe in the claim that “it's the same math and that is why 50 pages of text are letter-by-letter identical in our case”.

Garrett: Oracle continue to circumvent EXPORT_SYMBOL_GPL()

Posted May 12, 2014 17:14 UTC (Mon) by Cyberax (✭ supporter ✭, #52523) [Link] (2 responses)

Intention counts.

The shim is written for an express purpose of running DTrace. It doesn't have any other significant users. An argument could be made that it's in fact a part of DTrace and thus GPL covers the whole DTrace kernel-space code.

Garrett: Oracle continue to circumvent EXPORT_SYMBOL_GPL()

Posted May 12, 2014 18:00 UTC (Mon) by khim (subscriber, #9252) [Link]

Intent indeed counts, but without an actual court case it's impossible to say how much it counts. It's true that shim does not have any other significant users. But it's not important. What's important is other question: could it have other users? Is it well-defined enough for that? And as you guess oponions on that front are quite different.

Garrett: Oracle continue to circumvent EXPORT_SYMBOL_GPL()

Posted May 14, 2014 21:13 UTC (Wed) by Wol (subscriber, #4433) [Link]

The other thing to bear in mind is whether dtrace on linux is *the* *same* as dtrace on Solaris.

The netwotsit example is crucial here. Here we have a kernel shim (GPL) for the purpose of running windows binaries to drive a network card. I actually can't see any reason here why such a shim shouldn't use EXPORT_SYMBOL_GPL - the windows code clearly isn't a derivative of the kernel.

If dtrace is the same on both linux and solaris, then the same argument applies. If, however, dtrace has been significantly modified to work on linux (as seems likely), then that argument breaks down. The modifications are a clear indication of "derivativeness", and a shim that use EXPORT_SYMBOL_GPL is a clear attempt to get round the explicit indications of the copyright holders. Should a court agree that dtrace is derivative, then the use of such symbols makes a finding of copyright infringement pretty much a slam-dunk.

Cheers,
Wol

Garrett: Oracle continue to circumvent EXPORT_SYMBOL_GPL()

Posted May 12, 2014 20:01 UTC (Mon) by joncbender (guest, #82805) [Link]

My copy of dtrace-modules is distributed under CDDL. The only mention of GPL in the source tree is:
- The minimal cyclic implementation has been removed from the DTrace modules because it is now provided by an equivalent GPL impementation in the core kernel.
- Functionality that depends on walking the stack (determining stack depth, or collecting a backtrace) is now provided by a GPL implementation in the core kernel.

The code is from http://public-yum.oracle.com/repo/OracleLinux/OL6/UEKR3/l...

This sound like the nvdia driver

Posted May 12, 2014 19:29 UTC (Mon) by jhhaller (guest, #56103) [Link] (18 responses)

DTrace was originally written for Solaris, and was not a derived work at that point.

If, and this is a big if, the shim layer only translates Solaris calls DTrace makes into their Linux equivalents, then DTrace remains independent of Linux and not a derived work. The shim layer is obviously a derived work of Linux, and a derived work of DTrace (or Solaris) as it is implementing APIs DTrace expects.

How is this different from the nvidia driver?

This sound like the nvdia driver

Posted May 12, 2014 19:30 UTC (Mon) by Cyberax (✭ supporter ✭, #52523) [Link] (8 responses)

NVidia driver does not depend on GPL-only symbols.

This sound like the nvdia driver

Posted May 12, 2014 19:33 UTC (Mon) by jhhaller (guest, #56103) [Link] (6 responses)

But, does that really matter? Either it's a derived work or it isn't. Just because it's using a facility in Solaris that is only available in Linux as _GPL still wouldn't make it a derived work.

This sound like the nvdia driver

Posted May 12, 2014 19:38 UTC (Mon) by Cyberax (✭ supporter ✭, #52523) [Link] (5 responses)

_GPL is a statement from developers that they believe it's impossible NOT to create a derived work by using GPL-only symbols. Of course, a court might override it.

But in this case Oracle's own arguments that API is copyrightable undermines this argument. There's no way in hell that DTrace-on-Linux is NOT a derivative work of Linux kernel _API_. And they have no license for this.

This sound like the nvdia driver

Posted May 12, 2014 20:00 UTC (Mon) by khim (subscriber, #9252) [Link] (4 responses)

_GPL is a statement from developers that they believe it's impossible NOT to create a derived work by using GPL-only symbols.

The relation “if module uses this _GPL symbol then it must be so intimately tied to kernel that it's impossible to make it non-derived work” is non-transitive (othwerwise it'll make no sense: all modules are tied directly or indirectly to kernel proper which obviously uses _GPL symbols).

And shim is GPL-licensed, so… what's your problem?

This sound like the nvdia driver

Posted May 12, 2014 20:04 UTC (Mon) by Cyberax (✭ supporter ✭, #52523) [Link] (3 responses)

That flies out of the window if APIs themselves are copyrighted.

If DTrace has "#include <linux/kernel.h>" somewhere in its source code then it's a derived work of Linux _API_. And in this case they can't argue about 'mere aggregation' - their code is not functional without Linux API and they don't have a license for it.

Moreover, even NVidia loophole with local compilation is not available for them because they ship already compiled code.

PS: please note, that userspace use of Linux kernel headers is explicitly allowed by Linux kernel developers.

This sound like the nvdia driver

Posted May 12, 2014 21:28 UTC (Mon) by khim (subscriber, #9252) [Link] (2 responses)

PS: please note, that userspace use of Linux kernel headers is explicitly allowed by Linux kernel developers.

Really? News to me. For such “explicit grant” to be meaningful just in one, very narrow case it must be added to the license. Like this. If/when kernel developers clarify that they don't think that inclusion of kernel headers from userspace program makese them derived work of kernel but not explicitly change the license they are creating precedent which can be applied to D-Trace equally well.

This sound like the nvdia driver

Posted May 12, 2014 21:41 UTC (Mon) by Cyberax (✭ supporter ✭, #52523) [Link] (1 responses)

True, there's no explicit grant because developers have always assumed that API itself is not copyrightable.

However, various countries' contract laws have a notion of 'convention estoppel' ( http://en.wikipedia.org/wiki/Estoppel#Convention ).

It has always been a common knowledge among Linux developers that userspace API usage of which kernel headers are a part does not make a derived work. Indeed, kernel developers even took pains to make kernel headers usable for userspace software from early days of Linux.

This sound like the nvdia driver

Posted May 12, 2014 22:06 UTC (Mon) by khim (subscriber, #9252) [Link]

Indeed. But if grant is implicit and not explicit then one can not just go an say “it's Ok to do #include <linux/kernel.h> in userspace program and it does not make your program a derivative of kernel but it's not Ok to do #include <linux/kernel.h> in your module because it does make you module a derivative of kernel”, because, you see, these lines are identical and if you have no formal grant in writing which exludes one yet permits another then you'll need to prove that they, indeed, are materially different.

This sound like the nvdia driver

Posted May 12, 2014 20:03 UTC (Mon) by PaXTeam (guest, #24616) [Link]

as of 3.14 it actually does if you have CONFIG_DEBUG_VM enabled due to EXPORT_SYMBOL_GPL(dump_page).

This sound like the nvdia driver

Posted May 12, 2014 23:15 UTC (Mon) by jhhaller (guest, #56103) [Link] (8 responses)

Well, I did the hard work and looked at dtrace source (not the shim), which does have some include of Linux headers which are not replicated in the Oracle source. For example the idr routines defined in linux/idr.h are called by at least: dtrace/dtrace_probe.c.

So, this implementation of DTrace is using Linux kernel headers, and calling some Linux kernel functions directly and not through the shim.

Had the module been limited to using Solaris definitions and interfaces, or even moved to a source/shim model for both Solaris and Linux, I think it would have been possible to say the module was definitely not a derivative work. But, using Linux kernel APIs directly leaves it open to question.

One technical change which could be made would be to force all symbols declared in a GPL module to be GPL only, preventing a GPL module from exporting symbols to a a non-GPL module. Going full circle back to the original post, it would require the nvidia shim to use a license other than GPL (like BSD) to be able to export symbols to their binary module, and prevent them from using any GPL only APIs in their shim. This would have the unintentional effect of breaking non-GPL modules using symbols in a GPL module which would work if that module had been compiled in, so it would be nice for this restriction to not apply to GPL modules which are part of the standard kernel build.

This sound like the nvdia driver

Posted May 12, 2014 23:43 UTC (Mon) by dlang (guest, #313) [Link] (4 responses)

remember that the Oracle lawsuit was about using headers that were declared in GPL files.

This sound like the nvdia driver

Posted May 13, 2014 1:06 UTC (Tue) by khim (subscriber, #9252) [Link] (3 responses)

Not even close. Oracle lawsuit is about taking bits and pieces from GPL-licensed headers, adding some other bits and pieces and slapping different license on top of the result. AFAICS Oracle does not try to change Linux headers and slap CDDL on top of them.

This sound like the nvdia driver

Posted May 13, 2014 5:27 UTC (Tue) by Cyberax (✭ supporter ✭, #52523) [Link] (2 responses)

Google has NOT copied any code from Oracle's Java (apart from a trivial rangeCheck).

Oracle insists that the mere use of an API definition makes a derived work. And it follows that ALL kernel modules will now require a valid license chain the second they #include any kernel code. And Oracle uses Linux API in their DTrace code directly, without any shims.

Yet they have no license for it. _GPL symbols are merely an icing on the cake.

NVidia might still get away with their module, since they made sure to be independent from ANY Linux API in their proprietary code. They only use a shim, which is also implemented for many other platforms (FreeBSD, Solaris, Windows and I think QNX).

This sound like the nvdia driver

Posted May 14, 2014 6:20 UTC (Wed) by kugel (subscriber, #70540) [Link] (1 responses)

> Oracle insists that the mere use of an API definition makes a derived work. And it follows that ALL kernel modules will now require a valid license chain the second they #include any kernel code. And Oracle uses Linux API in their DTrace code directly, without any shims.

It insists that *reimplementation* (not use) of an API infringes copyright (by being derivate work?). The mere use would require all Java programs to be open source.

This sound like the nvdia driver

Posted May 14, 2014 6:24 UTC (Wed) by Cyberax (✭ supporter ✭, #52523) [Link]

Nope. A mere use is sufficient, since Oracle thinks that an API is copyrightable.

Regular programs are fine, because they have a license from Sun/Oracle permitting the API use - both GPL with a Classpath exception and Sun/Oracle's proprietary licenses grant a right to _use_ Java APIs.

This sound like the nvdia driver

Posted May 13, 2014 1:17 UTC (Tue) by khim (subscriber, #9252) [Link]

One technical change which could be made would be to force all symbols declared in a GPL module to be GPL only, preventing a GPL module from exporting symbols to a a non-GPL module.

This will be incredibly stupid change because if you'll apply this rule to kernel core then you'll find out that only _GPL symbols and GPL modules can ever exist and if don't apply it to kernel core then suddenly you'll have inconsistent rules for the bits of the very same program. Remember that these symbols exist in the first place to catch modules which are so intimately intermixed with kernel that they should be considered part of it… and if they are part of it then why suddenly different rules?

This sound like the nvdia driver

Posted May 20, 2014 22:17 UTC (Tue) by rich0 (guest, #55509) [Link] (1 responses)

> One technical change which could be made would be to force all symbols
> declared in a GPL module to be GPL only, preventing a GPL module from
> exporting symbols to a a non-GPL module.

So, then just mark the module as "GPL" in the data read by the kernel and then in the accompanying text state clearly that the module is not licensed GPL and is only marked as such for interoperability. Courts have already ruled that playing games like this with IP law basically makes your IP impossible to enforce. For example, the original Nintendo Gameboy would refuse to run a game which did not display the Nintendo trademark when it loaded, so a 3rd party just put the Nintendo trademark on their game without permission, Nintendo sued them, and the courts threw it out on the basis that Nintendo was the one who forced them to do things that way.

I don't get the argument that if A imports symbols from B then A is a derived work of B. I can see that A+B is a derived work of A, but B alone isn't unless you buy the whole APIs-are-copyrightable nonsense. Symbols are just cross-references - how is referencing something a copyright violation? That is right up there with the whole deep-linking debate.

Sure, I'd love to live in a world where it wasn't legal to run non-free software on Linux, but that desire doesn't really make it legally enforceable.

This sound like the nvdia driver

Posted May 20, 2014 22:27 UTC (Tue) by sfeam (subscriber, #2841) [Link]

Sure, I'd love to live in a world where it wasn't legal to run non-free software on Linux, but that desire doesn't really make it legally enforceable.
Why would you want to live in a world where linux is less useful? Making it outright illegal to run non-free software is beyond the most rabid rantings I've ever heard. You don't want to run it? Fine - don't run it.