Shipping trojaned binary blobs in F-Droid?

[pfalconMember]

I obviously rejoiced to see Busybox app included in F-Droid – it’s nice to know that the problem of building native binaries was solved. I proceeded to check how, and – … just found that F-Droid started to violate GPL and ship trojaned binary blobs.

So, why does it violates GPL? Because it ships Busybox licensed under GPLv2, but there’s no sign of source of it being built: https://gitorious.org/f-droid/fdroidserver/blobs/master/metadata/stericson.busybox.donate.txt

Why is it trojaned?

1. Because instead of source code, it comes with binary(ies) of unknown origin. This really should be enough to apply the presumption. But there’re more points for your amusement.
2. The package is named in such way as to confuse user as if it comes from a well-known cell phone vendor. Supposedly, that package is made by a gentleman named Stephen Erickson, but that’s only a guess. The fact is that he, instead of being modest and not confuse fellow users, prefers to border on impersonating other entity, supposedly trustworthy.
3. He (or they) also had all the freedom of not doing so, but instead he chose to disguise what is actually binary executable files as .png images: http://code.google.com/p/busybox-android/source/browse/#svn%2Ftrunk%2Fassets

[pfalconMember]

Oh, and just yesterday they dropped some patches in the repo after all: http://code.google.com/p/busybox-android/source/detail?r=4

[CiaranGMember]

Apart from point 2, I agree. Disabled – our build system can’t build those (yet – I have changes nearly ready to push to the repo that can do it), they rely on patching the c libraries. I have disabled it.

In any case, that project is consistently violating the GPL, because the source was only recently published, and then only for ONE particular version. New versions continue to be released in the Android Market without source.

[DominikMember]

I am sorry but must correct you:
The author is not violating the GPL if he sends the source code of the busybox binaries when asked by mail or snailmail.
Further more he is not violating the GPL by not providing the source code of the Android Frontend that is licensed under Apache License 2. This is due to the fact that he ships binaries which can have another license than the app itself.

[pfalconMember]

The author is not violating the GPL if he sends the source code of the busybox binaries when asked by mail or snailmail.

Ok, my friend asked for source. Via snailmail. Got nothing. Are you still sure the author is not violating GPL? Because I personally never can be sure if some entity violates GPL, but can be very reasonably sure when it doesn’t violate. That “when” allows to be reasonably sure not only me, but also you and my friend – each separately, not depending on gossip from each other. It even doesn’t require usage of advanced communication techniques like snailmail, pigeons, or fires on city walls. That method is just hosting the source at the same place and time as the binaries. Surprisingly, that’s what 95+% of folks who work with Free software do. So yes, “violate” in the messages above is not used in legal or formal sense, but in colloquial, with the connotation described – the entity doesn’t follow the best practices of license compliance, essentially making it hard on themselves to comply (but easier to not comply).

Further more he is not violating the GPL by not providing the source code of the Android Frontend that is licensed under Apache License 2. This is due to the fact that he ships binaries which can have another license than the app itself.

No, he ships single integral executable file which includes code from GPL-licensed projects, and GPL requires the whole project to be licensed under GPL in this case. You may think that APK is not exactly “single integral executable”, but good party to discuss that are FSF lawyers. Maybe they will release GPLv3.1 with Appendix N with special considerations for Android APKs (won’t apply to busybox though, they’re smartly stuck at GPLv2). Until then there’re good reasons to consider APKs as the above.

Also, if source is not released, it’s not an Open Source software, and F-Droid is about Open Source software.

[DominikMember]

Okay, when someone asked by snailmail and he did not answer that request he is breaking the GPL.
The last part of your post is very interesting for me. I would love to see something like you mentioned in a license.

I am working with Stericson on RootTools lib which I also use in my apps. I can email him and tell him the problems:
- newer versions of his Busybox installer should be uploaded to the repo
- don’t hide executeables behind pngs

What exactly is missing for you to rebuild the busybox binaries?

[pfalconMember]

Well, the GPL, as customary for legal documents, is written in general
form using generic terms, because it’s not possible to separately
mention every possible case. As such, which is also customary to legal
documents, it is subject to interpretation and commentary. Given above
is the straightforward interpretation which (reasonably) matches the
official (FSF’s) one.

So, http://www.gnu.org/licenses/gpl-2.0.html Section 3,
says that if one distributes object or executable form of GPL
Program/work based on it, that should be accompanied by source. That’s
mostly it – APK provided is the executable, which is produced by
taking the original busybox source, affixing with another code
(creating derivative, combination bound to be GPL-governed by
section 2), and then thru the series of build transformations made into
that executable, which is integral unit, directly based on the
original source code of busybox.

Now, the official commentary:
http://www.gnu.org/licenses/gpl-faq.html#MereAggregation (some other
Q/A in that FAQ may also apply or provide insight).

As the FAQ suggests, some cases are borderline, and in this specific
case (APK format and “installer” package) one can give many “pro”
arguments and counter them with many “cons” ones. But the problem is
exactly such situation – borderline, vague, inconsistent, conflicting.
One good way to keep an arbitrary system clean and working is to reject
any conflicting cases. That’s what many Free software projects do, and
in which way CiaranG maintains F-Droid, and I personally support and
value that.

So, the ways to disentangle the above situation would be:

1. Make sure that executable is unquestionably GPL compliant, i.e. for each version released, complete buildable source code for all components provided.

2. Make executable not contain GPL-licensed code, by either a) moving
it to a separate file (clearly representing separate work from GPL
standpoint) (APK or not; buildable source code must be provided); or b)
downloading it from network (the act of downloading/installing is
clearly a distribution per GPL terms, so users should be given
notice of license and offer to obtain the source (as usual, the
easiest way to comply with that is to give a direct link which has both
binary and source)).

[pfalconMember]

> What exactly is missing for you to rebuild the busybox binaries?

“You” here should be “us” or more specifically, “F-Droid”. F-Droid currently doesn’t have support to build native standalone binaries, and that’s missing. Of course, it should be automated, easy-to-use, reproducible. We also can’t expect 3rd party developers to switch to our build system, they will keep to use whatever they have, so F-Droid’s system should be generic enough to support wild varying.

That’s what missing and doing that is not exactly an easy task. IMHO, the right move would be to delegate that to existing Linux cross-build environment, and just integrate it with or into F-Droid. But CiaranG wrote that he almost had solution for that, and as I already opened quite a few RFC/discussion threads, so just wait for him. If anybody interested to work on that, just open a new thread on this and let’s get it started.

[Author]

Posts