|
|
Subscribe / Log in / New account

Google's disappearing Android GPL compliance opportunity

By Jonathan Corbet
January 4, 2012
All versions of the GNU General Public License require that anybody shipping GPL-licensed software in binary form make the associated source code available, either as an accompaniment to the binary distribution or, failing that, to anybody who asks for it later. Getting companies to actually comply with the GPL's requirements has always been a challenge, especially in the embedded systems world. The recent proliferation of Android-based devices has brought with it a whole new set of GPL compliance failures. Android is an interesting case, though, in that there is one company - Google - that is well positioned to require better behavior from those who ship Android.

Recently, Matthew Garrett, who has long tracked GPL compliance (or the lack thereof) in the Android world, has taken Google to task for failing to require better GPL behavior from Android distributors. His article (along with the followup on why GPL violations can make economic sense) is well worth reading in its entirety. In short, Matthew says that Google could force GPL compliance among Android distributors by either suing them or by requiring GPL compliance as a condition for use of the Android trademark (and, presumably, Google's proprietary Android applications). But, Matthew says, "Google makes money off other people's violation of the GPL", so it does nothing.

There is probably some truth to this argument. GPL compliance is not hard, but it is not free; skipping it makes Android-based devices a little cheaper to make and, thus, more competitive in the market. But there is almost certainly more to it than that - a fact that does not make this behavior any wiser in the long run.

One could start with the understanding that Google, and the Android part of Google in particular, suffers from a fairly strong case of GPL aversion. Considerable effort went into the creation of an almost GPL-free Android system; this included creating a new C library and a new Java virtual machine. Basing the whole thing on a GPL-licensed kernel may have been a necessary evil from the Android group's point of view, but accepting that evil does not require taking on an enthusiasm for enforcing the GPL's requirements.

Add to that the fact that the patent wars have put Android vendors into an unpleasant and uncertain legal situation. It seems clear that any commercial success in the mobile world is going to end up with patent leeches hanging all over it, but that doesn't change the fact that there is an especially visible legal cloud over Android at the moment. Adding GPL compliance problems to those already faced by Android vendors, especially if those problems come in the form of a copyright infringement lawsuit, could well be the straw that breaks the camel's back and causes those vendors to look more favorably on other systems. Anybody within Google who is considering a stronger stance on GPL compliance must certainly have that concern at the front of their mind.

Then, there is the little issue that few people want to talk about: what about those binary-only kernel modules? Google would not be able to take a position on GPL compliance in Android distributions without taking a position on binary-only modules. If use of the Android trademark is conditioned on GPL compliance, somebody will have to decide if distributions with proprietary modules (most of them, unfortunately) are compliant. A "no" answer would strip large numbers of devices of their trademark usage rights, while a "yes" answer would be a public statement that binary-only modules are OK. Given how few companies are willing to take a stand on this issue, it is unsurprising that Google does not want to find itself in that position.

Finally, it is worth observing that, for whatever reasons, companies almost never engage in GPL-enforcement actions despite owning the copyrights on large amounts of code. Almost all of the successful enforcement out there has been done by (or at least in the name of) individuals. The few exceptions, such as when IBM asserted GPL-infringement against SCO, show how serious the situation has to be before a corporation is willing to make such a move. So it could be said that Google is just behaving like all of its peers in this regard.

Having just made all of these excuses for Google's lack of action in this area, your editor would like to make one thing clear: a failure to insist on better GPL behavior may be entirely understandable, but, in the long (or not so long) run this approach is unwise and may prove dangerous for the Android market. If Google does not get Android vendors to clean up their act, others will lose their patience and do it for them. Indeed, as made clear by Harald Welte with regard to HTC's policy of delaying source releases, patience is already pretty well exhausted:

So I hereby declare my patience has ended here. I am determined to bring those outrageous delays to an end. This will be one of my new year resolutions for 2012: Use whatever means possible to make HTC understand that this is not how you can treat Free Software, the community, its customers, the GPL and in the end, copyright itself.

There are developers in our community who are prone to a certain amount of empty noise and bluster, but Harald is not one of them; this kind of threat, coming from him, is 100% credible.

One could say that this still works in Google's favor: individuals can force Android vendors to improve their behavior without associating Google's name with their actions. But if Google is worried about legal uncertainty surrounding use of Android, it must certainly worry about actions brought by individuals that are completely out of its control. That is especially true given that some individuals have been making ominous noises about GPL termination conditions and what might be required to regain GPL distribution rights after a violation. By looking the other way when Android vendors fail to live up to the GPL, Google may be helping those vendors set themselves up for attack by people or groups whose primary concern is not availability of the source code. Some of those people may be after serious financial gain or an opportunity to make the use of GPL-licensed code look like an inherently dangerous and risky thing.

If nothing else, contempt for the GPL will breed more of the same; as Matthew said, "In the absence of enforcement, GPL compliance only works if it's the norm". By ignoring its partners' GPL violations, Google is, at best, undermining that norm; at worst, it could be setting up Android (and possibly Linux) for a serious fall. Google still has the power to drive considerable improvements in this area if it takes the initiative now. Continued inaction, though, risks letting that initiative, and that power, slip away as others do the job that Google is unwilling to do. That does not seem like an outcome that would make anybody happy.


to post comments

Google's disappearing Android GPL compliance opportunity

Posted Jan 5, 2012 2:16 UTC (Thu) by ras (subscriber, #33059) [Link] (1 responses)

One thing Google could do to make life easier is provide a way to host the source on market.android.com. They could even go one step further, and make the build process produce both binary and source uploads.

Google's disappearing Android GPL compliance opportunity

Posted Jan 5, 2012 7:40 UTC (Thu) by rsidd (subscriber, #2582) [Link]

It's only the kernel source that is at issue here, and that's not distributed via market -- only by vendors.

Google's disappearing Android GPL compliance opportunity

Posted Jan 5, 2012 16:56 UTC (Thu) by shemminger (subscriber, #5739) [Link]

Do no evil != never try to do good?

Google's disappearing Android GPL compliance opportunity

Posted Jan 5, 2012 18:52 UTC (Thu) by ejr (subscriber, #51652) [Link]

If some vendor forgets to remove HyperV code, that could give Microsoft standing for a GPL compliance lawsuit. I don't see any obviously Apple-owned bits, but I'm sure some small company owning some piece could be bought to give them standing. Silly to leave this hole open.

Harald Welte has standing in German courts

Posted Jan 14, 2012 0:18 UTC (Sat) by clemenstimpler (guest, #71914) [Link]

1. There is precedent in German case law for the GPL requirement to disclose the source code: http://www.jbb.de/judgment_dc_frankfurt_gpl.pdf .

2. The cost to put this on trial in Germany are not as prohibitive as they are in the US.

3. The damage done to HTC does not depend on the venue of legal proceedings.

Google's disappearing Android GPL compliance opportunity

Posted Jan 18, 2012 16:42 UTC (Wed) by landley (guest, #6789) [Link] (18 responses)

One of the big ways to comply with the GPL is not to use it. The GPL has become a mushroom cloud of legal uncertainty, thanks in part to the FSF, and my own past mistakes.

In part GPLv2 has been tarred with the same brush as GPLv3 (the jar-jar binks of licenses), and as with the second two Matrix movies it makes people question whether the first was ever really any good.

In part the FSF has worked _very_hard to undermine GPLv2. Most recently, the Free Software Foundation took a flimsy excuse to retroactively relicense the last GPLv2 release of binutils (2.17) to GPLv3, by replacing the tarball on their website with a new tarball containing GPLv3 source files. (They did something similar to gdb, and who knows what else.)

Part of this is my fault, and I'm sorry. When I inherited Erik Andersen's "hall of shame" in busybox I told him I couldn't maintain it, and instead asked Pamela Jones of Groklaw if I could get any pro bono legal representation to actually _do_ something about the years of accumulated reports. She hooked me up with the SFLC (I was hesitant at first because the people behind it were the original legal arm of the FSF, but they assured me they'd formed a new organization to distance themselves from Stallman), and we spent a year going through the backlog of reports Erik had accumulated.

But doing this didn't result in a single line of useful code going into the repo, the source code we got was uniformly useless (when it wasn't vanilla with a couple printks it was a random source control snapshot plus backports of later commits from the same source control, the changes were all hardwiring config variables or commenting stuff out). From an engineering standpoint it was useless.

But the SFLC charged each company tens of thousands of dollars in legal fees, creating a self-financing legal machine that the FSF then borrowed to reopen an old wound with Linksys (causing Cisco to dissolve the Linksys division and exit Linux development entirely). At that point I went "it's doing more harm than good" and broke off my relationship with the SFLC, but the ball was already rolling and smashing through houses, now steered by an organization that got back in bed with the FSF.

This means GPLv2 BusyBox is legally speaking one of the most _dangerous_ pieces of software you can ship, and if license terms can retroactively change ala binutils 2.17 how can you ever be sure you're compliant?

Add all of that together, and GPL use in general is declining rapidly: http://www.itworld.com/it-managementstrategy/233753/gpl-c...

And that includes developers like me who aren't really fond of BSD licensing, but see the GPL as poisoned by the FSF's actions. Since the binutils thing, I've revived my old "toybox" project, relicensed it 2-clause GPL, and put work into explicitly doing a non-GPL replacement for busybox (and toolbox, which is a sad piece of software). If the only way to stop the busybox lawsuits is to render busybox irrelevant by reimplementing it from scratch... sounds like fun.

Google's disappearing Android GPL compliance opportunity

Posted Jan 18, 2012 18:23 UTC (Wed) by jrn (subscriber, #64214) [Link] (10 responses)

> Most recently, the Free Software Foundation took a flimsy excuse to retroactively relicense the last GPLv2 release of binutils (2.17) to GPLv3, by replacing the tarball on their website with a new tarball containing GPLv3 source files.

Please forgive me if I misunderstand, but: wouldn't this only affect people downloading the new tarball, rather than taking away rights from people who downloaded the old one?

Google's disappearing Android GPL compliance opportunity

Posted Jan 18, 2012 19:05 UTC (Wed) by bronson (subscriber, #4806) [Link]

It's true, you generally can't revoke a license from something you've already released (it gets murky, depends on license and jurisdiction).

However, this change does affect everybody who now has to wonder what version of binutils they're using and where exactly they got it from.

No, it'll effect everyone...

Posted Jan 18, 2012 19:13 UTC (Wed) by khim (subscriber, #9252) [Link]

Well, situation is not so black-and-white.

Old version of binutils included generated files which were contributed without source. Technically speaking it's violation of GPL (because files were submitted not in the preferred form of the work for making modifications to it) and apparently FSF never had a license for these files - thus it can not tranfer this license further. To rectify the situation original (not generated) files were formally contributed... under GPLv3. FSF also forgiven inadvertent GPL violations (can not find the actual press-release because of SOPA/PIPA blackout) to make life of users who used old tarballs easier.

This means that you can use all the files which were properly released under GPLv2 back then - but you can not use files which were released in violation of GPLv2: only inadvertent violations were forgiven and new replacement files are only available under GPLv3...

Not an ideal situation to be sure, but not the end of the world either...

Google's disappearing Android GPL compliance opportunity

Posted Jan 18, 2012 19:52 UTC (Wed) by dlang (guest, #313) [Link] (7 responses)

if they are changing the license they should change the release number, publishing a new tarball for the same version number under a different license means that you have no way of knowing if the people who compiled that version got it under GPLv2 or GPLv3

so someone who is complying with GPLv2 could be sued by someone for their non-complience with GPLv3 because that's what the files now claim.

this is careless at best, and leads to people not trusting the software because they don't know what license the version they already downloaded is under now.

Please don't spread FUD...

Posted Jan 18, 2012 20:59 UTC (Wed) by khim (subscriber, #9252) [Link] (6 responses)

<blockquote><font class="QuotedText">so someone who is complying with GPLv2 could be sued by someone for their non-complience with GPLv3 because that's what the files now claim.</font></blockquote>

<p>This is not what happened and you [hopefully] know that.</p>

<p>You <b>can</b> pick old tarball and <b>try</b> to change it. “Try” is important becuase you'll find out that you can not do that: all files with changed license have always included line <b>THIS FILE IS MACHINE GENERATED WITH CGEN</b> and what does GPLv2 and/or GPLv3 say about such files? Right: you can not modify them - you should only modify original files. Original files were <b>not</b> included in old version of binutils thus these files were unmodifyable. In fact they were unusable because FSF distributed them under GPL so you needed to offer source - and you had no source to offer!</p>

<p>FSF did two things:<br />
1. It forgiven past <b>inadvertent</b> violations (people who only use tarballs and not try to change it are 100% clear).<br />
2. It provided source files for all these autogenerated files - but under GPLv3.</p>

<p>Do I like this solution? No: this is stupid to try to inject GPLv3 in old packages released under GPLv2. Does it make practical difference? No: now you hack the exact version released long ago - but only on GPLv3 terms, not on GPLv2 terms while before you had no right to modify them at all.</p>

<p>Files which were not mistakenly released without source five years ago are still distributed under GPLv2 in new tarball.</p>

<p>P.S. Note that new tarball is called <b>binutils-2.17a.tar.bz2</b> while old tarball is called <b>binutils-2.17.tar.bz2</b>. After old tarballs disappeared there was <b>huge</b> outcry from people who found out that their scripts stopped working - so eventually FSF added sysmlinks from old filenames to new filesnames to help these people. Pehaps <b>this</b> was a problem you are so angry about?</p>

Please don't spread FUD...

Posted Jan 18, 2012 21:54 UTC (Wed) by dlang (guest, #313) [Link] (5 responses)

>> so someone who is complying with GPLv2 could be sued by someone for their non-complience with GPLv3 because that's what the files now claim.

> This is not what happened and you [hopefully] know that

I did not say that someone has sued, I'm saying that someone could sue, and point to the file as distributed by the FSF as proof that it's released under the GPLv3.

and if they don't intend to be able to do this, why change the license?

the fact that someone could then point out that this version (2.17) was released before the GPLv3 was released, and therefor claiming that it's use must comply with GPLv3 could be considered fraud just further weakens the FSF.

having two files that claim to be the same version, with (as I understand it) the only difference between them being the license is just a bad idea. you don't want people to be able to start arguing "when I downloaded the file it said X and then you changed it to say Y"

it doesn't matter if they replaced the file or just changed it from being a file to being a symlink. people downloading things can't tell the difference. they download the file claiming to be 2.17 and it's now different.

Please don't spread FUD...

Posted Jan 18, 2012 21:59 UTC (Wed) by jrn (subscriber, #64214) [Link] (4 responses)

> I did not say that someone has sued, I'm saying that someone could sue, and point to the file as distributed by the FSF as proof that it's released under the GPLv3.

> and if they don't intend to be able to do this, why change the license?

See <http://lwn.net/Articles/475946/>.

I'll admit I'm a bit disappointed to read that you apparently are claiming that the binutils maintainers did this with the intention of lying.

Please don't spread FUD...

Posted Jan 23, 2012 0:35 UTC (Mon) by landley (guest, #6789) [Link] (3 responses)

The binutils maintainers insisted that Red Hat sign over the copyrights to them (which they've always done as a condition of contributing code to GNU proejcts), and then the FSF took those contributed files and released them under GPLv3, not under GPLv2.

That was a choice the binutils guys made, not Red Hat. The FSF could have released those files under GPLv2. They chose not to do so. They chose to retroactively relicense the old tarball, and to make the new tarball under a different license available from the old link, and wait for people like me to go "why did my checksum fail and fall back to a mirror" in order to even notice it had happened.

Whether they were being incompetent, or being sneaky, is a separate issue. They did what they did, by choice.

How is that "spreading FUD"?

Rob

the term "retroactive relicensing"

Posted Jan 23, 2012 1:25 UTC (Mon) by jrn (subscriber, #64214) [Link] (1 responses)

Who said you were spreading FUD? khim's corrections were in response to a comment by dlang.

However, your characterization _still_ strikes me as strange. Usually when I see the words "retroactively relicense the old tarball", I would assume that that means there was old code under one license and they have revoked the license, replacing it with a new one. You can be unhappy with the license chosen for binutils 2.17a and the choice to put that symlink there (and I would agree with you) but calling it fraud as dlang did or retroactive relicensing as you are seems disingenuous.

Please take a note of the following...

Posted Jan 23, 2012 2:11 UTC (Mon) by khim (subscriber, #9252) [Link]

You can be unhappy with the license chosen for binutils 2.17a and the choice to put that symlink there (and I would agree with you)

As I've already explained: initially file was just removed, symlink was added later to [hopefully] help users with automatic scripts. I'm not sure it was good idea - but it was quite explicitly not produced by RMS, FSF or "binutils guys"...

As I've said already: stop spreading FUD. I may not agree with everything FSF does (and the fact that they released these files under GPLv3 looks strange to me, too), but I at least tend to check facts before trying to tell tales about FSF conspiracies.

Good try...

Posted Jan 23, 2012 1:56 UTC (Mon) by khim (subscriber, #9252) [Link]

They chose to retroactively relicense the old tarball, and to make the new tarball under a different license available from the old link, and wait for people like me to go "why did my checksum fail and fall back to a mirror" in order to even notice it had happened.

Whether they were being incompetent, or being sneaky, is a separate issue. They did what they did, by choice.

How is that "spreading FUD"?

Well, apparently you don't know what FUD is. Definition: FUD is generally a strategic attempt to influence perception by disseminating negative and dubious or false information - and this is what you are doing here.

FSF never relicensed old tarball: new tarball was put under different name. Then people started complaining that old tarballs disappeared and offered a solution: This kind of URL change is a serial killer for automatic build system/script already shipped. Is it possible to have simlinks like 'oldername'->'newname' (as for example binutils-2.21.1a.tar.bz2 tarball will actually contain binutils-2.21.1)? and binutils maintaines agreed to make few symlinks.

Google's disappearing Android GPL compliance opportunity

Posted Jan 23, 2012 3:09 UTC (Mon) by landley (guest, #6789) [Link] (6 responses)

> Since the binutils thing, I've revived my old "toybox" project,
> relicensed it 2-clause GPL...

Sigh. Obviously 2-clause BSD.

I'll get used to saying that someday. (I miss the days when GPLv2 was a viable license for userspace code. I hate the FSF with a fiery passion for taking it away from me. This idiots are their own worst enemies. They can't deal with success, and reopen old wounds to avoid it. I remember the first time I met Richard Stallman in person back in 2000 I asked him why the FSF wasn't opposing software patents and he said it wasn't his fight. This was the height of the campaign to stick GNU/ on the front of Linux, _that_ was his fight...)

Rob

Google's disappearing Android GPL compliance opportunity

Posted Jan 26, 2012 18:27 UTC (Thu) by nix (subscriber, #2304) [Link] (5 responses)

I miss the days when GPLv2 was a viable license for userspace code. I hate the FSF with a fiery passion for taking it away from me.
Because the FSF have forbidden you from using the GPLv2 forevermore!

Oh, wait, they haven't.

Google's disappearing Android GPL compliance opportunity

Posted Jan 26, 2012 20:52 UTC (Thu) by dlang (guest, #313) [Link] (4 responses)

It's not that they have forbidden anyone from using the GPLv2 (although they strongly discourage it).

The issue is that they've affected the name "GPL" to the point where _anything_ with GPL in it gets rejected, including LGPL.

Google's disappearing Android GPL compliance opportunity

Posted Jan 26, 2012 21:22 UTC (Thu) by rahulsundaram (subscriber, #21946) [Link] (3 responses)

rejected by whom? If people dont understand GPLv2 and GPLv3 and LGPL are all different licenses, FSF is not responsible for that.

Google's disappearing Android GPL compliance opportunity

Posted Jan 26, 2012 21:48 UTC (Thu) by dlang (guest, #313) [Link] (2 responses)

rejected by non-technical people who hear the scare stories about the "GPL will cause you to have to give away all your code" nonsense who aren't sure which version of the GPL will cause the problem, they just know that there are problems with using "GPL code" and so don't go any further.

yes, it's silly, and mostly it's a case of management being lazy and not knowing what's going on, but at the same time it's a very real effect.

how much of this is the fault of the FSF? that's harder to say.

the GPLv2 was something that was fairly broadly accepted (still with some FUD, but still with a lot of companies using it). the GPLv3 has split the community, with some people eagerly embracing it, but with many people (including many prominent people) thinking that it goes too far. That makes even companies that accepted the GPLv2 move away from GPL code. Some of it is the 'taint' on the name GPL, but some of it is the fact that much GPLv2 code is GPLv2+ code and companies don't want to get stuck with having the maintain a v2 fork or being trapped by v3 so they look to just avoid it entirely.

Google's disappearing Android GPL compliance opportunity

Posted Jan 26, 2012 23:22 UTC (Thu) by dmarti (subscriber, #11625) [Link]

"split the community"? I hadn't realized that the open source/free software community had a uniform set of positions on licensing before.

Google's disappearing Android GPL compliance opportunity

Posted Feb 1, 2012 0:56 UTC (Wed) by dashesy (guest, #74652) [Link]

yes, it's silly, and mostly it's a case of management being lazy and not knowing what's going on, but at the same time it's a very real effect
And even lawyers who prefer to take the easy side. Specially if the companies are not exactly software companies, management has less knowledge about software. GPlv2+ blurs the line here. At least for smaller companies, these stories just scares them away.


Copyright © 2012, Eklektix, Inc.
This article may be redistributed under the terms of the Creative Commons CC BY-SA 4.0 license
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds