Live data from Hacker News

Mysterious Android codebase commit

android.googlesource.com

141–150 of 170 posts

Re: Mysterious Android codebase commit

#141
post #35

Earlier quoted context omitted.

I'm all for the JVM but it's too powerful to run arbitrary code man. No JVM in my browser please.

The Java plugin's mistake was to embed a rich sandboxing mechanism right in the middle of the language layer. The Java runtime, in the middle of parsing bytecode and registering class hierarchies, is supposed to enforce who can access what things, not simply as an advisory mechanism or safety check (as public/private is just about everywhere else), but as a security mechanism under active assault, with only this sing…

The Java plugin's mistake was to have a crap auto update mechanism, and be politically unpopular because it wasn't open source. That's it.

Both Firefox and Chrome ship massive numbers of security fixes with a high degree of regularity, but nobody cares, because:

1) It's the web, and The Web is close to religion for many people.

2) Their auto update mechanisms are pretty good, for Chrome, best in class, so people get the bug fixes.

The JVM sandboxing mechanism itself isn't the issue. The design is sound. All sandboxes have escapes especially where native code is concerned, and JavaScript sandboxes have proven no different in this respect. The issue boils down to auto update (lack of).

Re: Mysterious Android codebase commit

#142
post #133

Earlier quoted context omitted.

I am biased towards Oracle because I do want Android to be closer to orginal Java and wish both companies collaborate for future Java versions. However I do agree that Google's PR has tried to picture Google as victim. If we see Google specifically didn't choose OpenJDK to avoid GPL. So they wanted to make profits but avoid collaboration. If this makes them bring to use GPL, let it be.

> If we see Google specifically didn't choose OpenJDK to avoid GPL. As far as I know, when Android started to be developed, OpenJDK didn't exist

You're right, but it existed early enough (before Android's release) to be adopted by Android. Here is the relevant timeline -- http://www.pcworld.com/article/253666/a_timeline_of_oracles_.... OpenJDK was released in May 2007.

Re: Mysterious Android codebase commit

#143
post #112

Earlier quoted context omitted.

> Okay, so can I modify it so that it doesn't conform to the Java specification? Can I modify it bit-by-bit until it's bytewise identical to Harmony? Absolutely (on both counts, although if it is identical to Harmony you may be in violation of the license due to a collision between GPLv2 and ASL, as ASL imposes further restrictions which GPLv2 does not allow -- see the next paragraph). > Because if I do, Oracle will…

> [1]: I am willing to bet that very few people understand what the Oracle v. Google court case is all about, And what it was about?

First, we should separate the motivation for the lawsuit from the legal arguments. Corporations don't go to court to win legal arguments; they go to court to defend or promote their business.

I) The motivation for the lawsuit was that at the time, Java's main revenue stream was licensing Java IP (either an actual implementation or the permission to implement the spec) for use in mobile devices. That was how Sun made money off of Java. Java's commercial license allowed people to freely implement the specification as long as they pass the compatibility test, unless the implementation was for use in mobile devices -- this required a paid license. Google then created an implementation of (a part of) the spec, and didn't reach a licensing agreement with Sun (they couldn't agree on a price; I think Sun wanted $25M for the first five years or something). Google used Java IP to directly attack said IP's main revenue source. That is not to say that what they did wasn't legal, but that is why what they did mattered to Sun (and then Oracle) enough to sue them. Google needed Java because developing a language ecosystem suitable for phone application takes years. Google knew that such a lawsuit is forthcoming -- you can't come at a company like that and not expect one -- but hoped that they could defend their actions in court, at least on legal grounds. So that's what the lawsuit was about.

II) Now for the legal case. Oracle wanted to get their (in their view -- fair) share of Android no matter how, so they used -- as anyone does -- any legal argument they could think of which would get the desired business result, from patents to copyright. Some stuck, some didn't. In the end, it was the API copyright argument that convinced the (appeals) court. But before I say a few words about that, let me reiterate: Oracle didn't set out to copyright APIs; they set out to get a share of Android, which attacked their main Java revenue stream directly using their own IP. Anyway, Google claimed that APIs aren't copyrightable, but Oracle won that round. Now, I will not go into this question itself -- there are good arguments for both sides -- but only into its ramifications. Google started a massive PR campaign to convince people that that ruling is disastrous for them, but it isn't, and for several reasons.

