On Mon, 13 Oct 2008 20:31:08 +0200 "Roberto A. Foglietta" <[EMAIL PROTECTED]> wrote:
> > 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. > > > > 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? You cannot have a single licence that is dual-licence GPL and proprietary, you have TWO licences. The files must specify which licence is in use. The proprietary code won't make the header files public so how is this a problem? The GPL code is in use. > 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)? Nonsense. Logically incoherent. You keep thinking that you can mix proprietary and GPL - you cannot. > 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. Huh? If the library is used with GPL code, the GPL headers are used. The copyright of the files included specifies the licence of the executable created from the compilation process. Use the proprietary headers, create a proprietary executable - the executable cannot be GPL because it includes software that is incompatible with the GPL and cannot be released as free software. If you create a free software executable, you cannot use the proprietary headers because you must release the complete source code. > Running code depend on what is installed on the system BEFORE > application has been called. ? This makes no sense. You cannot include GPL code into proprietary code, you cannot include proprietary code into GPL code. > In addition who compile the application > could have no any relationship with who run the software and with who > have installed the system. Relationships don't matter - what matters is the licence of the code being used. If I compile the code for Debian, I'll be using the GPL code. It is what happens at compilation that determines whether the resulting executable can be distributed. > 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? Sorry, your translation of your ideas has made the final text almost incomprehensible. Proprietary code cannot be linked against GPL code, no matter how you try to wiggle out of it. -- Neil Williams ============= http://www.data-freedom.org/ http://www.nosoftwarepatents.com/ http://www.linux.codehelp.co.uk/
pgpflviZ1af2Z.pgp
Description: PGP signature
_______________________________________________ busybox mailing list [email protected] http://busybox.net/cgi-bin/mailman/listinfo/busybox
