Re: primary distribution location
On Wed, 5 Feb 2003, Conor MacNeill wrote: Noel J. Bergman wrote: Conor, I expect that people are worried about the viral implications of LGPL, I'm worried about it :) If it's LGPL, I can use it at work, but I can't release any code that imports from the LGPL'd jar. And with RMS' 99 article: http://www.fsf.org/licenses/why-not-lgpl.html It would seem that it is not in the FSF' interest to clarify the LGPL as far as it applies to Java as they/he only want the LGPL to be used in certain strategic cases. We're trying to get alternate licensing from any LGPL code. So far we haven't had too much of a problem getting such licenses, but we'll see. How about side-stepping the issue entirely and organising some kind of collation of projects on sourceforge/ibiblio, or even if lgpl is the main problem, setting up a project at savannah to host all the lgpl plugins to asf licenced works? Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: primary distribution location
Can I explore the issue a little bit further? The question that usually arises on Ant is not the storing and distribution of LGPL code itself, but the storing of code that links with or depends on the LGPL code. As an example, let's say we want to provide an SSH task for Ant (a recent question). There are a number of LGPL SSH java libraries around. The code in our respository would be developed under the ASF licence - it would consist of a Java class that merely drives the LGPL library. It will typically have import statements - something like: import lgpl.sshlibrary.Thingy; This code cannot be compiled without the LGPL library. Once compiled. however, it can be distributed without the library. To use the task code a user needs to supply the LGPL library independently. So can the above code be stored in our repository? Can the compiled code be included in a binary distribution? The import statement alone is sufficient to make the source code a work based on the Library, which means we could distribute under the terms of section 6. Those terms are viral and disallow binary-only releases, making our product viral because the Apache license does not require redistribution of source with executables. In short, the answer is no, and this applies to any software with copyright of The Apache Software Foundation. Roy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: primary distribution location
On Wed, 5 Feb 2003, Martin van den Bemt [EMAIL PROTECTED] wrote: There is a way around all this if you write an interface that is used to be generic, and have the interface implementation stored elsewhere. But the interface implementation would have to be LGPLed again, so you don't really win anything. Stefan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: primary distribution location
You do win.. You don't have to have the direct implementation in apache cvs and ask if the eg gpl'ed software would include an implementation of that in their distro's. (who doesn't want an ant task for use with their software) Another thing that can be done (and is GPL legal so to say) is make an exception for certain projects. That has to be stated in the license however, which in my opinion is even better and this way the implementation can live in cvs. So the project concerning can just add Apache Ant can make direct use of our library without having to redistribute their code under the terms of section 6 (quoting Roy on the last part). (read the complete gpl pages a couple of days ago and above seems possible) Maybe Roy can comment on above however. If we can have one way to approach these kinds of siutation (eg always ask for exclusing of terms 6 in the license) and if not look for an alternative approach, that would make it a very clear way of doing things and make sure Apache doesn't get in legal trouble. Mvgr, Martin I am public domain and compatible with apache -Original Message- From: Stefan Bodewig [mailto:[EMAIL PROTECTED] Sent: Wednesday, February 05, 2003 09:35 To: community@apache.org Subject: Re: primary distribution location On Wed, 5 Feb 2003, Martin van den Bemt [EMAIL PROTECTED] wrote: There is a way around all this if you write an interface that is used to be generic, and have the interface implementation stored elsewhere. But the interface implementation would have to be LGPLed again, so you don't really win anything. Stefan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: primary distribution location
On Wed, 5 Feb 2003, Martin van den Bemt [EMAIL PROTECTED] wrote: You do win.. You don't have to have the direct implementation in apache cvs and ask if the eg gpl'ed software would include an implementation of that in their distro's. OK, the interface is there, Ant's Task class. I'm just a bit kidding here. Point is that people want to see an SSH task in Ant but all suitable libraries seem to be LGPLed (or worse). We have already suggested that these libraries ship with tasks of their own. Adding some SSH library abstraction to Ant wouldn't make live easier for the libary developers IMHO. So in this particular situation, you don't gain anything. In a broader context, the strategy you describe may help, I agree. So the project concerning can just add Apache Ant can make direct use of our library without having to redistribute their code under the terms of section 6 Sure. Or they could simply switch to a better license directly 8-) Stefan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: primary distribution location
It will typically have import statements - something like: import lgpl.sshlibrary.Thingy; The import statement alone is sufficient to make the source code a work based on the Library, which means we could distribute under the terms of section 6. Those terms are viral and disallow binary-only releases, making our product viral because the Apache license does not require redistribution of source with executables. Thank you very much for this explanation. It should help explain to authors why we are asking them to provide their LGPL code under a different open source license. Many believe that LGPL works differently than you've explained. Not to put too fine a point on this, but just to understand. A number of Java packages, such as JNDI and JavaMail, completely decouple the client code from the service provider. There is no source connection whatsoever between the client code and a service providing jar. In fact, there is no direct binary connection. Available service providers are dynamically registered with the intermediary standard technology, e.g., JavaMail. When the client code invokes the intermediary, the intermediary checks its registry, and invokes whichever service provider is handling that particular protocol/resource. The service provider is literally a black box. In that specific situation, what is permissible? --- Noel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: primary distribution location
The import statement alone is sufficient to make the source code a work based on the Library, which means we could distribute under the terms of section 6. Those terms are viral and disallow binary-only releases, making our product viral because the Apache license does not require redistribution of source with executables. In short, the answer is no, and this applies to any software with copyright of The Apache Software Foundation. Roy, I'm trying hard to understand. I went into section 6 of http://www.gnu.org/copyleft/lesser.html, and suppose you are referring to one of the 5 conditions (a-e) in that clause which we cannot comply with. No, I am referring to the first paragraph, which states 6. As an exception to the Sections above, you may also combine or link a work that uses the Library with the Library to produce a work containing portions of the Library, and distribute that work under terms of your choice, provided that the terms permit modification of the work for the customer's own use and reverse engineering for debugging such modifications. which is okay for the ASF, but not okay for all of the people who redistribute ASF software as parts of other projects. That is why this is not an issue of legality -- it is an issue of policy. The ASF policy is to not use LGPL code in any of our projects. Roy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: primary distribution location
On Wed, 5 Feb 2003, Noel J. Bergman wrote: Thank you very much for this explanation. It should help explain to authors why we are asking them to provide their LGPL code under a different open source license. Bear in mind that although, i.e the ASF, may be allowed to do so and distribute it from our site; the people on the receiving end are -not- allowed to pass that what they got from us on to anyone else. Or in other words; we are no longer in the land of legal black-and-whites; but we are now talking about policy. How inportant is it for us that when you get soome code from the ASF, in any way shape or for, you are then allowed to give it to anyone else without further thoughd or requirements. And the ASF has always considered that crucial. Many believe that LGPL works differently than you've explained. Again - we are no talking policy and no longer do/cannot-do from a license perspective anymore. Those who believe so generally do not look at the redistribution in the second or third step. I personally think it is important to look at that. For ideologic reasons; I want it to be as easy and unencumbered as possible, and for pragmatic reasons; what happens if some (source) code is lost, if a URL dies. Dw - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: primary distribution location
On Wed, 5 Feb 2003, Noel J. Bergman wrote: It will typically have import statements - something like: import lgpl.sshlibrary.Thingy; Thank you very much for this explanation. It should help explain to authors why we are asking them to provide their LGPL code under a different open source license. Many believe that LGPL works differently than you've explained. They're wrong :) Or at least, not right yet. Not to put too fine a point on this, but just to understand. A number of Java packages, such as JNDI and JavaMail, completely decouple the client code from the service provider. There is no source connection whatsoever In that specific situation, what is permissible? We could link to their site and recommend downloading their jar? :) Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: primary distribution location
Noel J. Bergman wrote: Not to put too fine a point on this, but just to understand. A number of Java packages, such as JNDI and JavaMail, completely decouple the client code from the service provider. I realize that this is addressing a completely different point, but if you take a look at the license for either JNDI or JavaMail, you will see that item (i) in the second supplimental license term in the Sun Microsystems, Inc. Binary Code License Agreement reads: Sun grants you a non-exclusive, non-transferable, limited license to reproduce and distribute the Software in binary form only, provided that you (i) distribute the Software complete and unmodified and only bundled as part of your Programs This makes the following non-compliant with the license: http://www.ibiblio.org/maven/jndi/jars/ http://www.ibiblio.org/maven/javamail/jars/ The interesting question is: who is liable? - Sam Ruby - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: primary distribution location
Roy T. Fielding wrote: In short, the answer is no, and this applies to any software with copyright of The Apache Software Foundation. which brings up a very good point that may have been overlooked: this applies to anything on ibiblio or elsewhere that is copyright the asf. it does not apply strictly to the repositories on the asf machines, but to the asf *code*. -- #kenP-)} Ken Coar, Sanagendamgagwedweinini http://Golux.Com/coar/ Author, developer, opinionist http://Apache-Server.Com/ Millennium hand and shrimp! - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: primary distribution location
board hat=on in fact, until such time as a clear determination is made, i'm ruling that it is *not* allowed. it is not worth the risk. so lgpl-licensed materials in the asf repositories are forbidden until a final decision is made. /board that may seem heavy-handed and arbitrary; i apologise ahead of time, particularly if i turn out to be wrong. however, i am saying this in good faith and in an attempt to do what's right. i will welcome an official answer no less than anyone else. While I do not want to have a discussion on the matter, I would like to state my preference to have some determination on this matter in the near future. -Andy licenses are stupid and annoying, just play freaking nice Oliver - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
