Oracle and the End of Programming as We Know It(drdobbs.com)
drdobbs.com
Oracle and the End of Programming as We Know It
http://www.drdobbs.com/jvm/232901227
76 comments
Here's to the pattern continuing in the case of Oracle. They are a blight.
I'd be a tad bit concerned about a patent troll obtaining Oracle's IP if they ever go down, though.
Oh, the joy of having to choose the lesser of two evils.
Oh, the joy of having to choose the lesser of two evils.
Oracle already goes after the small players who don't have a patent portfolio of their own, and patent trolls tend to avoid the bigger players anyway.
It could be worse, but not much worse.
It could be worse, but not much worse.
Let's worry about the first, "real" evil right now, rather than a hypothetical one in the future.
Or, take a cue from Stallman and worry about both.
[deleted]
API copyrights is a terrible idea that would promote vendor lock in and block interoperability. It would be a disaster for companies writing to a small niche API or who lost access to a flaky vendor's approach to their problem.
This wouldn't really be so bad as far as programming languages go. AT&T already cross-licensed the C and UNIX ecosystem to the University Of California's open source BSD project and you could inherit their license. Java VMs and compilers could be distributed under GPL (and Android would be a better platform under GPL with less fragmentation). Python, Ruby, Perl, and the like license themselves to the world freely and easily.
I can't think of any really major programming languages that would be harshly damaged. C# is largely effectively proprietary because Microsoft rattles the patent sabre at non-Windows implementations. I don't know what the status of Javascript might be, but the standard API is fairly tiny.
Of course, no unfree language or API in the future would ever gain traction without a monopoly platform provider of some kind to require it and still it would never spread beyond that platform. Users would be too terrified of vendor lock-in.
Things like Wine would need to take development overseas, but the need for them is shrinking along with the use of proprietary platform binaries.
This wouldn't really be so bad as far as programming languages go. AT&T already cross-licensed the C and UNIX ecosystem to the University Of California's open source BSD project and you could inherit their license. Java VMs and compilers could be distributed under GPL (and Android would be a better platform under GPL with less fragmentation). Python, Ruby, Perl, and the like license themselves to the world freely and easily.
I can't think of any really major programming languages that would be harshly damaged. C# is largely effectively proprietary because Microsoft rattles the patent sabre at non-Windows implementations. I don't know what the status of Javascript might be, but the standard API is fairly tiny.
Of course, no unfree language or API in the future would ever gain traction without a monopoly platform provider of some kind to require it and still it would never spread beyond that platform. Users would be too terrified of vendor lock-in.
Things like Wine would need to take development overseas, but the need for them is shrinking along with the use of proprietary platform binaries.
>C# is largely effectively proprietary because Microsoft rattles the patent sabre at non-Windows implementations.
C# is an open standard, submitted to ISO and ECMA (at least for versions < latest). MS also signed a legally binding patent pledge to not sue anyone for the language and runtime IIRC.
There exist at least two C# open source implementations that I know of, Mono and some GNU project.
C# is an open standard, submitted to ISO and ECMA (at least for versions < latest). MS also signed a legally binding patent pledge to not sue anyone for the language and runtime IIRC.
There exist at least two C# open source implementations that I know of, Mono and some GNU project.
The runtime is a hodgepodge of standardised bits and Microsoft extensions though.
That's my worry. They could always find some technicality to sue over.
Its being an open standard doesn't stop Microsoft asserting copyright over the APIs it describes. As far as I can tell, while ECMA controls the copyright of the standard document itself, they make no claims about the software described within it. Neither would the patent pledge.
I would be surprised if such a pledge would be legally binding.
What section of law does it fall under? Contract? Can you sign a contract with "the general public"?
What section of law does it fall under? Contract? Can you sign a contract with "the general public"?
IT lawyer and digital liberties' advocate Carlo Piana mentions at https://plus.google.com/u/0/115445134403759043734/posts/coVx... that such API copyrightability has been largely denied by the SAS v. WPL case that came out today (nice coincidence !) : "[...] neither the functionality of a computer program nor the programming language and the format of data files used in a computer program in order to exploit certain of its functions constitute a form of expression of that program and, as such, [they] are not protected by copyright in computer programs" - http://curia.europa.eu/juris/document/document.jsf?text=&...
Fortunately that happens in Europe, but that also means the ruling doesn't apply abroad. With US being very keen on trying to apply local laws to companies/people in other countries... We'll see what happens.
A ruling could also go along the line that Sun / Oracle might have a copyright to the API but Google was free to use them.
In any case I guess we will see appeals from either side.
The author mixed in C# and VB in Mono - while MS has in the past applied and received patents on their APIs they have explicitly provided this use. This might be the way forward - company who created those APIs keeps control but let everyone use them.
Nevertheless, IMHO if I provide a solution like the Java language into the public domain / license it under GNU, parts like APIs become elements of speech - otherwise the whole thing becomes rather philosophical (and solved far more than 100 years ago by Hegel - 100% information is not possible).
In any case I guess we will see appeals from either side.
The author mixed in C# and VB in Mono - while MS has in the past applied and received patents on their APIs they have explicitly provided this use. This might be the way forward - company who created those APIs keeps control but let everyone use them.
Nevertheless, IMHO if I provide a solution like the Java language into the public domain / license it under GNU, parts like APIs become elements of speech - otherwise the whole thing becomes rather philosophical (and solved far more than 100 years ago by Hegel - 100% information is not possible).
Actually, if APIs/languages turned out to be copyrightable, IBM might just sue Oracle for using SQL and other related APIs. Oracle are even trying to invalidate the defence of implicit acceptance (same situation with both Sun and IBM).
Really stupid move on Oracle's part.
Really stupid move on Oracle's part.
That would be actually very good for Oracle. Oracle would pay a certain amount of money to IBM in exchange for licensing these APIs. As they say, business is IBM's middle name so it's not like they're going to make this a political question, they will happily take the money. Suddenly, the barrier to enter to relational database market is a lot higher, and PostgreSQL (and MySQL copies without a license from Oracle) are illegal. How is this a stupid move on Oracle's part?
I guess it would speed up nosql adoption quite a bit if things would actually get that far.
NoSQL isn't a replacement for SQL. It's a separate technology.
Yes I understand that, but if SQL would become oracle expensive I think you will see a lot of companies/projects switching to one of the many nosql options that don't infringe IBM's patented API.
I don't think you understand. How can you switch from the one to the other if they're separate technologies? Going on foot is not a substitute for driving a car when we're talking about transporting 100 refrigerators from a port to a warehouse 300 km inland, it's only a substitute when we're talking about transporting a person less than a few kilometers and when time is of little importance.
That's not to say that there are no alternatives to relational databases or SQL, but the leap to 'oh then NoSQL will take over' doesn't make much sense.
That's not to say that there are no alternatives to relational databases or SQL, but the leap to 'oh then NoSQL will take over' doesn't make much sense.
Raise the price of the current solution sufficiently, and the migration then makes a whole lot of sense.
This even if the target product is less capable, less desirable or otherwise inferior, given a sufficiently large price delta (or hassle delta or product support delta, etc) then management and operations and finance will most definitely encourage the migration.
This even if the target product is less capable, less desirable or otherwise inferior, given a sufficiently large price delta (or hassle delta or product support delta, etc) then management and operations and finance will most definitely encourage the migration.
Both are in the business of storing data that can later be retrieved again, so I don't think your analogy really holds in this case. Maybe you are thinking of one particular nosql solution but I think almost all projects could find an alternative to a database that uses SQL. That is not to say that it shouldn't be a relational database or that there's a one shoe fits all solution out there.
I think you would really struggle to find adequate replacements for relational databases in at least two areas: reporting and ad-hoc queries.
Mongodb has ad-hoc queries (not as simple as SQL, but still). Many engines can run huge aggregated queries (hadoop?)
But I think the problem is placed in the wrong place. If SQL the language/API is copyrighted, then isn't it easier produce a new API with the same functionality?)
But I think the problem is placed in the wrong place. If SQL the language/API is copyrighted, then isn't it easier produce a new API with the same functionality?)
Actually we had nosql databases for far more than we have had SQL databases (by definition, for one). They were quite popular in the seventies / early eighties. So, those too could have lots of old patents and prior art.
Old, expired patents, so that wouldn't be a stopper.
Patents, maybe. Copyright? Oracle's case is all about copyright, no?
Copyright as it stands today would only be a stopper if you tried to grab the actual implementations from that era, which wouldn't even run without serious work. Reimplementations would be clear.
Copyright even as Oracle is grabbing at it would only be an issue if you cloned those old APIs, which is probably also not what would happen, as the APIs wouldn't translate to anything today either.
Copyright even as Oracle is grabbing at it would only be an issue if you cloned those old APIs, which is probably also not what would happen, as the APIs wouldn't translate to anything today either.
There's a big distinction between SQL and Java in that regard. SQL being published as an ISO standard implies that its creators intended for others to be able to produce their own implementations of it.
Sun/Oracle did no such thing with Java, and has always officially claimed that implementations needed to be licensed by them. It was almost 15 years ago that Sun sued Microsoft for implementing Java in a way they didn't like.
Sun/Oracle did no such thing with Java, and has always officially claimed that implementations needed to be licensed by them. It was almost 15 years ago that Sun sued Microsoft for implementing Java in a way they didn't like.
According to Groklaw, the jury will not decide whether copyright applies to APIs. The judge instructed them to assume it does, find whether there is a violation, and if so, the judge will decide whether APIs can be copyrighted at all. If they find no violation, he doesn't have to rule on the matter.
Good observation. I wonder what would happen if programming and selling software in the US suddenly becomes too dangerous to do. Would it impact the rest of the world?
I'd hope it'd help to further flame innovation in Europe and Asia. Crippling US innovation with onerous IP laws (like this might lead to) would probably lead short-term to a dip in global tech innovation (and a correlated rise in IP law expenditures :)) until money and talent moves elsewhere on the globe. One can hope.
On the other hand, the US has always been good at exporting copyright provisions and IP laws so worst case, we'll all be at the behest of rent-seekers like Oracle, etc.
On the other hand, the US has always been good at exporting copyright provisions and IP laws so worst case, we'll all be at the behest of rent-seekers like Oracle, etc.
Since the US has a habit of forcing it's practices on the rest of the world, I'm sure it would have an impact on the long term.
Because of software patents, I already see programming and selling software in the US as a dangerous thing to do.
Because of software patents, I already see programming and selling software in the US as a dangerous thing to do.
>However, a silver lining could present itself: The jury could affirm that the APIs are copyrighted but that the syntax of the function signatures are a fair use exception.
Perhaps I'm missing something, but aren't APIs a documented bunch of function signatures and class hierarchies? According to the silver lining above, what's not covered by the fair-use?
Perhaps I'm missing something, but aren't APIs a documented bunch of function signatures and class hierarchies? According to the silver lining above, what's not covered by the fair-use?
Hmm, maybe publishing the API in book form?
This is a sad situation. I don't want to name names, but the startup I am working at is being sued by a much bigger company for exactly the same thing. Copyright infringement over their APIs.
One question is what will happen with Apache Harmony? From what I've read of the case, Apache have basically done the exact same thing that Google did, but Sun/Oracle never bothered to go after them. How will that project survive with the proverbial sword of Damocles hanging over it?
The Apache Harmony project has been discontinued.
Oh, you're right! I only wondered because of what I've been reading about the case, since it was mentioned a few times.
Though I guess the same question could be asked of GNU Classpath, which as far as I can see is still actively maintained.
Though I guess the same question could be asked of GNU Classpath, which as far as I can see is still actively maintained.
Any idea how much would this license that Google possibly needed may have cost? Or would it have been one of a kind?
From what I've read, price wasn't the issue. Google tried to buy a license, but Sun was afraid of losing control over Java (while Google wanted control over Android, or, at least, wanted handset vendors to be able to do what they want with it, which, apparently, has proven to be a mistake as well). Some middle ground would have been the best choice, but the two sides couldn't find one.
The Sun CEO at the time claimed that they would have paid Google to use Java, the disagreement was who got to make decisions and neither side trusted the other to get it right (personally I think history has vindicated Google on this point).
Well, considering the success of Amazon's Android fork, I think that vindication is still pending.
And no matter who's been right - legally or business-wize - I find it seriously annoying to have two Javas.
And no matter who's been right - legally or business-wize - I find it seriously annoying to have two Javas.
Amazon use Dalvik don't they? Why not the JVM?
Because OpenJDK is GPL licensed, and I guess Amazon didn't want to open-source their code. BTW, Google doesn't want to open-source (or even let Apple look at) the Nexus Android code.
That's not the case.
Sun wanted to charge Google for the license, but also wanted there to be a per-handset license fee. That per-handset fee was what Google couldn't agree on.
Sun wanted to charge Google for the license, but also wanted there to be a per-handset license fee. That per-handset fee was what Google couldn't agree on.
Direct quote from Schwartz's testimony:
"We probably would have paid them to work with us on a Java phone"
The decision of exactly how open-source to be and therefore whether to require a per-handset fee is the kind of decision I was referring to that they couldn't agree on.
"We probably would have paid them to work with us on a Java phone"
The decision of exactly how open-source to be and therefore whether to require a per-handset fee is the kind of decision I was referring to that they couldn't agree on.
From Schmidt's testimony:
Sun wanted $30-50 million for a Java license
http://mobile.theverge.com/2012/4/24/2970872/live-eric-schmi...
I've read the $300 million figure and per-handset fee elsewhere, but I can't find it now.
Sun wanted $30-50 million for a Java license
http://mobile.theverge.com/2012/4/24/2970872/live-eric-schmi...
I've read the $300 million figure and per-handset fee elsewhere, but I can't find it now.
The bigger point is, these figures (even $300 million) are a pittance for Google/Sun/Oracle compared with meeting their wider business goals. Google must have spent about that much just trying to launch a competitor to H.264 (e.g. roughly 130 million to buy On2).
[deleted]
I don't care who wins this case, but as a Java developer I hope that eventually Android will come into the Java fold, adhere to standards and run on an awsome, standard JVM. Imagine using all JVM languages, unmodified, on Android. Both Oracle and Google will gain from this, as well as the entire Java developer community.
(Side note: a ruling on API copyrights could have far reaching ramifications, some might be quite unfortunate, but it's important to make clear that Oracle did not start out trying to establish API copyrightability. They simply set out to nail Google for Android, and API copyright was simply a tool in their legal toolbox.)
(Side note: a ruling on API copyrights could have far reaching ramifications, some might be quite unfortunate, but it's important to make clear that Oracle did not start out trying to establish API copyrightability. They simply set out to nail Google for Android, and API copyright was simply a tool in their legal toolbox.)
Is that a defence? That they didn't start with the copyright on APIs as their goal, it just happens to be something they stumbled on as an idea and decided to use to pursue google?
Absent mindedly creating an hitherto unknown revenue stream that lets you apply licensing fees to everyone under the sun and destroying the software industry as a sort of half-baked by-product is just fine, if you didn't mean to do it at the beginning?
really?
I'm sure the business majors of the world will rejoice in that. I don't.
Absent mindedly creating an hitherto unknown revenue stream that lets you apply licensing fees to everyone under the sun and destroying the software industry as a sort of half-baked by-product is just fine, if you didn't mean to do it at the beginning?
really?
I'm sure the business majors of the world will rejoice in that. I don't.
The business majors of the world will rejoice no matter which of thse fat-cats prevails. I find them both equally disgusting (see recent discoveries about Google's breach of privacy in WiFi-gate).
I just hate to see people rushing to either side in what is essentially a business war. I hate seeing corporations brainwashing people into believeing they have good intentions. They don't.
I just hate to see people rushing to either side in what is essentially a business war. I hate seeing corporations brainwashing people into believeing they have good intentions. They don't.
>* I hate seeing corporations brainwashing people into believeing they have good intentions. They don't.*
No, man, they don't, they want to make, howyacallit, MONEY... (takes another bong hit), ... that's like hideous man.
Well, joking aside, people aren't exactly taking Google's or Oracle's side, that just note that if Oracle wins it's bad news for everyone else too
--despite whatever Google has done on the "wifi-gate" which is something completely different and beside the point in this discussion.
No, man, they don't, they want to make, howyacallit, MONEY... (takes another bong hit), ... that's like hideous man.
Well, joking aside, people aren't exactly taking Google's or Oracle's side, that just note that if Oracle wins it's bad news for everyone else too
--despite whatever Google has done on the "wifi-gate" which is something completely different and beside the point in this discussion.
> if Oracle wins it's bad news for everyone else
See, I'm not 100% sure about this. This could be Google spreading FUD to gain popular support (and, oh, how much the corporate heads at Google love to hear the crowds cheer them on - it makes them feel so of the people, for the people).
IANAL, but couldn't the ruling say that simply implementing an API is fair use, but the way Google did it isn't (because it's not quite compatible, or because it's too compatible, or because it was done in bad faith after they'd failed to obtain a license, or for whatever reason)?
See, I'm not 100% sure about this. This could be Google spreading FUD to gain popular support (and, oh, how much the corporate heads at Google love to hear the crowds cheer them on - it makes them feel so of the people, for the people).
IANAL, but couldn't the ruling say that simply implementing an API is fair use, but the way Google did it isn't (because it's not quite compatible, or because it's too compatible, or because it was done in bad faith after they'd failed to obtain a license, or for whatever reason)?
>See, I'm not 100% sure about this. This could be Google spreading FUD to gain popular support
Well, the core of the case is if APIs are copyrightable or not. One could not care less about Google and still want a negative verdict on the matter.
>IANAL, but couldn't the ruling say that simply implementing an API is fair use, but the way Google did it isn't (because it's not quite compatible, or because it's too compatible, or because it was done in bad faith after they'd failed to obtain a license, or for whatever reason)
Even that would be bad.
If they keep it as clear-cut as "APIs are not copyrightable, period" it's good for anyone.
But if instead the courts muddies this to "APIs are not copyrightable, but you can be convicted if you copy them /in bad faith/not compatible enough/too compatible/whatever" then you can never really be sure.
Whatever pulls the law towards a more restrictive interpretation of the APIs are not copyrightable is bad, because it sets a precedence (a, so called "Overton window").
PS. I don't much like the notion of "FUD". A corporation could be spreading lies, sure. But FUD smells too much like a relic of some GNU-zealot parlance from the 90's Microsoft Wars. To me it's as dated as "information superhighway", and doubly confusing.
Well, the core of the case is if APIs are copyrightable or not. One could not care less about Google and still want a negative verdict on the matter.
>IANAL, but couldn't the ruling say that simply implementing an API is fair use, but the way Google did it isn't (because it's not quite compatible, or because it's too compatible, or because it was done in bad faith after they'd failed to obtain a license, or for whatever reason)
Even that would be bad.
If they keep it as clear-cut as "APIs are not copyrightable, period" it's good for anyone.
But if instead the courts muddies this to "APIs are not copyrightable, but you can be convicted if you copy them /in bad faith/not compatible enough/too compatible/whatever" then you can never really be sure.
Whatever pulls the law towards a more restrictive interpretation of the APIs are not copyrightable is bad, because it sets a precedence (a, so called "Overton window").
PS. I don't much like the notion of "FUD". A corporation could be spreading lies, sure. But FUD smells too much like a relic of some GNU-zealot parlance from the 90's Microsoft Wars. To me it's as dated as "information superhighway", and doubly confusing.
You can run other JVM languages on Android today. The Android compiler take Java byte code and translates it to Dalvik byte code.
See here for Clojure: http://dev.clojure.org/display/design/Android+Support
"Works out of the box with 1.2.0+" -- other JVM languages should have a similar story.
See here for Clojure: http://dev.clojure.org/display/design/Android+Support
"Works out of the box with 1.2.0+" -- other JVM languages should have a similar story.
Not really. Many languages emit bytecode at runtime. I saw a Clojure solution to this once which involved writing the bytecode to a local file, running the Dalvik compiler (locally, on the mobile device!) to create an apk, and loading it. Clearly, that's jumping through hoops.
That's not really fair, tbh, (and I'm a huge fan of Clojure). It's dog-slow on Android. I don't know the details, but I think it's has a lot to do with differences between Dalvik and Hotspot.
Clojure is currently significantly slower than Java in general, likely due to dynamic typing. See:
http://shootout.alioth.debian.org/u64q/benchmark.php?test=al...
Right, but that's not terribly relevant to this thread. As I understand it the difference between Clojure on Dalvik and Java on Dalvik is much greater than Clojure on Hotspot and Java on Hotspot.
> Side note: a ruling on API copyrights could have far reaching ramifications, some might be quite unfortunate, but it's important to make clear that Oracle did not start out trying to establish API copyrightability. They simply set out to nail Google for Android, and API copyright was simply a tool in their legal toolbox.
Er, I'm not seeing the part of that which makes Oracle look better.
Er, I'm not seeing the part of that which makes Oracle look better.
It's not supposed to, except to say that Oracle isn't trying to fight developers - it's just fighting Google (though innocent developers may be accidental victims).
Frankly, I can't bring myself to whole-heartedly support either party. They're both big, fat, super-rich and super-powerful conglomerates who have no one's interest in mind except their own (and, possibly, their shareholders').
Frankly, I can't bring myself to whole-heartedly support either party. They're both big, fat, super-rich and super-powerful conglomerates who have no one's interest in mind except their own (and, possibly, their shareholders').
> It's not supposed to, except to say that Oracle isn't trying to fight developers - it's just fighting Google (though innocent developers may be accidental victims).
In this case, the two are functionally equivalent. It's not even a subtle side effect, everyone is saying it as loudly as possible, so "accidental" or "unintended" seem disingenuous at this point.
In this case, the two are functionally equivalent. It's not even a subtle side effect, everyone is saying it as loudly as possible, so "accidental" or "unintended" seem disingenuous at this point.
True. Then again, everything large corporations do is disingenuous.
what difference would it make to run android on JVM instead of DVM? Isn't android too far along to take a u-turn and change the roots.
It would make a lot of difference. First of all, you'd be able to run programs written in dynamic JVM languages like Clojure, Groovy or JRuby unmodified.
Second, Dalvik was designed for low-power, low-performane, previous-generation handsets. Embedded HotSpot is years ahead of it in terms of performane.
I honestly don't know if Android is too far along to switch.
Second, Dalvik was designed for low-power, low-performane, previous-generation handsets. Embedded HotSpot is years ahead of it in terms of performane.
I honestly don't know if Android is too far along to switch.
Dalvik is optimized for low-power, low-memory devices. If you tried to run the full HotSpot VM on your phone you'd suck the battery dry in minutes and you'd have to at least double the onboard ram to even boot it.
Well those resources were certainly well spent, as the current dominance of these two companies indicates.