On Mon, Jun 1, 2015 at 5:12 AM, Jaromír Cápík <tav...@seznam.cz> wrote:
> > The guy who implemented locale support for uClibc, Manuel Nova, never
> > quite finished it, and left the code with a config symbol "manuel's
> > warnings". He wandered away from uClibc development almost ten years
> > ago, and nobody really inherited his work. Sounds like it's
> > bit-rotted.
> >
> > I took a stab at it a few years back, but distributing a binary
> > tarball of data sourced from glibc seemed like a license violation,
> What license violation? The glibc library is released under the GPL

Actually it's released under LGPL, which is not actually the same
license. (Plus there was 2.1 vs 2.0 skew for a bit, and the glibc
developers were talking about switching to GPLv3 for a while until red
hat quashed it, and there was the whole mepis thing...)

> license and therefore you can freely redistribute and modify
> sources and even binary data.

And if you redistribute binaries without the corresponding sources you
get a shakedown from the FSF or the Conservancy asking for many
thousands of dollars.

> > and I _really_ didn't want to throw a glibc source tarball in the
> > uclbic download directory.
> I don't think you need to.

Allow me to introduce you to the Mepis disaster:

The FSF went after Ubuntu derivative distro, which at the time had a
press release on its website quoting Mark Shuttleworth saying how
great it was that Mepis was basing itself on Ubunt. Mepis' crime was
not mirroring ubuntu source tarballs it hadn't modified. They pointed
at their upstream for stuff they hadn't modified, with the explicit
consent of Ubuntu, and the FSF said "no, you must mirror it yourself".
How the FSF even got INVOLVED between the two parties, I couldn't tell
you, but they stuck their nose in and nearly bankrupted a small three
person garage operation.

In response to that, I added an explicit explanation of the busybox
FAQ saying if you use a vanilla unmodified busybox version and SAY
it's a vanilla unmodified version X and that you did not modify it,
you do not need to mirror the source tarball but can point at us
instead because we don't need you to give us code you already have, we
just want you to _identify_ it.

Bradley Cooper, the guy whose somewhat acromonious parting of the ways
with the Software Freedom Law Center resulted in founding the Software
Freedom Conservancy, has only ever pushed two git commits to the
busybox web repository. What they did was remove the safe harbor
provision I'd added:


(Second commit was basically a typo fix to the first.)

Note that I wrote the text he was removing (posted to the mailing
list), and new maintainer Denys Vlasenko is the one who checked it in
to the website:


I yelled at Bradley about it on irc (on the public #uclibc channel,
October 10, 2013, you can probably pull it out of riker's ibot if you
want to scroll down far enough):

<landley_> The paragraph starting: <p>So if you built an unmodified
BusyBox release and you point people at the URL
<landley_> -to the SPECIFIC source tarball on busybox.net you built it
from and truthfully
<landley_> -say "that's it, no patches", we've accepted that as
compliance even from
<landley_> Got removed entirely.
<landley_> It was not replaced with any rewording. It was removed.
<bkuhn> landley_: I know, I removed it because the GPLv2 just doesn't
allow that.  BusyBox is GPLv2-only.  I know *you* don't mind that, and
that we haven't *enforced* against anyone who does that, but it's just
not what the license says.

I.E. if we say on the busybox website that "this behavior is ok for
this project" (the ex-maintainer writing it, current maintainer
uploading it), that's not allowed because GPLv2 is magic, it's not our
license on our project that we're using to give permission to use our
copyrights, the FSF's interpretation trumps that of the developers
writing and releasing the code, The Convervancy reserves the right to
sue even if the project maintainers say no because ONE DEVELOPER
SOMEWHERE might disagree, and the FSF has a _history_ of taking action
on exactly these grounds.

So yes, I feel I would totally have to upload a copy of glibc source
tarball if we derived binary stuff from it because the FSF is a group
of foaming loonies with a history of suing their supposed friends
because they like persecuting minor heresies.

(I looked at extracting just the relevant source and it's an
incestuous tangle, as is all FSF code. One of the big advantages of
musl: it contains zero FSF code, and is in fact MIT-licensed, which is
basically the BSD license in a boston accent.)

