Re: primary distribution location
Costin Manolache wrote: >> >> Where is this policy defined? I'd really like a definitive statement about >> this from someone with the authority to make such a pronouncement :-) > > Good luck... > > Since I doubt this will happen - I'm inclined to just start using LGPL and > force someone to make an official decision ( like force the removal if it > is against a rule, or admit that LGPL is ok by lack of action ). i recommend against pulling the board's beard in that manner. there are other alternatives beyond those you list that you might end up 'forcing.' deliberately tainting the repositories in order to find out if it's allowed might quite possibly result in fairly summary action. this is a *legal* issue; if it is determined that it is not allowable, not only will the offending code be yanked, but a very dim view will be taken of the person endangering the asf's own assets. i urge patience. fwiw, the issue of lgpl-covered code in apache-licensed repositories is not one that is being ignored. but neither is it a simple one that can be solved with an off-the-cuff decision. 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. 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. -- #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
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. 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]
Re: primary distribution location
On Tue, 4 Feb 2003, Andrew C. Oliver wrote: > > > > > > 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. That's fine with me - a "no" is better than ambiguity. Does the same policy apply to JCP, Sun, IBM, etc licenses - i.e. not allowed unless a board decision to allow is made ? Or is it only for LGPL? Or more clearly - is there a list of licenses that the board approved ? BTW, I agree that "not allowed unless specifically permited" is a good policy regarding licenses, and I'm glad someone finally stated this with the board hat on ( even if only for LGPL - but that's a start :-) Costin > > > >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. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: primary distribution location
Rodent of Unusual Size wrote: 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. 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. Ken, that's great. It's good to have a definitive statement so when the question comes up, as it invariably does, I can be confident in the answer. 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? I'm not trying to split hairs here - these are very common questions in Ant task development. To date we have said that LGPL linking tasks cannot be committed to CVS - we generally suggest that the LGPL library develop and host the task code (whether their linkage to ASF licensed code breaks their licence is then a problem for them :-) ) The following thread is a good example of this sort of discussion: http://marc.theaimsgroup.com/?t=10383359585&r=1&w=2 Thanks Conor - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: primary distribution location
Conor, I expect that people are worried about the viral implications of LGPL, although I am not sure how that applies with a jar. One of the long standing issues with the FSF licenses is how to apply them in a Java environment. 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. --- Noel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: primary distribution location
Noel J. Bergman wrote: Conor, I expect that people are worried about the viral implications of LGPL, although I am not sure how that applies with a jar. One of the long standing issues with the FSF licenses is how to apply them in a Java environment. Totally agree. I'm OK if the answer is "No, you can't have code that links to LGPL in ASF CVS". As I said on the Ant list, LGPL is written using C-think (headers, object code, etc). It is not clear how to interpret this in a Java context, especially when the LGPL itself is fuzzy about some things. For example, when talking about whether code which links to LGPL becomes a derivative work it says "The threshold for this to be true is not precisely defined by law." 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. If you look at this message, http://marc.theaimsgroup.com/?l=ant-dev&m=104393719401495&w=2 from the thread I mentioned, you'll see that this is not always forthcoming. I certainly respect their right to stick to the licence of their choice. Conor - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
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
Henri Yandell wrote: 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? ... which was one of the suggestions at the start of this discussion when it popped up on infrastructure@ ;) IMHO, it looks like Maven, Centipede and Ted already have parts of the solution, so let's have a look at how we can combine all this and come up with something, also on the repository side. Dirk suggested to look at FreeBDS ports also for inspiration. -- Steven Noelshttp://outerthought.org/ Outerthought - Open Source, Java & XML Competence Support Center Read my weblog athttp://blogs.cocoondev.org/stevenn/ stevenn at outerthought.orgstevenn at apache.org - 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
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. No direct calls in the code to the stuff, just a jar dependency (assuming that is allowed though).. It's not making distribution easier, but can get around some problems. Mvgr, Martin > -Original Message- > From: Conor MacNeill [mailto:[EMAIL PROTECTED] > Sent: Wednesday, February 05, 2003 01:01 > To: community@apache.org > Subject: Re: primary distribution location > > > Rodent of Unusual Size wrote: > > > > 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. > > > > 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. > > Ken, that's great. It's good to have a definitive statement so when the > question comes up, as it invariably does, I can be confident in > the answer. > > 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? > > I'm not trying to split hairs here - these are very common > questions in Ant > task development. To date we have said that LGPL linking tasks cannot be > committed to CVS - we generally suggest that the LGPL library develop and > host the task code (whether their linkage to ASF licensed code > breaks their > licence is then a problem for them :-) ) > > The following thread is a good example of this sort of discussion: > > http://marc.theaimsgroup.com/?t=10383359585&r=1&w=2 > > > Thanks > Conor > > > > - > 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: > 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
Roy T. Fielding wrote: 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, Thanks for the clear statement. Conor - 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
Roy T. Fielding wrote: 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, 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. Looking at a) and b), it seems this is possible: You must give prominent notice with each copy of the work that the Library is used in it and that the Library and its use are covered by this License. You must supply a copy of this License. If the work during execution displays copyright notices, you must include the copyright notice for the Library among them, as well as a reference directing the user to the copy of this License. Also, you must do one of these things: # a) Accompany the work with the complete corresponding machine-readable source code for the Library including whatever changes were used in the work (which must be distributed under Sections 1 and 2 above); and, if the work is an executable linked with the Library, with the complete machine-readable "work that uses the Library", as object code and/or source code, so that the user can modify the Library and then relink to produce a modified executable containing the modified Library. (It is understood that the user who changes the contents of definitions files in the Library will not necessarily be able to recompile the application to use the modified definitions.) # b) Use a suitable shared library mechanism for linking with the Library. A suitable mechanism is one that (1) uses at run time a copy of the library already present on the user's computer system, rather than copying library functions into the executable, and (2) will operate properly with a modified version of the library, if the user installs one, as long as the modified version is interface-compatible with the version that the work was made with. ... To the best of my understanding (which might be flawed, of course), I think the idea of setting up a non-ASL jar repo might address these conditions. Could you clarify where my misunderstanding is? -- Steven Noelshttp://outerthought.org/ Outerthought - Open Source, Java & XML Competence Support Center Read my weblog athttp://blogs.cocoondev.org/stevenn/ stevenn at outerthought.orgstevenn at apache.org - 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
On Wed, 5 Feb 2003, Rodent of Unusual Size wrote: > 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*. But it applies just to Java? Or is this above and beyond the Java issue? Any chance of yourself and Roy coming up with a statement that could be included in the Jakarta newletter that's being published soon? Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: primary distribution location
> We could link to their site and recommend downloading their jar? :) We could. Not very convenient for users; just make-work on their part which would be nice to avoid. --- Noel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
