You are viewing a plain text version of this content. The canonical link for it is here.
Posted to community@apache.org by Rodent of Unusual Size <Ke...@Golux.Com> on 2003/02/04 20:05:39 UTC
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.
<board hat="on"> in fact, until such time as a clear determination
is made, i'm ruling that it is *not* allowed. it is not worth the
risk. so lgpl-licensed materials in the asf repositories are
forbidden until a final decision is made. </board>
that may seem heavy-handed and arbitrary; i apologise ahead of
time, particularly if i turn out to be wrong. however, i am
saying this in good faith and in an attempt to do what's right.
i will welcome an official answer no less than anyone else.
--
#ken P-)}
Ken Coar, Sanagendamgagwedweinini http://Golux.Com/coar/
Author, developer, opinionist http://Apache-Server.Com/
"Millennium hand and shrimp!"
---------------------------------------------------------------------
To unsubscribe, e-mail: community-unsubscribe@apache.org
For additional commands, e-mail: community-help@apache.org
Re: primary distribution location
Posted by Costin Manolache <co...@apache.org>.
On Tue, 4 Feb 2003, Andrew C. Oliver wrote:
> >
> >
> ><board hat="on"> in fact, until such time as a clear determination
> >is made, i'm ruling that it is *not* allowed. it is not worth the
> >risk. so lgpl-licensed materials in the asf repositories are
> >forbidden until a final decision is made. </board>
That'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: community-unsubscribe@apache.org
For additional commands, e-mail: community-help@apache.org
Re: primary distribution location
Posted by "Andrew C. Oliver" <ac...@apache.org>.
>
>
><board hat="on"> in fact, until such time as a clear determination
>is made, i'm ruling that it is *not* allowed. it is not worth the
>risk. so lgpl-licensed materials in the asf repositories are
>forbidden until a final decision is made. </board>
>
>that may seem heavy-handed and arbitrary; i apologise ahead of
>time, particularly if i turn out to be wrong. however, i am
>saying this in good faith and in an attempt to do what's right.
>i will welcome an official answer no less than anyone else.
>
>
While I do not want to have a discussion on the matter, I would like to
state my preference to have some determination on this matter in the
near future.
-Andy "licenses are stupid and annoying, just play freaking nice" Oliver
---------------------------------------------------------------------
To unsubscribe, e-mail: community-unsubscribe@apache.org
For additional commands, e-mail: community-help@apache.org
Re: primary distribution location
Posted by Steven Noels <st...@outerthought.org>.
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>
--
Steven Noels http://outerthought.org/
Outerthought - Open Source, Java & XML Competence Support Center
Read my weblog at http://blogs.cocoondev.org/stevenn/
stevenn at outerthought.org stevenn at apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: community-unsubscribe@apache.org
For additional commands, e-mail: community-help@apache.org
Re: primary distribution location
Posted by Henri Yandell <ba...@generationjava.com>.
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: community-unsubscribe@apache.org
For additional commands, e-mail: community-help@apache.org
Re: primary distribution location
Posted by Conor MacNeill <co...@cortexebusiness.com.au>.
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: community-unsubscribe@apache.org
For additional commands, e-mail: community-help@apache.org
RE: primary distribution location
Posted by "Noel J. Bergman" <no...@devtech.com>.
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: community-unsubscribe@apache.org
For additional commands, e-mail: community-help@apache.org
Re: ATTN: Maven developers [was: primary distribution location]
Posted by Costin Manolache <co...@apache.org>.
On Wed, 5 Feb 2003, Sam Ruby wrote:
> 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.
If possible: we need a review on the JMX1.2 RI license. My understanding
is that it allows redistribution ( JMX1.1 was more restrictive ) and it
doesn't seem to require "click" or other things.
No other JMX1.2 implementation exists at this moment and we need
some of the security enhancements. Tomcat5 relies on JMX. I consider
this critical.
Costin
>
> 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: community-unsubscribe@apache.org
> For additional commands, e-mail: community-help@apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: community-unsubscribe@apache.org
For additional commands, e-mail: community-help@apache.org
ATTN: Maven developers [was: primary distribution location]
Posted by Sam Ruby <ru...@apache.org>.
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: community-unsubscribe@apache.org
For additional commands, e-mail: community-help@apache.org
Re: primary distribution location
Posted by Henri Yandell <ba...@generationjava.com>.
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: community-unsubscribe@apache.org
For additional commands, e-mail: community-help@apache.org
Re: primary distribution location
Posted by Rodent of Unusual Size <Ke...@Golux.Com>.
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*.
--
#ken P-)}
Ken Coar, Sanagendamgagwedweinini http://Golux.Com/coar/
Author, developer, opinionist http://Apache-Server.Com/
"Millennium hand and shrimp!"
---------------------------------------------------------------------
To unsubscribe, e-mail: community-unsubscribe@apache.org
For additional commands, e-mail: community-help@apache.org
Re: primary distribution location
Posted by Conor MacNeill <co...@cortexebusiness.com.au>.
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: community-unsubscribe@apache.org
For additional commands, e-mail: community-help@apache.org
Re: primary distribution location
Posted by "Roy T. Fielding" <fi...@apache.org>.
>> 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: community-unsubscribe@apache.org
For additional commands, e-mail: community-help@apache.org
Re: primary distribution location
Posted by Steven Noels <st...@outerthought.org>.
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:
<quote>
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.
...
</quote>
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>
--
Steven Noels http://outerthought.org/
Outerthought - Open Source, Java & XML Competence Support Center
Read my weblog at http://blogs.cocoondev.org/stevenn/
stevenn at outerthought.org stevenn at apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: community-unsubscribe@apache.org
For additional commands, e-mail: community-help@apache.org
Re: primary distribution location
Posted by Sam Ruby <ru...@apache.org>.
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: community-unsubscribe@apache.org
For additional commands, e-mail: community-help@apache.org
RE: primary distribution location
Posted by Dirk-Willem van Gulik <di...@webweaving.org>.
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: community-unsubscribe@apache.org
For additional commands, e-mail: community-help@apache.org
RE: primary distribution location
Posted by "Noel J. Bergman" <no...@devtech.com>.
> 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: community-unsubscribe@apache.org
For additional commands, e-mail: community-help@apache.org
RE: primary distribution location
Posted by Henri Yandell <ba...@generationjava.com>.
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: community-unsubscribe@apache.org
For additional commands, e-mail: community-help@apache.org
RE: primary distribution location
Posted by "Noel J. Bergman" <no...@devtech.com>.
> > 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: community-unsubscribe@apache.org
For additional commands, e-mail: community-help@apache.org
Re: primary distribution location
Posted by "Roy T. Fielding" <fi...@apache.org>.
> 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: community-unsubscribe@apache.org
For additional commands, e-mail: community-help@apache.org
Re: primary distribution location
Posted by Stefan Bodewig <bo...@apache.org>.
On Wed, 5 Feb 2003, Martin van den Bemt <ma...@mvdb.net> 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: community-unsubscribe@apache.org
For additional commands, e-mail: community-help@apache.org
RE: primary distribution location
Posted by Martin van den Bemt <ma...@mvdb.net>.
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:bodewig@apache.org]
> 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 <ma...@mvdb.net> 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: community-unsubscribe@apache.org
> For additional commands, e-mail: community-help@apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: community-unsubscribe@apache.org
For additional commands, e-mail: community-help@apache.org
Re: primary distribution location
Posted by Stefan Bodewig <bo...@apache.org>.
On Wed, 5 Feb 2003, Martin van den Bemt <ma...@mvdb.net> 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: community-unsubscribe@apache.org
For additional commands, e-mail: community-help@apache.org
RE: primary distribution location
Posted by Martin van den Bemt <ma...@mvdb.net>.
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:conor@cortexebusiness.com.au]
> Sent: Wednesday, February 05, 2003 01:01
> To: community@apache.org
> Subject: Re: primary distribution location
>
>
> Rodent of Unusual Size wrote:
> >
> > <board hat="on"> in fact, until such time as a clear determination
> > is made, i'm ruling that it is *not* allowed. it is not worth the
> > risk. so lgpl-licensed materials in the asf repositories are
> > forbidden until a final decision is made. </board>
> >
> > that may seem heavy-handed and arbitrary; i apologise ahead of
> > time, particularly if i turn out to be wrong. however, i am
> > saying this in good faith and in an attempt to do what's right.
> > i will welcome an official answer no less than anyone else.
>
> 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=103833595800005&r=1&w=2
>
>
> Thanks
> Conor
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: community-unsubscribe@apache.org
> For additional commands, e-mail: community-help@apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: community-unsubscribe@apache.org
For additional commands, e-mail: community-help@apache.org
Re: primary distribution location
Posted by Conor MacNeill <co...@cortexebusiness.com.au>.
Rodent of Unusual Size wrote:
>
> <board hat="on"> in fact, until such time as a clear determination
> is made, i'm ruling that it is *not* allowed. it is not worth the
> risk. so lgpl-licensed materials in the asf repositories are
> forbidden until a final decision is made. </board>
>
> that may seem heavy-handed and arbitrary; i apologise ahead of
> time, particularly if i turn out to be wrong. however, i am
> saying this in good faith and in an attempt to do what's right.
> i will welcome an official answer no less than anyone else.
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=103833595800005&r=1&w=2
Thanks
Conor
---------------------------------------------------------------------
To unsubscribe, e-mail: community-unsubscribe@apache.org
For additional commands, e-mail: community-help@apache.org