[personal profile] mjg59
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.

Date: 2014-05-11 03:32 pm (UTC)
From: (Anonymous)
I'm not a fan of Oracle'e, I'm not a fan of the copyrightability of APIs and I don't think Google should be found legally guilty of anything. That said, I think Google was ethically wrong in how they dealt with Sun and, following that, Oracle. Regardless, I'd say that adding GPL'd code in the kernel that changes the exportability of a symbol is just fine. Anyone is freely able to change GPL'd code and release it under the same license to do anything they like. They can remove EXPORT_SYMBOL_GPL completely if they want and then put a module on top of that. If you're willing to release and support that kernel, then you haven't _legally_ done anything wrong. Like Google though, I think you have ethical problems.

Date: 2014-05-11 04:26 pm (UTC)
eagle: Me at the Adobe in Yachats, Oregon (Default)
From: [personal profile] eagle
I'd really like to agree with you, but I have long, long experience working with this issue due to working with OpenAFS (whose implementation predated the existence of Linux, although I suppose one can argue about whether the small amount of Linux-specific code is a derivative work). It's covered by the IBM Public License, which is another GPL-incompatible license (although for less significant reasons).

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.

This is not simple.

Date: 2014-05-12 08:38 am (UTC)
From: (Anonymous)
EXPORT_SYMBOL_GPL does not exactly get done at random.

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.

Date: 2014-05-12 05:26 pm (UTC)
From: [personal profile] snits
It is resolved internally by using getrawmonotonic() since it doesn't appear the dtrace licensing is going to be changed any time soon. Due to process (to be polite) a tag with the commit hasn't been pushed to oss.oracle.com yet though it has been in the repo since the middle of March. In the worst case it will be there at the end of the month when the next quarterly update is released, but I have asked once again for tag to be pushed to oss with the fix.

I'm torn

Date: 2014-05-11 06:47 pm (UTC)
From: (Anonymous)
On one hand, I would love to see dtrace exposed in the Linux kernel. Linux is saturated with all sorts of perf-esque APIs, none of which are the de facto routine and many of which don't support dynamic tracing. On the other hand, I hate Oracle's heavy handed legal tactics and I don't trust anything they do.

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)
From: (Anonymous)
But, seriously, fuck Google. They just take anything they want and steal it.

Re: Not a fan of Oracle…

Date: 2014-05-12 02:01 am (UTC)
From: (Anonymous)
Actually they didn't steal anything. They took what was open and intended to be used by anybody and resulting product is still open and can be used by anybody.

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)
From: (Anonymous)
I think you need to recheck the licensing agreement to Java again. The issue with Google's implementation was that it was not 100% byte-code and source code compatible. Furthermore, sun restricted the java 'language'. The product was open, but the license for the Apis and language were not. It's the reason Sun and Apache got into it over the Apache VM.

Re: Not a fan of Oracle…

Date: 2014-05-13 04:41 pm (UTC)
From: (Anonymous)
Yes this is repeated over and over again but it is you who should do some checking instead. Google used APIs that much is true and Sun CEO already confirmed it was OK for Google to do that:

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.

Not just Oracle

Date: 2014-05-11 09:45 pm (UTC)
From: (Anonymous)
Isn't this how the nVidia graphics drivers work as well?

Re: Not just Oracle

Date: 2014-05-12 01:07 am (UTC)
From: (Anonymous)
No. They do not use any _GPL_ONLY symbols. Although as a poster above mentioned, symbols change at complete random and rarely have any technical reason for being GPL only or not.

Re: Not just Oracle

Date: 2014-05-12 04:21 pm (UTC)
From: (Anonymous)
In most cases it's the user themselves who downloads the nVidia driver and configures it to load into the kernel, which doesn't trigger the GPL. Only distribution of the combined works triggers the GPL.

Re: Not just Oracle

