Re: Classpath Licensing
On Thursday, February 6, 2003, at 12:30 PM, Noel J. Bergman wrote: I believe Classpath has a special exception for distribution, but, AIUI, that isn't typical of FSF packages. I agree. The only issue for me is whether or not the Classpath packages are a suitable special case that we can use. The answer is no. Look, this should be clear from the license text. The exception refers to the effect of linking done by the Classpath code, which is a neutral third-party. The exception is to allow the neutral third-party (GPL code) to cause other object code to be combined without altering the license of that object code. It does not make an exception to any direct use of the GPL code itself, such as if some part of our code did an import of one of the classes within the GPL library. As to the rest, you have a valid point that the FSF holds a copyright on the code. However, Nic is entitled to multi-license his own code (not all of Classpath, but I was specifically thinking of his implementation of JavaMail and Chris' implementations of JavaMail handlers), and thus it seems that their representation would have effect. Nic just repeated what the license says. It has no relevance to a situation where one java app/library imports from an LGPL class. Personally, I'd prefer for them to license their source under the ASF license, but as long as we can use their binaries, that suffices. We can *use* their binaries. We cannot introduce features that depend only on their binaries (or their source code, for that matter). Doing so restricts the distribution of our entire product to LGPL or GPL, which is why it is forbidden within the ASF. If the developer dual-licenses the code in a form that is non-viral, such as the Apache or MPL 1.1 licenses, then we can depend on it. Roy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Classpath Licensing
On Thursday, February 6, 2003, at 12:30 PM, Noel J. Bergman wrote: I believe Classpath has a special exception for distribution, but, AIUI, that isn't typical of FSF packages. I agree. The only issue for me is whether or not the Classpath packages are a suitable special case that we can use. The answer is no. Look, this should be clear from the license text. The exception refers to the effect of linking done by the Classpath code, which is a neutral third-party. The exception is to allow the neutral third-party (GPL code) to cause other object code to be combined without altering the license of that object code. It does not make an exception to any direct use of the GPL code itself, such as if some part of our code did an import of one of the classes within the GPL library. As to the rest, you have a valid point that the FSF holds a copyright on the code. However, Nic is entitled to multi-license his own code (not all of Classpath, but I was specifically thinking of his implementation of JavaMail and Chris' implementations of JavaMail handlers), and thus it seems that their representation would have effect. Nic just repeated what the license says. It has no relevance to a situation where one java app/library imports from an LGPL class. Personally, I'd prefer for them to license their source under the ASF license, but as long as we can use their binaries, that suffices. We can *use* their binaries. We cannot introduce features that depend only on their binaries (or their source code, for that matter). Doing so restricts the distribution of our entire product to LGPL or GPL, which is why it is forbidden within the ASF. If the developer dual-licenses the code in a form that is non-viral, such as the Apache or MPL 1.1 licenses, then we can depend on it. I see perfectly the point. One of the distinguishing (positioning) features of the ASF is that it allows us (at least me, I suspect many of us) to work with clients using the Apache code base, without forcing them to free our modifications to the source code. While I try to encourage contributing back from my customers, I'm not always able to get the message through. Some times it is due to the changes revealing Business processes that they don't want to show. Most of the times it is because they (mistakenly) believe that their modifications give them a competitive advantage. I make my life, at least bug are found and they always allow me to contribute back small patches in core tools. I would not be able to use GPL code in such contexts, or it would be far more difficult, if I arrived with code that forced restrictions upon them. Given that the position of knowledgeable people seems to be that LGPL + original interfaces = derivative work (which I half agree), I understand and support the ASF policies regarding the subject. My small +1 ;-) Regards, Santiago Roy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Classpath Licensing
Nic, Thank you for the explanation. I am cc'ing others to pass on your explanation. Hopefully this can put a few of the licensing concerns in these specific cases to rest, but if there is a need for any further clarification required, I hope that the ASF Board will contact you directly as necessary. -- Noel -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Nic Ferrier Sent: Thursday, February 06, 2003 4:44 To: Noel J. Bergman Cc: Chris Burdess Subject: Re: Classpath Licensing Noel J. Bergman [EMAIL PROTECTED] writes: Serge: The Classpath author adds an addendum to allow bundling of this library into an executable, but that still won't allow us to distribute jars in CVS or downloadable with source builds (never mind Java doesn't have executables). ibiblio would still be in violation of the license, as would CVSWeb, CVS, and anything that allowed these Jars to be downloaded independently. This is not correct. The exception allows Apache (or any) code to object link to ClasspathX code. Distributing the jar file is not a problem. Noel said: By the way, if you are curious about the LGPL, I understand that one of the problems with the LGPL is this clause: When a work that uses the Library uses material from a header file that is part of the Library, the object code for the work may be a derivative work of the Library even though the source code is not. Whether this is true is especially significant if the work can be linked without the Library, or if the work is itself a library. The threshold for this to be true is not precisely defined by law. Because the FSF has thus far declined to clarify the picture for Java, the preceding clause is interpreted that simply an import could be construed to contaminate the importing class. The FSF is clear on the issue. You can object link LGPLed Java with other code without special permission. This is because there is no textual inclusion. The GPL+exception btw is well understood on this side of the fence because it is the licence Guile has used for many years to protect the source code but not preventing linking to other code. Nic - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Classpath Licensing
Noel J. Bergman [EMAIL PROTECTED] writes: Nic, Thank you for the explanation. I am cc'ing others to pass on your explanation. Hopefully this can put a few of the licensing concerns in these specific cases to rest, but if there is a need for any further clarification required, I hope that the ASF Board will contact you directly as necessary. Ok Noel. I don't mind peope coming to me with direct questions but I'd rather not get involved in the general discussion because: 1. I'm not a lawyer, you should talk to Eben or to rms if you need 100% lawyer proof stuff 2. discussions like this have a tendancy to go nowhere in particular. Nic - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
