Shachar Shemesh <[EMAIL PROTECTED]> writes: > Oron Peled wrote: > > >>Its yet to stand up in court though. > >> > > > > >What should stand up in court? The "right" to distribute software > >against its license terms? You must be drinking. > > > >The only thing a court may need to decide is if linking a library > >makes your software a derived work. As I said before, this case > >looks clear enough to most people that even infringing companies > >prefer to release code and not go to court when they get caught. > > > >good day, > > > > Merely linking with a library does not make your software derived work > of that company! How can that be? > > Let's take an example. Suppose Wine is distributed under the GPL (It's > LGPL, but for the sake of discussion). According to your logic, any > program that is built to link against Wine is a derivative work of > Wine, and therefor must be under the GPL. This is patently > absured. Most of the programs that link with Wine never heard of Wine > in their entire life. They were built to link with Win32 API, > expecting Microsoft's version of it. How can a software that never > knew about my program be considered derivative work of it?
I think we should distinguish between the notions of "derivative work" and "must be distributed under GPL". According to the GPL FAQ, if there is a GPLed part (your hypothetical WINE) and a non-GPLed part (M$ Office) that are not "merely aggregated" but "combined into one program" then the whole must be released under GPL. So if you distribute a "M$ Office for Linux" which consists of the M$ binary and a GPLed WINE you are, according to the FSF interpretation, in violation of GPL, because you have designed the WINE libraries to run together with the M$ Office in a shared address space. I suspect this is precisely why WINE is under LGPL. At the same time, no one would say that M$ Office was a derivative work of GPLed WINE for this reason, because M$ Office makes perfect sense without WINE, as you pointed out. To quote GPL: "These requirements apply to the modified work as a whole. If identifiable sections of that work are not derived from the Program, and can be reasonably considered independent and separate works in themselves, then this License, and its terms, do not apply to those sections when you distribute them as separate works. But when you distribute the same sections as part of a whole which is a work based on the Program, the distribution of the whole must be on the terms of this License, whose permissions for other licensees extend to the entire whole, and thus to each and every part regardless of who wrote it." So while M$ Office is clearly independent and not a "derived work", if you distribute it with your GPLed WINE you are in trouble, because the combination of both is a "derived work". It should be noted that the question of whether the above is in fact "combining two modules into one program" or "mere aggregation" is still open and left for judges to decide, cf. http://www.fsf.org/licenses/gpl-faq.html#MereAggregation The distinction that Stallman seems to make is that a function call in a shared address space is a mechanism used within a single program. (He uses "almost surely" for what I think is best represented by shared libraries). Pipes, sockets, command lines etc. are considered mechanisms intended for communication between different programs, and so they don't count. I suspect this is what Linus had in mind when he wrote the part of the kernel's COPYING file regarding modules. -- Oleg Goldshmidt | [EMAIL PROTECTED] ================================================================= To unsubscribe, send mail to [EMAIL PROTECTED] with the word "unsubscribe" in the message body, e.g., run the command echo unsubscribe | mail [EMAIL PROTECTED]
