Busybox under closed-source-license avaiable?

Roberto A. Foglietta roberto.foglietta at gmail.com
Mon Oct 13 18:31:08 UTC 2008


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. 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,
-- 
/roberto



More information about the busybox mailing list