First, it applies only to language-level APIs; not REST protocols, recently also referred to as APIs. This is not open to interpretation. Web "APIs" are not copyrightable for completely other reasons, reasons which are impossible (as much as anything in law is impossible) to argue against. Second, the court ruled that some of Google's argument regarding the copyrightability of APIs are really fair use arguments, and this is the second crucial point: if something is copyrighted, that does not mean you may not freely use it for some purposes. When it comes to interfaces, one fair use defense has been interoperability[1]. Courts have ruled it legal to "violate" copyright for the purpose of creating components that are interoperable with the original. This means that if you implement an API in order to break vendor lockin, you're probably within your right to do so. However, that is not what Google did in this particular case (Android is not interoperable with Java, only very, very partially). So while Google may still lose the fair-use question (which is still on the table), nearly all other implementors would still be protected by fair use.

To sum up the legal issue, while it has been in Google's best interest to cause panic, the ruling does not apply to any other player but Google because:

1. It only applies to language-level APIs; it does not and cannot apply to web APIs and other protocols (either software or hardware).

2. Implementing an API is protected by the interoperability fair-use defense, even if Google's particular (and highly unusual) use isn't.

And in any case, unless you use a company's (language-level) API against it, there is little chance they'll come after you; if you do, well, you knew they'd come after you even before this court case.

III) Finally, it is important to note that all along Google had the option of freely using OpenJDK. The use of OpenJDK does not require conformance with the Java standard; it is completely unencumbered. The reason Google opted not to do it was because at the time they were afraid phone manufacturers would not like OpenJDKs license, GPLv2 + the classpath exception, even though Android also make use of Linux, which is also licensed under the GPL. This reasoning seems to have changed now.

[1]: https://www.cs.duke.edu/courses/cps182s/fall02/cscopyright/C...

Re: Mysterious Android codebase commit

#144
post #143

Earlier quoted context omitted.

> [1]: I am willing to bet that very few people understand what the Oracle v. Google court case is all about, And what it was about?

First, we should separate the motivation for the lawsuit from the legal arguments. Corporations don't go to court to win legal arguments; they go to court to defend or promote their business. I) The motivation for the lawsuit was that at the time, Java's main revenue stream was licensing Java IP (either an actual implementation or the permission to implement the spec) for use in mobile devices. That was how Sun made…

I think after a legal counsel it was impossible for Oracle not to move to courts. Else others would create spin-off's from Java and cite Android as an example.

Re: Mysterious Android codebase commit

#145
post #143

Earlier quoted context omitted.

> [1]: I am willing to bet that very few people understand what the Oracle v. Google court case is all about, And what it was about?

First, we should separate the motivation for the lawsuit from the legal arguments. Corporations don't go to court to win legal arguments; they go to court to defend or promote their business. I) The motivation for the lawsuit was that at the time, Java's main revenue stream was licensing Java IP (either an actual implementation or the permission to implement the spec) for use in mobile devices. That was how Sun made…

> Google then created an implementation of (a part of) the spec, and didn't reach a licensing agreement with Sun

If Google used Apache Harmony, the ones implementing it where Apache Foundation. Why Oracle didn't sue Apache?

> hat is not to say that what they did wasn't legal, but that is why what they did mattered to Sun (and then Oracle) enough to sue them

Sun didn't sue Google in the 5 years Google used Android

> First, it applies only to language-level APIs; not REST protocols, recently also referred to as APIs. This is not open to interpretation. Web "APIs" are not copyrightable for completely other reasons, reasons which are impossible (as much as anything in law is impossible) to argue against.

And exactly why is different? The ruling talks about API and API's has nothing to do with being a language level API or a "web API".

> Second, the court ruled that some of Google's argument regarding the copyrightability of APIs are really fair use arguments"

As far as I know, the appeal court ruled that the fair use question must be decided in the forthcoming case, nothing more. As any other copyright case

> To sum up the legal issue, while it has been in Google's best interest to cause panic, the ruling does not apply to any other player but Google because: >1. It only applies to language-level APIs, not web APIs.

You have to make your case why only applies to lkevel language API's

> 2. It is protected by the interoperability fair-use defense, even if Google's particular use isn't.

No, it has to go to court so yes, any player must be concerned

Re: Mysterious Android codebase commit

#146
post #143

Earlier quoted context omitted.

First, we should separate the motivation for the lawsuit from the legal arguments. Corporations don't go to court to win legal arguments; they go to court to defend or promote their business. I) The motivation for the lawsuit was that at the time, Java's main revenue stream was licensing Java IP (either an actual implementation or the permission to implement the spec) for use in mobile devices. That was how Sun made…