> > See "probable license violation", above. (Maybe locale data isn't
> > copyrightable? Scenes a' faire? No idea, not personally going there.
> > You don't get these problems with musl.)
> I don't see any.

The locale tarballs that _did_ ship were generated from glibc source.
We do not ship the glibc source this binary data was generated from.
The uClibc project posted a binary and did not post the corresponding
source code from which that binary was generated. (It was locale data
rather than an executable, but copyright doesn't care.)

Now nobody has sued _us_ over it yet. But then Linksys settled with
the Linux developers in 2003
(http://www.forbes.com/2003/10/14/cz_dl_1014linksys.html) and then 5
years later the FSF went after Cisco (which had acquired Linux) for
the same BSP code the first thing had been about
So "years go by with no action" does not mean you're _safe_,
especially when the FSF starts feeling irrelevant and sidelined and
has to make a splash to regain the spotlight.

Me, I did license enforcement for a year and then couldn't get it to
STOP once I'd proved that a suing a dozen companies only added a
single line of code to busybox, and that line was just a more
elaborate copyright notice the lawyers requested to make suing easier.
No really: http://git.busybox.net/busybox/commit/?id=eb84a42fdd1d (And
then once I started opposing Bradley's sue-the-world agenda, guess
what one of his only two commits to the actual codebase was?
http://git.busybox.net/busybox/commit/?id=0e941d542736 of course. He
seems really upset that the guy who started the busybox enforcement
suits tried to stop them again once proving they were a complete waste
of time from an engineering perspective, and is trying to write me out
of history. In his ELC talk last year he referred to me not by name
but, and I quote, "a troll". Oh well.)

If you think these guys act in good faith, ask yourself why after they
tried to force the world at large to move from GPLv2 to GPLv3 and half
the userbase (including all the kernel developers) said "hell no",
they deleted the last GPLv2 release of binutils and gdb off the FSF
website and replaced them with "binutils 2.17a" and "gdb 6.6a"
versions (with binutils silently symlinking the old name to the new
tarball, I noticed when the sha1sum on the download didn't match), the
ONLY difference being that they retroactivelly added GPLv3 source code
to the tarball. Ask yourself why the FSF's "Savannah" repository
(their attempt to me-too sourceforge back when such a thing was
relevant) declared that GPLv2 only was not an acceptable license but
BSD licensing stuff was (https://lwn.net/Articles/176582/).

So if you think the GPL is happy and fluffy and nobody ever gets sued
for minor infractions by True Believers pushing an agenda most people
seem to disagree with, go for it. Me, I wasn't comfortable uploading
binaries derived from glibc source without mirroring the tarball,
which I didn't want to do. That is why I didn't upload updated locale
data when I looked at it a few years back, and now that setup's long
torn apart and I'd have to recreate it from scratch.

> > There's a problem that uclibc was never quite an independent project,
> > it copied glibc headers, copied glibc locale data, snapshotted glibc's
> > thread implementation... If you don't care about licenses at all and
> > don't thing the FSF will ever sue you, then it's fine. If you _do_
> > treat the FSF like a wounded rabid weasel, and don't want to get any
> > of it on you, this poses a problem.
> I really don't get what copyright infringement you're writing about.

"This tarball of binary data was compiled from this tarball of source
code, the source code is gpl, we must ship that source code". The fact
the binary data is locale data rather than executable data is
immaterial. The "we can identify the vanilla upstream version and not
mirror it" argument is the one mepis _lost_ and the one Bradley
_removed_ from the busybox license.html file when I explicitly tried
to say "our project will not do this to you because WE are not crazy".
Bradley invoked his right to be crazy on busybox's behalf no matter
what the current _and_ previous maintainer agreed on. (And copyright
law lets him do it because we classify our open source projects as
collective works rather than joint authorship, see
. It's basically a stack of derived works, each copyright to which
must be individually licensed, so _any_ contributor can veto the whole
thing. With joint authorship, any author can issue a new license to
the whole thing.)

But beyond the obvious, the free software foundation's advocates take
an extremely... "aggressive" view of what counts as an infraction of
its personal reading of the license text. GPLv2 section 2a says we
have to list the date of every change _in_the_file_. Is source control
comments good enough? That's basically the same question as "could
Mepis get away with pointing at ubuntu's servers for the packages it
hadn't modified in its derived distro". Didn't stop legal action from
being taken from them.

When section 1 says " keep intact all the notices that refer to this
License and to the absence of any warranty;" does that mean you can
never rephrase, simplify, or correct the FSF's old mailing address
from when they moved several years back in any of the license
boilerplate at the top of each file? Surely no SANE person would sue
you for doing something like that... would they? (How much of the file
are we allowed to modify, exactly?)

That's why I'm uncomfortable using projects that copy a lot of code
from FSF packages, giving the FSF strong standing to sue no matter
what the later authors think. Personally, these days I try to minimize
my exposure to the crazy.

> > Adding m68k support to musl is probably easier than fixing locale
> > support in uClibc.
> Well ... I built libiconv & gettext and that allows me to continue
> at least. I cannot change the C library like shoes :]
> uClibc is proven to be quick and reliable.

Good luck with it. As I mentioned, I am still using it in Aboriginal.
I don't plan on upgrading it, but I have a longish patch stack and did
get working m68k binaries for the last release version (although not
locale support).

> >> Anybody has got a copy of the above archive?
> >
> > I don't think it was ever uploaded. I'm not sure it was ever actually made.
> >
> >
> Hmm ... why the 'complicated' archive name then?

I expect somebody _intended_ to make it and upload it. Probably found
out that the infrastructure broke when they tried to generate it and
went "I should debug that and fix that and upload the thing"... and
never got around to it.

> It looks more like created for tests, but never uploaded
> or uploaded and then deleted as broken or because
> someone thought it violates licenses?

I had nothing to do with the original patch berhnard checked in, I
thought I'd fix it retroactively (like a year later) and then changed
my mind, but most other people haven't actually _done_ license
enforcement and thus don't have the mindset of what licensing actually

It's really easy to type a date into a file, especially if you mean to
update a file that also has a much older data in a similar format. You
can type today's date, mean to create and upload the file real soon
now... and never get around to it.

There's been a lot  of that with uClibc over the years...

uClibc mailing list

Reply via email to