Usual disclaimers apply. I am not a lawyer. This is not legal advice. Micha Feigin wrote: > On Wed, 13 Dec 2006 13:26:46 +0200 > Shachar Shemesh <[EMAIL PROTECTED]> wrote: > > >> They manage 1 and 2, they have a very good case for claiming that the >> userspace tool is not a derived work of their kernel space driver, and >> thus not bound by the kernel module's license. >> >> Shachar >> > > This goes into another legal question, at what point does "uses" becomes > "derived work". > > For example, if I have a program that uses a GPL library, but could just as > well have used a LGPL of non-free library, possibly with a slight api change, > is > it derived work or not? > I'm assuming here that all three libraries have the same interface. In other words, they export exactly the same functions, named the same, and having the same semantics, so that replacing one with the other is, at worst, a case of recompilation with no code changes.
The FSF would have you believe that this is derived work. As I have stated many times in the past, I don't buy this. The ultimate counter example I can give is Wine. The simple fact of the matter is that NOTHING will cause MS Word to become derived work of Wine. I think we would all agree that it doesn't matter what the Wine license might be, nor that any Windows program running under wine is, in fact, dynamically linking to it. If three different implementations provide the same interface, it's fairly obvious that your program depends on the interface, rather than on the implementation of the libraries. If that is the case, it's pretty clear to me that you cannot claim that your program is derived from the library, and thus the library's license does not affect you. As I stated above, the FSF have a pretty different view, but I actually that this view is self contradicting. For reasons why, check out the license for a program called "rsyncrypto" (this is not someone else supporting my view, as I wrote rsyncrypto. This is merely me being lazy re-typing what I said there) - http://rsyncrypto.svn.sourceforge.net/viewvc/rsyncrypto/trunk/COPYING?revision=174&view=markup. > (I have a debate of which mathematical libraries to use at the moment). > If they are not of identical interfaces, and you cannot have your own program be GPL, everything else being equal, I'd go with the LGPL version. > If I spilt the API into a module and bundle one that works with the GPL code > and one with the non-GPL code thus giving the option for both of them, does > that matter? > To my thinking - yes. If you create an interface that is independent of the implementation, no-one using that interface can be said to be derived work of the implementation. Yes, that does mean that the GPL isn't as strong as we may hope/wish it to be. This is, I think, a direct result of it being a *copyright* license. When the copyright protection ends - so does the GPL protection. Shachar -- Shachar Shemesh Lingnu Open Source Consulting ltd. Have you backed up today's work? http://www.lingnu.com/backup.html ================================================================= 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]
