Post Syndicated from Bradley M. Kuhn original http://ebb.org/bkuhn/blog/2010/07/15/motorola-admits.html

I’ve written
before about the software freedom issues inherent with
Android/Linux. Summarized shortly: the software freedom community
is fortunate that Google released so much code under Free Software
licenses, but since most of the code in the system is Apache-2.0
licensed, we’re going to see a lot of proprietarized,
non-user-upgradable versions. In fact, there’s no Android/Linux
system that’s fully Free Software yet. (That’s
why Aaron Williamson
and I try to keep
the Replicant
project going. We’ve focused on the HTC Dream and the NexusOne,
since they are the mobile devices closest to working with only Free
Software installed, and because they allow the users to put their own
firmware on the device.)

I was therefore intrigued
to
discover last night
(via mtrausch)
a
February blog post
by Lori Fraleigh
of
Motorola, wherein Fraleigh clarifies Motorola’s opposition to
software freedom for its Android/Linux users:

We [Motorola] understand there is a community of developers interested in
… Android system development … For these developers, we
highly recommend obtaining either a Google ADP1 developer phone or a Nexus
One … At this time, Motorola Android-based handsets are intended for
use by consumers.

I appreciate the fact that Fraleigh and Motorola are honest in their
disdain for software developers. Unlike Apple — who tries to hide
how developer-unfriendly its mobile platform is — Motorola readily
admits that they seek to leave developers as helpless as possible,
refusing to share the necessary tools that developers need to upgrade
devices and to improve themselves, their community, and their software.
Companies like Motorola and Apple both seek to squelch the healthy hacker
tendency to make technology better for everyone. Now that I’ve seen
Fraleigh’s old blog post, I can at least give Motorola credit for
full honesty about these motives.

I do, however, find the implication of Fraleigh’s words revolting.
People who buy
the devices, in Motorola’s view, don’t deserve the right to improve
their technology. By contrast, I believe that software freedom should
be universal and that no one need be a “mere consumer” of
technology. I believe that every technology user is a potential
developer who might have something to contribute but obviously cannot if
that user isn’t given the tools to do so. Sadly, it seems, Motorola
believes the general public has nothing useful to contribute, so the
public shouldn’t even be given the chance.

But, this attitude is always true for proprietary software companies,
so there are actually no revelations on that point. Of more interest is
how Motorola was able to do this, given that Android/Linux (at least
most of it) is Free Software.

Motorola’s ability to take these actions is a consequence of a few
licensing issues. First, most of the Android system is under the
Apache-2.0 license (or, in some cases, an even more permissive license).
These licenses allow Motorola to make proprietary versions of what
Google released and sell it without source code nor the ability for
users to install modified versions. That license decision is lamentable
(but expected, given Google’s goals for Android).

The even more lamentable licensing issue here is regarding Linux’s
license,
the GPLv2.
Specifically, Fraleigh’s post claims:

The use of open source software, such as the Linux kernel … in a
consumer device does not require the handset running such software to be
open for re-flashing. We comply with the licenses, including GPLv2.

I should note that, other than Fraleigh’s assertion quoted above, I
have no knowledge one way or another if Motorola is compliant
with GPLv2 on its
Android/Linux phones. I don’t own one, have no plans to buy one, and
therefore I’m not in receipt of an offer for source regarding the
devices. I’ve also received no reports from anyone regarding possible
non-compliance. In fact, I’d love to confirm their compliance: please
get in touch if you have a Motorola Android/Linux phone and attempted to
install a newly compiled executable of Linux onto your phone.

I’m specifically interested in the installation issue because GPLv2
requires that any binary distribution of Linux (such as one on telephone
hardware) include both the source code itself and the scripts to
control compilation and installation of the executable. So, if
Motorola wrote any helper programs or other software that installs Linux
onto the phones, then such software, under GPLv2, is a required part of
the complete and corresponding source code of Linux and must be
distributed to each buyer of a Motorola Android/Linux phone.

If you’re surprised by that last paragraph, you’re probably not alone.
I find that many are confused regarding this GPLv2 nuance. I believe
the confusion stems from discussions during the
GPLv3
process about this specific
requirement. GPLv3
does indeed expand the requirement for the scripts to control
compilation and installation of the executable into the concept
of Installation Information. Furthermore,
GPLv3’s Installation Information is much more expansive than
merely requiring helper software programs and the like.
GPLv3’s Installation Information includes any material,
such as an authorization key, that is necessary for installation of a
modified version onto the device.

