mjg59 | Oracle continue to circumvent EXPORT_SYMBOL

Oracle won their appeal regarding whether APIs are copyrightable. There'll be ongoing argument about whether Google's use of those APIs is fair use or not, and perhaps an appeal to the Supreme Court, but that's the new status quo. This will doubtless result in arguments over whether Oracle's implementation of Linux APIs in Solaris 10 was a violation of copyright or not (and presumably Google are currently checking whether they own any code that Oracle reimplemented), but that's not what I'm going to talk about today.

Oracle own some code called DTrace (Wikipedia has a good overview here - what it actually does isn't especially relevant) that was originally written as part of Solaris. When Solaris was released under the CDDL, so was DTrace. The CDDL is a file-level copyleft license with some restrictions not present in the GPL - as a result, combining GPLed code with CDDLed code will (in the absence of additional permission grants) result in a work that is under an inconsistent license and cannot legally be distributed.

Oracle wanted to make DTrace available for Linux as part of their Unbreakable Linux product. Integrating it directly into the kernel would obviously cause legal issues, so instead they implemented it as a kernel module. The copyright status of kernel modules is somewhat unclear. The GPL covers derivative works, but the definition of derivative works is a function of copyright law and judges. Making use of explicitly exported API may not be sufficient to constitute a derivative work - on the other hand, it might. This is largely untested in court. Oracle appear to believe that they're legitimate, and so have added just enough in-kernel code (and GPLed) to support DTrace, while keeping the CDDLed core of DTrace separate.

The kernel actually has two levels of exposed (non-userspace) API - those exported via EXPORT_SYMBOL() and those exported via EXPORT_SYMBOL_GPL(). Symbols exported via EXPORT_SYMBOL_GPL() may only be used by modules that claim to be GPLed, with the kernel refusing to load them otherwise. There is no technical limitation on the use of symbols exported via EXPORT_SYMBOL().

(Aside: this should not be interpreted as meaning that modules that only use symbols exported via EXPORT_SYMBOL() will not be considered derivative works. Anything exported via EXPORT_SYMBOL_GPL() is considered by the author to be so fundamental to the kernel that using it would be impossible without creating a derivative work. Using something exported via EXPORT_SYMBOL() may result in the creation of a derivative work. Consult lawyers before attempting to release a non-GPLed Linux kernel module)

DTrace integrates very tightly with the host kernel, and one of the things it needs access to is a high-resolution timer that is guaranteed to monotonically increase. Linux provides one in the form of ktime_get(). Unfortunately for Oracle, ktime_get() is only exported via EXPORT_SYMBOL_GPL(). Attempting to call it directly from the DTrace module would fail.

Oracle work around this in their (GPLed) kernel abstraction code. A function called dtrace_gethrtimer() simply returns the value of ktime_get(). dtrace_gethrtimer() is exported via EXPORT_SYMBOL() and therefore can be called from the DTrace module.

So, in the face of a technical mechanism designed to enforce the author's beliefs about the copyright status of callers of this function, Oracle deliberately circumvent that technical mechanism by simply re-exporting the same function under a new name. It should be emphasised that calling an EXPORT_SYMBOL_GPL() function does not inherently cause the caller to become a derivative work of the kernel - it only represents the original author's opinion of whether it would. You'd still need a court case to find out for sure. But if it turns out that the use of ktime_get() does cause a work to become derivative, Oracle would find it fairly difficult to argue that their infringement was accidental.

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.

Flat | Top-Level Comments Only

As someone who does a lot of GPL and commercial linux work, I can't understand how a timer can be considered as GPL. Perhaps I'm wrong - isn't this essentially wrapping a hardware timer?

I think we should all feel a bit humbled in our arm chair lawyering today. Why would an API receive copyright protection?

So who is to say that wrapping a hardware timer isn't a creative act? Or consider the work of art that is ktime untion (returned by both the original and dtrace's version of the function):
http://lxr.free-electrons.com/source/include/linux/ktime.h#L46

Put that in a frame and sell it at an art gallery I say, I felt inspired by the seconds going before nanoseconds for big endian platforms. Truly a metaphor for life itself.

No idea how it's in .us, but in .de, computer programs explicitly do *not* fall under Art but under Works of Literature, with some exclusions, and an explicit mention that neither artistic measures nor quality have an effect on copyrightability.

It may well be that the API for a single timer is not copyrightable (under this ruling), but the collection of all APIs your module uses might still be. Similarly a novel or a chapter of one, or a poem, may be composed of simple enough sentences that no single sentence is worthy of copyright protection, but taken together in a given arrangement (or, if you will, "structure, sequence and organization") is a protected work. On an even lower level a novel is composed of words, none of which is likely to be copyrightable, but the whole still is.

