> We could link to their site and recommend downloading their jar? :)
We could. Not very convenient for users; just make-work on their part which
would be nice to avoid.
--- Noel
-
To unsubscribe, e-mail: [EMAIL PROTEC
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
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 app
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 li
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
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
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 o
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
> > 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 bi
On Wed, 5 Feb 2003, Martin van den Bemt <[EMAIL PROTECTED]> wrote:
> You do win.. You don't have to have the direct implementation in
> apache cvs and ask if the eg gpl'ed software would include an
> implementation of that in their distro's.
OK, the interface is there, Ant's Task class. I'm just
Bodewig [mailto:[EMAIL PROTECTED]
> Sent: Wednesday, February 05, 2003 09:35
> To: community@apache.org
> Subject: Re: primary distribution location
>
>
> On Wed, 5 Feb 2003, Martin van den Bemt <[EMAIL PROTECTED]> wrote:
>
> > There is a way around all this if you writ
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 r
On Wed, 5 Feb 2003, Martin van den Bemt <[EMAIL PROTECTED]> wrote:
> There is a way around all this if you write an interface that is
> used to be generic, and have the interface implementation stored
> elsewhere.
But "the interface implementation" would have to be LGPLed again, so
you don't real
round
some problems.
Mvgr,
Martin
> -Original Message-
> From: Conor MacNeill [mailto:[EMAIL PROTECTED]
> Sent: Wednesday, February 05, 2003 01:01
> To: community@apache.org
> Subject: Re: primary distribution location
>
>
> Rodent of Unusual Size wrote:
> >
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 questio
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
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'
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
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
Rodent of Unusual Size wrote:
in fact, until such time as a clear determination
is made, i'm ruling that it is *not* allowed. it is not worth the
risk. so lgpl-licensed materials in the asf repositories are
forbidden until a final decision is made.
that may seem heavy-handed and arbitrary; i ap
On Tue, 4 Feb 2003, Andrew C. Oliver wrote:
> >
> >
> > in fact, until such time as a clear determination
> >is made, i'm ruling that it is *not* allowed. it is not worth the
> >risk. so lgpl-licensed materials in the asf repositories are
> >forbidden until a final decision is made.
That's fin
in fact, until such time as a clear determination
is made, i'm ruling that it is *not* allowed. it is not worth the
risk. so lgpl-licensed materials in the asf repositories are
forbidden until a final decision is made.
that may seem heavy-handed and arbitrary; i apologise ahead of
time, partic
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 m
23 matches
Mail list logo
