On Sunday 12 October 2008 11:06:37 Roberto A. Foglietta wrote: > 2008/10/12 Neil Williams <[EMAIL PROTECTED]>: > > On Sun, 2008-10-12 at 16:25 +0200, Roberto A. Foglietta wrote: > >> 2008/10/12 Denys Vlasenko <[EMAIL PROTECTED]>: > >> > On Wednesday 08 October 2008 10:24:32 pm Lin Xbasu wrote: > >> >> Hi, > >> >> > >> >> Can you please tell me, whether it is possible to get a license for > >> >> the busybox to distribute it as object code / executable without > >> >> beeing forced to publish the source code as GPL does? > >> > > >> > I think busybox had many contributors over the years, and it's > >> > virtually impossible to contact them all and convince every single one > >> > of them to agree on this. > >> > > >> > You have to comply with GPL v2. Which is not difficult and costs > >> > nothing. > >> > >> In case you want deliver your specific proprietary command line > >> executable and you would like to keep its size very small then you can > >> compile it linking against busybox library. Remember that GPL allow > >> only dynamic linking, static should enforce GPL redistributions terms > >> and make your application bigger. > > > > Eh? The GPL does not allow dynamic linking against non-free code. Are > > you thinking of the LGPL? > > Thanks very much for your promptly correction. I forgot to say that > the point of view I exposed is NOT the strictly/cautionary one.
Considering that the GPL on busybox _is_ actively enforced these days, and I'm one of the two people in whose name enforcement has happened (last I checked Denys hasn't been maintainer long enough for his code to wind up in the products any suits have been filed about yet, but it'll happen eventually), useful questions to ask might be: 1) What would the maintainers (Erik, myself, and Denys) consider allowable, or at least not worth pursing? 2) What would the SFLC lawyer consider infringement worth filing a lawsuit over? Your personal opinions are not involved in either of those questions. > The problem is > not any more what GNU indicates (we just know) but what various courts > would think about GPL terms application. IMHO it is not decided yet. > > http://www.novell.com/coolsolutions/feature/1532.html 2004 is before the SFLC settled its first lawsuit, and before Novell was bought out by Microsoft. > [citation] > In sum, users of the GPL code are empowered to do pretty much > whatever they want with GPL code, provided that they assert no > proprietary rights to the original code and open source any derivative > works. Untangling the question of what constitutes a derivative work > is the thorniest issue the GPL raises, No, copyright law raises that issue, not the GPL. > and was by far the biggest > roadblock to Linux adoption by the world. Wow, so Microsoft leveraging the installed base of windows systems to prevent preinstalls of _anything_ else on PC systems (OS/2, BeOS, etc) was a smaller roadblock? In the embedded world, the fact uClibc before about version 0.9.26 didn't really work, and busybox's 1.00 release wasn't until October 2004, and the Linux 2.2 and 2.4 kernels being total power hogs for things like Cell phones (you couldn't even shut off the clock interrupt when the system was idle)... Those weren't contributing factors either? The GPL was a bigger problem than Microsoft's Licensing 6? Good to know. > However, as noted, dynamic > linking to GPL code is generally not considered to create a derivative > work. What's trolltech built its business on all this time? (QT is GPL, not LGPL. It's a shared library. Show me the closed source QT applications out there.) http://trolltech.com/products/appdev/licensing/licensing#qt-open-source-license > This is *not* to say that this is the "Right" legal outcome - no > one can know the definitive answer on that matter until a court > settles it I.E. not only are you talking out your ass, but you _know_ you're talking out your ass. > - but it is to argue that general industry practice has > come to view dynamic linking as acceptable. The license on this particular product is being actively enforced by Erik Andersen, myself, and the Software Freedom Law Center. Why not ask [EMAIL PROTECTED] what is and is not allowed, since they're the ones enforcing it? > In the previous link there some good points, for community too, to > have a soften approach to consider dynamic liking acceptable. Busybox is a set of command line utilities. The shared library is purely internal, we've never offered it to the world for use in other projects under other licenses. You seem to be saying that people can lift code from busybox for use in another project and claim that other project is not a derived work of busybox. All projects export stable documented APIs that act as barriers to derived work status. The kernel's always stated that system calls are an API barrier. Shared libraries were fuzzy because of Linus's early statements that some modules could be binary only, and these days the kernel labels many of its module export symbols as "GPL only" to be explicit about _not_ allowing proprietary use of them. That's not a technical "shared vs static" thing, that's the project maintainers expressing their intent about where the edge of their project lies, which is very important in judging derived work status. Back on my watch, Busybox pondered offering zlib exports. I don't think we ever got around to it, but _if_ we did that wouldn't mean the rest of the contents of the library _weren't_ internal to busybox. Heck, you can extend the behavior of a GPL binary a lot with LD_PRELOAD intercepts, ala fakeroot. Or with ptrace things, the way User Mode Linux works. If you added extensive new behavior to an executable that way and claimed your result wasn't GPL even though the executable you'd extended was, and somebody decided to sue claiming that you were insane, you're confident how that suit would go, because it's "dynamic"? > It is not easy for me to understand exactly legal English but the > following link seem to say "yes, dynamic linking with GPL is > acceptable". Ok, I'll bite. Why does the LGPL exist, then? If a suit comes into court and the open source side says "we have two licenses: LGPL was created after the GPL already existed because people brought up the issue of linking proprietary code against shared libraries like glibc, and companies like trolltech made quite a good living for many years getting people to pay for commercial licenses to link proprietary code against qt; if we'd wanted to LGPL it we had could have, but we didn't"... I'm quite happy to ask Denys to _remove_ the shared library capability from busybox if it honestly seemed like having it might undermine our project's ability to enforce the license terms. (Not that I'm saying it does, and I point out it's his call these days, not mine. But is that really the road you want to go down?) Rob _______________________________________________ busybox mailing list [email protected] http://busybox.net/cgi-bin/mailman/listinfo/busybox
