Oracle v. Google judge to decide whether APIs are Copyrightable, not the jury(groklaw.net)
groklaw.net
Oracle v. Google judge to decide whether APIs are Copyrightable, not the jury
http://www.groklaw.net/article.php?story=20120421131810380
65 comments
"...Josh Bloch (the Google employee who checked it into Android) wrote it in the first place and gave it to Sun."
What does that mean exactly--'gave it to Sun'? He was a Sun employee at the time. It's silly to say the Java code he wrote while working at Sun was given to Sun by him. Likewise, it's silly to say that then by extension when he went to work for Google he just took his code with him and gave it to Android.
What does that mean exactly--'gave it to Sun'? He was a Sun employee at the time. It's silly to say the Java code he wrote while working at Sun was given to Sun by him. Likewise, it's silly to say that then by extension when he went to work for Google he just took his code with him and gave it to Android.
From the fine article, it seems that the code in question is timsort, which Bloch wrote after he left Sun. He gave the code to Sun by pushing it into the OpenJDK.
The code in question is most certainly not TimSort, but the rangecheck() method within it, which is copied verbatim from arrays.java, which Bloch wrote while at Sun. It's what Oracle is using to show that Bloch did reference Sun code and Android is not a clean-room implementation. It's there in the Groklaw piece, but glanced over very quickly because, well it's groklaw.
"Q. Why did you use the same rangecheck() function in Timsort as was in arrays.java?
A. It's good software engineering to reuse an existing function.
Q. But why use the exact same code?
A. I copied rangecheck() as a temporary measure, assuming this would be merged into arrays.java and my version of rangecheck() would go away.
[Discussion of Timsort dates and Android work dates.]"
"Q. Why did you use the same rangecheck() function in Timsort as was in arrays.java?
A. It's good software engineering to reuse an existing function.
Q. But why use the exact same code?
A. I copied rangecheck() as a temporary measure, assuming this would be merged into arrays.java and my version of rangecheck() would go away.
[Discussion of Timsort dates and Android work dates.]"
Is this rangecheck() function that we're debating critical to the Android platform? Is that the feature that made it so popular? Clearly not, or Oracle would have made smartphones already. I'm curious as to how many different ways a range check function can be written in Java. Can we reasonably expect Bloch to re-implement his own code in a slightly different way? Should Google have diff'd Android source against Java source? What does Open Source mean to you?
private void RangeCheck(int index) {
if (index >= size)
throw new IndexOutOfBoundsException(
"Index: "+index+", Size: "+size);
}
It doesn't even check for underflow!
To do so would be meaningless, since arrays already do that.
Fun fact: Java's ArrayList RangeCheck function has had a brutally stupid misfeature for over a decade (yes, I had posted it as a bug -- ignored) which prevented its add(), set(), and get() methods from being inlined. I kid you not.
To wit: these methods all call RangeCheck, which potentially throws an exception, along these lines (here's get(i) in pseudocode):
This was trivially fixable:
Fun fact: Java's ArrayList RangeCheck function has had a brutally stupid misfeature for over a decade (yes, I had posted it as a bug -- ignored) which prevented its add(), set(), and get() methods from being inlined. I kid you not.
To wit: these methods all call RangeCheck, which potentially throws an exception, along these lines (here's get(i) in pseudocode):
RangeCheck(i)
if (i >= maxLength) throw exception about i
get(i)
RangeCheck(i)
return array[i]
This was trivially fixable:
ThrowException(i)
throw exception about i
get(i)
if (i >= maxLength) ThrowException(i)
return array[i]
In related news:
Google-Sun court docs reveal long Java licensing dance
For more than five years, Google sought to license Java or acquire rights to the language before Sun got into the hands of Oracle or IBM.
http://news.cnet.com/8301-1035_3-57417898-94/google-sun-cour...
Google-Sun court docs reveal long Java licensing dance
For more than five years, Google sought to license Java or acquire rights to the language before Sun got into the hands of Oracle or IBM.
http://news.cnet.com/8301-1035_3-57417898-94/google-sun-cour...
[deleted]
As someone who obsesses over API design, it is interesting for me to reflect on why I don't consider APIs copyrightable, even though I have spent so much effort and creativity designing them.
The issue makes the most sense to me when I think of APIs as communications protocols. Indeed APIs for remote services literally are communications protocols. But even for the in-process case an API is the means by which two decoupled pieces of code communicate.
In this sense, APIs aren't that different from languages themselves. If you get really abstract, you could think of LISP as nothing but S-expression syntax and everything else (including define, lambda, etc) as an API.
Languages themselves aren't copyrightable, even thought things you can say in a language are. Languages like Lojban certainly had a lot of creative design go into them, but that alone doesn't make them copyrightable.
So even though I think you can make a pretty convincing philosophical argument for why APIs shouldn't be copyrightable, the critical deciding factor to me in is a practical one. Allowing APIs to be copyrightable would be a huge and unwarranted advantage to incumbents at the expense of innovation and disruptive technology. Users of any API would be locked in to one particular provider of that API.
The ability to swap out one component for another is a fundamental tool for software engineers, and it's a fantastically pro-competitive check that keeps people honest. If your API provider BigCo raises their prices and no one else is allowed to compete with them because their API is copyrighted, how is that good for anyone except BigCo? In particular, someone else may have developed a superior way of implementing the API; allowing them to do so could help move the entire industry forward. Protecting BigCo from this disruption gives them no incentive to move their own tech forward; they can continue to coast on the vendor lock-in of their customers. We're not talking about letting others copy their product, but rather allowing others to speak the same language that everyone is currently speaking to BigCo.
I agree with Joshua Bloch's sentiment that API design is "tough" and "a noble and rewarding craft," but I don't think either of these imply legally-protected status. I think it would be terrible for the industry if the judge ruled that APIs are copyrightable.
The issue makes the most sense to me when I think of APIs as communications protocols. Indeed APIs for remote services literally are communications protocols. But even for the in-process case an API is the means by which two decoupled pieces of code communicate.
In this sense, APIs aren't that different from languages themselves. If you get really abstract, you could think of LISP as nothing but S-expression syntax and everything else (including define, lambda, etc) as an API.
Languages themselves aren't copyrightable, even thought things you can say in a language are. Languages like Lojban certainly had a lot of creative design go into them, but that alone doesn't make them copyrightable.
So even though I think you can make a pretty convincing philosophical argument for why APIs shouldn't be copyrightable, the critical deciding factor to me in is a practical one. Allowing APIs to be copyrightable would be a huge and unwarranted advantage to incumbents at the expense of innovation and disruptive technology. Users of any API would be locked in to one particular provider of that API.
The ability to swap out one component for another is a fundamental tool for software engineers, and it's a fantastically pro-competitive check that keeps people honest. If your API provider BigCo raises their prices and no one else is allowed to compete with them because their API is copyrighted, how is that good for anyone except BigCo? In particular, someone else may have developed a superior way of implementing the API; allowing them to do so could help move the entire industry forward. Protecting BigCo from this disruption gives them no incentive to move their own tech forward; they can continue to coast on the vendor lock-in of their customers. We're not talking about letting others copy their product, but rather allowing others to speak the same language that everyone is currently speaking to BigCo.
I agree with Joshua Bloch's sentiment that API design is "tough" and "a noble and rewarding craft," but I don't think either of these imply legally-protected status. I think it would be terrible for the industry if the judge ruled that APIs are copyrightable.
One thing that suprises me is how well the judge seems to grasp this rather technical issue.
Judge Alsup has a B.S. degree and apparently planned to be an engineer before he got interested in civil rights: http://www.fedbar.org/Resources_1/Judicial-Profiles/Judicial...
You'd be surprised how well people can pick up on things if they have a reason to learn and a good explanation. Especially since most people "don't understand" because they don't want to learn.
Not all judges, lawyers etc. come from a non-technical background. I, for example, have a BA in Computer Science, but am currently studying for MA in Law. I imagine this is more common than people think.
That seems correct: whether copyright law in principle covers copyright of APIs is a question of law rather than fact.
And, more importantly, the judge is far more well-versed with both the tech and the law side of things to be in a position to make a more-informed and accurate ruling on the matter.
http://www.pcmag.com/article2/0,2817,2403292,00.asp
Under questioning from Oracle lawyer Michael Jacobs, Reinhold contended that "each page of the [Java] language specification includes a copyright notice,"
"Page, 39, testified over the course of two days, claiming that Google only used elements of the Java programming language that are freely available in the public domain. But after being admonished from the bench for evasive responses to Oracle questioning, the Google CEO finally admitted that his company never obtained a license to use Java code in its own software."
Under questioning from Oracle lawyer Michael Jacobs, Reinhold contended that "each page of the [Java] language specification includes a copyright notice,"
"Page, 39, testified over the course of two days, claiming that Google only used elements of the Java programming language that are freely available in the public domain. But after being admonished from the bench for evasive responses to Oracle questioning, the Google CEO finally admitted that his company never obtained a license to use Java code in its own software."
Having a copyright notice does not mean it's copyrighted, though. Rural Telephone Service Co. probably had a copyright notice in their listings too, but the court still found it uncopyrightable.
If Google were publishing copies of that specification, that would be relevant.
I'm surprised that copyrightability of APIs is still an open question in (US) law. Is that because people haven't copied each other's APIs before, or because when they did nobody cared about the legality?
It might be a bit of a stretch to say it's an open question. This is the first time (AFAIK) anyone has sued over it, so there's no case law. The closest equivalent in "big" cases is probably Lotus v. Borland (http://en.wikipedia.org/wiki/Lotus_Dev._Corp._v._Borland_Int...).
Basically, Lotus sued Borland because the menu layout of Quatro was identical to 1-2-3. They won initially, but ultimately lost in the Supreme Court. The judgement was that the mechanism for using a program was not a copyrightable form. Prior to this case, I guess everyone sane had assumed that an API was a basically equivalent mechanism (just one for a programmer instead of a user). But Oracle has the constitutional right to sue for what they believe they own, so there's no "short circuit" that would prevent the suit.
Basically, Lotus sued Borland because the menu layout of Quatro was identical to 1-2-3. They won initially, but ultimately lost in the Supreme Court. The judgement was that the mechanism for using a program was not a copyrightable form. Prior to this case, I guess everyone sane had assumed that an API was a basically equivalent mechanism (just one for a programmer instead of a user). But Oracle has the constitutional right to sue for what they believe they own, so there's no "short circuit" that would prevent the suit.
I thought that the copyrightability of APIs was a question in USL vs. BSDi (http://en.wikipedia.org/wiki/USL_v._BSDi). Am I mistaken?
If settlement occurs before a judgment is passed down, then the court case doesn't bind future decisions.
Might want to fix that link, there's a `'` in there.
This has actually been the same situation with patents. There are so many vague patents given to companies already, that if everyone who has a patent actually started enforcing them at once, the entire tech industry could collapse within months.
The only reason this hasn't happened is because most companies are not that "evil" to actually try to use vague patents against other companies, and they just want to own them for defensive purposes (which wasn't the goal of patents at all). But this shows just how screwed up the law is, and that if all companies would want to collect their "rights" the system would collapse. Instead, right now there are only a few who do it, and it's very profitable for them because nobody is really challenging them on this.
The only reason this hasn't happened is because most companies are not that "evil" to actually try to use vague patents against other companies, and they just want to own them for defensive purposes (which wasn't the goal of patents at all). But this shows just how screwed up the law is, and that if all companies would want to collect their "rights" the system would collapse. Instead, right now there are only a few who do it, and it's very profitable for them because nobody is really challenging them on this.
and the same discussion on being able to get a patent on APIs also happened - the most famous contestant at that time was Microsoft's .Net API patent application (now US7581231) - by now MS hold a series of patents on other APIs plus has a whole lot of additional API patent applications pending.
Now one could say that there are many patents that should have never been granted to MS or others (one of the better examples for MS would certainly be getting a patent on a Windows sudo implementation - US6775781) - but it might be indicative why MS went along the path to get patents on APIs vs trying to just copyright it.
Given that copyright protects the form of expression rather than the subject matter itself this pretty much explains why the copyright office would only require the first and last 50 lines of code.
While the answer with e.g. REST APIs that are pretty much exchangeable might be rather easy with more complex ones like system level or also the Java API this becomes pretty complex.
Maybe an analogy might help: If you take a car you might be able to patent and copyright most parts and functions but you certainly will not be able to copyright that you can drive the car per-se.
With an API like the Java API where the majority has been open sourced the actual use of the API (IMHO up to the wording of it or making this wording available in your application) is merely the general ability to use the solution overall - like diving a car or making it possible to drive along with other cars in traffic.
Then comes the question if Sun / Oracle have actually previously provided the permission to use the API directly or as part of other licenses (e.g. ClassPath)
Now one could say that there are many patents that should have never been granted to MS or others (one of the better examples for MS would certainly be getting a patent on a Windows sudo implementation - US6775781) - but it might be indicative why MS went along the path to get patents on APIs vs trying to just copyright it.
Given that copyright protects the form of expression rather than the subject matter itself this pretty much explains why the copyright office would only require the first and last 50 lines of code.
While the answer with e.g. REST APIs that are pretty much exchangeable might be rather easy with more complex ones like system level or also the Java API this becomes pretty complex.
Maybe an analogy might help: If you take a car you might be able to patent and copyright most parts and functions but you certainly will not be able to copyright that you can drive the car per-se.
With an API like the Java API where the majority has been open sourced the actual use of the API (IMHO up to the wording of it or making this wording available in your application) is merely the general ability to use the solution overall - like diving a car or making it possible to drive along with other cars in traffic.
Then comes the question if Sun / Oracle have actually previously provided the permission to use the API directly or as part of other licenses (e.g. ClassPath)
Or because nobody had so much to win as Oracle does now. And because nobody copied Larry Ellison's API until now.
I feel the judge will rule that APIs are not subject to copyright. There is no expression of creativity and it is fairly mechanical. I also think that if they are subject to copyright lots of people are going to get sued.
There is no expression of creativity and it is fairly mechanical.
I disagree. Designing a good API is one of the most difficult skills to acquire in all of software development. If creating a good API were "fairly mechanical" then the world wouldn't be full of crappy ones, and we'd all rejoice permanently in the comforting glow that comes from writing code against an API written by someone who gets it.
Despite this, I strongly believe that APIs should be excluded from copyright, for the same reason that I support the US exclusion of fonts. Some things are too important to general communication and creativity to allow any individual to have exclusive control over them, and they demonstrably can and will be created without needing that incentive to make them economically viable.
I disagree. Designing a good API is one of the most difficult skills to acquire in all of software development. If creating a good API were "fairly mechanical" then the world wouldn't be full of crappy ones, and we'd all rejoice permanently in the comforting glow that comes from writing code against an API written by someone who gets it.
Despite this, I strongly believe that APIs should be excluded from copyright, for the same reason that I support the US exclusion of fonts. Some things are too important to general communication and creativity to allow any individual to have exclusive control over them, and they demonstrably can and will be created without needing that incentive to make them economically viable.
API design requires much skill and foresight. As you said:
Designing a good API is one of the most difficult skills to acquire in all of software development.
However, the yardstick for copyrightability remains creativity (among other things). Some tangible work that was formed by the "sweat of one's brow" is not necessarily copyrightable, unless it was done creatively by the sweat of one's brow. Feist v. Rural [1] is the common case to cite here, where it was decided that telephone books were not creative, and thus not copyrightable, despite the effort that went into creating them.
[1] https://en.wikipedia.org/wiki/Feist_v._Rural
Designing a good API is one of the most difficult skills to acquire in all of software development.
However, the yardstick for copyrightability remains creativity (among other things). Some tangible work that was formed by the "sweat of one's brow" is not necessarily copyrightable, unless it was done creatively by the sweat of one's brow. Feist v. Rural [1] is the common case to cite here, where it was decided that telephone books were not creative, and thus not copyrightable, despite the effort that went into creating them.
[1] https://en.wikipedia.org/wiki/Feist_v._Rural
An API is not a compilation of facts, though. The specific names in an API and their relationships to each other seem like a creative work. There is no pre-existing fact that requires, for instance, that java.lang.String has several overloads of a lastIndexOf method that take the particular arguments that they do. Someone invented that.
It may be that APIs are not copyrightable subject matter, or that there is some general defense based on fair use or interoperability, but I don't think it can be argued that creating an API is not a creative act.
It may be that APIs are not copyrightable subject matter, or that there is some general defense based on fair use or interoperability, but I don't think it can be argued that creating an API is not a creative act.
>An API is not a compilation of facts, though. The specific names in an API and their relationships to each other seem like a creative work.
The trouble is that it is a compilation of facts. "There is a function in Java called lastIndexOf in class java.lang.String that takes int as argument and returns int." That's a fact. The formal specification of that fact is "public int lastIndexOf(int)" -- that can't be a creative expression of the fact because it's the only way you can formally represent it to the compiler. The language mandates that expression; you can't alter it so there is no opportunity for creativity.
Or to put it a different way, you might want to call it a creative endeavor to lay out a city and name all the streets. But if the person who named all the streets then comes around trying to claim a copyright over an independent cartographer's map of the city or the local phone book because it contains all of the street names, I wouldn't expect much sympathy.
But I think the crux of it is this:
>Someone invented that.
Exactly. Software development contains both engineering and creative components. The functional components are patentable (in countries like the US that have software patents). The creative components are copyrightable. But the API is strictly functional -- if there is any protection for it, it's in the domain of patents. You can call inventions creative all you like, but you can't copyright function.
The trouble is that it is a compilation of facts. "There is a function in Java called lastIndexOf in class java.lang.String that takes int as argument and returns int." That's a fact. The formal specification of that fact is "public int lastIndexOf(int)" -- that can't be a creative expression of the fact because it's the only way you can formally represent it to the compiler. The language mandates that expression; you can't alter it so there is no opportunity for creativity.
Or to put it a different way, you might want to call it a creative endeavor to lay out a city and name all the streets. But if the person who named all the streets then comes around trying to claim a copyright over an independent cartographer's map of the city or the local phone book because it contains all of the street names, I wouldn't expect much sympathy.
But I think the crux of it is this:
>Someone invented that.
Exactly. Software development contains both engineering and creative components. The functional components are patentable (in countries like the US that have software patents). The creative components are copyrightable. But the API is strictly functional -- if there is any protection for it, it's in the domain of patents. You can call inventions creative all you like, but you can't copyright function.
This makes me think of WINE. WINE takes the direct API, as in all the doSomethings(), and rewrites how it does that thing to work on a different environment than the original API call intended it to do. In the end, it may have the same exact or near exact result, but it does it in a completely different way.
I'd fear that if Oracle wins here, a huge number of open source projects like Wine and even the Gnash Flash alternative would find themselves under attack when they had previously been determined outside of court to be legitimate and fair uses of an API reimplementation.
I'd fear that if Oracle wins here, a huge number of open source projects like Wine and even the Gnash Flash alternative would find themselves under attack when they had previously been determined outside of court to be legitimate and fair uses of an API reimplementation.
Absolutely. I mean forget about WINE, what about SQL? Recall that SQL originally came out of IBM. It kind of makes you wonder whether Oracle's lawyers have thought this one through.
I would argue that once an API is published and put into use, it becomes a list of facts about the interfaces in the program. You cannot change an API without undermining its entire purpose. In that sense, it is factual, in that the API class paths and signatures are effectively routing information between a client program and the API implementation. They describe the means by which you give data to a library and give data back.
An API may be entirely as functional (though not necessarily as usable) if no creative thought or effort goes into it. You could have all your API methods be called api1(...), api2(...) and still have them function. Creativity and skill are a very useful component in making APIs, but I would argue that they are not requisite, as evidenced by the dearth of uncreative APIs created by unskilled programmers who have still managed to create libraries and services that we use on a daily basis.
An API may be entirely as functional (though not necessarily as usable) if no creative thought or effort goes into it. You could have all your API methods be called api1(...), api2(...) and still have them function. Creativity and skill are a very useful component in making APIs, but I would argue that they are not requisite, as evidenced by the dearth of uncreative APIs created by unskilled programmers who have still managed to create libraries and services that we use on a daily basis.
According to Joshua Block, Google's Chief Java Architect. (slide 62 and 63)
“I find it very rewarding to design great APIs and have people come to me years later and say, wow, you know, the collections framework changed my life.”
"API design is a noble and rewarding craft"
"API design is tough"
“I find it very rewarding to design great APIs and have people come to me years later and say, wow, you know, the collections framework changed my life.”
"API design is a noble and rewarding craft"
"API design is tough"
I believe bringing the concept of a fact into question will do more harm than good. A phone book is _not merely_ a set of facts, but also a set of agreements. Surely one can look inside the phone and disagree with one's own listing. If one were to dive into an API and find that it mistakenly calls an undefined function, or typos abound, in this case the API would need to be changed because it has become less functional. It may be rendered useless. A phonebook cannot be rendered useless if even all the numbers are incorrect; though I doubt such a philosophical argument need be presented (Sorite's Paradox).
My goal here is to understand the analogy that is being made. True, one could development algorithms from a phonebook such that bank robberies and pranksterism may take place. This possibility secures a conceptual machinery for viewing a phonebook and an API as conceptually similar, since such practices would likely presuppose a concept of hierarchical relationships between numbers and names in the book, assuming sophistication. However, such practice is not the intent behind the phonebook, and so further a concept of hierarchy is unnecessary essentially to the phonebook. An API depends on some basic conceptual metaphor (@see Metaphors We Live By by Lakoff and Johnson to grok the sense in which I use "conceptual metaphor") of:
A FUNCTION IS INSIDE A CLASS
(I do not count sorting or grouping concepts in a phonebook as "hierarchical.") And this concept is essential to the working of the API. So I believe the comparison is unfair, if not misleadingly true (that APIs and phonebooks are compilations of facts) when thinking of phonebooks whose institutional facts are conceptually nearer, by analysis, in proximity to their brute facts (those facts to which no other facts are necessary to ground their truth). An API and a phonebook are compilations of institutional facts, and should be compared only if the structures of those facts they assert are grounded in relevantly similar conceptual spaces (the institutions wherein those facts are true).
My goal here is to understand the analogy that is being made. True, one could development algorithms from a phonebook such that bank robberies and pranksterism may take place. This possibility secures a conceptual machinery for viewing a phonebook and an API as conceptually similar, since such practices would likely presuppose a concept of hierarchical relationships between numbers and names in the book, assuming sophistication. However, such practice is not the intent behind the phonebook, and so further a concept of hierarchy is unnecessary essentially to the phonebook. An API depends on some basic conceptual metaphor (@see Metaphors We Live By by Lakoff and Johnson to grok the sense in which I use "conceptual metaphor") of:
A FUNCTION IS INSIDE A CLASS
(I do not count sorting or grouping concepts in a phonebook as "hierarchical.") And this concept is essential to the working of the API. So I believe the comparison is unfair, if not misleadingly true (that APIs and phonebooks are compilations of facts) when thinking of phonebooks whose institutional facts are conceptually nearer, by analysis, in proximity to their brute facts (those facts to which no other facts are necessary to ground their truth). An API and a phonebook are compilations of institutional facts, and should be compared only if the structures of those facts they assert are grounded in relevantly similar conceptual spaces (the institutions wherein those facts are true).
For a good API I'd agree with you that it's a difficult skill to learn. In the case of java I would say that "no expression of creativity and it is fairly mechanical" is a fairly apt description.
I can agree with parts of it, but I still think Google should pay Oracle for licensing Java. They copied the entire API so they could leverage the entire Java ecosystem, I think that's quite unfair to Oracle. Oracle is not suing microsoft for implementing their own .NET VM.
Oracle/Sun couldn't sue MS for their VM because .NET has nothing do due with Java except some common high-level architectural strategies (bytecode/msil, GC, VM, etc.) that neither company has exclusive claims on.
In fact the .NET VM came about as a direct result of the fact that Oracle(Sun) did sue Microsoft for incompletely implementing the Java JDK under a license agreement between them, and MS had to abandon J++ and started work on C# to replace it.
http://www.javaworld.com/javaworld/jw-10-1997/jw-10-lawsuit....
In fact the .NET VM came about as a direct result of the fact that Oracle(Sun) did sue Microsoft for incompletely implementing the Java JDK under a license agreement between them, and MS had to abandon J++ and started work on C# to replace it.
http://www.javaworld.com/javaworld/jw-10-1997/jw-10-lawsuit....
What does it mean to "leverage the entire Java ecosystem?"
Developer tools (eclipse), libraries, developers trained in Java, Java training. Just some of reasons they did not create their own VM like Microsoft.
Okay, but Oracle doesn't own the talents of everyone who knows Java, and has nothing to do with Eclipse.
Do K&R collect massive royalties for all the operating systems written in C? Does Oxford demand licensing fees from speakers of English-derived dialects? Most of the words ("APIs") are the same.
Do K&R collect massive royalties for all the operating systems written in C? Does Oxford demand licensing fees from speakers of English-derived dialects? Most of the words ("APIs") are the same.
They did create their own VM -- Dalvik.
Sort of -- but not in the same sense that the .NET CLR is MS's own VM, with its own unique bytecode (MSIL code).
Dalvik compiles ("dexes") Java bytecode (most of which, except for Android-specific libraries, would run on any JVM) down to Dalvik 'bytecode'.
It's honestly not that different from what the MSVM tried to do. The main difference, it seems to me, between the MS/Sun lawsuit over the MSVM, and the Google/Oracle suit, is that 1) Google did implement the entire JDK -- they simply added more proprietary libraries that can't run on a conventional JVM and 2) MS had a binding agreement with Sun.
If Google wins (and for the record I'm on their side of this completely), my question is -- does that mean Microsoft didn't need that license agreement with Sun to begin with -- the one signed in 1996 that eventually caused the downfall of J++/MSVM, and the birth of .NET?
That would be an interesting turn.
Dalvik compiles ("dexes") Java bytecode (most of which, except for Android-specific libraries, would run on any JVM) down to Dalvik 'bytecode'.
It's honestly not that different from what the MSVM tried to do. The main difference, it seems to me, between the MS/Sun lawsuit over the MSVM, and the Google/Oracle suit, is that 1) Google did implement the entire JDK -- they simply added more proprietary libraries that can't run on a conventional JVM and 2) MS had a binding agreement with Sun.
If Google wins (and for the record I'm on their side of this completely), my question is -- does that mean Microsoft didn't need that license agreement with Sun to begin with -- the one signed in 1996 that eventually caused the downfall of J++/MSVM, and the birth of .NET?
That would be an interesting turn.
So asking for forgiveness and not permission would work out for Google? I don't see how that can work, the only way is if API's are not copyrightable, which will be up to the judge and not the jury.
AIUI the main problem with Microsoft's implementation was that they were calling it "Java" with the implication that it was compatible.
[deleted]
Again -- and this probably works in your argument's favor -- MS did implement a JDK under a license agreement with Sun, and then violated that agreement by corrupting the JDK specification with incomplete/missing pieces.
MS didn't start work on the .NET VM until they had to abandon their corrupted Java VM under a court order -- the whole reason C# and .NET exists in the first place instead of J++ and the MSVM.
MS didn't start work on the .NET VM until they had to abandon their corrupted Java VM under a court order -- the whole reason C# and .NET exists in the first place instead of J++ and the MSVM.
"They copied the entire API ..."
They are using Apache Harmony. Ask Oracle, they will tell you it is not Java.
They are using Apache Harmony. Ask Oracle, they will tell you it is not Java.
I don't even think they should be excluded because they're important, but simply because they are required for interoperability, which can never be made illegal anyway.
...exclusion of fonts. Some things are too important to general communication and creativity to allow any individual to have exclusive control over them
I realize we're getting off-topic, but I'm curious how that follows. It is certainly important for people to have access to some typefaces, but if fonts were copyrightable there would still be some public-domain ones for people to use. Why is it important that people be able to use "premium" typefaces?
I realize we're getting off-topic, but I'm curious how that follows. It is certainly important for people to have access to some typefaces, but if fonts were copyrightable there would still be some public-domain ones for people to use. Why is it important that people be able to use "premium" typefaces?
The problem is where you draw the line. All typefaces based on a western alphabet are ultimately going to be somewhat similar, because the shapes of the letters are what they are. The differences between many typefaces' designs are subtle at best, and frankly little more than typographic snobbery in some cases. Given that copyright applies not just to the original work but also to derived works, if you allow the basic design of a typeface to be protected then you are in danger of covering not just the design of the typeface but the entire medium of written communication.
That said, "premium" typefaces in common styles (geometric sans, transitional serif, etc.) tend to be premium mostly because of all the detail work beyond the basic shape, such as hinting and kerning. Since that work is part of the implementation font file rather than the design, AIUI it can still be covered by copyright even in the US.
That said, "premium" typefaces in common styles (geometric sans, transitional serif, etc.) tend to be premium mostly because of all the detail work beyond the basic shape, such as hinting and kerning. Since that work is part of the implementation font file rather than the design, AIUI it can still be covered by copyright even in the US.
Ah. Even if, say, the original Times was copyrighted, it would have long expired by now. That's why I don't see any harm in having (reasonable-length) copyright for all typefaces of the last century or so.
According to Joshua Block, Google's Chief Java Architect. (slide 62 and 63)
“I find it very rewarding to design great APIs and have people come to me years later and say, wow, you know, the collections framework changed my life.”
"API design is a noble and rewarding craft"
"API design is tough"
Also, according to Andy Rubin (slide 73)
“Ha, wish them luck. Java.lang api’s are copyrighted. And Sun gets to say who they license the tck to, and forces you to take the ‘shared part’ which taints any clean room implementation.”
According to Google employee Bob Lee (Slide 72)
Q. Did you consult the Java docs when doing your work on the API implementations for Android?
A. Yes.
Q. Okay. And where did you obtain those Java docs?
A. They’re posted for free on Sun’s website...
Q. Did you observe any copyright notices on the specifications?
A. Yes.
“I find it very rewarding to design great APIs and have people come to me years later and say, wow, you know, the collections framework changed my life.”
"API design is a noble and rewarding craft"
"API design is tough"
Also, according to Andy Rubin (slide 73)
“Ha, wish them luck. Java.lang api’s are copyrighted. And Sun gets to say who they license the tck to, and forces you to take the ‘shared part’ which taints any clean room implementation.”
According to Google employee Bob Lee (Slide 72)
Q. Did you consult the Java docs when doing your work on the API implementations for Android?
A. Yes.
Q. Okay. And where did you obtain those Java docs?
A. They’re posted for free on Sun’s website...
Q. Did you observe any copyright notices on the specifications?
A. Yes.
There are copyright notices in printed editions of the king James bible yet the words themselves are still in the public domain and you are free to use them however you want to.
NKJV, the bible one typically finds in the USA, was edited and published in 1979 and is most certainly under copyright as a whole. In general, translations or adaptations of a work are under their own separate copyright.
Your overarching point that some things have false (or partially false) notice on them is accurate -- however the point that copyright law is subtle and often unclear in its details is equally valid.
Your overarching point that some things have false (or partially false) notice on them is accurate -- however the point that copyright law is subtle and often unclear in its details is equally valid.
The words are not in the "public domain"... you can't make a wholesale, verbatim copy of the King James Bible and call it the "hammersend Bible" because of copyright law. You may quote relevant passages from it though; this is well-established "fair use" doctrine.
https://en.wikipedia.org/wiki/Authorized_King_James_Version#...
https://en.wikipedia.org/wiki/Authorized_King_James_Version#...
That's only valid in the UK. The Oracle vs Google trial is taking place in the United States where the KJV bible is most certainly in the public domain.
That's incorrect. The text is in the public domain but it is still covered by copyright. The copyright is not enforced outside the UK at this time. It is not pedantry; one cannot claim to have written the KJV version. A work that has passed into the public domain, or has become publicly available, still retains copyright.
http://en.wikipedia.org/wiki/Copyright#Public_domain
Here's a concrete example. Someone wrote a very successful book and it is protected by copyright laws. You may reproduce sections of it, but not the whole book. After X years have passed, and the book has passed into the public domain, you may reproduce it in full. You may not alter the work to credit yourself as the author.
Similarly, the crux of the matter is: does the Google version of the Java API constitute a derivative work that is significantly different from the Sun-Oracle version? As stated above, the UK and US do not recognize common law of copyright. So despite the fact that the Sun-Oracle APIs are publicly available, it does not allow Google to claim that the code that belonged to Sun-Oracle is free from restrictions and thus can be copied.
http://en.wikipedia.org/wiki/Copyright#Public_domain
Here's a concrete example. Someone wrote a very successful book and it is protected by copyright laws. You may reproduce sections of it, but not the whole book. After X years have passed, and the book has passed into the public domain, you may reproduce it in full. You may not alter the work to credit yourself as the author.
Similarly, the crux of the matter is: does the Google version of the Java API constitute a derivative work that is significantly different from the Sun-Oracle version? As stated above, the UK and US do not recognize common law of copyright. So despite the fact that the Sun-Oracle APIs are publicly available, it does not allow Google to claim that the code that belonged to Sun-Oracle is free from restrictions and thus can be copied.
"It is not pedantry; one cannot claim to have written the KJV version"
Sure one can. In fact, copyright has nothing to say regarding plagiarism. US copyright only prevents the copying of a work. I could claim to have authored Star Wars, the Bible, and your post -- copyright does not provide you recourse against this so long as I do not /copy/ them.
"The text is in the public domain but it is still covered by copyright."
No, it is not. Text in the public domain is not covered by copyright according to US law. Copyright ONLY applies to copies and incorporation into derivative works in the USA.
I apologize for being contradictory but you are completely wrong on both points here.
Sure one can. In fact, copyright has nothing to say regarding plagiarism. US copyright only prevents the copying of a work. I could claim to have authored Star Wars, the Bible, and your post -- copyright does not provide you recourse against this so long as I do not /copy/ them.
"The text is in the public domain but it is still covered by copyright."
No, it is not. Text in the public domain is not covered by copyright according to US law. Copyright ONLY applies to copies and incorporation into derivative works in the USA.
I apologize for being contradictory but you are completely wrong on both points here.
Google will have to display Android's relevance via the difference between implementing an API into a piece of software vs. the open and free use of an API's concept, which in this case is mostly a set of [37] "best practices" for a programming language. I suspect the latter is where Google will try and grab some ground in the copyright debate in the days to come.
The more amusing bit is that the incriminating code snipped in Oracle's slides goes the other way: the code is in Java because Josh Bloch (the Google employee who checked it into Android) wrote it in the first place and gave it to Sun. So the same TimSort implementation got carried with him into Android. There may still be a copyright question if he actually assigned ownership to Sun, I guess. But suing the author over the use of open source code he gave you in another open source project is... yeah.