
Sun, Oracle, Android, Google, Mozilla and JDK Copyleft FUD - g1n016399
http://ebb.org/bkuhn/blog/2016/01/05/jdk-in-android.html
======
defenestration
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...](http://andreasgal.com/2016/01/05/oracle-sinks-its-claws-into-
android/)

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](http://ebb.org/bkuhn/blog/2016/01/05/jdk-in-android.html)

~~~
chei0aiV
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.

[https://sfconservancy.org/supporter/](https://sfconservancy.org/supporter/)
[https://sfconservancy.org/copyleft-
compliance/principles.htm...](https://sfconservancy.org/copyleft-
compliance/principles.html)

------
guelo
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.

~~~
rodgerd
> P.S. The law of the land is now that when you create an API it is
> copyrighted.

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.

~~~
saurik
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.

[https://news.ycombinator.com/item?id=7723853](https://news.ycombinator.com/item?id=7723853)

~~~
fpgeek
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)?

~~~
cwyers
There's a difference between "not compatible yet" and "rips out Swing and
implements its own UI library."

~~~
monocasa
Legally is there?

------
wbillingsley
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

~~~
kuschku
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)

------
azakai
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)

~~~
bipin_nag
Its a response to earlier article [http://andreasgal.com/2016/01/05/oracle-
sinks-its-claws-into...](http://andreasgal.com/2016/01/05/oracle-sinks-its-
claws-into-android/) by former Mozilla CTO.

~~~
auvrw
heh, Swing is part of the android api now.

~~~
izacus
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 :/

------
kevingadd
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.

~~~
incepted
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.

~~~
pcwalton
> 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.

[1]:
[https://en.wikipedia.org/wiki/Andreas_Gal](https://en.wikipedia.org/wiki/Andreas_Gal)

~~~
bitmapbrother
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.

------
po1nter
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]

[1]: [https://github.com/xamarin/XobotOS](https://github.com/xamarin/XobotOS)
[2]: [https://blog.xamarin.com/android-in-c-
sharp/](https://blog.xamarin.com/android-in-c-sharp/)

~~~
giancarlostoro
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.

~~~
StevePerkins
> 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.

~~~
incepted
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.

~~~
StevePerkins
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.

~~~
incepted
> the compiler's insistence that you do something with that that returned
> struct,

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.

~~~
StevePerkins
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.

------
rms_returns
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.

~~~
icebraining
"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.

~~~
rms_returns
> 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.

------
mtgx
> 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.

~~~
chei0aiV
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.

[http://sfconservancy.org/supporter/](http://sfconservancy.org/supporter/)

------
invalidname
Another response to the article with a somewhat different angle available
here: [https://www.codenameone.com/blog/debating-brendan-eich-
over-...](https://www.codenameone.com/blog/debating-brendan-eich-over-android-
openjdk-move.html)

------
baroa
So Oracle supports OpenJDK. They even hope to ditch their flavor of Java in
favor of the open one. What's the fuss?

------
pron
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](https://news.ycombinator.com/item?id=10811011).

~~~
nl
_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.

~~~
matharmin
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.

~~~
curt15
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.

[https://www.publicknowledge.org/news-blog/blogs/gpl-does-
not...](https://www.publicknowledge.org/news-blog/blogs/gpl-does-not-depend-
copyrightability-apis)

------
dingo_bat
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.

~~~
rms_returns
> I just use the MIT license.

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.

~~~
nirvdrum
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.

~~~
rms_returns
You are right, I stand corrected! APL refers more to the collection of Apache
licenses by the OSI:

[http://opensource.org/licenses/apachepl.php](http://opensource.org/licenses/apachepl.php)

The particular license is just "Apache License" or ASL, in fact.

~~~
nirvdrum
Thanks for the link. I hadn't seen that page before, nor the proper noun
"Apache Public Licenses." I guess we both learned something :-)

------
throwaway_forcl
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.

~~~
pjmlp
Both Sun and Oracle have zero issues with companies that follow the Java
license.

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](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".

~~~
icebraining
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.

~~~
pjmlp
Google is also killing Java with their Java 6 and a half fork, without any
public roadmap how future versions are going to be supported.

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.