Date: 2014-05-12 10:01 pm (UTC)
From: (Anonymous)
What Nvidia Works is different.

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)
From: (Anonymous)
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?

Re: Eh... It's a timer

Date: 2014-05-12 01:15 am (UTC)
From: (Anonymous)
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.

Re: Eh... It's a timer

Date: 2014-05-13 11:13 am (UTC)
From: (Anonymous)
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.

Re: Eh... It's a timer

Date: 2014-05-12 08:48 am (UTC)
From: (Anonymous)
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.

Re: Eh... It's a timer

Date: 2014-05-12 10:07 am (UTC)
From: (Anonymous)
"...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.

Re: Eh... It's a timer

Date: 2014-05-12 11:15 am (UTC)
From: (Anonymous)
Yes you can, as creation of modified works is a right reserved to the copyright holder.

Re: Eh... It's a timer

Date: 2014-05-12 11:15 am (UTC)
From: (Anonymous)
> 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).

Re: Eh... It's a timer

Date: 2014-05-12 03:44 pm (UTC)
From: (Anonymous)
It's not. If you legally own an unlicensed copy of office there's no copyright violation in running it.

Re: Eh... It's a timer

Date: 2014-05-18 12:03 pm (UTC)
From: (Anonymous)
Except that you need to circumvent DRM, which is illegal in many jurisdictions

Re: Eh... It's a timer

Date: 2014-05-13 01:49 am (UTC)
From: (Anonymous)
"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.

Europe, Google, Oracle and linux

Date: 2014-05-12 01:32 pm (UTC)
From: (Anonymous)
Luckily, in Europe, APIs are not copyrightable, which means that Oracle has nothing against Google, and the Linux kernel developers have nothing against Oracle, to use.

Re: Europe, Google, Oracle and linux

Date: 2014-05-12 03:03 pm (UTC)
From: (Anonymous)
That has almost no real world relevance since almost no one only distributes software in Europe. Google and Oracle are clearly not part of that small group

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)
From: (Anonymous)
It is about sanctimonious Americans (USA) or more specifically sanctimonious company named Oracle that could not let go and had to prove something that could fly only in USA. And now when Oracle did this in the end it will probably not affect Andorid and Google all that much but ruling like this does open doors for potential abuse from big companies in the future.

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)
From: (Anonymous)
But sure there are a lot of companies located in USA that could be affected by this ruling and they often do not do business only in USA. There are foreign companies that would like to do business in USA.

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)
From: (Anonymous)
Name a software company that doesn't have to follow this ruling. This isn't a building code or even a food safety rule, I can't think of an industry more international than software. Well at least not as transatlantic.

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)
From: (Anonymous)
Yes this attitude is quite common. A ruling in USA affects other juridical systems. It doesn't.

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)
From: (Anonymous)
US courts rarely cite foreign court decisions (and it's sometimes controversial when they do) so TBH the reverse never occurred to me. It's certainly not common to think that foreign states abide by US court decisions. I really didn't know that's what you meant.

> 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)
From: (Anonymous)
"The fact that this ruling will not be enforced by the European judicial system has about no relevance to software companies."

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.

Date: 2014-05-13 03:15 am (UTC)
From: (Anonymous)
If APIs are copyrightable, then presumably EXPORT_SYMBOL_GPL() would have to be considered a "technological protection measure" gating access to the API. That in turn would make Oracle's shim module a circumvention device.

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)
From: (Anonymous)
As Oracle V. Google showed, API's are not copyrightable so you might as well change EXPORT_SYMBOL_GPL() to EXPORT_SYMBOL_WE_DONT_LIKE_YOU_LARRY() which accomplishes all you possibly can here.

Profile

Matthew Garrett

About Matthew

Power management, mobile and firmware developer on Linux. Security developer at Nebula. Ex-biologist. @mjg59 on Twitter. Content here should not be interpreted as the opinion of my employer.

Page Summary

Expand Cut Tags

No cut tags