Sun, Oracle, Android, Google, Mozilla and JDK Copyleft FUD
ebb.org
ebb.org
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
https://sfconservancy.org/supporter/ https://sfconservancy.org/copyleft-compliance/principles.htm...
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.
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.
Oracle's argument is that an API is copyrightable, and cloning an API is illegal.
The only known way to obtain a license to use those APIs is to use the GPLed Java implementation of those APIs.
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.
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.
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.
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.
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.
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
https://www.softwarefreedom.org/resources/2008/compliance-gu...
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).
How is it different from any other reimplementation of an existing API?
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.
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.
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.
A word of caution: IANAL.
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.
why, which API does that infringe?
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."
[1]: https://www.cs.duke.edu/courses/cps182s/fall02/cscopyright/C...
[2]: https://adtmag.com/blogs/watersworks/2015/07/google-java-api...
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).
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)?
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.
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.
[1]: https://github.com/wine-mirror/wine/blob/367b30d8278684aaff3...
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.
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.
[1]: https://www.law.cornell.edu/uscode/text/17/102
[2]: http://www.mateoaboy.com/f6/blog_files/804f4c5940fe299168ea6...
Well that's just not true now is it.
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.
This is no happy coincidence.
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.
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?
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 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.
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.
(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.
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.
Oracle has stolen an "r" from the API specification of my full name. How/where can I sue them?
Also the license requires that all of Java is taken, not cutting down pieces as they feel like.
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.
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
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)
Yeah, this seems to be a clear case of an editorialized article title. :(
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.
> 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.
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.
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.
[1]: https://github.com/xamarin/XobotOS [2]: https://blog.xamarin.com/android-in-c-sharp/
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!
It was really amazing to play games like [1] on phones like [2]
[1] http://java.mob.com.de/game/anno_create_a_new_world.html
[2] http://www.siamphone.com/spec/lg/images/kp501/lg_kp501_1.jpg
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 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.
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.
Check out the flutter project (http://flutter.io) for a hint of what Dart on Android and iOS looks like.
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.
But it doesn't. You can write `ok, _ := Foo()` and poof, the error is ignored.
Java's checked exceptions don't let you get away with this kind of sloppy programming.
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.
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.
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.
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.
Well, we could just all move to Germany, where ownership over copyright can never be signed away, and then fork Java.
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.
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.
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.
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.
>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.
https://www.publicknowledge.org/news-blog/blogs/gpl-does-not...
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.
If that is happening you are completely free.
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.
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].
[1]: https://www.cs.duke.edu/courses/cps182s/fall02/cscopyright/C...
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.
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.
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.
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.
http://opensource.org/licenses/apachepl.php
The particular license is just "Apache License" or ASL, in fact.
MIT: Do whatever you want
BSD: Do whatever you want, don't use our name
APL: Do whatever you want, don't sue us for patents
MPL: Do whatever you want, as long as you release modifications to the original source files
LGPL: You can use this as long as you publish changes to the library and dynamically link it in software with a non-(L)GPL license.
GPL: Any source code connected to this to this code must also be GPL.
* or, crazily enough, provide an object file or files that you can re-statically link against the LGPLed source.
There are plenty of happy JVM vendors to choose that haven't had any problem to comply with the license:
https://en.wikipedia.org/wiki/List_of_Java_virtual_machines
Microsoft with its J++ fork and Google with Android Java have no else but themselves to blame.
But apparently Google gets a free pass while Microsoft not, because "hey it's Google and they are sooo cool".
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.
This will become even worse after Java 9 and 10 get released, specially with the infrastructure API and language changes they bring in.
So if Google keeps their stubbornness, any Java library writer will be faced with support Android Java or official Java dilemma.
And hacks like RetroLamba aren't going to help anyway.
I really don't see any difference in behavior vs what Microsoft did.
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).
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.
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.
The situations are completely different. Microsoft was a Java licensee and as such, had to abide by the license (they didn't).
Google is not a Java licensee, so Oracle's attack on them is following a totally different angle.