![[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.
no subject
Date: 2014-05-11 03:32 pm (UTC)no subject
Date: 2014-05-11 03:36 pm (UTC)no subject
Date: 2014-05-11 04:26 pm (UTC)Our experience is that EXPORT_SYMBOL_GPL gets slapped on all sorts of things essentially at random, including interfaces for which you can't make any coherent claim that they're more of a copyright violation than many others not similarly tagged. Symbols that were available in previous versions are often withdrawn behind the EXPORT_SYMBOL_GPL barrier unless people complain (a lot), despite Linus's previous guarantee that this wouldn't be done. It's basically a complete mess from the perspective of a third-party, open-source kernel module developer (and relicensing OpenAFS is a giant disaster that won't ever happen, for reasons that aren't worth getting into).
The kernel definitely does not have clean hands here.
no subject
Date: 2014-05-11 06:39 pm (UTC)This is not simple.
Date: 2014-05-12 08:38 am (UTC)It is important that external modules do declare what functions they are using. Lot of symbols have been pulled behind EXPORT_SYMBOL_GPL because they were going to be deprecated.
ktime_get() is in fact not declared in any Linux kernel header file.
http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/include/linux/ktime.h
Yes no ktime_get(). So it is a pure internal Linux kernel function. You have to manually declare it where ever you wish to use it. Then you notice its support functions are all inline.
Please be warned inlined and being a different License to GPL does not work.
dtrace_getwalltime is using the in-lined function timespec_to_ktime.
Yes Matthew Garrett point to possible issue but the reality there is a solid issue in the dtrace_getwalltime the resulting binary is a mix of GPL an Non GPL code that is not legal. All because someone missed the inline.
Yes this is the problem with a lot of those EXPORT_SYMBOL_GPL its not always the function that spits this that is the problem. Sometime it can be that all the support functions around that are inline.
I'm torn
Date: 2014-05-11 06:47 pm (UTC)Now that Brendan Gregg works for Netflix, if dtrace support gets to a good point (one that doesn't actually crash or impede the runtime of the kernel), we can presume that we might see a dtrace toolkit for Linux (and hopefully by now not one that relies on non-portable function boundary tracing).
Not a fan of Oracle…
Date: 2014-05-11 07:01 pm (UTC)Re: Not a fan of Oracle…
Date: 2014-05-12 02:01 am (UTC)They could pay Sun to develop software for them but they decided they will do it themselves from scratch. This is something worth debating about but what was done was done. From business perspective they made the right call or they could buy Sun at that time. This is vital part of their product and i do see why they want to have it developed in-hause.
Oracle can take Dalvik back if they claim (some part of it) it got stolen by Google. The licence doesn't prevent this it never has. If Oracle would do that and they would be successful in monetizing Dalvik would you say they have stolen Dalvik from Google?
Does Red Hat steal from other Linux vendors because they are successful making money building on top of Linux? Does Oracle steal from Red Hat because they use Linux?
Somebody would just have to explain this to the judges before they went and made this irrational decision. How can you steal Linux for example if nothing is preventing you to take it and build your product on top of it in the first place. This is how business is done in this days and you are not stealing if you make money doing it like that. Oracle does it like that just look at their product portfolio. Do they steal from Red Hat? What would the judge say on that? I imagine some judges would say yes indeed Oracle is stealing from Red Hat for example but judges like that should not take cases like this in the first place but should left the decision to other judges that actually understand what they are judging about.
Re: Not a fan of Oracle…
Date: 2014-05-13 06:38 am (UTC)Re: Not a fan of Oracle…
Date: 2014-05-13 04:41 pm (UTC)http://www.cnet.com/news/former-sun-ceo-says-googles-android-didnt-need-license-for-java-apis/
The story should end there and everything else is pure media driven PR from Oracle and alike that got you convinced Google actually had stole something. You are listing things Google didn't use for example it didn't use Java in any form they made Dalvik from scratch. If i am not mistaken true 1 single LOC was found in few million LOC but was already removed. They "stole" 1 LOC imagine that.
Bottom line Google didn't steal anything. Probably the judges that made this ruling are aware of this fact. I imagine as this is USA they went with Oracles bluff to send a message API can indeed be copyrighted but in my opinion they are aware Google didn't steal any APIs from Sun.
The problem here is Oracle and this Judges made precedent ruling that could open doors for abuse in the future. But then again maybe this same Judges would make a different more common sense ruling when it would come to some specific software projects and would say sure some APIs where copyrighted but use of them is fair use to preserve compatibility. I don't know i guess we will just have to wait and see if something like that happens in the future.
Re: Not a fan of Oracle…
Date: 2018-02-21 09:18 pm (UTC)Not just Oracle
Date: 2014-05-11 09:45 pm (UTC)Re: Not just Oracle
Date: 2014-05-12 01:07 am (UTC)Re: Not just Oracle
Date: 2014-05-12 04:21 pm (UTC)Re: Not just Oracle
Date: 2014-05-12 10:01 pm (UTC)1 Nvidia driver does include a wrapper source that is GPL with binary linking exceptions. With Nvidia the dtrace linking functions to be exported would be in this file so maintaining the GPL status. The inline issue is vastly legally reduced in this case. Basically the GPL flag is thrown by a function its time to consider a duel license or extended license GPL.
2 Nvidia when they need a function request it formally put on the exported list even if it means reduced hardware support until it is.
Nvidia is well behaved legally yet still annoying on limiting support.
Eh... It's a timer
Date: 2014-05-11 10:07 pm (UTC)Re: Eh... It's a timer
Date: 2014-05-12 01:15 am (UTC)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.
Re: Eh... It's a timer
Date: 2014-05-13 11:13 am (UTC)Re: Eh... It's a timer
Date: 2014-05-12 08:48 am (UTC)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.
Re: Eh... It's a timer
Date: 2014-05-12 10:07 am (UTC)You can't violate a copyright if you're not distributing anything.
Re: Eh... It's a timer
Date: 2014-05-12 11:15 am (UTC)Re: Eh... It's a timer
Date: 2014-05-12 11:15 am (UTC)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).
Re: Eh... It's a timer
Date: 2014-05-12 03:44 pm (UTC)Re: Eh... It's a timer
Date: 2014-05-18 12:03 pm (UTC)Re: Eh... It's a timer
Date: 2014-05-13 01:49 am (UTC)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.
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.
no subject
Date: 2014-05-13 03:15 am (UTC)Wouldn't that make using or distributing such a circumvention device would be a criminal act under the DMCA? It wouldn't even matter if using the API was a copyright infringement or not, since the DMCA deals with the act of circumvention itself.
It doesn't matter
Date: 2014-05-24 02:55 am (UTC)