> Google then created an implementation of (a part of) the spec, and didn't reach a licensing agreement with Sun If Google used Apache Harmony, the ones implementing it where Apache Foundation. Why Oracle didn't sue Apache? > hat is not to say that what they did wasn't legal, but that is why what they did mattered to Sun (and then Oracle) enough to sue them Sun didn't sue Google in the 5 years Google used Android > F…

> Why Oracle didn't sue Apache?

Simple: because they didn't have the motivation (see point (I)). Their goal wasn't to copyright APIs (that just was one of the many tactics used in court, and the one that just happened to win), but to get their share of Android. Suing Apache wouldn't have helped their goal in the least.

Also, while not relevant to the question, I will note that even if APIs are copyrighted, Harmony has a much stronger fair-use defense than Android: 1. It was done for the purpose of interoperability and 2. it was not intended to make a profit. Each of these is a fair use defense alone, and certainly together, but neither is true for Android (although the first might be partially true).

> Sun didn't sue Google in the 5 years Google used Android

Because they didn't have the resources and the inclination, as the company was already in a downward spiral and such a lawsuit could only have hurt them at the time. Google, however, fully expected them to.

> The ruling talks about API and API's has nothing to do with being a language level API or a "web API".

That's only because the term "API" -- until very recently -- was only used to describe language-level API, while what today is known as a web API has always been called a protocol, so don't let the recent overloading of the term confuse you.

More to the point, the reason copyright may apply to APIs but certainly not to protocols is because copyright law is not only concerned with the intent, abstraction, or use of the work, but also with its form. This why other IP protections (like patents) exist, to cover works whose form does not match those covered by copyright.

In particular, copyright requires a fixed representation (in text, image, recording etc.). So, for example, if I tell you a story, the story isn't copyrighted. But if I write it down -- or even record it -- then the text of the story or the recording is copyrighted. It doesn't matter that the purpose in all three cases was the same: to convey a story (once that fixed form is copyrighted, the protection may extend to non-exact reproductions, but that original fixed-form must exist). While a protocol may be described in a text and that text is copyrighted, the described protocol itself cannot be, because it does not have a fixed representation in text (a completely different text could describe the same protocol). A language API does have a fixed form.

> the appeal court ruled that the fair use question must be decided in the forthcoming case, nothing more. As any other copyright case

Yes, but that was the point. Google made some arguments that they believed would make APIs non-copyrightable. The court ruled that those arguments are fair-use arguments which are not relevant to the question of copyrightability, but may be used as a defense once APIs are copyrighted.

> No, it has to go to court so yes, any player must be concerned

Quite the opposite. It is the copyright holder who has to sue you. Any company would sue you if they believe they have a case, and you would still need to defend yourself in court when they do. The question of API copyrightability had never been decided, so even before the ruling there was a good chance you'd be sued, and you'd still need to defend yourself. Now, it is true that a ruling against API copyrightability would have removed this threat (which had existed even prior to this case), but now your position is not much different than before, only that except making two arguments (as Google did) -- that API are not copyrightable and if they are, you've made fair use of them -- you only have one: fair use.

Re: Mysterious Android codebase commit

#147
post #146

Earlier quoted context omitted.

> Google then created an implementation of (a part of) the spec, and didn't reach a licensing agreement with Sun If Google used Apache Harmony, the ones implementing it where Apache Foundation. Why Oracle didn't sue Apache? > hat is not to say that what they did wasn't legal, but that is why what they did mattered to Sun (and then Oracle) enough to sue them Sun didn't sue Google in the 5 years Google used Android > F…

> Why Oracle didn't sue Apache? Simple: because they didn't have the motivation (see point (I)). Their goal wasn't to copyright APIs (that just was one of the many tactics used in court, and the one that just happened to win), but to get their share of Android. Suing Apache wouldn't have helped their goal in the least. Also, while not relevant to the question, I will note that even if APIs are copyrighted, Harmony ha…

> That's only because the term "API" -- until very recently -- was only used to describe language-level API, while what today is known as a web API has always been called a protocol, so don't let the recent overloading of the term confuse you.

A protocol is not the same as an API and I don't hink that the, for example, Google Maps interface is a protocol

> More to the point, the reason copyright may apply to APIs but certainly not to protocols is because copyright law is not only concerned with the intent, abstraction, or use of the work, but also with its form. This why other IP protections (like patents) exist, to cover works whose form does not match those covered by copyright.

