Re: Licensing again.
I echo Andrew's reservations. The reasons behind the restriction of LGPLed imports are unclear and apparently undocumented. Such a crucial matter deserves to be properly documented. If the restriction cannot be justified, then it should be lifted. I urge all Apache members and committers to carefully follow licensing related discussions. The matter is too important to be blindly deferred to the wisdom of the board. Think a little on yourself. Read the BSD license. Understand its sprit. Read the Apache license. See how much or how little it differs. At 10:30 09.02.2003 -0500, Andrew C. Oliver wrote: I'd like to state my preference that this ASF policy be changed in the near future. I prefer to be able to collaborate freely with other opensource developers. I find this policy needlessly obstructs this abillity. I understand that IBM and Sun (referring to Sam's earlier explanation) have a compelling coporate interest in being able to create commercial forks of Apache's products, however introducting LGPL dependencies does not prevent this, it only prevents them from forking that dependency. If that were a problem, them having to create a new proprietary edition of that dependency is prefferable in my opinion to the Opensource developers having an arbitrary barrier to collaboration. -Andy This following is to the best of my understanding, and as simply as I know how to state it: There is no reason that ibiblio cannot distribute L/GPL binaries, subject to the conditions of those licenses. There is no reason why such binaries can not be placed there by ASF personnel. Depending on the license, similar statements can be made about other binaries from various sources. It is ASF policy at this time that the runtime of any ASF codebase may not involve the Java import of any L/GPL code. This is to be interpreted as the transitive closure of imports: if A (ASF) imports B (non ASF) which imports C (L/GPL), then A is in violation of this policy. Compile time only dependencies (like running Checkstyle on POI) are not an issue, though I would encourage everybody to make such dependencies purely optional. The reasons behind this policy involve on an appreciation of the needs of people who wish to include ASF code in proprietary and commercial products. Being able to serve such a wide audience is a core value of the ASF. This advice is based on Roy and others having sought after and obtained legal advice and council. I am aware that Brian and others have been working to resolve this for some time, but I have no expectation that this will be resolved soon. I hope this makes things clearer. I am copying board@apache in order to solicit clarifications and/or corrections. If you do not hear of any such changes in the next few days, please treat this as official ASF policy. - Sam Ruby -- Ceki - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Licensing again.
Ceki Gülcü wrote: I echo Andrew's reservations. The reasons behind the restriction of LGPLed imports are unclear and apparently undocumented. Such a crucial matter deserves to be properly documented. If the restriction cannot be justified, then it should be lifted. You have that backwards. LGPL has special rules for 'link'. What exactly is the concept of a 'link' in Java? If A imports B and A and B are not in the same Java package (but perhaps share some similar names in the first three qualifiers) are they in the same 'library' or not? Java has been around for some time, and you would think that this would some clarification of how these concepts map to Java would have been provided. Can we read something into the fact that it has not? More importantly would you be willing to risk the value of your reputation and some important software assets on the chance that a jury of 12 people would agree with what we decided to assign to the meaning of terms used in the LGPL license? It is not up to the ASF to define what the FSF means when they say 'link' and 'library' in the context on Java. I urge all Apache members and committers to carefully follow licensing related discussions. The matter is too important to be blindly deferred to the wisdom of the board. Think a little on yourself. Read the BSD license. Understand its sprit. Read the Apache license. See how much or how little it differs. I would encourage general discussion of this on [EMAIL PROTECTED] This topic has a much wider applicability than Jakarta. - Sam Ruby - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Licensing again.
At 07:21 12.02.2003 -0500, Sam Ruby wrote: LGPL has special rules for 'link'. What exactly is the concept of a 'link' in Java? If A imports B and A and B are not in the same Java package (but perhaps share some similar names in the first three qualifiers) are they in the same 'library' or not? Indeed, reading the LGPL does not give a clear answer. Thank you for pointing out the heart of the issue. Java has been around for some time, and you would think that this would some clarification of how these concepts map to Java would have been provided. Can we read something into the fact that it has not? If you chose to. However, if would be better not to read anything into that fact. More importantly would you be willing to risk the value of your reputation and some important software assets on the chance that a jury of 12 people would agree with what we decided to assign to the meaning of terms used in the LGPL license? It depends on the formulation of the license. In the case of LGPL, I would certainly not want to take that risk. It is not up to the ASF to define what the FSF means when they say 'link' and 'library' in the context on Java. No, it is not up to the ASF. However, has the ASF attempted to clarify the matter with the FSF? Why not ask the FSF if importing java classes is considered as derivative work or simply as work that uses the library? In the absence of a clear response from the FSF, there is no doubt that it is safer to shy away from LGPLed code. I urge all Apache members and committers to carefully follow licensing related discussions. The matter is too important to be blindly deferred to the wisdom of the board. Think a little on yourself. Read the BSD license. Understand its sprit. Read the Apache license. See how much or how little it differs. I would encourage general discussion of this on [EMAIL PROTECTED] This topic has a much wider applicability than Jakarta. Sure. - Sam Ruby -- Ceki - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Licensing again.
No, it is not up to the ASF. However, has the ASF attempted to clarify the matter with the FSF? Why not ask the FSF if importing java classes is considered as derivative work or simply as work that uses the library? In the absence of a clear response from the FSF, there is no doubt that it is safer to shy away from LGPLed code. I'm drafting a letter from myself to Richard Stallman. I had thought I'd already sent it but I sent it to myself which is usually what I do when I think something needs more editing. -Andy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Licensing again.
Ceki Gülcü wrote: At 07:21 12.02.2003 -0500, Sam Ruby wrote: LGPL has special rules for 'link'. What exactly is the concept of a 'link' in Java? If A imports B and A and B are not in the same Java package (but perhaps share some similar names in the first three qualifiers) are they in the same 'library' or not? Indeed, reading the LGPL does not give a clear answer. Thank you for pointing out the heart of the issue. Java has been around for some time, and you would think that this would some clarification of how these concepts map to Java would have been provided. Can we read something into the fact that it has not? If you chose to. However, if would be better not to read anything into that fact. See below. More importantly would you be willing to risk the value of your reputation and some important software assets on the chance that a jury of 12 people would agree with what we decided to assign to the meaning of terms used in the LGPL license? It depends on the formulation of the license. In the case of LGPL, I would certainly not want to take that risk. It is not up to the ASF to define what the FSF means when they say 'link' and 'library' in the context on Java. No, it is not up to the ASF. However, has the ASF attempted to clarify the matter with the FSF? Why not ask the FSF if importing java classes is considered as derivative work or simply as work that uses the library? I am aware of a number of people, including FSF board members, who have tried to work with the FSF on this and a number of broader issues, and furthermore that their work is continuing. However much I would wish otherwise, I must confess that I am not hopeful that this will be resolved soon. People are free to license their works under any number of licenses. There are open source licenses which define derivative works more clearly. An example: http://www.mozilla.org/MPL/MPL-1.1.html The ASF is comfortable with dependencies on code under the MPL license. In the absence of a clear response from the FSF, there is no doubt that it is safer to shy away from LGPLed code. I urge all Apache members and committers to carefully follow licensing related discussions. The matter is too important to be blindly deferred to the wisdom of the board. Think a little on yourself. Read the BSD license. Understand its sprit. Read the Apache license. See how much or how little it differs. I would encourage general discussion of this on [EMAIL PROTECTED] This topic has a much wider applicability than Jakarta. Sure. - Sam Ruby -- Ceki - 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: Licensing again.
Andrew C. Oliver wrote: No, it is not up to the ASF. However, has the ASF attempted to clarify the matter with the FSF? Why not ask the FSF if importing java classes is considered as derivative work or simply as work that uses the library? In the absence of a clear response from the FSF, there is no doubt that it is safer to shy away from LGPLed code. I'm drafting a letter from myself to Richard Stallman. I had thought I'd already sent it but I sent it to myself which is usually what I do when I think something needs more editing. A better approach would be to send the e-mail to http://emoglen.law.columbia.edu/ -Andy - Sam Ruby - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Licensing again.
I will do this as well. Thanks. -Andy A better approach would be to send the e-mail to http://emoglen.law.columbia.edu/ -Andy - Sam Ruby - 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: Licensing again.
No, it is not up to the ASF. However, has the ASF attempted to clarify the matter with the FSF? Why not ask the FSF if importing java classes is considered as derivative work or simply as work that uses the library? It doesn't really matter. There are restrictions imposed on a 'work that uses the library' that are not permissible under the ASF license. 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. The terms of the ASF license permit use without these restrictions. Sun [ so as not to pick on Sam's employer for a change], for example, could reuse Tomcat in an application that doesn't allow reverse engineering. -SMD - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Licensing again.
It should be noted that Apache Software Foundation members are the legal *owners* of the software that is available under the Apache Software License. Indeed, that is one of the key benefits to becoming an ASF member, as opposed to just a committer on one or more projects. It seems perfectly reasonable that decisions on the license under which that software is licensed should be made by the people that own it. I'm curious. What is the legal basis for this claim of ownership? /Larry Rosen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Licensing again.
Andrew C. Oliver wrote: I've never heard this other interperatation outside of the ASF. I'll put more research into the issue and get back to you. I know that all of the developers that use LGPL that I know of think that the jar binaries can be used with no problem at all in any type of code, including ASF. If it's not the case, we should IMHO help them be aware that it's not the case. Or at the very least until the ASF changes its unique interperetation, just ask the authors for a disclaimer *like* (but not exactly like) on the CLASSPATH project (which is GPL). Honestly I'm not exactly sure under the ASF interperatation what the difference between GPL or LGPL is. (This is why I find this interperation so doubtful) While some authors will probably be like What's the point, thats why its LGPL? some will probably cooperate. There is a clear difference between LGPL and GPL for languages which have a clearly defined concept of link. Languages such as C. Classpath is licensed under the terms of the GNU General Public License with the following special exception. As a special exception, the copyright holders of this library give you permission to link this library with independent modules to produce an executable, regardless of the license terms of these independent modules, and to copy and distribute the resulting executable under terms of your choice, provided that you also meet, for each linked independent module, the terms and conditions of the license of that module. An independent module is a module which is not derived from or based on this library. If you modify this library, you may extend this exception to your version of the library, but you are not obligated to do so. If you do not wish to do so, delete this exception statement from your version. Define link. If you were subscribed to [EMAIL PROTECTED], you would have already seen the following: http://nagoya.apache.org/eyebrowse/ReadMsg?[EMAIL PROTECTED]msgId=641442 http://nagoya.apache.org/eyebrowse/ReadMsg?[EMAIL PROTECTED]msgId=641503 -Andy - Sam Ruby - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Licensing again.
On Mon, 2003-02-10 at 16:19, Sam Ruby wrote: Define link. If you were subscribed to [EMAIL PROTECTED], you would have already seen the following: http://nagoya.apache.org/eyebrowse/ReadMsg?[EMAIL PROTECTED]msgId=641442 http://nagoya.apache.org/eyebrowse/ReadMsg?[EMAIL PROTECTED]msgId=641503 Based on that the rule should be : We cannot use anything that causes the ASF to change their license at any point AND doesn't change the license of any of the projects using the software in any way they want. (extending, rewriting), without a single exception. That would have stopped me from putting any time in looking at other ways to solve this problem :) Mvgr, Martin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Licensing again.
On 10/2/03 4:05 Lawrence E. Rosen [EMAIL PROTECTED] wrote: It should be noted that Apache Software Foundation members are the legal *owners* of the software that is available under the Apache Software License. Indeed, that is one of the key benefits to becoming an ASF member, as opposed to just a committer on one or more projects. It seems perfectly reasonable that decisions on the license under which that software is licensed should be made by the people that own it. I'm curious. What is the legal basis for this claim of ownership? The fact that each contributor, prior access to our CVS repository, signs a paper saying that for whatever goes in CVS, he assigns copyright and ownership of the code to the ASF... No more no less than what any random employee of a software company does with his employer... Pier - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Licensing again.
Does this mean the ASF has taken away the ability for others to do derived works (including derived works that make the code commercial or GPL -- with a simple name change)? That would mean the license is no longer open source (by OSD anyway)? This is a strange discussion thread. On Mon, 2003-02-10 at 12:36, Pier Fumagalli wrote: On 10/2/03 4:05 Lawrence E. Rosen [EMAIL PROTECTED] wrote: It should be noted that Apache Software Foundation members are the legal *owners* of the software that is available under the Apache Software License. Indeed, that is one of the key benefits to becoming an ASF member, as opposed to just a committer on one or more projects. It seems perfectly reasonable that decisions on the license under which that software is licensed should be made by the people that own it. I'm curious. What is the legal basis for this claim of ownership? The fact that each contributor, prior access to our CVS repository, signs a paper saying that for whatever goes in CVS, he assigns copyright and ownership of the code to the ASF... No more no less than what any random employee of a software company does with his employer... Pier - 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: Licensing again.
No there are plenty of works derived from Apache projects. Apache code may be freely modified or redistributed, but as per the Apache license: The end-user documentation included with [redistributions of Apache code], if any, must include the following acknowlegement: This product includes software developed by the Apache Software Foundation (http://www.apache.org/). Alternately, this acknowlegement may appear in the software itself, if and wherever such third-party acknowlegements normally appear. The fact that Apache code has an owner (the ASF membership) and a copyright does not exclude it from having an open-source license. In fact, if the code did not have an owner, the license would be exceedingly difficult to defend. - Morgan --- Timothy Halloran [EMAIL PROTECTED] wrote: Does this mean the ASF has taken away the ability for others to do derived works (including derived works that make the code commercial or GPL -- with a simple name change)? That would mean the license is no longer open source (by OSD anyway)? This is a strange discussion thread. On Mon, 2003-02-10 at 12:36, Pier Fumagalli wrote: On 10/2/03 4:05 Lawrence E. Rosen [EMAIL PROTECTED] wrote: It should be noted that Apache Software Foundation members are the legal *owners* of the software that is available under the Apache Software License. Indeed, that is one of the key benefits to becoming an ASF member, as opposed to just a committer on one or more projects. It seems perfectly reasonable that decisions on the license under which that software is licensed should be made by the people that own it. I'm curious. What is the legal basis for this claim of ownership? The fact that each contributor, prior access to our CVS repository, signs a paper saying that for whatever goes in CVS, he assigns copyright and ownership of the code to the ASF... No more no less than what any random employee of a software company does with his employer... Pier - 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] = Morgan Delagrange http://jakarta.apache.org/taglibs http://jakarta.apache.org/commons http://axion.tigris.org http://jakarta.apache.org/watchdog __ Do you Yahoo!? Yahoo! Mail Plus - Powerful. Affordable. Sign up now. http://mailplus.yahoo.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Licensing again.
On Mon, 10 Feb 2003, Timothy Halloran wrote: Date: 10 Feb 2003 13:43:24 -0500 From: Timothy Halloran [EMAIL PROTECTED] Reply-To: Jakarta General List [EMAIL PROTECTED] To: Jakarta General List [EMAIL PROTECTED] Subject: Re: Licensing again. Does this mean the ASF has taken away the ability for others to do derived works (including derived works that make the code commercial or GPL -- with a simple name change)? That would mean the license is no longer open source (by OSD anyway)? People who *use* Apache code are free to use it in any way they want (subject, of course, to the Apache license requirements). That means that they can incorporate GPL/LGPL code on their own -- no problems. The user of Apache software can even redistribute Apache+GPL code in a package if they want -- nothing has changed there. The issue at hand for Apache is what are the license terms that cover the code that Apache *itself* distributes? Users of Apache code, quite naturally, will assume that the Apache Software License covers *all* the code in that distribution. That assumption is violated when a GPL/LGPL package is included, and this matters a *lot* to organizations that, for whatever policy reasons, choose not to utilize GPL/LGPL code. Craig McClanahan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Licensing again.
Martin van den Bemt wrote: On Mon, 2003-02-10 at 16:19, Sam Ruby wrote: Define link. If you were subscribed to [EMAIL PROTECTED], you would have already seen the following: http://nagoya.apache.org/eyebrowse/ReadMsg?[EMAIL PROTECTED]msgId=641442 http://nagoya.apache.org/eyebrowse/ReadMsg?[EMAIL PROTECTED]msgId=641503 Based on that the rule should be : We cannot use anything that causes the ASF to change their license at any point AND doesn't change the license of any of the projects using the software in any way they want. (extending, rewriting), without a single exception. That would have stopped me from putting any time in looking at other ways to solve this problem :) Ahh, like the sun licenses too? ;-) Mvgr, Martin - 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: Licensing again.
I'd like to state my preference that this ASF policy be changed in the near future. I prefer to be able to collaborate freely with other opensource developers. I find this policy needlessly obstructs this abillity. I understand that IBM and Sun (referring to Sam's earlier explanation) have a compelling coporate interest in being able to create commercial forks of Apache's products, however introducting LGPL dependencies does not prevent this, it only prevents them from forking that dependency. If that were a problem, them having to create a new proprietary edition of that dependency is prefferable in my opinion to the Opensource developers having an arbitrary barrier to collaboration. -Andy This following is to the best of my understanding, and as simply as I know how to state it: There is no reason that ibiblio cannot distribute L/GPL binaries, subject to the conditions of those licenses. There is no reason why such binaries can not be placed there by ASF personnel. Depending on the license, similar statements can be made about other binaries from various sources. It is ASF policy at this time that the runtime of any ASF codebase may not involve the Java import of any L/GPL code. This is to be interpreted as the transitive closure of imports: if A (ASF) imports B (non ASF) which imports C (L/GPL), then A is in violation of this policy. Compile time only dependencies (like running Checkstyle on POI) are not an issue, though I would encourage everybody to make such dependencies purely optional. The reasons behind this policy involve on an appreciation of the needs of people who wish to include ASF code in proprietary and commercial products. Being able to serve such a wide audience is a core value of the ASF. This advice is based on Roy and others having sought after and obtained legal advice and council. I am aware that Brian and others have been working to resolve this for some time, but I have no expectation that this will be resolved soon. I hope this makes things clearer. I am copying board@apache in order to solicit clarifications and/or corrections. If you do not hear of any such changes in the next few days, please treat this as official ASF policy. - Sam Ruby - 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: Licensing again.
Andrew C. Oliver wrote: I'd like to state my preference that this ASF policy be changed in the near future. [snip] ... introducting LGPL dependencies does not prevent this, it only prevents them from forking that dependency. That is not my understanding. Is this simply your opinion, or can you substantiate this? I know people, including people on the ASF board, legal council, and others who I respect that have come to a different conclusion. ASF members that wish to be more directly involved in this issue can subscribe to [EMAIL PROTECTED] Before anyone asks, yes, this is a subscriber moderated list. - Sam Ruby - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Licensing again.
At 11:22 AM 9/02/2003 -0500, you wrote: Andrew C. Oliver wrote: I'd like to state my preference that this ASF policy be changed in the near future. [snip] ... introducting LGPL dependencies does not prevent this, it only prevents them from forking that dependency. That is not my understanding. Is this simply your opinion, or can you substantiate this? I know people, including people on the ASF board, legal council, and others who I respect that have come to a different conclusion. ASF members that wish to be more directly involved in this issue can subscribe to [EMAIL PROTECTED] Before anyone asks, yes, this is a subscriber moderated list. If that's true then this has a huge impact on a lot of existing projects (and I'm not talking about apache projects). Regards, Glen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Licensing again.
That is not my understanding. Is this simply your opinion, or can you substantiate this? I know people, including people on the ASF board, legal council, and others who I respect that have come to a different conclusion. I've never heard this other interperatation outside of the ASF. I'll put more research into the issue and get back to you. ASF members that wish to be more directly involved in this issue can subscribe to [EMAIL PROTECTED] Before anyone asks, yes, this is a subscriber moderated list. Note that I don't object to such a list being that way. :-) -Andy - Sam Ruby - 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: Licensing again.
Andrew C. Oliver wrote: ASF members that wish to be more directly involved in this issue can subscribe to [EMAIL PROTECTED] Before anyone asks, yes, this is a subscriber moderated list. Note that I don't object to such a list being that way. :-) I do :-) ( last time I checked - it was ASF members, not committers - and committers are supposed to know the licenses too ) Costin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Licensing again.
Ditto plus some, Seeing the license issues discussed is also of interest to end users who are under that license. And for list members are faced with similar issues in other projects. Costin Manolache wrote: Andrew C. Oliver wrote: ASF members that wish to be more directly involved in this issue can subscribe to [EMAIL PROTECTED] Before anyone asks, yes, this is a subscriber moderated list. Note that I don't object to such a list being that way. :-) I do :-) ( last time I checked - it was ASF members, not committers - and committers are supposed to know the licenses too ) Costin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Ellis Teer www.sitepen.com http://www.sitepen.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Licensing again.
On Sun, 9 Feb 2003, Ellis Teer wrote: Date: Sun, 09 Feb 2003 18:41:54 -0800 From: Ellis Teer [EMAIL PROTECTED] Reply-To: Jakarta General List [EMAIL PROTECTED] To: Jakarta General List [EMAIL PROTECTED] Subject: Re: Licensing again. Ditto plus some, Seeing the license issues discussed is also of interest to end users who are under that license. And for list members are faced with similar issues in other projects. It should be noted that Apache Software Foundation members are the legal *owners* of the software that is available under the Apache Software License. Indeed, that is one of the key benefits to becoming an ASF member, as opposed to just a committer on one or more projects. It seems perfectly reasonable that decisions on the license under which that software is licensed should be made by the people that own it. Craig McClanahan PS: Yes, I am an ASF member, and therefore one of those owners. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Licensing again.
Andrew C. Oliver wrote, On 10/02/2003 1.31: That is not my understanding. Is this simply your opinion, or can you substantiate this? I know people, including people on the ASF board, legal council, and others who I respect that have come to a different conclusion. I've never heard this other interperatation outside of the ASF. I'll put more research into the issue and get back to you. I know that all of the developers that use LGPL that I know of think that the jar binaries can be used with no problem at all in any type of code, including ASF. If it's not the case, we should IMHO help them be aware that it's not the case. ASF members that wish to be more directly involved in this issue can subscribe to [EMAIL PROTECTED] Before anyone asks, yes, this is a subscriber moderated list. Note that I don't object to such a list being that way. :-) -- Nicola Ken Barozzi [EMAIL PROTECTED] - verba volant, scripta manent - (discussions get forgotten, just code remains) - - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
