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: http://archive09.linux.com/articles/55285 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: http://git.busybox.net/busybox-website/commit/?id=09ea33fdd63acbf5160090e8563c0a9a35ff7f6f (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: http://git.busybox.net/busybox-website/commit/license.html?id=8ab0ffdccf6c429c8ddbaf21fce4f206859ab6f8 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 (http://en.wikipedia.org/wiki/Free_Software_Foundation,_Inc._v._Cisco_Systems,_Inc.) 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 http://copyright.universityofcalifornia.edu/ownership/joint-works.html . 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 _means_. 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... Rob _______________________________________________ uClibc mailing list uClibc@uclibc.org http://lists.busybox.net/mailman/listinfo/uclibc
