2008/10/13 Tito <[EMAIL PROTECTED]>: > On Monday 13 October 2008 20:31:08 Roberto A. Foglietta wrote: >> 2008/10/13 Neil Williams <[EMAIL PROTECTED]>: >> > 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 _______________________________________________ busybox mailing list [email protected] http://busybox.net/cgi-bin/mailman/listinfo/busybox