However, merely because GPLv3 expanded installation
information requirements does not lessen GPLv2’s requirement of
such. In fact, in my reading of GPLv2 in comparison to GPLv3, the only
effective difference between the two on this point relates to
cryptographic device lock-down⁰. I do admit that under GPLv2, if you give
all the required installation scripts, you could still use cryptography
to prevent those scripts from functioning without an authorization key.
Some vendors do this, and that’s precisely why GPLv3 is written the way
that it is: we’d observed such lock-down occurring in the field, and
identified that behavior as a bug in GPLv2 that is now closed with
GPLv3. (Please see
the footnote as to why I think I
previously erred in that deleted interpretation.)

However, because of all that hype about GPLv3’s new Installation
Information definition, many simply forgot that the GPLv2 isn’t
silent on the issue. In other words, GPLv3’s verbosity on the subject
led people to minimize the important existing requirements of GPLv2
regarding installation information.

As regular readers of this blog know, I’ve spent much of my time for
the last 12 years doing GPL enforcement. Quite often, I must remind
violators that GPLv2 does indeed require the scripts to control
compilation and installation of the executable, and that candidate
source code releases missing the scripts remain in violation of GPLv2.
I sincerely hope that Android/Linux redistributors haven’t forgotten
this.

I have one final and important point to make regarding Motorola’s
February statement: I’ve often mentioned that the mobile industry’s
opposition to GPLv3 and to user-upgradable devices is for
their own reasons, and nothing to do with regulators or other
outside entities preventing them from releasing such software. In their
blog post, Motorola tells us quite clearly that the community of
developers interested in … experimenting with Android system
development and re-flashing phones … [should obtain] either a
Google ADP1 developer phone or a Nexus One, both of which are intended
for these purposes. In other words, Motorola tacitly admits that
it’s completely legal and reasonable for the community to obtain such
telephones, and that, in fact, Google sells such devices. Motorola was
not required to put lock-down restrictions in place, rather
they made a choice to prohibit users in this way. On this
point, Google chose to treat its users with respect, allowing them to
install modified versions. Motorola, by contrast, chose to make
Android/Linux as close to Apple’s iPhone as they could get away with
legally.

So, the next time a mobile company tries to tell you that they just
can’t abide by GPLv3 because some third party (the FCC is their frequent
scapegoat) prohibits them, you should call them on their
FUD. Point out
that Google sells phones on the open market that provide
all Installation Information that GPLv3 might require. (In other
words, even if Linux were GPLv3’d, Android/Linux on the NexusOne and HTC
Dream would be a GPLv3-compliant distribution.) Meanwhile, at least one
such company, Motorola, has admitted their solitary reason for avoiding
GPLv3: the company just doesn’t believe users deserve the right to
install improved versions of their software. At least they admit their
contempt for their customers.

Update (same day):
jwildeboer
pointed me to
a few
posts
in the custom ROM and jailbreaking communities about their concerns about
Motorola’s new offering, the Droid-X. Some commentors there point out
that eventually, most phones get jailbroken or otherwise allow user
control. However, the key point of
the CrunchGear
User Manifesto is a clear and good one: no company or person has
the right to tell you that you may not do what you like with your own
property. This is a point akin and perhaps essential to software
freedom. It doesn’t really matter if you can figure out to how
to hack a device; what’s important is that you not give your money to the
company that prohibits such hacking. For goodness sake, people, why don’t
we all use ADP1’s and NexusOne’s and be done with this?

Updated (2010-07-17): It appears
that cryptographic
lock down on the Droid-X is confirmed (thanks
to rao for the link). I hope
everyone will boycott all Motorola devices because of this, especially
given that there are Android/Linux devices on the market that
aren’t locked down in this way.

BTW, in Motorola’s answer to Engadget on this,
we see they are again subtly sending FUD that the lock-down is somehow
legally required:

Motorola’s primary focus is the security of our end users and protection
of their data, while also meeting carrier, partner and legal requirements.

I agree the carriers and partners probably want such lock down, but I’d
like to see their evidence that there is a legal restriction that requires
that. They present none.

Meanwhile, they also state that such cryptographic lock-down is the
only way they know how to secure their devices:

Checking for a valid software configuration is a common practice within
the industry to protect the user against potential malicious software
threats.

Pity that Motorola engineers aren’t as clueful as the Google and HTC
engineers who designed the ADP1 and Nexus One.

---

⁰ Update on 2020-04-09: At the
time I wrote the text above, I was writing for a specific organization where
I worked at the time, who held this position, and I’d cross-posted the blog
post here. I trusted lawyers I spoke to at the time, who insisted that
GPLv2’s failure to mention cryptography meant that “scripts
used to control compilation and installation of the
executable” necessarily did not include items mentioned
explicitly GPLv3’s Installation Instructions definition. I believed these
lawyers, and shouldn’t have. Lawyers I’ve talked to since making this post
have taught me that the view stated above lacks nuance. The issue of
cryptographic lock-down in GPLv2, and how to interpret “scripts used to
control … installation” in an age of cryptographic lock-down,
remain an open question of GPL interpretation.