Post Syndicated from Bradley M. Kuhn original http://ebb.org/bkuhn/blog/2016/01/05/jdk-in-android.html

I have probably spent more time dealing with the implications and
real-world scenarios of copyleft in the embedded device space than anyone.
I’m one of a very few people charged with the task of enforcing the GPL for
Linux, and it’s been well-known for a decade that GPL violations on Linux
occur most often in embedded devices such as mobile hand-held computers (aka
“phones”) and other such devices.

This experience has left me wondering if I should laugh or cry at
the news
coverage
and pundit
FUD that has quickly come forth from Google’s decision to move from the
Apache-licensed Java implementation to the JDK available from Oracle.

As
some smart commenters like Bob Lee have said, there is already
at least one essential part of Android, namely Linux itself, licensed as
pure GPL. I find it both amusing and maddening that respondents use
widespread GPL violation by chip manufacturers as some sort of
justification for why Linux is acceptable, but Oracle’s JDK is not.
Eventually, (slowly but surely) GPL enforcement will adjudicate
the widespread problem of poor Linux license compliance — one way
or the other. But, that issue is beside the point when we talk of the
licenses of code running in userspace. The real issue with that is
two-fold.

First, If you think the ecosystem shall collapse because “pure GPL
has moved up the Android stack”, and “it will soon virally
infect everyone” with copyleft (as you anti-copyleft folks love to
say) your fears are just unfounded. Those of us who worked in the early
days of reimplementing Java in copyleft communities thought carefully about
just this situation. At the time, remember, Sun’s Java was completely
proprietary, and our goal was to wean developers off Sun’s implementation
to use a Free Software one. We knew, just as the early GNU developers knew
with libc, that a fully copylefted implementation would gain few adopters.
So, the earliest copyleft versions of Java were under an extremely weak
copyleft called the
“GPL
plus the Classpath exception”. Personally, I was involved as a
volunteer in the early days of the Classpath community;
I helped name
the project and design the Classpath exception. (At the time, I
proposed we call it the “Least GPL” since the Classpath
exception carves so many holes in strong copyleft that it’s less of a
copyleft than even the Lesser GPL and probably the Mozilla Public License,
too!)

But, what does the Classpath exception from GNU’s implementation have to
with Oracle’s JDK? Well, Sun, before Oracle’s acquisition, sought to
collaborate with the Classpath community. Those of us who helped start
Classpath were excited to see the original proprietary vendor seek to
release their own formerly proprietary code and want to merge some
of it with the community that had originally formed to replace their code
with a liberated alternative.

Sun thus released much of the JDK under “GPL with Classpath
exception”.
The reasons
were clearly explained (URL linked is an archived version of what once
appeared on Sun’s website) on their collaboration website for all to see.
You see the outcome of that
in
many files in the now-infamous commit from last week. I strongly
suspect Google’s lawyers vetted what was merged to made sure that the
Android Java SDK fully gets the appropriate advantages of the Classpath
exception.

So, how is incorporating Oracle’s GPL-plus-Classpath-exception’d JDK different from having an Apache-licensed Java userspace? It’s not
that much different! Android redistributors already have strong copyleft
obligations in kernel space, and, remember that Webkit is LGPL’d; there’s
also already weak copyleft compliance obligations floating around Android,
too. So, if a redistributor is already meeting those, it’s not much more
work to meet the even weaker requirements now added to the
incorporated JDK code. I urge you to ask anyone who says that this change
will have any serious impact on licensing obligations and analysis for
Android redistributors to please prove their claim with an actual example
of a piece of code added in that commit under pure GPL that
will combine in some way with Android userspace applications. I admit I
haven’t dug through the commit to prove the negative, but I’d be surprised
if some Google engineers didn’t do that work before the
commit happened.

You may now ask yourself if there is anything of note here at
all. There’s certainly less here than most are saying about it. In
fact, a Java industry analyst (with more than a decade of experience in the
area) told me that he believed the decision was primarily technical.
Authors of userspace applications on Android (apparently) seek a newer Java
language implementation and given that there was a reasonably licensed Free
Software one available, Google made a technical switch to the superior
codebase, as it gives API users technically what they want while also
reducing maintenance burden. This seems very reasonable. While it’s less
shocking than what the pundits say, technical reasons probably were the
primary impetus.

So, for Android redistributors, are there any actual licensing risks to
this change? The answer there is undoubtedly yes, but the situation is
quite nuanced, and again, the problem is not as bad as the anti-copyleft
crowd says. The Classpath exception grants very wide permissions.
Nevertheless, some basic copyleft obligations can remain, albeit in a
very weak-copyleft manner. It is possible to violate that weak
copyleft, particularly if you don’t understand the licensing of all
third-party materials combined with the JDK. Still, since you must comply
with Linux’s license to redistribute Android, complying with the Classpath
exception’d stuff will require only a simple afterthought.

Meanwhile, Sun’s (now Oracle’s) JDK, is likely nearly 100% copyright-held by Oracle.
I’ve written
before
about the dangers of the consolidation of a copylefted codebase with a
single for-profit, commercial entity. I’ve even pointed out
that Oracle
specifically is very dangerous in its methods of using copyleft as an
aggression.

Copyleft is a tool, not a moral principle. Tools can be used incorrectly
with deleterious effect. As an analogy, I’m constantly bending paper clips
to press those little buttons on electronic devices, and afterwards, the
tool doesn’t do what it’s intended for (hold papers together); it’s bent
out of shape and only good for the new, dubious purpose, better served by a
different tool. (But, the paper clip was already right there on my desk, you
see…)

Similarly, while organizations like Conservancy use copyleft in a
principled way to fight for software freedom, others use it in a
manipulative, drafter-unintended, way to extract revenue with no intention
standing up for users’ rights. We already know Oracle likes to use GPL
this way, and I really doubt that Oracle will sign a pledge to follow
Conservancy’s and
FSF’s principles
of GPL enforcement. Thus, we should expect Oracle to aggressively
enforce against downstream Android manufacturers who fail to comply with
“GPL plus Classpath exception”. Of course, Conservancy’s GPL
Compliance Project for Linux developers may also enforce, if the violation
extends to Linux as well. But, Conservancy will follow those principles
and prioritize compliance and community goodwill. Oracle won’t. But,
saying that means that Oracle has “its hooks” in Android makes
no sense. They have as many hooks as any of the other thousands of
copyright holders of copylefted material in Android. If anything, this is
just another indication that we need more of those copyright holders to
agree with
the principles,
and we should shun codebases where only one for-profit company holds
copyright.

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.

Finally, the bigger problem in Android with respect to software freedom is
that the GPL is widely violated on Linux in Android devices. If this
change causes Android redistributors to reevalute their willful ignorance
of GPL’s requirements, then some good may come of it all, despite Oracle’s
expected nastiness.

Update on 2016-01-06: I specifically didn’t mention the
lawsuit above because I don’t actually think this whole situation has much
to do with the lawsuit, but if folks do want to read my analysis of the
Oracle v. Google lawsuit, these are my posts on it in reverse chronological
order: [0], [1],
[2],
[3].
I figured I should add these links given that all the discussion on at
least one forum discussing this blog post is about the lawsuit.