RE: Initial Developer's Public License
Lawrence E. Rosen wrote: [...] Courts don't issue advisory opinions. ... Okay. For the sake of any possible benefit to anyone else who cares, here's some stuff that I think is rather interesting (and highly entertaining ;-) ) reading. Note: follow the links/see the entire context. A) http://tinyurl.com/2f96c quote I hate to have to play this role with a fellow hacker, but... If you don't change to using the GPL, then you'll have to stop using readline. Readline's terms say that the whole program has to be under the GPL, and just having the user do the link doesn't change this. If the program is designed to run with readline as a part, then readline is a part of it. [...] The FSF position would be that this is still one program, which has only been disguised as two. The reason it is still one program is that the one part clearly shows the intention for incorporation of the other part. I say this based on discussions I had with our lawyer long ago. The issue first arose when NeXT proposed to distribute a modified GCC in two parts and let the user link them. Jobs asked me whether this was lawful. It seemed to me at the time that it was, following reasoning like what you are using; but since the result was very undesirable for free software, I said I would have to ask the lawyer. What the lawyer said surprised me; he said that judges would consider such schemes to be subterfuges and would be very harsh toward them. He said a judge would ask whether it is really one program, rather than how it is labeled. /quote B) http://tinyurl.com/2syev quote RMS: We have no say in what is considered a derivative work. That is a matter of copyright law, decided by courts. When copyright law holds that a certain thing is not a derivative of our work, then our license for that work does not apply to it. Whatever our licenses say, they are operative only for works that are derivative of our code. /quote C) http://tinyurl.com/33na5 quote Feel free to post/add this. I wrote it some time ago for a corporate lawyer who wondered what the GPL exception was. Names and companies removed not because I think they are ashamed, but because I don't want people to read too much into them. Linus /quote D) http://www.oksid.ch/license/rms.html quote Here is a copy of a discussion that I had with RMS about the GPL. This was a private discussion, because RMS has rejected my proposal to talk about it on gnu.misc.discuss. That's the reason why I have removed all RMS's answers. [...] Hello, I would like to have your opinion about this article : http://www.linuxjournal.com/article.php?sid=6366 The official FSF's opinion is OSI is wrong. Do you have a personal opinion about that ? Maybe can we talk about it on gnu.misc.discuss ? [...] Does it mean that all Solaris programs are copyrighted by SUN ? Line removed Line removed Line removed Line removed You confirm what I'm thinking : you don't have any valid arguments. /quote regards, alexander. -- license-discuss archive is at http://crynwr.com/cgi-bin/ezmlm-cgi?3
RE: Initial Developer's Public License
Ann W. Harrison wrote: [...] In this example, the commercial tool would probably be a single executable and not a set of libraries or plug-ins. To my understanding, that's similar to a User's Guide to Version 9 based on, extending and correcting the Guide for Version 8. To my uneducated understanding, that's similar to http://www.amazon.com/exec/obidos/ASIN/0387954015 To me, this book is a mere aggregation of papers/works with some glue (start up code, etc ;-) ). Aggregation doesn't make this whole book [just like the executable] a derivative work of its components. I tend to think that executables are like Java JARs (JARs are simple archives of java classes files and any other data stuff). I just can't see how a copyright in one Java class can affect other classes (even if something is inherited/composed/linked with the other(s)). regards, alexander. P.S. You might want to take a look at the CPL FAQ (Q15 and Q19). Eclipe.org legal FAQ is also worth reading. -- license-discuss archive is at http://crynwr.com/cgi-bin/ezmlm-cgi?3
RE: Initial Developer's Public License
Err. Eclipe.org legal FAQ I meant http://www.eclipse.org/legal/legalfaq.html. To: Ann W. Harrison [EMAIL PROTECTED] cc: [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED] Subject:RE: Initial Developer's Public License Ann W. Harrison wrote: [...] In this example, the commercial tool would probably be a single executable and not a set of libraries or plug-ins. To my understanding, that's similar to a User's Guide to Version 9 based on, extending and correcting the Guide for Version 8. To my uneducated understanding, that's similar to http://www.amazon.com/exec/obidos/ASIN/0387954015 To me, this book is a mere aggregation of papers/works with some glue (start up code, etc ;-) ). Aggregation doesn't make this whole book [just like the executable] a derivative work of its components. I tend to think that executables are like Java JARs (JARs are simple archives of java classes files and any other data stuff). I just can't see how a copyright in one Java class can affect other classes (even if something is inherited/composed/linked with the other(s)). regards, alexander. P.S. You might want to take a look at the CPL FAQ (Q15 and Q19). Eclipe.org legal FAQ is also worth reading. -- license-discuss archive is at http://crynwr.com/cgi-bin/ezmlm-cgi?3 -- license-discuss archive is at http://crynwr.com/cgi-bin/ezmlm-cgi?3
Re: Initial Developer's Public License
Alexander Terekhov scripsit: To my uneducated understanding, that's similar to http://www.amazon.com/exec/obidos/ASIN/0387954015 To me, this book is a mere aggregation of papers/works with some glue (start up code, etc ;-) ). Aggregation doesn't make this whole book [just like the executable] a derivative work of its components. Indeed, it's plainly a collective work. I tend to think that executables are like Java JARs (JARs are simple archives of java classes files and any other data stuff). I just can't see how a copyright in one Java class can affect other classes (even if something is inherited/composed/linked with the other(s)). Presumably object code is a derivative of source code, however, and so a JAR file, while it is a collective work with respect to bytecode, is a collection of derivative works with respect to source code. Native executables aren't simply collections, however; linkers break up and redistribute the individual object files into different regions of the executable. -- There is / One art John Cowan [EMAIL PROTECTED] No more / No less http://www.reutershealth.com To do / All things http://www.ccil.org/~cowan With art- / Lessness -- Piet Hein -- license-discuss archive is at http://crynwr.com/cgi-bin/ezmlm-cgi?3
Re: Initial Developer's Public License
John Cowan wrote: [...] Native executables aren't simply collections, however; linkers break up and redistribute the individual object files into different regions of the executable. Do you seriously believe that such details/linking analysis [whether this or that linker redistributes the individual object files into different regions, etc.] matters? C'mon, RMS is right: it makes no difference whether linking is static or dynamic. Neither constitutes creation of derivative work, I think/hope. I may be wrong, of course. regards, alexander. -- license-discuss archive is at http://crynwr.com/cgi-bin/ezmlm-cgi?3
Re: Initial Developer's Public License
Alexander Terekhov scripsit: The resulting *compilation* is copyrightable. I think the distinction compilation-vs-derivative is rather obvious. Whereas I think the distinction is very subtle and full of borderline cases, of which the native executable is just one. First thing you learn when you're in a lawin' family is that there ain't any definite answers to anything. --Harper Lee, _To Kill A Mockingbird_ -- Well, I'm back. --SamJohn Cowan [EMAIL PROTECTED] -- license-discuss archive is at http://crynwr.com/cgi-bin/ezmlm-cgi?3
Re: Initial Developer's Public License
Alexander Terekhov [EMAIL PROTECTED] writes: John Cowan wrote: [...] Native executables aren't simply collections, however; linkers break up and redistribute the individual object files into different regions of the executable. Do you seriously believe that such details/linking analysis [whether this or that linker redistributes the individual object files into different regions, etc.] matters? C'mon, RMS is right: it makes no difference whether linking is static or dynamic. Neither constitutes creation of derivative work, I think/hope. I may be wrong, of course. All static linkers not only break up the individual object files and scatter them into different regions where they are merged with other objects, they also modify the objects as they are distributed based on the contents of the other objects included in the link. I think it is a pretty big stretch to say that static linking does not produce a derivative work of the objects included in the link. The original work is clearly identifiable in the resulting executable, and it can not be removed without leaving many traces behind. Ian -- license-discuss archive is at http://crynwr.com/cgi-bin/ezmlm-cgi?3
Re: Initial Developer's Public License
Ian Lance Taylor wrote: [...] I think it is a pretty big stretch to say that static linking does not produce a derivative work of the objects included in the link. ... With all those $$ legal funds to protect open source of lately, I just wonder whether the time is right for some vendor-neutral organization to bring the issue of linking into court. It could be a friendly, relatively-inexpensive summary judgment action, oder? Just an idea. regards, alexander. -- license-discuss archive is at http://crynwr.com/cgi-bin/ezmlm-cgi?3
Re: Initial Developer's Public License
Alexander Terekhov [EMAIL PROTECTED] writes: Ian Lance Taylor wrote: [...] I think it is a pretty big stretch to say that static linking does not produce a derivative work of the objects included in the link. ... With all those $$ legal funds to protect open source of lately, I just wonder whether the time is right for some vendor-neutral organization to bring the issue of linking into court. It could be a friendly, relatively-inexpensive summary judgment action, oder? Just an idea. Who would benefit from taking such an action? For a free software organization, the upside is minimal, and the downside is severe. Ian -- license-discuss archive is at http://crynwr.com/cgi-bin/ezmlm-cgi?3
Re: Initial Developer's Public License
Ian Lance Taylor wrote: [...] Who would benefit from taking such an action? The Global Economy, of course. For a free software organization, the upside is minimal, and the downside is severe. Really? I see nothing wrong if a free software organization would have to adopt some EULA (to restrict the use of free software). My, what a mess. regards, alexander. -- license-discuss archive is at http://crynwr.com/cgi-bin/ezmlm-cgi?3
RE: Initial Developer's Public License
With all those $$ legal funds to protect open source of lately, I just wonder whether the time is right for some vendor-neutral organization to bring the issue of linking into court. It could be a friendly, relatively-inexpensive summary judgment action, oder? Just an idea. Courts don't issue advisory opinions. They resolve disputes. The issue of linking under the GPL has never been appropriately presented to a court by parties to a specific dispute, with standing and able to assert one or more causes of action. /Larry Rosen -- license-discuss archive is at http://crynwr.com/cgi-bin/ezmlm-cgi?3
RE: Initial Developer's Public License
Larry - For what it is worth, I think your analysis is exactly correct. -Rod On Wed, 11 Feb 2004, Lawrence E. Rosen wrote: Here are two examples that I think would not be allowed under OSL which are allowed under IDPL. A commercial database repair tool that uses the on disk structure definitions, compression/decompression routines and other parts of the Firebird database code. The repair tool combines that code with proprietary code to discover and repairs corruption. Developers of such a tool would publish the interfaces between the Firebird code and their own code, but would not be compelled to release their product under an open source license. A package for automatically compressing the stored format of the database. The actual compression code could remain proprietary. The developer could sell Firebird in half the space. However the interfaces to the compression code would be published under the IDPL, allowing others to create plug-replaceable compression packages. Ann, As I understand copyright law, the OSL and IDPL have the same effect. I don't see the plug-in applications you described as creating derivative works, except for the modifications you have to make to the Firebird code itself to plug-in those modules to those API interfaces. The changes to Firebird code would have to be distributed under the OSL, but only those changes. Licensees could implement other plug-in software to discover and repair corruption or to do compression -- and plug them in the same way. It makes no difference whether the plug-ins are open source or proprietary. This depends, of course, on my analysis of whether the combinations you described are derivative works. I suggested that they aren't, based on your brief descriptions. (Please don't draw specific legal conclusions from my preliminary read of your software architecture; I disclaim anything you might interpret as advice!) I gather your product is designed to work with independently-created and independently-owned plug-ins. If so, how does your simply linking to those plug-ins (or from those plug-ins to you) cause them to be brought under the terms of the OSL? A licensor under the OSL has no right to do that. No open source license can prohibit any licensee from creating proprietary combinations of independently-created proprietary and open source software that merely work together through APIs. Such combinations are not derivative works of software. Does anyone on this list disagree with that conclusion? If so, what factors about derivative works analysis in the software context am I forgetting that are relevant to Ann's brief examples? /Larry Rosen -- license-discuss archive is at http://crynwr.com/cgi-bin/ezmlm-cgi?3 -- license-discuss archive is at http://crynwr.com/cgi-bin/ezmlm-cgi?3
RE: Initial Developer's Public License
I had described A commercial database repair tool ...parts of the Firebird database code.. with proprietary code In this example, the commercial tool would probably be a single executable and not a set of libraries or plug-ins. To my understanding, that's similar to a User's Guide to Version 9 based on, extending and correcting the Guide for Version 8. Please don't draw specific legal conclusions from my preliminary read of your software architecture I greatly appreciate your time and consideration ... with no liability attached ;) I gather your product is designed to work with independently-created and independently-owned plug-ins. Not particularly, though that's a general direction that software appears to be moving. Primarily, it's used with client applications that need transaction-based data storage. We would like to allow others to build tools around the package like the database repair tool I suggested. Again, thank you for your efforts to educate the unenlightened. Sincerely, Ann -- license-discuss archive is at http://crynwr.com/cgi-bin/ezmlm-cgi?3
