Some quotes to quickly understand what is going on.
Andreas Gal, Former CTO of Mozilla, wrote yesterday:
"... a curious event got my attention: A commit appeared in the Android code base that indicates that Google is abandoning its own re-implementation of Java in favor of Oracle’s original Java implementation. I’ll try to explain why I think this is a huge change and will have far-reaching implications for Android and the Android ecosystem."
Source: http://andreasgal.com/2016/01/05/oracle-sinks-its-claws-into...
Bradley M. Kuhn, in charge with the task of enforcing the GPL for Linux, wrote today:
"Thus, my conclusion about this situation is quite different than the pundits and link-bait news articles. I speculate that Google weighed a technical decision against its own copyleft compliance processes, and determined that Google would succeed in its compliance efforts on Android, and thus won't face compliance problems, and can therefore easily benefit technically from the better code. However, for those many downstream redistributors of Android who fail at license compliance already, the ironic outcome is that you may finally find out how friendly and reasonable Conservancy's Linux GPL enforcement truly is, once you compare it with GPL enforcement from a company like Oracle, who holds avarice, not software freedom, as its primary moral principle."
Source: http://ebb.org/bkuhn/blog/2016/01/05/jdk-in-android.html
He isn't going to be able to enforce the GPL for Linux much longer as SFC needs about 1800 supporters to be able to continue their eminently reasonable copyleft compliance work.
It's weird how uncommon the knowledge that Google lost the lawsuit is. They lost it in appeal at the Federal Circuit. There is a remaining "fair use" decision from the lower courts but Google doesn't have much hope there.
Google's current approach using Harmony's clean-room API implementation has been basically deemed illegal. Google will likely have to pay millions if not billions to Oracle for copyright infringement. And they will continue to be infringing as long as they are distributing their current Android systems.
P.S. The law of the land is now that when you create an API it is copyrighted.
> The law of the land is now that when you create an API it is copyrighted.
The US is the only strange land where such a law could be even comprehended. Asserting API copyright to someone on the basis of accusation of copying nine lines of code[1] indicates that a jury isn't in its right mind.
Nine lines of extremely trivial code; one would be hard pressed to write it any other way. The judge from the initial trial basically yelled at the Oracle attorneys saying that it was code that a highschooler could have written.
HN is a strange forum, where ostensibly intelligent people will post uninformed, sensationalistic comments despite the presence of multiple earlier comments in the same thread by better-informed people explaining things clearly. To wit: https://news.ycombinator.com/item?id=10848716
(While I am not sure it nails all the nuances exactly, especially around the distinction between web and language APIs, it is an infinitely better account of the situation than what I've seen in any tech media so far. Golly, I wonder why.)
Of course, it doesn't help that the better informed comment is also down-voted, making it harder to find.
No doubt, the link you have provided has some merit and explains a lot about the Oracle's side of coin. But after reading a lot about this story from all different angles, my final impression is that no organization is all too saintly or 100% honest, and neither are any altogether guilty. In fact, the thing about organizations is that they are multi-faced and do a lot of complex things and its just impossible to keep track of all those details.
Considering all this, I feel that the only important thing in technology is that concentration of power shouldn't be in the hands of one/few tech companies, be it Oracle or Google. Rather, there should be checks and balances everywhere. Ideally, all software should be produced by communities where all coders are chosen strictly on merit every commit passes through the scrutiny of all members.
>P.S. The law of the land is now that when you create an API it is copyrighted.
No, it's just the law of the Federal Circuit and only when interpreting 9th circuit law. Their decision is not binding precedent on any of the usual circuits, and their usual domain is patent law, not copyright law.
No. The Federal Circuit has subject matter jurisdiction, not geographic jurisdiction. Their decisions are binding precedent throughout the United States.
I think that is correct. This case is a little misleading because there were both patent and copyright claims at the district court level. As a result of the patent claims, the Federal Circuit had jurisdiction over the entire case, even though the copyright claims were to be adjudicated under 9th Circuit precedent. If they had only brought copyright claims, this appeal would have been heard at the 9th Circuit Court of Appeals.
WINE is designed to be compatible with Win32. It is built to be interoperable with that existing product. They strive to be complete, and when issues are found with compatibility, they fix those issues. None of this is true of Android, which explicitly went out of its way to build an incompatible ecosystem of software and libraries using the core work of defining the Java API somewhere in the middle. When the case was first being talked about here, I did a writeup on some of this, extracting quotes from the court's decision that I think make the idea clear. I recommend reading that post.
But WINE isn't designed to be interoperable with Windows. I'm not even sure what that means. Outside of some special cases, it's not like you can get something useful (or even functional) by arbitrarily mixing and matching Windows and WINE components.
Instead, for the APIs it supports, WINE was designed to interoperate with Windows programs (binary and source) in same kind of way the Android Java environment interoperates with Java programs (again both binary and source) for the APIs it supports. There are some minor differences (e.g. WINE works with binary applications directly, Android requires that Java bytecode be compiled to Dex bytecode, etc.) but the overall structure is the same.
Sure, Android only supports few Java APIs and WINE supports tons of Windows APIs, but that's the distinction fair use hangs on, how does any re-implementation of a proprietary API ever get off the ground (legally anyway)?
That point on Microsoft is just their revisionism, though; the documents and emails gathered by discovery at the time show they weren't excited about Java, but actually trying to "kill cross-platform Java by growing the polluted Java market" (direct quote from their internal strategy docs).
So I'm wondering who Microsoft would sue under US jurisdiction for Wine implementing Windows APIs.
Its not like there is some central corporate entity behind Wine - Codeweavers sells its own proprietary fork and could be sued, but upstream free software Wine was founded by a guy from Switzerland (outside the jurisdiction of the incredibly barbaric IP around software in the US, at least until the TPP passes and spreads that plague through the Pacific rim, but even then Europe remains safe and sane for now). They could sue any individual contributor to Wine who lives in the US, but there is no way to extract royalties from the Wine project itself.
> I look forward to the extinction WINE and PostgreSQL, and the resurrection of the SCO corpse for another tilt at Linux vendors, he said sarcastically.
Wasn't one of the central issues that Google copied Java headers verbatim? Wine doesn't copy windows.h [1]; it seems to be a clean room reimplementation.
I don't see why. WINE is done for interoperability and is non-profit: two fair use defenses. SQL is a language and therefore not copyrightable (its spec isn't "fixed", which is a prerequisite for copyright). And as for SCO, AFAIK, it was ruled that they don't own the copyright to begin with.
This says they are[1]: Interoperability has been succesfully used as a fair-use defense in the past, and commercial use decreases the chances of a fair-use ruling. Both points (interoperability and commercial use) are central to the Oracle v. Google case, and have been brought up by both sides. See here[2]:
I reached out to Collard, a partner at Dorsey & Whitney, who specializes in intellectual property... "In my opinion, the biggest problem for Google is the commercial nature of its use [of the APIs]," he said. "That is generally a strike against finding fair use. Its best argument is probably interoperability -- in other words, it should be fair use because Google must use the APIs in order to make its products interoperable."
Starting with oracle hopefully.
(Un)fortunately (and IANAL) I don't think copyrights are enforceable if you don't enforce them everytime you know of a violation.
That won't happen because IBM also uses a lot of Java stuff including the great eclipse infrastructure. They will end up suing each other for a lot of components if that happens. If rumors are to be believed, Oracle and IBM have some sort of "agreement" that they won't sue each other on these matters.
I would venture a guess that IBM is a paid up licensee of Java, they've been releasing their own proprietary JVM for quite a while and never been sued by Sun/Oracle for it AFAIK
But this article seems to be saying that Oracle's version is GPLed. If that's the case, then how can Oracle sue Google for copyright infringement? Is it for violating the GPL?
Google did a clean-room implementation. But what about derivatives? Obviously you have to redistribute your source. Does using your patched version magically become legal iff your changes are merged into the upstream? This seems to defeat the GPL entirely, since it doesn't matter that you have a license to modify the source code if doing so means you are violating copyright on the APIs.
OpenJDK being licensed under the GPL means that the APIs are under the GPL as well. You can legally create your own implementation of the APIs, as long as you don't violate the GPL. Your project would be considered a "derived work" of the APIs, meaning you need to keep the same GPL license.
Apache Harmony is Apache Licensed, and that license is only comaptible with GPL3+. OpenJDK is GPL2 + classpath exception, so no, Harmony is not a valid derivative work of OpenJDK.
Since the only free software Oracle still maintains is the stuff they couldn't relicense from Sun, and the acquisition was before the GPL3 was finalized and even then Sun would not have been able to relicense all their stuff before being bought out, there is no chance of any Oracle products being Apache compatible in the future.
> since it doesn't matter that you have a license to modify the source code if doing so means you are violating copyright on the APIs
I don't understand your argument, wouldn't using the license (GPL) imply a license to use and modify the API's? And that would mean you can create your own modified API, provided it is also under GPL.
This doesn't apply to Google's clean-room implementation since that wasn't using the GPL license.
So, can they take OpenJDK, through a series of commits revert it back to what they have now, release that under the GPL, and be legally in the clear, as long as they don't call it OpenJDK or something that might be confused with it (the license for the name is stricter)?
They don't even have to go through those motions, they could just release what they have under the same license as OpenJDK and grab some of the interface definitions they need from OpenJDK
And they wouldn't necessarily be "legally in the clear"... when this is all said and done they may be found to have infringed copyright illegally and will have to pay a price for breaking the law. Complying with the OpenJDK license would only protect them going forward, not for past transgressions.
Interesting move on Oracle's part would be to try to prove that Google infringed on OpenJDK's copyright (i.e., violated the GPL)... then under GPLv2 Google could lose their rights to redistribute OpenJDK
I don't see why not; as long as it's derived from GPL licensed code, and they respect the license, they have the right to change it to whatever they want.
This seems to defeat the GPL entirely, since it doesn't matter that you have a license to modify the source code if doing so means you are violating copyright on the APIs.
Indeed.
IANAL, but that is one (of many) problems with this legal outcome.
Although it's possible that the explicit permission to change the code in the GPL would be interpreted as a license the the API as well.
Although it's possible that the explicit permission to change the code in the GPL would be interpreted as a license the the API as well.
I don't see how it can be any other way; since the infringement was based on the copyright of the API, by having a legal license to the copyright of the code that implements the API, I don't see how can one lack a license to the API. It'd be different if the API was somehow patented, but copyright explicitly covers the actual implementation.
Google did a clean-room implementation of copied APIs. Those APIs are licensed under two licenses, and Google chose neither. All you need to do is choose one and comply with it.
All the ruling means is that if you copy an API you should either comply with the license (Google didn't comply with either possible licenses) or don't, but have a good fair-use defense, such as non-profit use and/or interoperability (neither applies to Android, but that hasn't been ruled yet).
Now let me say this again: It has been in Google's best interest to keep people's confused about the ramifications of this court case, because Oracle's legal's department is fierce, and if you believe that they might come after you, too, you'll support Google's position. The reality is that whichever side you're on and regardless of the outcome, the ruling in this court case will not apply to the rest of the industry (because Google's use of Java's API was very unusual).
Because usually reimplementations are done in a way that would allow programs/libraries written for the original platform run on your platform, i.e. reimplementations are usually done in a way that makes them drop-in replacements to the original as much as possible. That is not the case with Android. Running existing Java programs is a non-goal, and reusing libraries is only a goal as long as it helps Android's separate ecosystem (Java libraries -- for any Java standard -- work on Android only if they happen to use the subset of APIs implemented by Android; this is not due to any real limitations or lack of developer resources, but simply because being a drop-in or near-drop-in replacement for Java is not a goal for Android).
I will note again that Google is free to use OpenJDK however they like -- they don't need to be compatible or anything -- as long as they comply with the GPL license.
Google's implementation is a clean-room one, based on the former Apache Harmony and isn't a derivate of OpenJDK. If it would have been a derivate work of OpenJDK, then the GPLv2 license would have protected them.
And no, they didn't violate the GPL. When a copyright owner releases code under an open-source license, that doesn't mean that they are waiving their copyrights. Open-source is not the public domain.
Google was found to be infringing on Oracle's copyright when Google implemented APIs that mirrored the organization of the APIs exposed by Java libraries of the Java platform (as well as other portions of code).
From what I infer, Google borrowed the implementation of classes from Apache Harmony's project, which had nothing to do with OpenJDK. That is, it is an independent implementation of the J2SE, etc.. If that is the case, Google can be found to be infringing on Oracle's copyright when it distributes binaries derived from Apache Harmony code that infringes on Oracle's copyright over Java APIs.
The version the article is talking about is OpenJDK; Oracle holds the copyright of the OpenJDK implementation, and licenses it under the GPL. By using OpenJDK, Google is allowed to distribute programs and code derivative of OpenJDK code as long as it complies with the terms of the licenses.
It won most counts and lost on the API's aren't copyrightable stance. The thing is that even if API's are copyrightable what is the damage if someone does a clean room implementation...
Since Oracle/Sun is effectively giving OpenJDK for free I'd argue the damages are effectively 0 USD so Oracle would win a 0 USD compensation. Since the lower court justice mostly sided with Google I'm guessing compensation won't be much for Oracle.
To make a few more things clear: that APIs are not copyrighted has never been settled law either, so the chances of getting sued over copyright violation has always existed. The only difference is that before (as Google did) you could make two arguments: 1) that APIs aren't copyrightable to begin with, and 2) if they are, then you're making fair use of them. Now only option 2 exists (with the caveat of the ruling serving as a precedent, as other commenters say).
Also, copyrighted APIs are only "language-level" APIs (or just APIs as we've always called them) -- not web APIs (or protocols, as we used to call them), simply because web APIs lack other prerequisites to be copyrightable.
To the question of fair use. There are several fair use defenses, but two apply to the industry in cases like this: 1/ non-profit use, 2/ use for the sake of compatibility (to prevent vendor lock-in). AFAIK, all third-party implementations of APIs happen to be one or the other (or both). Android is neither -- it is for profit and it is not compatible with Java programs. More than that: it wasn't even done to prevent vendor lock-in. So even if Google loses on the fair-use case, chances are that the defense still holds for all other cases of third-party implementation. Unlike the claims made by Google's PR, this ruling's effect on the industry are at worst tiny, and most likely nil.
> with the caveat of the ruling serving as a precedent, as other commenters say
No, this is incorrect. Because it was a copyright case decided by the Federal Circuit, it is precedent nowhere. Literally no court will need to treat it as precedent. Please educate yourself further before making these lengthy posts in threads like this; you're spreading misinformation.
> Also, copyrighted APIs are only "language-level" APIs... not web APIs (or protocols, as we used to call them)
From this and your post below, this appears to be a distinction you have made up (to appeal to the audience here? I have no clue). "Structure, sequence and organization" are certainly aspects of web APIs that could be copyrightable under the Federal Circuit's ruling.
Also, no one called web APIs "protocols" anymore than they called system calls "protocols". Unless you're talking about actual protocols, in which case I'd just stick to calling them "protocols" because that's what we still call them.
> There are several fair use defenses, but two apply to the industry in cases like this: 1/ non-profit use, 2/ use for the sake of compatibility (to prevent vendor lock-in).
Non-profit use is neither necessary or sufficient for fair use (see Google's recent book scanning ruling, for instance), and the compatibility argument is not with existing JVMs but with existing Java source code.
As for the rest of you post on fair use, I would suggest other readers to take a look at the actual four factors of fair use in the US, as your summary is a poor one. One good source:
I am most certainly not. I concede that I am not clear on how much this serves as a precedent if at all, but that has little or no bearing on what I've said on the case.
> From this and your post below, this appears to be a distinction you have made up (to appeal to the audience here? I have no clue). "Structure, sequence and organization" are certainly aspects of web APIs that could be copyrightable under the Federal Circuit's ruling.
You can apply "structure, sequence and organization" to anything you like, but if you want it to be copyrighted, your work must be fixed. If it is not fixed -- as in the case of web "APIs" -- it cannot be copyrighted no matter what other properties it may have. If there is a piece of text long enough to be considered "a work" that must be replicated verbatim (or through some copyright-preserving transformation) for you to implement my web API, then that could be copyrighted.
The problem is that even if you have a fixed media form you may not be eligible to copyright (which is where structure, sequence etc. applies).
> and the compatibility argument is not with existing JVMs but with existing Java source code.
Android is not compatible with Java sources.
> I would suggest other readers to take a look at the actual four factors of fair use in the US, as your summary is a poor one. One good source
That is indeed a much better summary of fair use than my poor attempt. Nevertheless, it has no bearing on my point, which is that the result of this lawsuit has little to no effect on any other players.
> I am most certainly not. I concede that I am not clear on how much this serves as a precedent if at all, but my comments are not predicated on that issue in the least (it is a minor point at best).
This:
> The only difference is that before (as Google did) you could make two arguments: 1) that APIs aren't copyrightable to begin with, and 2) if they are, then you're making fair use of them. Now only option 2 exists (with the caveat of the ruling serving as a precedent, as other commenters say).
is incorrect. Whether or not your comments are predicated on, you know, your comments themselves, I don't care.
> Android is not compatible with Java sources.
There is a whole lot of code that works on Android because those 37 Java packages are API-compatible, which was pretty important back in 2008. You can argue that's creating an incompatible Java ecosystem in order to allow Google to bootstrap an Android ecosystem, but that is compatibility.
As for your web APIs/protocol thing you're on about, I'd suggest defining what exactly you're talking about for anyone to discuss it with you. As it is you seem to be vaguely waving at something you've already defined to not be subject to copyright in order to give an example of something not subject to copyright...but now with a name that appeals to a broad audience (speaking of PR...)
Even if it is, calling that "spreading misinformation" is a stretch, as the words "at worst" would make the statement completely true.
Also, if the case serves as no precedent whatsoever how could it have an effect? If it does have some, then what I said holds, and if it doesn't, then there was no cause for panic to begin with, and my point doubly holds.
> There is a whole lot of code that works on Android because those 37 Java packages are API-compatible.
In general, no Java library works on Android except by happy coincidence, as Android conforms with none of the several Java standards. Some libraries (that happen to only use the particular subset Google has chosen to implement) may just so happen to work, true, but it is not true that Android is interoperable with Java for any well-accepted definition of "interoperable" or "Java". Whether or not that's enough to make Google's implementation fall under fair-use is a separate question, but my point is that even if Google's use isn't fair use, that has little bearing on other cases where much stronger "drop-in" compatibility was sought.
> I'd suggest defining what exactly you're talking about for anyone to discuss it with you.
Certainly. I am referring to this: "Copyright protection subsists .. in original works of authorship fixed in any tangible medium of expression"[1]. Explanation here[2]. A specific description of a web API is certainly copyrighted (like any text), but the API it describes is not because it is not fixed. There can be many wildly different texts all describing the same web API. This is not true for library APIs, that are fixed text, just like any other code (that is not sufficient to make them copyrightable, but it is necessary).
Programming languages are -- similarly to web APIs but not library APIs -- not fixed.
> In general, no Java library works on Android except by happy coincidence
This is not true at all.
Every single library I have ever added in my build.gradle has always worked. Every. Single. Time.
Even libraries that were compiled with Java 8, which is the most baffling thing, if you think about it (since Android doesn't support Java 8).
Most of these libraries were compiled and deployed to the Maven repo by Java developers who had no idea whether their library was going to be used on Android. And yet, it does.
From Android's perspective, of course it isn't coincidence. Google implemented those APIs that they thought would be useful to Android developers. But from Java's perspective it is coincidence. If I have a Java application or a library (designed for SE or ME -- doesn't matter), it will only work on Android if I'm lucky (I'm not saying there's a 10% chance of it working, but it isn't 90% either). As a maintainer of several Java libraries -- none work on Android -- I feel this pain when people ask us to support Android, and there's a lot of work involved in making that happen.
While I think your understanding of the business situation is accurate, I don't think your distinction about language vs. web APIs stands. My (non-lawyer) take on the situation is this: The interoperability exception for copyright applies only at the system level, for things like binary protocols, byte code and machine instructions. This, I think, is because at that level there is only purely functionality and little expression. Copyright law explicitly covers creative expression and not functionality.
APIs, on the other hand, are required for humans to create systems that interact with other systems. As such they are meant for human consumption and communication and can have significant creative expression. Note that to be interoperable with other Java code, Google did not have to re-use the existing API. They could have used their own APIs, or heck their own language, that compiled down to the same byte-code. This is why I think the interoperability exception does not apply to this case.
As such, I think this ruling does mean that most web APIs, being text-based and intended for human consumption, could be copyright-eligible.
> most web APIs, being text-based and intended for human consumption, could be copyright-eligible.
But the very first condition of copyright eligibility is that the work have some fixed media representation. What fixed representation does a web-API have, a representation that must be replicated for the API to be implemented?
It is true. No Java standard is supported by Android: not SE (maybe some of the new SE compact profiles, but those don't apply to Android's version of Java), not any ME profile, and not any other more obscure Java standards. If a Java library happens to only use the "Android subset" then it will work, but as that subset is not specified by any Java edition or profile, such compatibility can only be coincidental (of course, Google made sure that the libraries they thought may help their ecosystem will work, so it's not a coincidence from that perspective, but it certainly does not make their case for interoperability).
You should abstain from speculating and posting your personal analysis in threads like these. When I say "you", I don't mean the indefinite second person form that stands in for saying "people in general"; I mean you in particular. Your understanding of the relevant statutory and case law is bad, and your comments are, at best, unhelpful. Realistically though, we can call them harmful. Better to just hold it in.
If you're posting to satisfy an earnest effort to be productive and helpful, instead use the time that you would have otherwise spent writing these comments to go somewhere and ask questions in an attempt to better understand the area of discussion here. But don't do this.
While I am not a lawyer and I admit that my previous comment was too legal in nature for my own comfort, it is not any more harmful than Google's agitprop shrieks over a software apocalypse. I am familiar enough with the software industry to conclude that the ruling, for non-legal reasons, is likely to have little or no impact on the industry, which, aside from a few notable cases (each with their own very special circumstances) has not been in the habit of replicating proprietary library APIs wholesale for any purpose (let alone for purposes other than freedom from vendor lock-in) for quite some time. Others, of course, may have other opinions.
While I myself have simplified some of the points regarding fair use defense, I also linked (in this comment: https://news.ycombinator.com/item?id=10851052) to a more nuanced discussion. The bottom line is that both interoperability and commercial use will play a central role in the debate over Google's fair-use claim (and any debate over API implementation).
I also know that Google was encouraged to use OpenJDK for Android precisely in order to prevent the very predictable lawsuit (as well as for other reasons) long before it happened, but Google refused to use GPL software for that part of the Android runtime.
A bit undermined by speculation like "we should expect Oracle to..." and "despite Oracle's expected nastiness" being so central to the analysis.
If we're talking speculation, then I'm guessing the next piece of news might be an announcement that Google is buying Java and Oracle's Java team. The line of thinking goes...
- Despite currently looking like losing a lawsuit, Google has just cosied closer to Oracle's version of Java. (Something's afoot...)
- Despite currently looking like winning a lawsuit, and Java 8 being very well received, Oracle's rumoured to have just let its Java evangelists go, and to be less interested in Java than it used to be. (They look willing to sell...)
- JavaOne was apparently a bit light on announcements (Could something other than just work on Java 9 be distracting them and making them put some plans on hold for a mo...)
- Having a litigious competitor own a key piece of Android is surely a pain point for Google that gets more painful as Android keeps storming ahead. Buying it would make that pain go away.
- Google's looking at possibly having to pay some money in the lawsuit, and will likely want to get something for it
- Oracle's looking at an uncertain return from the lawsuit, hasn't extracted that much revenue from Java itself, and might just be happy to take some cash for someone else to be custodian of it from here on
On the other hand, a lot of companies using Java (including SIEMENS, SAP, etc) might oppose such a move from Google, and even end up buying Oracles Java team themselves.
Similar to how people expected Microsoft or Google to buy here maps, and then a bunch of car manufacturers bought it (due to wanting to have an open alternative usable in their cars, without relying on an oligopol)
Why is there "Mozilla" in the hn title here, but not in the article's title? (nor the article body, except for a small aside about the MPL license, in parentheses)
Which is just one of the total lies written in that article (Swing is not and will not be part of Android API which you can easily check in commits). Sadly Andreas doesn't really understand what he was writing about :/
> Why is there "Mozilla" in the hn title here, but not in the article's title? (nor the article body, except for a small aside about the MPL license, in parentheses)
Yeah, this seems to be a clear case of an editorialized article title. :(
I find it hard to believe that the author of this post didn't know better than to refer to Andreas as a "pundit". I have my many disagreements with him personally but it's ridiculous to treat him as a tech media talking head when his opinions on the subject are clearly based on multiple years shipping an Android-derived operating system on phones. Not to mention Firefox for Android, which I think he had some involvement with as well. The post as a whole seems to be intended to frame disagreement with Mr. Kuhn's PoV as coming from uninformed rabble and media talking heads.
The post itself is well-written and thoughtfully argued, so it's disappointing that it's undermined by the author's choice of tone. If anyone is qualified to share their detailed thoughts on the OpenJDK/Android move, former/current officers of Mozilla are high on that list.
Unfortunately Andreas' post was very misinformed and full of statements that simply weren't true (like the quip about Swing for example) which kinda supports the scepticism. I'm not sure if Andreas really knew what he was writing about in detail.
Andreas' post is filled with incorrect statements, such as:
> Swing will now sit on every Android phone, using up resources.
It's pretty worrying that the former Mozilla CTO seems to be so uninformed about a topic or -- worse -- decided to write an article on a topic without even spending a few minutes researching it and understanding the implications.
It doesn't reflect well on Mozilla either that they hired someone who seems to be so out of his depth on core matters to Mozilla's business.
> It doesn't reflect well on Mozilla either that they hired someone who seems to be so out of his depth on core matters to Mozilla's business.
Andreas wasn't hired as an executive, and you could have easily confirmed this [1] before posting this comment. He started as a developer in 2008 on the JS engine. As he was basically responsible for TraceMonkey, Andreas is a large part of the reason why SpiderMonkey is one of if not the fastest JS engines around.
This topic is about a former Mozilla CTO (who allegedly worked with Android) and his inaccurate and baseless statements about the implications of Google's switch to the OpenJDK. I could accept this level of technical ignorance from a blogger or a journalist (although, a proper journalist would have researched it thoroughly), but to hear these comments coming from a CTO is baffling due to how out of touch his understanding of the situation was. I hate to use the word ignorant, but in this case he was pretty much ignorant on the entire topic which is sort of a head scratcher for someone who was once a CTO.
How he got there and what he did before is irrelevant.
The point is that he was Mozilla's CTO and his article is filled with inaccuracies showing he doesn't really understand what he's writing about and, worse, that he didn't even bother researching any of it.
I'm wondering why doesn't Google ditch Java entirely and create something like XobotOS[1]. I know it wouldn't be a popular move but at least the devs will get a decent language to use (C#) and users will have a better performing OS[2]
I've wondered the same. Apple did a good move with Swift. Not sure why Google doesn't invest in their own language. Would be really nice to see a full on native and new language for Android by Google.
I'm wondering why this is downvoted. I would love to have an official Android language that is better suited to mobile than Java. Instead of hacking away at the JVM (or cloning it) to make it work properly on CPU/memory/power-limited devices.
J2ME never had near enough functionality for the apps to do anything very interesting. I do not recall a single J2ME app apart from Opera Mini which was worth using. All the good (by the standards of that time) apps were non-J2ME, at least on Symbian and Windows Mobile.
So even though it was fast enough, I wouldn't compare it to Java as it exists for Android now.
You need to go to Japan more often. I worked quite a lot with NTT DoCoMo and they had amazingly useful games and apps. Everything from a bank machine locator to physical vending machine purchases (with NFC).
They had motion sensor support in J2ME devices that they used mostly for fishing/golf games circa 2003-2004 (don't hold me at the dates my memory is the gray equivalent of Swiss cheese).
Anyway, J2ME had a lot of levels CDC was pretty much Android equivalent but it didn't have GUI API on top of it because Sun disallowed MIDP on top of CDC and didn't offer anything other than AGUI which nobody used... I can go into endless details here but generally, the reason J2ME failed was that it was a tool built in 1999 with a single moderate update in 2004 and nothing else!
The only thing that hindered J2ME on my old flip phone from 2006 was the carrier disabling all the interesting APIs. If Android had been based on J2ME and put control in the hands of users instead of carriers, it would be a much better system IMO, especially in terms of security.
> Not sure why Google doesn't invest in their own language.
Has no one in this branch of the thread ever heard of a little thing called Go?
You could also bring up Dart, although Google's apparent commitment (and my own interest) in that is far lower.
Work IS coming along on being able to write full Android apps entirely in other Google-originated languages. You might reasonably ask why they're not pouring dramatically more resources into accelerating that process. I don't know, but I can only speculate that the enormous scale of the existing Android ecosystem makes it risky to send the wrong signal prematurely.
If we're looking at a matter of years before full featured Android apps in pure Go is feasible, then you probably wouldn't want to talk that up TODAY. The perception would be that Java on Android is dead, and major new app development for Android would halt.
Go isn't suitable for the kind of mission critical and memory constrained apps that Android requires.
The absence of generics and exceptions makes Go a step backward compared to Java. It was also absolutely not designed for Android (its driving design goal was to compile fast).
Dart's type system is also much weaker than Java so it would be a step back as well.
Right now, Google doesn't have any in-house credible alternative language to Java.
Interestingly, Kotlin is growing on Android without Google having anything to do.
Dart is a pretty nice language, and practically speaking I don't think it's "weaker" (optionally typed) system is a concern. The vast majority of Dart libraries are typed, giving you all of the benefits (compile time type checking, runtime type checks, intellisense, etc.)
Check out the flutter project (http://flutter.io) for a hint of what Dart on Android and iOS looks like.
I've been working professionally with Java for 19 years. I've only worked "semi-professionally" with Go for 3 or 4 years, as a secondary language for a few niche applications at work and some personal projects at home. So I may or may not be the most qualified person in the world to represent Go here.
All that being said, the longer I work with Go, the less I really see its lack of generics as a significant shortcoming. Go simply doesn't emphasize object-orientation to the same degree as idiomatic Java. Given the choice, I'd prefer to have that tool available than not have it. However, I haven't yet personally run across a real-world scenario in which lack of generics was an actual big deal.
I am QUITE comfortable in asserting that Go's error handling exceeds that of Java's, not lags it. The "try-catch" concept is still there (as "panic-recover"), albeit discouraged in many of the cases that an experienced Java developer would want to use it. The convention of having every function return a possible error struct, and the compiler's insistence that you do something with that that returned struct, pushes Go developers into a much more disciplined mindset of approaching exception handling.
The two points above are subjective, of course. Reasonable people could argue them either way. The third response is a bit more objective. Regarding the notion that Go is "absolutely not designed for Android" and its memory constraints, I must point out that neither is Java! As a matter of the Java language's syntactical suitability, the obvious observation is that Java PRE-DATES Android by more than 12 years. Considering the laws of physics and space-time, it was clearly not designed by James Gosling with Google's OS in mind. Secondly, the memory constraints of carrying a built-in garbage collection runtime also apply to Java. The only difference is a matter of maturity, and the level of resources that have gone into developing a custom Java solution for Android. There's no reason why Google couldn't do the some with Go (or almost any other language), and given Go's comparative simplicity it would probably take far less time to get there.
Sure, you can assign returned errors to the underscore black hole and move on. However, that is still consciously and deliberately "doing something" with it.
It is glaringly obvious in a code review that you have done this. Also, although I'm not personally familiar with any Go tools similar to PMD or Sonar in the Java world... it would be fairly easy to write a static analyzer that could scan code, recognize this pattern, and report on it (along with other code smells) in an automated manner.
Nevertheless, idiomatic Go functions return an error structure, and you must do something with that error structure. There is no ambiguity as to where the error structure came from.
Contrast that with Java's model, which is much more (pardon the expression) catch-all. There is endless debate on how wide or narrow to make your try-catch blocks, when to handle an exception locally vs. throwing it back to the caller, etc.
It is very common to deal with bugs that stem from silently "swallowing" exceptions at an inappropriately low level. It is just as common to see patterns where nearly all methods throw nearly everything without a catch at all... and there's a monster try-catch block at the top level catching the base "Exception" class.
Worst of all, there are entire classes of runtime exceptions which are NOT declared as throwable in the method's signature. The compiler has no means of insisting that you do anything about those, because the compiler doesn't know which ones are possible during a given method call. Go's error handling model is safer and better thought-out in that regard.
When you think about issues stemming from Java's handling of checked vs. unchecked exception types, it makes a lot more sense why Go went in the direction it did. Also, why Go application developers are discouraged from using "panic-recover"... and why Go library developers almost always recover from panics and create error structs for passing back upstream.
Adding Go to the official SDK and providing official bindings.
Go team is just doing what everyone else does, by making use of the NDK and writing Go wrappers manually on top of JNI calls to the official Android APIs.
So far there have been zero interest from Android team to support anything other than Java. Even the C and C++ support is just to write performance code to be consumed from Java, not to write full blown apps.
They were never asked by Google to make a language, and as far as I've always known (feel free to provide a link that says otherwise) Google employees are allowed to spend some of their work time to work on side projects, I've never heard of Google only paying them to work on Go and only Go, please feel free to correct me on this as it's news to me.
the comparison between dalvik & xamarin is not that interesting anymore (it was in 2012 though). It would be interesting to remake this bench.
Why doesn't Google ditch java ?
Because such a switch would be very costly and there are many more cost effective ways to improve the platform (like for example databinding).
I also doubt that Google would choose a language controlled by Microsoft, they had enough trouble with the java lawsuit..
if the rumors of the merge of Android & ChromeOS are true, maybe this will be accompanied with with a big framework change ?
It will depend on how this plan materialize exactly but that would be the right time for that.
The important thing is that Java should not be allowed to be owned and trolled upon by companies. Java belongs to the community that developed it collectively, not to a single corporation that paid bucks to purchase it from Sun.
And Java IS open source. Lets not allow Oracle to monopolize and troll the API spec. If we allow that to happen, it will open a floodgates of patent trolls across the United States and the victims could be innocent startups who have just begun struggling and innovating in the market.
"Lets not allow" sounds nice, but how do you actually expect us to accomplish this? After all, Oracle does own most of the code in OpenJDK, and even the contributions must be accompanied by a signed agreement giving them joint ownership of the copyright.
> how do you actually expect us to accomplish this?
As a citizen, you can vote for legislators and senators who are of sane-mind and who understand technology enough to understand the hilarity of this situation. After all, you can read everything about them online when a candidate stands for an election, its not like some developing/third-world country where information and media are controlled.
I agree with you for the situations you quote, however the spirit of the law is here to prevent incompatible copycats to fork off. If Microsoft launched their own version of Java with a tiny number of incompatibilities, this law could be reused against them.
> Eventually, (slowly but surely) GPL enforcement will adjudicate the widespread problem of poor Linux license compliance — one way or the other
So when is that going to happen? The Linux Foundation just stopped funding the Software Freedom Conservancy, in a concerted effort with others to kill it and any GPL enforcement.
When you, everyone else in this thread and all your friends become supporters of the Software Freedom Conservancy, then they will have enough funding to continue GPL compliance efforts. Right now they are about 50 supporters below the level needed to continue basic services (but do no compliance activities). They need a few thousand more supporters to keep up with GPL compliance activities.
This entire thing may be confusing to a lot of people, as many are already confused by what the entire Android court case was about. The confusion is not accidental. Google's very extensive PR machine has put in a lot of resources to make sure people are confused (what Oracle puts into lawyers, Google puts into PR). But just to lay down a few facts:
Since 2006/7, Java has been available under two licenses: commercial and open-source. The commercial license allows free implementation of the Java APIs and has a full patent grant, but requires conformance with the Java TCK (Technology Compatibility Kit) and requires payment if used in mobile devices (this was Java's main revenue stream for a long time). It is also possible to license the JDK source from Oracle under the commercial license for a fee. The same JDK is also released under the GPL. This license is completely free and unencumbered (the GPL itself prohibits any restrictions). It does not require compatibility (unless you want to call the result "Java"), and has no field of use restrictions. It also has a full (implicit) patent grant. As this article notes, OpenJDK's copyleft is not viral either (certainly not more than Linux): applications and libraries running on top of it are unaffected due to the "classpath exception". You can do whatever you like with Java when you use it under the terms of its open-source license: use the implementation, use just the APIs and implement it yourself, use the whole thing or just small portion, pass the TCK, not pass the TCK, fork it or not. You are even allowed to use it to implement .NET.
Google has had both of these options for licensing Java (at least since May 2007, but that was still before Android was released). Until very recently, Google chose neither. They couldn't reach an agreement with Sun on the fee for the first license, and didn't like the second (possibly because they feared that phone manufacturers would reject a GPL runtime, classpath exception or no). Instead, they chose to argue in court that the APIs are not Oracle's to license[1].
What has changed now? Perhaps Google realized that given Android's success, phone vendors would swallow whatever license Google gives them. In any event this is a win for everyone: Google wins because they will need to spend less resources on maintaining Android, Oracle wins because Java will now be on Android, and Android and Java developers win because they'll have a better runtime and greater compatibility. This is contingent, however, on Google not forking OpenJDK too much beyond compatibility; the license does allow them to do so.
Yes, the mainline OpenJDK project is steered by the JCP (Google, Intel, Twitter, and IBM are all members) and Oracle does have veto power, but that is just the project governance. Anyone is free to fork OpenJDK, as long as they don't call the result Java (unless they fork and choose to pass the TCK). The situation is no different from other large open-source projects.
[1]: I have no opinion on whether or not Google's actions were legally justified (I do have an opinion about their ethics), but I do know that unlike Google's PR line, the ruling has little or no effect on the industry. Google's actions with Java's APIs were quite different from any other API implementation that I know of. Also, the ruling does not apply to web APIs. See discussion here: https://news.ycombinator.com/item?id=10811011.
Google's actions with Java's APIs were quite different from any other API implementation that I know of
How were Google actions different from what the Apache Foundation did with the Harmony project (which Google used for their Java implementation), or from any other API implementation? Is it just that the copyright holder eventually released a GPL version of the code while Google chose to stick with their own implementation? I don't see how that is relevant.
API copyright being enforcable is huge for the industry, it means it was illegal for the Harmonly project to implement Java without a license, or for GNUStep to implement Cocoa, or for Mono to implement .NET Windows.Forms. Also 1991 Linux was probably illegal and Wine definitely is. These are just off the top of my head, just search for "open source implementation of" on Bing, chances are most of the results are about illegal projects, including open source implementation of various standards: standards don't necessarily come with a universal license grant, at least for patents (see e.g. the H.264 situation). I would be interested to know if things are different regarding copyright licenses.
> How were Google actions different from what the Apache Foundation did with the Harmony project
The harmony project was intended as a drop-in replacement for JDK classes, namely as a component in a system interoperable with Java. Android is not such a system (although Android may yet be ruled to be fair-use, too).
> it means it was illegal for the Harmony project to implement Java without a license, or for GNUStep to implement Cocoa, or for Mono to implement .NET Windows.Forms. Also 1991 Linux was probably illegal and Wine definitely is.
That is the wrong conclusion. That something is copyrighted does not automatically mean that replicating it is illegal because of something called fair-use. If the goal of your implementation is to create an interoperable system, then you might be within your rights to implement an API even without complying with the license[1].
Ah that is a good point. It's an important difference between Android on one side and Harmony, GNUStep and Wine on the other side.
However I would put Linux together with Android then: Linux was similarly replicating Unix APIs for the convenience of compatibility with existing code, and explicitely not aiming for full interoperability.
Octave is another project with an approach similar to Android: trying to provide an open-source Matlab that is mostly compatible, for convenience and to increase the appeal of the platform to Matlab developers, but they are not interested in compatibility for its own sake[1].
Mono falls in the middle, as they are not only providing an alternative runtime for .NET applications, they're also interesting in expanding the platform with new APIs such as POSIX bindings and Gtk#.
[1] At least that was the case a few years ago. It might have changed lately. And this disinterest for full compatibily was partly due there being no "Matlab standard" to implement. See this post from 2000 by the Octave maintainer (https://lists.gnu.org/archive/html/help-octave/2000-12/msg00...):
I never intended Octave to be a Matlab clone, nor am I really
interested in creating such a thing, but that seems to be what many
users of Octave want. It is not very interesting to me to simply
reimplement all the features/bugs of Matlab.
I am finding it too constraining to try to maintain almost any level
of compatibility with a proprietary product for which there is no
standard. It stifles any creativity by the threat of future
incompatibility. I see this is as a real problem, not just an
imagined one.
Free software needs a vision beyond reimplementation of existing
proprietary tools. Those of us who are interested in free software
tools must become leaders rather than followers, and I am optimistic
that this can happen for numerical software. But I don't believe it
can happen if Octave continues down its current path.
Anyone is free to fork OpenJDK, as long as they don't call the result Java (unless they fork and choose to pass the TCK). The situation is no different from other large open-source projects.
Unless I'm missing something, this is no longer the case. Oracle is arguing that they own the API and the only legal implementation is theirs (ie, Java). Just renaming is (say... "Android") is insufficient.
Forking is going to be legally on very shaky ground at least.
Oracle does own copyright on the APIs (according to the Federal Circuit), but they do provide it in OpenJDK under the GPL. That means anyone is free to fork it, under the terms of the GPL.
What Google did was copy the APIs, remove the copyright notice (arguing the APIs aren't copyrightable), and release the code under a different license. You can't do that under the GPL terms.
Public Knowledge, an ally of the FSF, actually recommends independent implementation (like what Google did with Java and glibc) as a method for escaping the GPL:
>If a developer does not want to be subject to the licensing terms of a library, he has a few options...Another option for a developer is to do what Google did when it created Android, and create replacement code libraries that are compatible with the existing code libraries, but which are new copyrighted works. Being "compatible" in this context means that the new libraries are called in the same way that the old libraries are--that is, using the same APIs. But the actual copyrighted code that is being called is a new work.
Forking is totally legal.
You need to do some things however.
Don't call it OpenJDK since OpenJDK is copyrighted.
Don't remove the Copyright inside the files.
License new code as the same license as applied to OpenJDK.
All these complex licences (GPL2, GPL3, LGPL, Least GPL, etc) do nothing except create confusion about which license to use. I have found a simple solution that allows me to focus on my work and not on the legalese; I just use the MIT license.
If you've ever read some ToA, or EULA, you won't find GPL that bad regarding the language and length. Also, simplified/explained versions exists, which should make it more digestible.
As the author of the article said, it's a tool, and you may or may not use it. Don't downplay the need for a copyleft licence (which a cool hack around copyright, if you ask me): some people use is from a philosophical reason, and some - as the basis for their entire business model.
Reading the GPL at length, it seems as though it were written as if the only build process were C, and the only way to run software was on a single computer. The GPL is unclear when it comes to how it applies to something as complex as a content management system that could be deployed and running as a single service across multiple servers. The language it uses (linking, distribution, even 'code' itself) is ambiguous. And apparently the only clear way to ensure that you are in compliance with it is a shakedown from the Software Freedom Conservancy to grant you permission to use it in ways it was never written to handle.
The principles of copyleft are tremendously valuable, I just wish we had a modern license that reflected the reality of the modern internet, and modern software.
Yeah, its age is showing, truth to be told. That's why we have now AGPL for network programs, and LGPL for libraries.
About the ambiguity - my feeling about it is that they (Stallman and the lawyers, I suppose) leaned towards the usual way these documents are done, to make the licence more general - which irks us, the programmers. For a lawyer, "the code" is a good enough term.
I agree with you on having a new copyleft licence - but I'm afraid is hard to get something even to match GPL, and worse - you can step in the same, or other subtle traps as the initial versions of the GPL did - that tivoization stuff was nasty as hell. If only some of the licenses would "die" eventually, but the process reminds me of this comic - https://xkcd.com/927/
That's good, but there other options too that are practically similar to MIT. Most notably, the APL (Apache Public License), MPL (Mozilla Public License) and even the old BSD public license. They just differ in legal gobbledegook in their content, but essentially, you can pick and use any software under these terms and you can use/modify them in whatever manner with a peace of mind!
APL more explicitly/specifically transfers the legal rights to the user of the software through the legal wordings used. In this manner, APL is an improvement over the MIT, which in turn, is an improvement over good old BSD license. Even BSD license intended to do the same thing, but it appears that the modern law prefers every intention to be explicitly stated, rather than leaving room for assumption/derivation of that intent.
Is the Apache Public License different from the Apache License? I can't find any reference of the former and I've always seen the latter shortened to ASL or ASLv2. Apologies if this comes across as a passive aggressive correction -- I'm really curious if they're different things.
Same here. And every explanation, interpretation or clarification I see is more evidence that the licences are murky and there is no way of knowing how a court of law in my jurisdiction dealing with my cases would interpret it. Unlike my employer, which produces GPL software and has a legal department, I want something that is clear and not open to interpretation yet meets my personal goals for my personal projects. MIT fits that to a T.
I'm not sure how common knowledge this is, but Oracle is quietly going after any company of any significant size which uses Java in their software at all. It's not just the embedded stuff either; simply using Java in enterprise software is enough to bring them running with their team of lawyers threatening a lawsuit. These suits are being settled at large sums without raising any external indication that this is going on. It's not the big guys or the startups that have to worry, it's the mid-sized companies that know a long, protracted lawsuit with Oracle will not end well for them.
I don't disagree with your rebuttal of GP's post, that said,
Google with Android Java have no else but themselves to blame.
That argument is equivalent to "well, you should just have not left your door unlocked". Just because Google could have used OpenJDK and thus avoid the lawsuit doesn't mean they should have to do so.
And Microsoft's case is completely different, as they did get a license from Sun, and preceded to deliberately violate it, with the intention (as we know from the internal emails and documents) of killing Java.
But apparently Google gets a free pass while Microsoft not, because "hey it's Google and they are sooo cool".
Interesting indeed how the two cases are perceived differently. I wonder to what extent they really were similar, legally speaking. At least one important difference is that Microsoft did license Java from Sun. Microsoft was using the Java trademark and advertising J++ as "Java-compatible" although their implementation was not passing the compliance tests.
To go back to the perception of Microsoft and Google's actions by the community, I think it's not hard
to explain:
On one hand, you have Microsoft developing a proprietary Java product with the goal of undermining cross-platform Java and locking users and developers to the Windows platform. Remember the famous internal Microsoft email:
"We should just quietly grow j++ share and assume that people will take more advantage of our classes without ever realizing they are building win32-only java apps."
On the other hand, there is Google using Java for the purpose of delivering an open-source operating system. They didn't license Java, but I think the perception is that one should not require a license to use a programming language and/or implement its standard libraries. And compared to Microsoft, the perception is that any Java incompatibily introduced by Google in Android is not malicious but due to technical decisions (be they good or bad).
I bet that when Java 10 finally gets released, maybe around 5 years from now, Google might eventually release Java 8 support.
Even their recent actions with OpenJDK are related to version 7, not 8.
At their Autumn conference they only addressed Java 8, reluctantly during Q&A, and still asked devs to cherry pick features from it.
Given that Google is creating a Python 3 / Python 2 situation, due to their Java fork, I fail to see how their actions are less damaging to the Java eco-system than what Microsoft did.
Given that Google is creating a Python 3 / Python 2 situation, due to their Java fork, I fail to see how their actions are less damaging to the Java eco-system than what Microsoft did.
Right, so they are damaging the Java ecosystem. Though it's not clear this outweighs the benefit of drawing developers to the language in the first place.
My point is, intent matters in shaping the public's perception. Say someone releases (or maintains) an awesome Python 2 library. I certainly won't see that as evil, if they aren't doing it with the purpose of undermining Python 3.
Andreas Gal, Former CTO of Mozilla, wrote yesterday: "... a curious event got my attention: A commit appeared in the Android code base that indicates that Google is abandoning its own re-implementation of Java in favor of Oracle’s original Java implementation. I’ll try to explain why I think this is a huge change and will have far-reaching implications for Android and the Android ecosystem." Source: http://andreasgal.com/2016/01/05/oracle-sinks-its-claws-into...
Bradley M. Kuhn, in charge with the task of enforcing the GPL for Linux, wrote today: "Thus, my conclusion about this situation is quite different than the pundits and link-bait news articles. I speculate that Google weighed a technical decision against its own copyleft compliance processes, and determined that Google would succeed in its compliance efforts on Android, and thus won't face compliance problems, and can therefore easily benefit technically from the better code. However, for those many downstream redistributors of Android who fail at license compliance already, the ironic outcome is that you may finally find out how friendly and reasonable Conservancy's Linux GPL enforcement truly is, once you compare it with GPL enforcement from a company like Oracle, who holds avarice, not software freedom, as its primary moral principle." Source: http://ebb.org/bkuhn/blog/2016/01/05/jdk-in-android.html