![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
mjg59Oracle 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.
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.
Europe, Google, Oracle and linux
Date: 2014-05-12 01:32 pm (UTC)Re: Europe, Google, Oracle and linux
Date: 2014-05-12 03:03 pm (UTC)Nothing more annoying than sanctimonious Europeans, especially on copyright where the global treaties were mostly all their idea.
Re: Europe, Google, Oracle and linux
Date: 2014-05-12 09:47 pm (UTC)Anyway what i am trying to say is fellow Americans (USA) you have to solve this one for yourself as it does not affect the rest of the world all that much. You did it now you should clean up the mess if you don't want to deal with this and feel somebody over done it in the end.
Re: Europe, Google, Oracle and linux
Date: 2014-05-12 10:24 pm (UTC)Therefore yes in the end we all in a way should care and try to help each other as much as we can to make nonsense go away and go after common sense. About that GPL remark and EU i am not sure EU courts would not take GPL licence serious but AINAL and will leave up that to (EU) courts to decide in individual cases and express my opinion after the fact. Just like in this Oracle vs. Google ruling where USA court ruled in favour of something that is nonsense.
http://www.cnet.com/news/former-sun-ceo-says-googles-android-didnt-need-license-for-java-apis/
It was already determined Google did not steal APIs but Oracle just had to make general example out of it and persuaded USA Judges to say and send a message generally speaking API can be copyrighted. This obviously can't affect Android but could introduce troublesome practices from software vendors located in USA in the future. Hopefully this will not escalate all that much and will be quickly forgotten or over-ruled in the future. If not i guess we will just have to deal with this the best we can.
Re: Europe, Google, Oracle and linux
Date: 2014-05-13 05:48 am (UTC)You're correct its the US' fault. I don't see how if you were a lawyer for a European software company (tbh I can't think of a non-multinational software company off the top of my head) the fact that it's the US to blame would give you much comfort.
Re: Europe, Google, Oracle and linux
Date: 2014-05-13 04:54 pm (UTC)You have to get the same ruling in EU or China or Brazil... in order to say it affects the world (both GPL or Oracle API dispute). But USA is a big market and lot of IT/Software companies are from USA or do business in USA and that is why i said sure we all should care and try to help when something like this happens in USA. The same as some try to help the best they can when something that affects us one way or another in other parts of the world. Like civil right issues for examples in some parts of the world. It might not affect the whole world the same but that should not be the reason the rest of the world should not care and at least state opinion in hope it will improve something in the future.
Re: Europe, Google, Oracle and linux
Date: 2014-05-14 01:20 am (UTC)> You have to get the same ruling in EU or China or Brazil... in order to say it affects the world
Um, no you don't.
The fact that this ruling will not be enforced by the European judicial system has about no relevance to software companies. When you produce a global product you are certainly in a 'least common denominator' situation. That's true for safety rules; if a company can make one product that can be sold unmodified to every country they will do that. (So in the US you sometimes get phones like the Nexus 4 with their headphone power weakened to EU satisfaction.) But you can't hack or slightly modify your way out of APIs now being treated as copyrightable. Everyone who cares (eg anyone with money or who competes with those that have money) will reverse engineer instead of copy & paste.
Re: Europe, Google, Oracle and linux
Date: 2014-05-14 03:55 pm (UTC)Again it will likely not be enforced in the rest of the world (only USA). I would say that fact is relevant to software/hardware companies. For example if Oracle would actually succeed and phone manufactures would have to pay a fee to Oracle i guess it makes all the difference if that only applies to USA or the whole world.
But as already explained SUN CEO said Google didn't steal any APIs from them and i would imagine any sane jury will say OK judges judged APIs can be copyrighted in USA but in Google case copyright holder didn't prevent them to use them freely as they choose.
For any future rulings i hope individual cases where only compatibility is at stake jury members in USA courts will often choose compatibility over bluff. But i guess now that USA Judges added this additional burden and FUD we will just have to wait and see how individual cases presented to the USA courts will be ruled.