Bryan is a smart funny guy, but he's an opinionated asshole that represents everything wrong with silicon valley engineer "rockstar" culture.
I didn't rewatch the video, but have seen it and met him dozens of times back in the OpenSolaris then Joyent days. He seems to simplify things to portray cause and effect that do not exist due to the complexity of real life.
I trust his ability to engineer a brilliant product, but I don't trust his ability to create a lovable product - it's all about the engineering goodness to him, and not solving the real world problems. Joyent's financials and yearly change of directions will probably back that up...
Oracle is Oracle - there are good things and bad things about a process driven company with 2000 products, but understand there is massive bias in Bryan's video - he didn't get his way and he wants people to know it.
Oh, I understand that, but I find the video entertaining, and I will say that I often have trouble finding viewpoints from places like Oracle, IBM, and SUN. Ever notice how there are tons of videos/tech talks from Microsoft, Google, and the Open Source crowd, but places like Oracle/IBM/SAP it feels very vaulted?
As a former product manager from one of the vaulted companies we had tons of video around business benefits and use cases, but very little on the implementation part. Look for the curated video channels for the big vendor players.
You wouldn't give a shit either if you could get nearly 10bln dollars for it.
Most people would sell their mother for that amount, and it's a bit hard to come to your investors and say well guys we could've gotten 10bln which would give you a heck of a dividend but we cared about our reputation too much so we passed on it.
Yeah, but how much have they expended on this legal adventure already? It has been going on for ~6 years now and there's no end in sight, no clear victory for anybody. Doesn't Oracle have better things to do?
Considerably less than 10bln, say even if they spent 100m on legal fees, that's still about 1% of what they would end up earning that's 1:100 return on investment no one would in their right mind would pass on that.
OK, but it is still a roll of the dice and there are costs beyond legal fees. 1:100 is _highly_ unlikely. Lawsuits are a crappy way to make money for a software company.
Creating a startup to service the CIA is a pretty crap move too; Oracle's launch was largely fueled by creating the database for the CIA in the late 1970s.
They are not going to get $10^9 for it, they are asking for that much because asking is free.
But then, when the rubble stops bouncing and the companies come to an agreement, that high watermark will help them negociate an actual price that is both reasonable but higher than what otherwise would have been.
What was the reason that the appeals court overturned the ruling on APIs?
For $9.3 billion - surely it is is economically viable for Google to spend 10 million on a coordinated and public campaign to lobby lawmakers to change the law? If they did it publicly then they'd have huge support.
Heck, Google could even openly label Oracke as greedy, conniving bastards and almost certainly no amount of protest from Oracle would be convincing! All Google need to point out is that Oracle are screwing a majority of Android users.
A side note: they must truly be regretting choosing Java.
This may be one of the reasons Google invented Go (language). I wouldn't be surprised to see if future versions of their platforms are Go-lang only. Make Java obsolete
I'd be happy with golang for Android -- but if Google is interested in that, they seriously have the project understaffed. Seems like just a few engineers on the go mobile project. It's been alpha stage for almost a year.
Isn't Dart for browsers? And it looks like WebAssembly might overtake Dart there. Maybe that would work for Chrome Web Apps on Android, I haven't tried.
For native apps, I think it's still mainly Java, tho JetBrains is promoting Kotlin as an alternative.
The way I remember it dart was released to replace javascript as an actual viable sane language for apps, which means it could double as a longterm replacement for smartphone apps as well.
Mozilla resisted dart in the browser and focused heavily on improving javascript which left dart dead in the water.
No clue why you are being downvoted as this is an important point: Android's Java forcefeed is negative in more ways than one. We need multiple alternatives (yes yes Kotlin I know but more). Many programmers dislike Java and will do anything to avoid having to use it.
Judging from the mess that cross compiling binary to Android is (compared to iOS), it seems that Google is not seriously offering that as an option.
Weird to me, as it is the best way to ensure every one can do what every they like on your platform (and possible re-use large portions of code on other platforms).
Go is entirely pointless as a GUI language - it has a niche it tries to fit well.
Dart is much much better as a Java replacement and efforts like flutter are really promising for cross language dev - IPC architecture behind it and chrome (Mojo) is how Android should have been implemented, then it doesn't matter what languages you use they are trivial to swap because IDL defined interfaces can be reimplemented transparently and client API can be generated automatically. Instead you are locked in to their JVM
interesting to see that the highly-supported VM platforms are spawning ecosystems of languages that target other languages. javascript is the best example but JVM is a close second (clojure, scala, kotlin).
the trade-off here is accepting build slowness & complexity in exchange for escaping the negatives of the default language for your platform.
I think we won't get off this trend until we figure out a bytecode format that balances sandboxing and portability. WASM?
I agree but I don't understand how that relates to Dart (has a standalone VM of decent quality) or Mojo (IPC API language - basically abstracts stuff on a OS process level - cross language/VM/process interop being transparent)
Both great products with great technology but neither is ubiquitous. JVM & javascript have pentrated their target audience enough that 'building on top' saves your users some installation work.
For the record, it was not Oracle that was "doing squat". Oracles's JDK keeps improving, and btw Oracle is paying for most of it. Since Android "fork", Oracle added generics and lambdas and G1 and bazillion other improvements.
The company that was "doing squat" was Google. Their shitty (and incompatible) Java implementation is where Oracle's was 6 years ago.
I am afraid you are digressing. Oracle maintains and has rights for the language Java and Oracle JVM. Google has power over Android. codecamper isnt talking about what improvements current Java has or how how shitty the Android java is. IT is about Android itself. Google contributed most to Android, Oracle did not.
That is not what "digressing" means. When someone talks on topic, that is not "digressing". Why not check an online dictionary, they are free and super helpful.
If I were to write an ISC licensed clean room implementation of Apple UIKit, would Apple be in the right to bury me?
If Oracle thinks they can ask for 9.3 billion and are likely expecting to get 1 or 2, it sounds scary.
But I hope this will lead to more and more open APIs without a single entity holding the keys and people being very scared to use closed and copyrighted APIs. If less people use it, its importance will equally be diminishing. That's the hope.
If I were to write an ISC licensed clean room implementation of Apple UIKit, would Apple be in the right to bury me?
"The appeals court reversed the district court on the central issue, holding that the "structure, sequence and organization" of an API was copyrightable"[0]
That's pretty clear. Even if you re-implement every function by hand, if you keep the same API, then it can be a copyright infringement. Note that you may still have other defenses such as license agreements, or fair use. But this ruling considers copying API/function declarations the same as actual code.
How did the original PC clones get away with reverse engineering / re-implementing the IBM BIOS? Or alternatives to MS-DOS like DR-DOS? Is it just that nobody thought to use this attack?
This is a brand new ruling. Indeed, I'm not sure a lot of legal people thought SSO of apis was a copyrightable artifact. Otherwise, it's likely that a lot of stuff wouldn't have been created in the same way (Google's work on dalvik, all of the "aws compatiable api" cloud tools, etc).
The key thing here is that even though they ruling is saying that SSO is copyrightable, that still means the normal defenses against copyright infringement are still available (ex: fair use). It also means that re-implementing a clean room compatible implementation of an API could still mean licensing fees, and thus less interoperability. Think about open source software that implements a compatibility layer to interoperate with a closed source API. Just copying that SSO could be infringement, and thus some people are likely going to be less interested in creating that software if there are possible legal repercussions.
> What does the API ruling mean for the rest of us?
It's muddled due to the peculiar nature of the appeals path in this case. In a normal copyright case, filed in a court in San Francisco as this case was, here is how things work.
1. A trial is held in a Federal district court. That court looks to the Federal copyright statue (17 USC), the Supreme Court, and the United States Court of Appeals for the Ninth Circuit (which I will just call 9th Circuit CoA from now on) for the copyright law that the court must follow.
2. If there are any copyright issues that the court cannot resolve using the sources mentioned above, it might also look to decisions of the Courts of Appeals for circuits other than the 9th Circuit, or to academic writings, or actually to anything else that might provide some insight.
None of these other sources are binding, though. Only the Supreme Court and the 9th Circuit CoA decisions are binding on a San Francisco Federal district court.
3. The district court reaches a decision, and the losing party appeals. The appeal goes to the 9th Circuit CoA. The 9th Circuit CoA makes a decision.
4. The 9th Circuit COA decision is binding precedent on all future copyright cases heard in district courts in the 9th Circuit.
Now compare this to a patent case. Assume it is purely a patent case. As with our hypothetical copyright case, let's assume this patent case is filed in a San Francisco Federal court.
Everything is the same as it is with the copyright case except replace "Court of Appeals for the Ninth Circuit" with "United States Court of Appeals for the Federal Circuit" (CAFC) [1]. Patent case appeals from district courts all go to CAFC regardless of which Circuit the district court is in.
Where it gets muddled is when a case is both a patent case and a copyright case. That was the case in Oracle vs. Google.
In that situation, the appeal from the district court goes to CAFC, and CAFC rules on both the patent aspects of the appeal and the copyright aspects. However, on the copyright aspects CAFC is supposed to follow the precedents of the appeals court for the Circuit, so in this case they are supposed to follow 9th Circuit CoA copyright precedent...and many legal scholars think they botched this.
This is a pretty messed up design because it creates a situation where you have one court (CAFC) interpreting another court's binding precedent (9th Circuit CoA), but there is no path to appeal the decision from the first court to the second court. In every other situation that comes to mind, if one court is supposed to follow the precedent of another court there is a way to have that second court review the first court.
CAFC's copyright ruling is binding on the district court in this particular case. It is not binding anywhere else. If, say, Apple and Microsoft got into a tussle over APIs and one sued the other in a district court in the 9th Circuit, that court would still look to what the 9th Circuit CoA has said, not to what CAFC says. CAFC would be just another non-Supreme Court, non-9th Circuit CoA source that the court could consider for insight but is not obligated to follow.
So, as long as an API dispute does not also involve patents, the legal status of APIs should be what it was before Oracle vs. Google.
That's assuming that you also think that if you end up getting sued it will not involve patents. If it involves patents, and your lawsuit is in the 9th, then you should assume that CAFC will rule consistently with their Oracle ruling at least until an API case makes it to the 9th Circuit CoA and they say something that makes it clear CAFC misunderstood 9th precedent.
[1] replace might not be quite correct. The district court in a patent case will look to the Supreme Court and CAFC for precedent, but it might also still look to the appeals court for its Circuit, too, because that court will have heard patent appeals before CAFC was created and some of those might still be precedent in that Circuit.
Does anyone have any insight/source on why Java was a good choice for Android at the time it was created? I got lost in a sea of garbage while trying to find anything about that. I would like to understand why Java and not something else.
You're right, but Google released the first Android handsets.
Actually I forgot when the Sun/Oracle sale happened. Android 1.0 was released before Oracle bought Sun. Though I suppose there was always the possibility of legal action by Sun.
Didn't Google think about changing languages several years ago but were already so invested in Java, they decided not to?
I may be remembering that incorrectly
I fear the same thing will happen with Microsoft's .Net code. Once we are all using it the rules will change and we'll be at the mercy of a mega corporation.
Huh, I have never heard about the royalty free licence or opensourcing of parts of clr. Do you have source for that?
Like, the .net core was opensourced just last year, and even the .net micro for resource constrained devices was opensourced in 2010, 2 years after first android device existed.
I am not sure how usefull would using mono have been in this case.
On the other hand, I would agree that C# 3.0 with its support for lambdas, LINQ, ability to just use 'var' for local variable declaration, e.t.c looks like a much nicer language that what Java 6 SE was.
I couldn't find this memo. I'm interested in reading it.
I did find a WSJ article with a quote from a Google engineer:
"We have been over a bunch of these [alternatives to Java] and think they all suck," the Google email continued, according to the transcript, adding, "We conclude that we need to negotiate a license for Java." [0]
Thanks for posting that. The answer to OP's question is right there.
"Nevertheless, describing his experience from his first startup, Danger, Rubin highlighted the benefits of using Java for a smartphone -- primarily the well-known brand name as well as compatibility being that it is a common language taught at universities worldwide."
Because a lot of devs know Java, this let Android gain market share faster since the barrier to develop Android apps was smaller than using some less used or new language.
Well one thing I remember from one of the PyCons, someone had asked Guido (during the years he still worked a Google), why doesn't Android use Python or something to that effect.
And even though Guido is pretty laid back, that is one time I vividly remember he got emotional and said it was "a political decision". But it wasn't the message, it was how he said. It seemed it was something he might have had a strong opinion about.
With that said, trying to port an app to Android maybe 2-3 years back, for me, it kind of redeemed Java a bit. Before that my exposure was EJBs, some web applications and the general FactoryFactoryManager type junk. Working on Adroid's Java I saw a better Java so to speak. (I've heard the opposite from others how they hated Eclipse and Android's Java API and docs, but that wasn't my experience).
Android was not created in house by Google. The company created Android was using/emulating/whatever the technology that was popular when they created Android. They happened to check out Sun's Java 2 ME (J2ME) which Sun is pushing for small devices. At that time PDA, Windows CE, Symbian devices are popular and many are running or capable of running J2ME apps, just like running Java app on your PC today. J2ME is not just Java, but a complete SDK to build GUI apps.
Or rather, in their previous company Danger, Inc., the smartphone they developed for it used Java for those sorts of reasons, and I assume they just continued to do the same thing since it had worked well for them, technically at least.
Mostly correct. My recollection from my early days mobile programming was J2ME or BREW. J2ME was java, BREW was c++.. and usually seemed to be used by more constrained devices that couldn't afford the Java runtime overhead. BREW had all the pain of unmanaged c++ on the desktop, minus any good tools for debugging, and writing safe code. J2ME mostly worked and the carriers liked having a standardized format that encompassed the whole asset chain rather than each app writing thier own custom code for everything. Changing a carrier logo in a J2ME app was often as simple as dropping the new image into the Jar file.. vs BREW where you would have to resurrect the complete tool chain of that project, to fix anything that broke after the original contract ended.
Mostly correct. My recollection from my early days mobile programming was J2ME or BREW. J2ME was java, BREW was c++.. and usually seemed to be used by more constrained devices that couldn't afford the Java runtime overhead. BREW had all the pain of unmanaged c++ on the desktop, minus any good tools for debugging, and writing safe code. J2ME mostly worked and the carriers liked having a standardized format that encompassed the whole asset chain rather than each app writing thier own custom code for everything. Changing a carrier logo in a J2ME app was often as simple as dropping the new image into the Jar file.. vs BREW where you would have to resurrect the complete tool chain of that project, to fix anything that broke after the original contract ended.
"As Oracle tells it, Google was in a mad rush to get its operating system to market before competing platforms could take hold. It chose to use Java because there were already millions of programmers familiar with the language."
It's the 8th paragraph counting from the bottom up.
Well I remembered a keynote on android back in the early days talking about the amount of Java developers, that they could easily start development or something like that.
I think because iPhone SDK was objective-C and it wasn't widely used. So Google might've thought they would've had an edge there
> "In the first trial, a jury found Google had infringed Oracle’s copyright by copying into Android the "structure, sequence and organization" of 37 Java application programming interfaces"
I don't think these trials have been about technically using Java as a whole have they? They are about specifically copy/pasting those 37 classes into the Android code base. If I remember correctly, all other part of Android were basically a clean room implementation that did not even allegedly infringe on anything. They just screwed up in those few places.
IIRC the appeals court ruled that the "'structure, sequence and organization' of an API was copyrightable". So even if they hadn't copied a small number of classes¹, they'd still be liable if that decision holds.
¹ Or accidentally implemented them using the exact same code, which is quite possible given how trivial the code in question was - see rangeCheck
87 comments
[ 2.5 ms ] story [ 144 ms ] threadHe wasn't thrilled about it.
I didn't rewatch the video, but have seen it and met him dozens of times back in the OpenSolaris then Joyent days. He seems to simplify things to portray cause and effect that do not exist due to the complexity of real life.
I trust his ability to engineer a brilliant product, but I don't trust his ability to create a lovable product - it's all about the engineering goodness to him, and not solving the real world problems. Joyent's financials and yearly change of directions will probably back that up...
Oracle is Oracle - there are good things and bad things about a process driven company with 2000 products, but understand there is massive bias in Bryan's video - he didn't get his way and he wants people to know it.
Most people would sell their mother for that amount, and it's a bit hard to come to your investors and say well guys we could've gotten 10bln which would give you a heck of a dividend but we cared about our reputation too much so we passed on it.
https://www.iqt.org/
But then, when the rubble stops bouncing and the companies come to an agreement, that high watermark will help them negociate an actual price that is both reasonable but higher than what otherwise would have been.
How many people here would just go "oh nah, it's OK... go ahead, we don't want any money. Do your thing Google!".
For $9.3 billion - surely it is is economically viable for Google to spend 10 million on a coordinated and public campaign to lobby lawmakers to change the law? If they did it publicly then they'd have huge support.
Heck, Google could even openly label Oracke as greedy, conniving bastards and almost certainly no amount of protest from Oracle would be convincing! All Google need to point out is that Oracle are screwing a majority of Android users.
A side note: they must truly be regretting choosing Java.
For native apps, I think it's still mainly Java, tho JetBrains is promoting Kotlin as an alternative.
Mozilla resisted dart in the browser and focused heavily on improving javascript which left dart dead in the water.
Weird to me, as it is the best way to ensure every one can do what every they like on your platform (and possible re-use large portions of code on other platforms).
Dart is much much better as a Java replacement and efforts like flutter are really promising for cross language dev - IPC architecture behind it and chrome (Mojo) is how Android should have been implemented, then it doesn't matter what languages you use they are trivial to swap because IDL defined interfaces can be reimplemented transparently and client API can be generated automatically. Instead you are locked in to their JVM
the trade-off here is accepting build slowness & complexity in exchange for escaping the negatives of the default language for your platform.
I think we won't get off this trend until we figure out a bytecode format that balances sandboxing and portability. WASM?
The company that was "doing squat" was Google. Their shitty (and incompatible) Java implementation is where Oracle's was 6 years ago.
If I were to write an ISC licensed clean room implementation of Apple UIKit, would Apple be in the right to bury me?
If Oracle thinks they can ask for 9.3 billion and are likely expecting to get 1 or 2, it sounds scary.
But I hope this will lead to more and more open APIs without a single entity holding the keys and people being very scared to use closed and copyrighted APIs. If less people use it, its importance will equally be diminishing. That's the hope.
"The appeals court reversed the district court on the central issue, holding that the "structure, sequence and organization" of an API was copyrightable"[0]
That's pretty clear. Even if you re-implement every function by hand, if you keep the same API, then it can be a copyright infringement. Note that you may still have other defenses such as license agreements, or fair use. But this ruling considers copying API/function declarations the same as actual code.
[0] - https://en.wikipedia.org/wiki/Oracle_America,_Inc._v._Google....
This is a brand new ruling. Indeed, I'm not sure a lot of legal people thought SSO of apis was a copyrightable artifact. Otherwise, it's likely that a lot of stuff wouldn't have been created in the same way (Google's work on dalvik, all of the "aws compatiable api" cloud tools, etc).
The key thing here is that even though they ruling is saying that SSO is copyrightable, that still means the normal defenses against copyright infringement are still available (ex: fair use). It also means that re-implementing a clean room compatible implementation of an API could still mean licensing fees, and thus less interoperability. Think about open source software that implements a compatibility layer to interoperate with a closed source API. Just copying that SSO could be infringement, and thus some people are likely going to be less interested in creating that software if there are possible legal repercussions.
It's muddled due to the peculiar nature of the appeals path in this case. In a normal copyright case, filed in a court in San Francisco as this case was, here is how things work.
1. A trial is held in a Federal district court. That court looks to the Federal copyright statue (17 USC), the Supreme Court, and the United States Court of Appeals for the Ninth Circuit (which I will just call 9th Circuit CoA from now on) for the copyright law that the court must follow.
2. If there are any copyright issues that the court cannot resolve using the sources mentioned above, it might also look to decisions of the Courts of Appeals for circuits other than the 9th Circuit, or to academic writings, or actually to anything else that might provide some insight.
None of these other sources are binding, though. Only the Supreme Court and the 9th Circuit CoA decisions are binding on a San Francisco Federal district court.
3. The district court reaches a decision, and the losing party appeals. The appeal goes to the 9th Circuit CoA. The 9th Circuit CoA makes a decision.
4. The 9th Circuit COA decision is binding precedent on all future copyright cases heard in district courts in the 9th Circuit.
Now compare this to a patent case. Assume it is purely a patent case. As with our hypothetical copyright case, let's assume this patent case is filed in a San Francisco Federal court.
Everything is the same as it is with the copyright case except replace "Court of Appeals for the Ninth Circuit" with "United States Court of Appeals for the Federal Circuit" (CAFC) [1]. Patent case appeals from district courts all go to CAFC regardless of which Circuit the district court is in.
Where it gets muddled is when a case is both a patent case and a copyright case. That was the case in Oracle vs. Google.
In that situation, the appeal from the district court goes to CAFC, and CAFC rules on both the patent aspects of the appeal and the copyright aspects. However, on the copyright aspects CAFC is supposed to follow the precedents of the appeals court for the Circuit, so in this case they are supposed to follow 9th Circuit CoA copyright precedent...and many legal scholars think they botched this.
This is a pretty messed up design because it creates a situation where you have one court (CAFC) interpreting another court's binding precedent (9th Circuit CoA), but there is no path to appeal the decision from the first court to the second court. In every other situation that comes to mind, if one court is supposed to follow the precedent of another court there is a way to have that second court review the first court.
CAFC's copyright ruling is binding on the district court in this particular case. It is not binding anywhere else. If, say, Apple and Microsoft got into a tussle over APIs and one sued the other in a district court in the 9th Circuit, that court would still look to what the 9th Circuit CoA has said, not to what CAFC says. CAFC would be just another non-Supreme Court, non-9th Circuit CoA source that the court could consider for insight but is not obligated to follow.
So, as long as an API dispute does not also involve patents, the legal status of APIs should be what it was before Oracle vs. Google.
That's assuming that you also think that if you end up getting sued it will not involve patents. If it involves patents, and your lawsuit is in the 9th, then you should assume that CAFC will rule consistently with their Oracle ruling at least until an API case makes it to the 9th Circuit CoA and they say something that makes it clear CAFC misunderstood 9th precedent.
[1] replace might not be quite correct. The district court in a patent case will look to the Supreme Court and CAFC for precedent, but it might also still look to the appeals court for its Circuit, too, because that court will have heard patent appeals before CAFC was created and some of those might still be precedent in that Circuit.
Google just underestimated the idiocy of the US court system.
Actually I forgot when the Sun/Oracle sale happened. Android 1.0 was released before Oracle bought Sun. Though I suppose there was always the possibility of legal action by Sun.
Schmidt (being an ex-Sun executive) reached out to Sun to talk about an alliance.
http://icdn4.digitaltrends.com/image/google-schmidt-610x452....
Like, the .net core was opensourced just last year, and even the .net micro for resource constrained devices was opensourced in 2010, 2 years after first android device existed.
I am not sure how usefull would using mono have been in this case.
On the other hand, I would agree that C# 3.0 with its support for lambdas, LINQ, ability to just use 'var' for local variable declaration, e.t.c looks like a much nicer language that what Java 6 SE was.
I did find a WSJ article with a quote from a Google engineer:
"We have been over a bunch of these [alternatives to Java] and think they all suck," the Google email continued, according to the transcript, adding, "We conclude that we need to negotiate a license for Java." [0]
[0]http://www.wsj.com/articles/SB100014240531119035202045764826...
"Nevertheless, describing his experience from his first startup, Danger, Rubin highlighted the benefits of using Java for a smartphone -- primarily the well-known brand name as well as compatibility being that it is a common language taught at universities worldwide."
And even though Guido is pretty laid back, that is one time I vividly remember he got emotional and said it was "a political decision". But it wasn't the message, it was how he said. It seemed it was something he might have had a strong opinion about.
With that said, trying to port an app to Android maybe 2-3 years back, for me, it kind of redeemed Java a bit. Before that my exposure was EJBs, some web applications and the general FactoryFactoryManager type junk. Working on Adroid's Java I saw a better Java so to speak. (I've heard the opposite from others how they hated Eclipse and Android's Java API and docs, but that wasn't my experience).
"As Oracle tells it, Google was in a mad rush to get its operating system to market before competing platforms could take hold. It chose to use Java because there were already millions of programmers familiar with the language."
It's the 8th paragraph counting from the bottom up.
I think because iPhone SDK was objective-C and it wasn't widely used. So Google might've thought they would've had an edge there
I don't think these trials have been about technically using Java as a whole have they? They are about specifically copy/pasting those 37 classes into the Android code base. If I remember correctly, all other part of Android were basically a clean room implementation that did not even allegedly infringe on anything. They just screwed up in those few places.
¹ Or accidentally implemented them using the exact same code, which is quite possible given how trivial the code in question was - see rangeCheck