Busybox under closed-source-license avaiable?

[Roberto A. Foglietta]

2008/10/13 Tito <farmatito at tiscali.it>:
> 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
>

 Thanks Tito for have got the point.
 Now everything it clear for me.

 Ciao,
-- 
/roberto