As has been said over and over, there is no "non-GPL" and "GPL" parts of the kernel and its module API, but rather the _GPL prefix is merely a subjective expressed opinion of the author that if you use these, you are likely to be writing code that is intertwined enough with the kernel that you are likely to be creating a derived work. You still might very well be creating a derived work and thus violating the license even if you only use the non-_GPL symbols.

So, if you really *only* use the timer API, it might (or might not) be a short enough excerpt that it does not gain copyright protection, but the more of the kernel APIs you take (and that does include the non-_GPL ones, since those too are only licensed under the GPL), the more likely it is you are taking enough of it that you are in violation.

Note that there is a separate, untested argument that this ruling does not touch that actually loading your kernel module creates a work where your code and the kernel code are intertwined enough that it should be considered a derived work, in which case whoever loads it would violate the copyright of the kernel and, to the extent it's someone else than you, you would likely be liable for at least contributory infringement.

Also note that it is not the concept of timer or wrapping it that is copyrightable, but the specific way you do it, and in the case of the API the specific API you come up with. If there is only a single way or only a few ways to do it, it won't be protected. But there's ample room for creative choices there - for example, the particular names you use for the structures, fields and functions, none of which might be copyrightable in isolation. Put in another way, if two people implementing a timer API would be very unlikely to end up in the very same API (again including names, order of fields, ...), that tends to indicate that the choices are expressive enough to merit copyright protection.

The concept of a timer or a wrapped timer would be in the domain of patentability instead (but would probably fail for obviousness, which is a bar for patentability, but not for copyright). While I don't like the implications of this ruling, I do agree with the court that copyright law is clearly a more suitable fit for APIs (if they need to be protected at all) than patents, since there clearly is creative choice in how to write an API. If the API is exceedingly clever, the concepts there might warrant patent protection, but then that would not extend to the particular instance of the API, like function names.

Also note that the bar for copyrightablility is low but not nonexistent. A fairly trivial 9-line function like the rangeCheck() in this suit can already be expressive enough to be copyrightable. Presumably a similar level of expressiveness in an API would also merit copyrightability. I tend to think that the room for creative choices in a simple timer API is probably about the same as that in the rangeCheck() function, if not slightly more.

"...in which case whoever loads it would violate the copyright of the kernel..."

You can't violate a copyright if you're not distributing anything.

Yes you can, as creation of modified works is a right reserved to the copyright holder.

> You can't violate a copyright if you're not distributing anything.

If that were true then it'd not be a copyright violation to run unlicenced copies of Office.

You're confusing licencing requirements with the underlying copyright (basis).

It's not. If you legally own an unlicensed copy of office there's no copyright violation in running it.

Except that you need to circumvent DRM, which is illegal in many jurisdictions

"You can't violate a copyright if you're not distributing anything."

True until you remember Dtrace kernel object is include as part of the Orcales own Linux Distrobution. So the fact its pulled a inline code in that is GPL kernel license they have a problem. Yes they have done the distributing thing already.

The Nvidia idea of Linux interface parts in a GPL + (binary linking clause)/(incompadible license linking clause) licensed file is an extreamly good idea. To avoid the nightmares or at least migate them. In Nvidia case the breach would be minor. Annoying but minor. The GPL code was not intentionally miss licensed in using Nvidia method.

Inlining of stuff is done for performance optimisations and other things. Yes inline functions are a very fast way that you can end up tainted quickly. Yes build against 1 Linux kernel the module is perfectly safe to ship under a different license built against a different Linux kernel you can be in hell.

A lot of the GPL waning flags in the Linux kernel should be read a investage here might have a problem. Of course they appear and disappear seaming to be a random. Like cases were support functions are no longer inline it there might be no reason to keep the flag.

The problem is people look at the function that trips not the code using what it produces. Most cases it is the macros and inlines using the data the function produces where the big GPL infrignments will be. Samsung with the one file system driver was caught by something like this Oracle error. GPL what ends up in the resulting binary is just as important as what is in the source file.

Oracle continue to circumvent EXPORT_SYMBOL_GPL()

Eh... It's a timer

Re: Eh... It's a timer

Re: Eh... It's a timer

Re: Eh... It's a timer

Re: Eh... It's a timer

Re: Eh... It's a timer

Re: Eh... It's a timer

Re: Eh... It's a timer

Re: Eh... It's a timer

Re: Eh... It's a timer