You are viewing a plain text version of this content. The canonical link for it is here.
Posted to general@jakarta.apache.org by Sam Ruby <ru...@apache.org> on 2003/02/05 17:53:47 UTC
Re: failure notice
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*.
This issue has come up before. This time, let's flatten it.
In two weeks, there is a board meeting. At that time, I would like to
be able to report that the contents of the Maven repository conforms to
the policies of the Apache Software Foundation.
Code under the ASF License is clearly OK. As is the IBM Public License
(the pre-Jakarta BSF, for example) and the MPL (Rhino). The following
public domain components are also approved: Antlr and Doug Lea's
concurrency package.
Licenses clearly not conforming to the ASF's policies for distribution:
LGPL, GPL, Sun's Binary Code License.
Please direct any questions or comments (including new licenses to be
considered) to general@jakarta.apache.org. Some we can resolve for
ourselves (e.g., the specific public domain packages above). Others
I'll batch up and forward to the board and/or licensing folk.
By the board meeting after that (3rd week in March), I'd like to have
the infrastructure issues resolved (where should this data should be
hosted, mirrored, etc).
- Sam Ruby
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@jakarta.apache.org
For additional commands, e-mail: general-help@jakarta.apache.org
Re: Licensing again.
Posted by Steve Downey <st...@globeinvestment.com>.
>
> 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: general-unsubscribe@jakarta.apache.org
For additional commands, e-mail: general-help@jakarta.apache.org
Re: Licensing again.
Posted by Ceki Gülcü <ce...@qos.ch>.
Excellent initiative. You might want to share it with community@ before
sending it to RMS. Is there a way to copy the FSF as a group and not just RMS?
I am directing the discussion to community@ according to Sam's suggestion.
At 08:26 12.02.2003 -0500, you 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.
>
>-Andy
--
Ceki
---------------------------------------------------------------------
To unsubscribe, e-mail: community-unsubscribe@apache.org
For additional commands, e-mail: community-help@apache.org
Re: Licensing again.
Posted by "Andrew C. Oliver" <ac...@apache.org>.
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: general-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: general-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@jakarta.apache.org
For additional commands, e-mail: general-help@jakarta.apache.org
Re: Licensing again.
Posted by Sam Ruby <ru...@intertwingly.net>.
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: general-unsubscribe@jakarta.apache.org
For additional commands, e-mail: general-help@jakarta.apache.org
Re: Licensing again.
Posted by "Andrew C. Oliver" <ac...@apache.org>.
>
> 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: general-unsubscribe@jakarta.apache.org
For additional commands, e-mail: general-help@jakarta.apache.org
Re: Licensing again.
Posted by Sam Ruby <ru...@intertwingly.net>.
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 community@apache.org.
>> This topic has a much wider applicability than Jakarta.
>
> Sure.
>
>> - Sam Ruby
>
>
> --
> Ceki
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: general-help@jakarta.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@jakarta.apache.org
For additional commands, e-mail: general-help@jakarta.apache.org
Re: Licensing again.
Posted by Ceki Gülcü <ce...@qos.ch>.
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 community@apache.org. This
>topic has a much wider applicability than Jakarta.
Sure.
>- Sam Ruby
--
Ceki
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@jakarta.apache.org
For additional commands, e-mail: general-help@jakarta.apache.org
Re: Licensing again.
Posted by Sam Ruby <ru...@apache.org>.
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 community@apache.org.
This topic has a much wider applicability than Jakarta.
- Sam Ruby
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@jakarta.apache.org
For additional commands, e-mail: general-help@jakarta.apache.org
Re: Licensing again.
Posted by Ceki Gülcü <ce...@qos.ch>.
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: general-unsubscribe@jakarta.apache.org
For additional commands, e-mail: general-help@jakarta.apache.org
Re: Licensing again.
Posted by Glen Stampoultzis <tr...@iprimus.com.au>.
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 licensing@apache.org. 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: general-unsubscribe@jakarta.apache.org
For additional commands, e-mail: general-help@jakarta.apache.org
Re: Licensing again.
Posted by "Andrew C. Oliver" <ac...@apache.org>.
Martin van den Bemt wrote:
>On Mon, 2003-02-10 at 16:19, Sam Ruby wrote:
>
>
>>Define "link".
>>
>>If you were subscribed to community@apache.org, you would have already
>>seen the following:
>>
>>http://nagoya.apache.org/eyebrowse/ReadMsg?listName=community@apache.org&msgId=641442
>>http://nagoya.apache.org/eyebrowse/ReadMsg?listName=community@apache.org&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: general-unsubscribe@jakarta.apache.org
>For additional commands, e-mail: general-help@jakarta.apache.org
>
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@jakarta.apache.org
For additional commands, e-mail: general-help@jakarta.apache.org
Re: Licensing again.
Posted by Martin van den Bemt <ml...@mvdb.net>.
On Mon, 2003-02-10 at 16:19, Sam Ruby wrote:
>
> Define "link".
>
> If you were subscribed to community@apache.org, you would have already
> seen the following:
>
> http://nagoya.apache.org/eyebrowse/ReadMsg?listName=community@apache.org&msgId=641442
> http://nagoya.apache.org/eyebrowse/ReadMsg?listName=community@apache.org&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: general-unsubscribe@jakarta.apache.org
For additional commands, e-mail: general-help@jakarta.apache.org
Re: Licensing again.
Posted by Sam Ruby <ru...@apache.org>.
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 community@apache.org, you would have already
seen the following:
http://nagoya.apache.org/eyebrowse/ReadMsg?listName=community@apache.org&msgId=641442
http://nagoya.apache.org/eyebrowse/ReadMsg?listName=community@apache.org&msgId=641503
> -Andy
- Sam Ruby
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@jakarta.apache.org
For additional commands, e-mail: general-help@jakarta.apache.org
Re: Licensing again.
Posted by "Andrew C. Oliver" <ac...@apache.org>.
>> 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.
"
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.
"
-Andy
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@jakarta.apache.org
For additional commands, e-mail: general-help@jakarta.apache.org
Re: Licensing again.
Posted by Nicola Ken Barozzi <ni...@apache.org>.
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 licensing@apache.org. 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 nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@jakarta.apache.org
For additional commands, e-mail: general-help@jakarta.apache.org
Re: Licensing again.
Posted by "Andrew C. Oliver" <ac...@apache.org>.
>>
>>
>> I do :-) ( last time I checked - it was ASF members, not committers - and
>> committers are supposed to know the licenses too )
>>
>> Costin
>>
>>
Right but IIUC there might be "Gee costin just checked in some stuff
into CVS illegally, we better fix it. So and so just contacted us and
said if we don't delete it they'll sue us but if we mention it
publically they'll sue us too" or something like that.. In such a case
it seems like that might be a good place to discuss it..
-Andy
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: general-unsubscribe@jakarta.apache.org
>> For additional commands, e-mail: general-help@jakarta.apache.org
>>
>>
>>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@jakarta.apache.org
For additional commands, e-mail: general-help@jakarta.apache.org
Re: Licensing again.
Posted by "Craig R. McClanahan" <cr...@apache.org>.
On Mon, 10 Feb 2003, Timothy Halloran wrote:
> Date: 10 Feb 2003 13:43:24 -0500
> From: Timothy Halloran <th...@GS06.ISRI.CMU.EDU>
> Reply-To: Jakarta General List <ge...@jakarta.apache.org>
> To: Jakarta General List <ge...@jakarta.apache.org>
> 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: general-unsubscribe@jakarta.apache.org
For additional commands, e-mail: general-help@jakarta.apache.org
Re: Licensing again.
Posted by Morgan Delagrange <md...@yahoo.com>.
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 <th...@GS06.ISRI.CMU.EDU>
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"
> <lr...@rosenlaw.com> 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:
> general-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail:
> general-help@jakarta.apache.org
>
>
>
---------------------------------------------------------------------
> To unsubscribe, e-mail:
> general-unsubscribe@jakarta.apache.org
> For additional commands, e-mail:
> general-help@jakarta.apache.org
>
=====
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: general-unsubscribe@jakarta.apache.org
For additional commands, e-mail: general-help@jakarta.apache.org
Re: Licensing again.
Posted by Timothy Halloran <th...@GS06.ISRI.CMU.EDU>.
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" <lr...@rosenlaw.com> 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: general-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: general-help@jakarta.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@jakarta.apache.org
For additional commands, e-mail: general-help@jakarta.apache.org
Re: Licensing again.
Posted by Pier Fumagalli <pi...@betaversion.org>.
On 10/2/03 4:05 "Lawrence E. Rosen" <lr...@rosenlaw.com> 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: general-unsubscribe@jakarta.apache.org
For additional commands, e-mail: general-help@jakarta.apache.org
RE: Licensing again.
Posted by "Lawrence E. Rosen" <lr...@rosenlaw.com>.
> 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: general-unsubscribe@jakarta.apache.org
For additional commands, e-mail: general-help@jakarta.apache.org
Re: Licensing again.
Posted by "Craig R. McClanahan" <cr...@apache.org>.
On Sun, 9 Feb 2003, Ellis Teer wrote:
> Date: Sun, 09 Feb 2003 18:41:54 -0800
> From: Ellis Teer <el...@sitepen.com>
> Reply-To: Jakarta General List <ge...@jakarta.apache.org>
> To: Jakarta General List <ge...@jakarta.apache.org>
> 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: general-unsubscribe@jakarta.apache.org
For additional commands, e-mail: general-help@jakarta.apache.org
Re: Licensing again.
Posted by Ellis Teer <el...@sitepen.com>.
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 licensing@apache.org. 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: general-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: general-help@jakarta.apache.org
>
>
>
--
Ellis Teer
www.sitepen.com
http://www.sitepen.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@jakarta.apache.org
For additional commands, e-mail: general-help@jakarta.apache.org
Re: Licensing again.
Posted by Costin Manolache <cm...@yahoo.com>.
Andrew C. Oliver wrote:
>> ASF members that wish to be more directly involved in this issue can
>> subscribe to licensing@apache.org. 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: general-unsubscribe@jakarta.apache.org
For additional commands, e-mail: general-help@jakarta.apache.org
Re: Licensing again.
Posted by "Andrew C. Oliver" <ac...@apache.org>.
> 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 licensing@apache.org. 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: general-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: general-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@jakarta.apache.org
For additional commands, e-mail: general-help@jakarta.apache.org
Re: Licensing again.
Posted by Sam Ruby <ru...@apache.org>.
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 licensing@apache.org. Before anyone asks, yes, this is a
subscriber moderated list.
- Sam Ruby
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@jakarta.apache.org
For additional commands, e-mail: general-help@jakarta.apache.org
Re: Licensing again.
Posted by "Andrew C. Oliver" <ac...@apache.org>.
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: general-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: general-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@jakarta.apache.org
For additional commands, e-mail: general-help@jakarta.apache.org
Re: Licensing again.
Posted by Sam Ruby <ru...@apache.org>.
dion@multitask.com.au wrote:
> Sam Ruby <ru...@apache.org> wrote on 06/02/2003 03:53:47 AM:
>
> [snip]
>
>>Code under the ASF License is clearly OK. As is the IBM Public License
>>(the pre-Jakarta BSF, for example) and the MPL (Rhino). The following
>>public domain components are also approved: Antlr and Doug Lea's
>>concurrency package.
>>
>>Licenses clearly not conforming to the ASF's policies for distribution:
>>LGPL, GPL, Sun's Binary Code License.
>
> Could you please explain why ibiblio cannot distribute L/GPL and other
> opensource binaries as long as the license conditions are met?
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: general-unsubscribe@jakarta.apache.org
For additional commands, e-mail: general-help@jakarta.apache.org
Licensing again.
Posted by di...@multitask.com.au.
Sam Ruby <ru...@apache.org> wrote on 06/02/2003 03:53:47 AM:
[snip]
> Code under the ASF License is clearly OK. As is the IBM Public License
> (the pre-Jakarta BSF, for example) and the MPL (Rhino). The following
> public domain components are also approved: Antlr and Doug Lea's
> concurrency package.
>
> Licenses clearly not conforming to the ASF's policies for distribution:
> LGPL, GPL, Sun's Binary Code License.
Could you please explain why ibiblio cannot distribute L/GPL and other
opensource binaries as long as the license conditions are met?
--
dIon Gillard, Multitask Consulting
Blog: http://www.freeroller.net/page/dion/Weblog
Work: http://www.multitask.com.au
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@jakarta.apache.org
For additional commands, e-mail: general-help@jakarta.apache.org
Re: Licensing questions
Posted by Sam Ruby <ru...@apache.org>.
dion@multitask.com.au wrote:
> For each ASF jar file distributed, we need to distribute the
> license/copyright and conditions from the source of that jar.
>
> e.g. for ant, we need ants LICENSE, for jelly Jelly's license.
>
> Until ASL v2, when all the licenses become the same text, I understand
> that we need a license for each binary distribution of ASF code. Is this
> correct?
Let me generalize this a bit and then state a personal recommendation -
i.e., not an official statement of ASF policy, but how I would apply
common sense in this situation.
Independent of whether an artifact is source or binary, independent of
whether such an artifact is ASF Licensed or not, we need to make it
relatively easily apparent as to what license applies to everything.
This includes public domain, Mozilla Public License, Sun Public License
jars, ... everything.
When things are organized like the maven repository on ibiblio is, I
would recommend one license per directory. Ant, for example, has
multiple jars but it would be clear enough to me that each were covered
under the ASF license.
Even before ASF Sofware License v2, in my mind it would simplify things
if we were to consolidate and standardize our licenses. However, for
various reasons (impending v2, more serious license issues, desire to do
some thing other than purely licensing related on occasion <grin>), this
is not my personal top priority at this time.
-Sam Ruby
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@jakarta.apache.org
For additional commands, e-mail: general-help@jakarta.apache.org
Licensing questions
Posted by di...@multitask.com.au.
For each ASF jar file distributed, we need to distribute the
license/copyright and conditions from the source of that jar.
e.g. for ant, we need ants LICENSE, for jelly Jelly's license.
Until ASL v2, when all the licenses become the same text, I understand
that we need a license for each binary distribution of ASF code. Is this
correct?
--
dIon Gillard, Multitask Consulting
Blog: http://www.freeroller.net/page/dion/Weblog
Work: http://www.multitask.com.au
Sam Ruby <ru...@apache.org> wrote on 06/02/2003 03:53:47 AM:
> 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*.
>
> This issue has come up before. This time, let's flatten it.
>
> In two weeks, there is a board meeting. At that time, I would like to
> be able to report that the contents of the Maven repository conforms to
> the policies of the Apache Software Foundation.
>
> Code under the ASF License is clearly OK. As is the IBM Public License
> (the pre-Jakarta BSF, for example) and the MPL (Rhino). The following
> public domain components are also approved: Antlr and Doug Lea's
> concurrency package.
>
> Licenses clearly not conforming to the ASF's policies for distribution:
> LGPL, GPL, Sun's Binary Code License.
>
> Please direct any questions or comments (including new licenses to be
> considered) to general@jakarta.apache.org. Some we can resolve for
> ourselves (e.g., the specific public domain packages above). Others
> I'll batch up and forward to the board and/or licensing folk.
>
> By the board meeting after that (3rd week in March), I'd like to have
> the infrastructure issues resolved (where should this data should be
> hosted, mirrored, etc).
>
> - Sam Ruby
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: turbine-maven-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail:
turbine-maven-dev-help@jakarta.apache.org
>
> ForwardSourceID:NT000AD6BE
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@jakarta.apache.org
For additional commands, e-mail: general-help@jakarta.apache.org
RE: licensing review
Posted by Costin Manolache <co...@apache.org>.
On Wed, 5 Feb 2003, Noel J. Bergman wrote:
> > I don't get these GPL people who license their work as GPL, but don't
> > want the viral aspect...
>
> I believe that they are trying to separate the licensing of the source code
> vs. the binary. If you want to use their SOURCE, you have to keep the
> source code GPL; no proprietary changes. If you just want to use their
> BINARY, do with it as you wish, unencumbered.
>
> In any case, the only issue in my mind is receiving their binary releases
> unconstrained and unencumbered.
This is very similar with some of the other licenses from Sun ( and IBM )
that allow redistribution of the (original) binary - but don't provide the
source code under the same terms.
Costin
---------------------------------------------------------------------
To unsubscribe, e-mail: community-unsubscribe@apache.org
For additional commands, e-mail: community-help@apache.org
RE: licensing review
Posted by "Noel J. Bergman" <no...@devtech.com>.
> Certainly we need an official reading on
[http://www.gnu.org/software/classpath/],
> but Classpath is specifically licensed as GPL, the least compatible
open-source
> license out there (not even a murkier LGPL).
The issues with GPL are well-known.
> 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).
I don't believe that to be a correct reading, but we can get additional
clarification from them. AIUI, they intend for their binaries to be freely
distributable without constraint.
> I don't get these GPL people who license their work as GPL, but don't
> want the viral aspect...
I believe that they are trying to separate the licensing of the source code
vs. the binary. If you want to use their SOURCE, you have to keep the
source code GPL; no proprietary changes. If you just want to use their
BINARY, do with it as you wish, unencumbered.
In any case, the only issue in my mind is receiving their binary releases
unconstrained and unencumbered.
--- Noel
---------------------------------------------------------------------
To unsubscribe, e-mail: community-unsubscribe@apache.org
For additional commands, e-mail: community-help@apache.org
Re: licensing review
Posted by Henri Yandell <ba...@generationjava.com>.
On Wed, 5 Feb 2003, Serge Knystautas wrote:
> Certainly we need an official reading on this, but Classpath is
> specifically licensed as GPL, the least compatible open-source license
> out there (not even a murkier LGPL). 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.
If it's based on GPL, ie) LGPL or GPL with a clause, then until there's
any form of legal ruling on it, surely it's as good as GPL.
Hen
---------------------------------------------------------------------
To unsubscribe, e-mail: community-unsubscribe@apache.org
For additional commands, e-mail: community-help@apache.org
Re: licensing review
Posted by Serge Knystautas <se...@lokitech.com>.
Costin Manolache wrote:
>>Please also take a look at this: http://www.gnu.org/software/classpath/.
>>The authors intend and believe that the exception granted allows that code
>>so licensed "can be used to run free as well as proprietary applications and
>>applets." I have spoken with Nic Ferrier about this license exception.
>>They specifically intend for it to remove any viral implications related to
>>their binary distribution, and redistribution, and they believe that it does
>>so.
>>
>>In the specific case, this is related to the service provider example, so I
>>am only concerned about the permissible use of their binary jars.
>
>
> +1 - if Classpath license is found to be compatible, this will solve a lot
> of problems, as they provide alternative implementation for JNDI and
> many other APIs.
>
> I think this particular one deserves special attention !
Certainly we need an official reading on this, but Classpath is
specifically licensed as GPL, the least compatible open-source license
out there (not even a murkier LGPL). 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.
I don't get these GPL people who license their work as GPL, but don't
want the viral aspect... The fact that they don't understand the
implications of their licensing decision doesn't make us any less liable
to use it. If a commercial EULA had a clause that the company then
stated they didn't intend, if they don't reissue the code with a
different license, the original license is still enforceable.
--
Serge Knystautas
President
Lokitech >> software . strategy . design >> http://www.lokitech.com
p. 301.656.5501
e. sergek@lokitech.com
---------------------------------------------------------------------
To unsubscribe, e-mail: community-unsubscribe@apache.org
For additional commands, e-mail: community-help@apache.org
Re: licensing review
Posted by Costin Manolache <co...@apache.org>.
On Wed, 5 Feb 2003, Noel J. Bergman wrote:
> > Code under the ASF License is clearly OK. As is the IBM Public License
> > (the pre-Jakarta BSF, for example) and the MPL (Rhino). The following
> > public domain components are also approved: Antlr and Doug Lea's
> > concurrency package.
>
> > Licenses clearly not conforming to the ASF's policies for distribution:
> > LGPL, GPL, Sun's Binary Code License.
>
> Please also take a look at this: http://www.gnu.org/software/classpath/.
> The authors intend and believe that the exception granted allows that code
> so licensed "can be used to run free as well as proprietary applications and
> applets." I have spoken with Nic Ferrier about this license exception.
> They specifically intend for it to remove any viral implications related to
> their binary distribution, and redistribution, and they believe that it does
> so.
>
> In the specific case, this is related to the service provider example, so I
> am only concerned about the permissible use of their binary jars.
+1 - if Classpath license is found to be compatible, this will solve a lot
of problems, as they provide alternative implementation for JNDI and
many other APIs.
I think this particular one deserves special attention !
Costin
---------------------------------------------------------------------
To unsubscribe, e-mail: community-unsubscribe@apache.org
For additional commands, e-mail: community-help@apache.org
licensing review
Posted by "Noel J. Bergman" <no...@devtech.com>.
> Code under the ASF License is clearly OK. As is the IBM Public License
> (the pre-Jakarta BSF, for example) and the MPL (Rhino). The following
> public domain components are also approved: Antlr and Doug Lea's
> concurrency package.
> Licenses clearly not conforming to the ASF's policies for distribution:
> LGPL, GPL, Sun's Binary Code License.
Please also take a look at this: http://www.gnu.org/software/classpath/.
The authors intend and believe that the exception granted allows that code
so licensed "can be used to run free as well as proprietary applications and
applets." I have spoken with Nic Ferrier about this license exception.
They specifically intend for it to remove any viral implications related to
their binary distribution, and redistribution, and they believe that it does
so.
In the specific case, this is related to the service provider example, so I
am only concerned about the permissible use of their binary jars.
If there are problems with it, please let me know the specifics so that I
can pass them on to Nic & Co.
--- Noel
---------------------------------------------------------------------
To unsubscribe, e-mail: community-unsubscribe@apache.org
For additional commands, e-mail: community-help@apache.org
Re: failure notice
Posted by Henri Yandell <ba...@generationjava.com>.
On Wed, 5 Feb 2003, Sam Ruby wrote:
> This issue has come up before. This time, let's flatten it.
>
> In two weeks, there is a board meeting. At that time, I would like to
> be able to report that the contents of the Maven repository conforms to
> the policies of the Apache Software Foundation.
I'm not sure I understand why the ibiblio repository breaks any
rules/licences. It's only if an ASF project building from Maven/Centipede
were to use an LGPL project from it, or if the ibiblio repository is seen
as 'run' by the ASF.
The latter is currently probably true though, so ASF would be liable for
it having Sun licences on, but there's nothing to stop LGPL code being
redistributed(?) as long as it follows the LGPL/GPL rules for it.
> Code under the ASF License is clearly OK. As is the IBM Public License
> (the pre-Jakarta BSF, for example) and the MPL (Rhino). The following
> public domain components are also approved: Antlr and Doug Lea's
> concurrency package.
BSD/MIT? Why not all public-domain code?
> Licenses clearly not conforming to the ASF's policies for distribution:
> LGPL, GPL, Sun's Binary Code License.
What about the other Sun licences? SISSL and SPL?
Hen
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@jakarta.apache.org
For additional commands, e-mail: general-help@jakarta.apache.org