But a web API is not a protocol and a communication protocol is not what is used to call Google Maps, beeminder or other web applications.

> Yes, but that was the point. Google made some arguments that they believed would make APIs non-copyrightable. The court ruled that those arguments are fair-use arguments which are not relevant to the question of copyrightability, but may be used as a defense once APIs are copyrighted.

NO, the appeal ruling had nothing to do with Google arguments about fair use. If there is a new trial to rule about the fair use is because in the original trial, the ruling about fair use was stalled by the jury and Judge Alsup stated that API's can't be copyrighted. And the Appeal court didn't wanted to rule about fair use

> Quite the opposite. It is the copyright holder who has to sue you.

Yes, but fair use is not automatically granted, so, you're in danger to be sued by the copyright holder. Microsoft can sue WINE developers or Amazon can sue anyone developing a clone of the AWS API.

Re: Mysterious Android codebase commit

#148
post #146

Earlier quoted context omitted.

> Why Oracle didn't sue Apache? Simple: because they didn't have the motivation (see point (I)). Their goal wasn't to copyright APIs (that just was one of the many tactics used in court, and the one that just happened to win), but to get their share of Android. Suing Apache wouldn't have helped their goal in the least. Also, while not relevant to the question, I will note that even if APIs are copyrighted, Harmony ha…

> That's only because the term "API" -- until very recently -- was only used to describe language-level API, while what today is known as a web API has always been called a protocol, so don't let the recent overloading of the term confuse you. A protocol is not the same as an API and I don't hink that the, for example, Google Maps interface is a protocol > More to the point, the reason copyright may apply to APIs but…

> A protocol is not the same as an API and I don't hink that the, for example, Google Maps interface is a protocol

However you want to call it, unlike a "proper" API, it is not of the right form to be copyrighted, regardless of the ruling pertaining to "proper" APIs.

> NO, the appeal ruling had nothing to do with Google arguments about fair use.

The court didn't rule on fair use, but it did address it. They said that now that it has been clarified that interoperability is not relevant to the copyrightability analysis, it may still play a role in connection with fair use. Namely, that Google interoperability argument isn't an argument against copyright, but rather a fair-use defense, which should be argued separately (http://www.fosspatents.com/2014/05/oracle-wins-android-java-...).

> Yes, but fair use is not automatically granted, so, you're in danger to be sued by the copyright holder

That danger had existed even before the court case; the ruling simply did not lift it. Fair use is granted neither automatically nor in court. It is a defense to be used if you are sued.

Re: Mysterious Android codebase commit

#149
post #61

Earlier quoted context omitted.

Option two wasn't even worth mentioning. There is absolutely no way Google is going to abandon ART and switch to a significantly less performant VM. AOT is here to stay.

A JIT makes many tradeoffs but it is always capable of producing code at least as good as an AOT. How much better that code is depends on many factors, such as the language, the application, and how much time/energy you're willing to spend on optimization (the latter might lead to choosing to generate code that's less optimized than an AOT). A slightly bigger difference is not between JIT and AOT, but whether you can…

The main benefit from ART on Android is having all of the code generated in advance and mapped from storage. There's no waste from code being generated at runtime in-memory. Wasting memory by generating code dynamically certainly hurts performance so claiming that a JIT compiler is always just as good is not true.

There's room for a JIT compiler but the sanest baseline is mapping AOT compiled code from storage. It's way faster than a baseline interpreter and way lighter than a baseline method JIT.

Re: Mysterious Android codebase commit

#150
post #113

Earlier quoted context omitted.

Of course a JIT is capable of producing code as good as an AOT and perhaps even better since it can capture more profiling data. The problem with a JIT is the startup time and this has not gone unnoticed by Oracle as even they've started working on AOT.

Not startup but warmup (i.e. the time until the application is fully optimized). There are other problems with a JIT on small devices, such as increased memory and energy consumption (each may be significant or not, depending on how the JIT works). I am a big fan of JITs, but as with everything in software, it is a tradeoff.

Increased memory consumption and reduced page sharing between processes using the same code means lower performance. Memory bandwidth and cache capacity are a much bigger bottleneck than CPU throughput for most use cases. A JIT compiler is not competitive in performance with an AOT compiler if both are using the same code generation implementation. And profiling is limited in what it can do, especially when AOT compilation with PGO as used by projects like Firefox is considered.
Post reply on HN