** Mark Rafn :: > On Wed, 7 Sep 2005, Joe Smith wrote: > > > It is generally belived that the GPL 'derivative' clauses may > > actually be upheld in the case of static libraries. The fact > > that linking the .o's of the library directly with your program > > is equivelent to linking the library with the object files of > > your program, seems to verify this. The question still debated > > is whether Shared libraries are like this also. > > I haven't heard it debated very hotly in recent memory. General > acceptance seems to be that it applies equally to static and > dynamic linking. Dynamic linking DOES open up the possibility of > distributing the using code and not distributing the library > itself. The combination of the two may be un-distributable, > however.
One of two apply: either both Michael K. Edwards and I are in your killfile OR you haven't payed a lot of attention lately. My (and his) argument goes more or less like this: 1. GPL section 0 defines the expression "a work based on the Program", which will be used in the rest of the license as being "either the Program or any derivative work under copyright law"; after that, it paraphrases (separating the explanation with a colon) trying to explain what a derivative work is under copyright law, and failing, because it says "that is to say, a work containing the Program or a portion of it, either verbatim or with modifications and/or translated into another language." which is blatantly false, because the definition of a derivative work is "the work that results on an intellectually-novel transformation over the original work." 1.1. this leads me to the conclusion that (1) above defines "a work based on the Program" as a synonym for "a derivative work of the Program (or the Program itself)". 2. GPL section 0, paragraph 1 states that "Activities other than copying, distribution and modification are not covered by this License; they are outside its scope. The act of running the Program is not restricted". Hold on to your hats and I'll mention this later. 3. GPL section 2, paragraph 3 states that "mere aggregation of another work not based on the Program with the Program (or with a work based on the Program) on a volume of a storage or distribution medium does not bring the other work under the scope of this License." 3.1. this leads me to the conclusion that, even if at some point in time (run-time) the works (GPL-incompatible library and GPLd program, for instance) will be combined to form interdependent chunks of computer memory, as the program is NOT a derivative work of the library nor vice-versa, distributing in the same CD, website, or whatever both the program package and the library package will invoke section 2 paragraph 3, because they are not interdependent in the moment of the distribution. 3.2. and, in the light of (2) above, this is even not contributory infringement, because the GPL section 0 paragraph 1 _explicitly_ licenses the final user to do what he needs to _use_ the program. 3.3. it seems to me that it's absurd to think, for instance, that Debian cannot dynamic link a GPLd program with OpenSSL. Why? Because if I write a completely-compatible MassaSSL library and install it in my system just in the same places/names/sonames/whatever OpenSSL is installed, this would change the copyright status of _the_ _program_!! Because of the argument above, I don't think the combination of the two would be undistributable at all. Why is all that different in the case of static linking? Because in the case of static linking, the "intermingled" executable can be considered (altough I don't think so) "not merely aggregated", as the fixups are already resolved, etc, etc. > > > The linux kernel 'copying' file states this: NOTE! This > > copyright does *not* cover user programs that use kernel > > services by normal system calls - this is merely considered > > normal use of the kernel, and does *not* fall under the heading > > of "derived work". If that statement is true and if it does not > > qualify as a licence exception, then the following argument > > would hold: > > I think this is a license exception (or at least a clarification > that applies specifically to this work). It is not a statement > about GPL-licensed work in general. In this, you are right. > > > NOTE! The GPL does *not* cover programs that use shared > > library services by normal function calls - this is merely > > considered normal use of the shared library, and does *not* > > fall under the heading of "derived work". > > The copyright holder of a given library would have to make that > statement for the library in question for it to apply. Agreed. -- HTH, Massa -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
