Busybox under closed-source-license avaiable?

[Tito]

On Monday 13 October 2008 20:31:08 Roberto A. Foglietta wrote:
> 2008/10/13 Neil Williams <codehelp at debian.org>:
> > On Sun, 2008-10-12 at 18:06 +0200, Roberto A. Foglietta wrote:
> >> >> > 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.
> >
> > It is not even logically coherent, IMNSHO. This isn't just about how the
> > library is used at runtime. Using a public shared library involves
> > building against that shared library and this means *including* the
> > source code of that library directly into the program.
> > #include <qpl-header.h>
> > does exactly that - the preprocessor physically includes the entire
> > header file and all header files that it references into the object
> > files being compiled. The header file is copyrighted and licenced under
> > the GPL. The licence forbids the copying of the file and it's contents
> > except under the GPL. If you grep the resulting binary (even after using
> > strip), you will find that elements of that file are retained in the
> > executable - the (copyrighted) names of the symbols that are defined in
> > the GPL library. If that executable is not licenced under the GPL, that
> > contravenes the GPL. Simple. At the compilation stage, the GPL'd code
> > has become a part of the executable at a *physical* level that can be
> > easily identified later.
> >
> > The question is whether the non-free code can exist without the GPL
> > code. If it cannot be built without the GPL code then the GPL code is,
> > by definition, included in the executable - part of the executable, the
> > executable and the library are one program. The mere fact that the
> > object files are split into different files for convenience does not
> > detract from the fact that the symbols from the library are physically
> > part of the executable and therefore that the executable is derived from
> > the library - namely the header files and the definition of the
> > copyrighted symbols contained within. The linking comes later, the
> > problem is the inclusion of the copyrighted symbols and the licence
> > under which those symbols can be used. That is why I said that if the
> > library shows up in 'objdump -p' as NEEDED then the executable must be
> > released under the GPL.
> >
> 
>  However Linux proprietary modules do that! Ok they are tolerate in
> virtue of Linus willing.
> 
>  What happens if a proprietary library come out with some dual-licence
> headers (GPL and proprietary) and a GPL software has been dynamically
> linked against it? If a third-part develop a proprietary library and
> allow GPL code to inherits their symbols should they be forced to
> release the code (a part headers, obviously)?
> 
>  Example. Graphic library came out with dual licence but only headers
> are the same because proprietary one (much more optimized than GPLed)
> could differ in code from GPLed version and still be compatible as API
> level. Running code depend on what is installed on the system BEFORE
> application has been called. In addition who compile the application
> could have no any relationship with who run the software and with who
> have installed the system.

Hi,
as I've understood the problem:

Indipendently of who compiled the code and who runs the code,
the one WHO distributes the binary (mainly for commercial use) has to 
ensure that the requirements of the GPL license are fulfilled:

1) the source code must be available to the end-user
2) linking to non GPL libraries is not allowed.

3) Non GPL kernel modules are tolerated but not well accepted
    in the linux kernel as shown by various code changes
    done to make the life of NON-GPL modules difficult.
    The trend definitely goes towards forbidding them
    or maybe there will be no need for them in a near future.
         
OTOH if you use the code only in-house without distributing it 
to third parties you can link to what you like and keep the code
secret, same if you use it at your home for personal use.
For example you are free as private person to download,
compile and run nvidia kernel modules and you don't
infringe on any requirements of the GPL or to use your example,
you are free to substitute the library linked with a GPL binary
with a non GPL library if you are able to do it. Obviously you cannot
redistribute the result (GPL binary and NON GPL library)
whether dinamically nor statically linked.

Just my 0,2 cents

Ciao,
Tito

 
> I this case is the GPLed code which gains 
> some benefits (running faster) even if running faster ability come out
> not for free (in any sense). In this case the proprietary code could
> exist without the GPLed code and dynamic linking is the bridge between
> the two while static should not works as bridge. Do you think is it
> GPL compliant?
> 
>  Thanks,