This is hilarious as well: http://lists.busybox.net/pipermail/busybox/2006-September/058360.html
"Move GPLv2 vs v3 fun... Rob Landley rob at landley.net Sat Sep 9 23:49:58 UTC 2006 Previous message: Move GPLv2 vs v3 fun... Next message: Move GPLv2 vs v3 fun... Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] -------------------------------------------------------------------------------- On Friday 08 September 2006 7:04 pm, Aurelien Jacobs wrote: > > or should we just admit that the BusyBox license is GPLv2 only? > > I don't understand very well your reflexion about GPL. > - You dislike GPLv3 because it reduce some liberties > - You propose to remove the "or latter", IOW to remove a liberty > Isn't there a contradiction ? Or did I misunderstood your position ? Don't invent a straw man argument please. I consider licensing BusyBox under GPLv3 to be useless, unnecessary, overcomplicated, and confusing, and in addition to that it has actual downsides. 1) Useless: We're never dropping GPLv2. Therefore, nobody can enforce any of the new clauses of the GPLv3 on busybox code because people can continue to use it under the terms of GPLv2 which don't require them. So the new license is unenforceable on BusyBox code anyway, all it could possibly do to BusyBox is relax the terms, not tighten them. 2) Unnecessary: There's nothing wrong with GPLv2 that I'm aware of, and if something did crop up the Linux kernel would be screwed and that's big enough business for some large corporate entities to lobby to change the law to unscrew it. GPLv2 is 15 years old and it's been scrutinized by everybody from Microsoft to SCO. What reason is there for replacing it other than a cry for attention on the part of Richard Stallman? What exactly was wrong with GPLv2? 3) Overcomplicated: I'm not talking about the text of GPLv3, I'm talking about why would BusyBox need two licenses? We've been under GPLv2 all this time, that's the ONLY license we've ever had, and I'd like it to _stay_ the only license. I dowanna add unnecessary complexity to the project's licensing any more than I want to add unnecessary complexity to the project's code. 4) Unmotivated: Our current dual license was at first an afterthought, and is now an inconvenience. The GPLv3 did not _exist_ when BusyBox first shipped (and technically still doesn't), we just used the standard GPLv2 boilerplate which had the "or later" in it. This is not something we ever put any effort into, or placed any value on. It was a purely theoretical issue up until the FSF decided it had to do something to regain relevance. The "or later" clause is something I am now having to put effort into preserving and policing, and I really don't see any benefit from doing so. 5) Confusing: I hate having to point out the need for an "or later" clause to people when it's absent. Right now they can license code GPLv2 or "GPLv2 or later", and it's a subtle enough distinction that I keep having to point it out and ask "can we get an 'or later'" and it annoys me. GPLv2 and GPLv3 are clearly two different licenses, GPLv2 or later is a vague implicit dual license that's way too easily overlooked, and probably has been in the past. We didn't track this closely back when it was a purely theoretical issue, it's quite possible we sucked code from GPLv2-only projects, since at the time we just checked that it _was_ GPLv2. (We know we took some code from the Linux kernel, for example. The question is how much and where. You wanna do the audit?) I really like having the same license as the Linux kernel, and being able to take code from the Linux kernel without asking questions. I hate having to ask questions BEYOND "Is this code licensed under GPLv2?", and I really hate having to explain to people why GPLv2 isn't good enough to merge a patch. 6) Costly: To preserve the "or later" we can't use GPLv2 only code, which exists today. We had to pass on the diethotplug patch already. We're bending things a bit to continue to use the kernel's menuconfig. (Is it, or is it not part of the BusyBox source code? It's GPLv2 only.) Or how about the section of the kernel header files we sucked into libbb/loop.c? (That might or might not be scenes a' faire.) This is not going to improve with time. 7) Divisive: GPLv2 and GPLv3 aren't compatible, and BusyBox's current dual license is quite compatible with either of them. Although we can' donate code to projects under either license, we can't TAKE code from projects under any of those licenses. This means that the only people who might possibly benefit from our code being dual licensed those who want to suck BusyBox code into other GPLv3-only projects. (Not use us as a package, but use code snippets, or bolt our applets onto other things.) Except that if they do that, we can't take patches back from them. If they glue a GPLv3-only applet onto BusyBox, they can only distribute that modified version of BusyBox under GPLv3 only. We can't take that applet back into the the main BusyBox distro any more than we can currently take Greg's diethotplug code. I.E. the dual license encourages people to fork the project, in such a way that even if we get their code back, we can't integrate it. The only possible "benefit" of the dual license is making such a fork possible. Today there's 15 years worth of code under GPLv2, and not a line of code under GPLv3. I see absolutely no benefit from BusyBox being dual licensed under a license that doesn't even exist yet, a number of real and potential downsides, and I expect that the situation will only get worse as time goes on, because their are two possible scenarios: A) GPLv3 is successful. We get more GPLv3 only code submissions, greater amount of code we can't use because it isn't dual licensed under GPLv2. B) GPLv3 fails. We get more GPLv2 only submissions, which again we can't use. Everybody complained about the CDDL being pointless and divisive, but somehow they think the "or later" clause was universally adopted and thus this doesn't apply to GPLv3. Apparently they weren't paying attention when Linus Torvalds made it clear SIX YEARS ago that the "or later" clause had never applied to the Linux kernel in the first place: http://www.uwsg.iu.edu/hypermail/linux/kernel/0009.1/0096.html. And this is a very clear explicit statement which predates the current GPLv3 effort by a number of years. They were hoping to browbeat him into changing his mind (despite the fact he's not the only copyright holder to the kernel, as he himself made clear when the browbeating started: http://lwn.net/Articles/169825/ ). The FSF has also been trying to browbeat other projects that haven't got an "or later" clause into adding one: http://lwn.net/Articles/176582/ And so far, the response has been a resounding "meh", with wait and see being as positive as it gets. GPLv2 is not going away. There's no reason for it to. So what exactly is the purpose of GPLv3? Rob -- Never bet against the cheap plastic solution." LMAO! regards, alexander. P.S. "I'm insufficiently motivated to go set up a GNU/Linux system so that I can do the builds." Hyman Rosen <hyro...@mail.com> The Silliest GPL 'Advocate' P.P.S. "Of course correlation implies causation! Without this fundamental principle, no science would ever make any progress." Hyman Rosen <hyro...@mail.com> The Silliest GPL 'Advocate' -- http://gng.z505.com/index.htm (GNG is a derecursive recursive derecursion which pwns GNU since it can be infinitely looped as GNGNGNGNG...NGNGNG... and can be said backwards too, whereas GNU cannot.) _______________________________________________ gnu-misc-discuss mailing list gnu-misc-discuss@gnu.org http://lists.gnu.org/mailman/listinfo/gnu-misc-discuss
