Busybox under closed-source-license avaiable?

[Rob Landley]

On Sunday 12 October 2008 11:06:37 Roberto A. Foglietta wrote:
> 2008/10/12 Neil Williams <codehelp at debian.org>:
> > On Sun, 2008-10-12 at 16:25 +0200, Roberto A. Foglietta wrote:
> >> 2008/10/12 Denys Vlasenko <vda.linux at googlemail.com>:
> >> > 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 
gpl at busybox.net 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