Mailing-List: contact commons-dev-help@jakarta.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Jakarta Commons Developers List" <commons-dev@jakarta.apache.org>
Message-ID: <0a8f01c2ce18$a00da160$02010a0a@GERYON>
From: "Steve Downey" <steve.downey@globeinvestment.com>
To: "Jakarta Commons Developers List" <commons-dev@jakarta.apache.org>
References: 
 <OF2A5325D4.2B3FBC80-ONCA256CC5.00006044-CA256CC5.000187EE@multitask.com.au><09a701c2cdb6$a1615e10$02010a0a@GERYON>
 <m3of5p9xpl.fsf@bodewig.bost.de>
Subject: Re: [Graph2] nsUML license problem
Date: Thu, 6 Feb 2003 14:47:46 -0500
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

OK. Thanks for the reference. A little further down that thread, I finally
got the explanation of why LGPL is no good for ASF code!

http://archives.apache.org/eyebrowse/ReadMsg?listId=135&msgNo=1429

Reading Ken's message in light of this, it's a lot clearer. I'd focused on
this

>if a licence permits *linking* against
>a library, there's no prohibition on our packages requiring
>the library in order to run properly.

But it's clear that the 'viral' nature of LGPL section 6 (i.e.)

... provided that the terms permit modification of the work for the
customer's own use and reverse engineering for debugging such modifications

would attach restrictions on people who use ASF code that the ASF license
does not. e.g. They do not have to allow reverse engineering. So NO LGPL
imports.

OTOH, if someone had an LGPL implementation of a 'standard' interface, e.g.
the java crypto api, or an xml parser, that should be OK, since there
wouldn't be any LGPL code in the ASF code.

Is MPL or MPL-derived code OK? This is actually on point, as there may be a
replacement for the nsuml library available from the NetBeans project, which
uses the Sun Public License, which is a search-and-replace version of the
Mozilla Public License.

NSUML is being abandoned, and I've seen traffic on the argouml list
regarding replacing it with the metadata repository (MDR) library from
NetBeans.

Moreover, I'm actually interested in this because I use statecharts to model
servlet activity, and have done a few handwritten code generators for them.
I hadn't noticed before this that graph had anything to do with it.

----- Original Message -----
From: "Stefan Bodewig" <bodewig@apache.org>
To: <commons-dev@jakarta.apache.org>
Sent: Thursday, February 06, 2003 11:32 AM
Subject: Re: [Graph2] nsUML license problem


> On Thu, 6 Feb 2003, Steve Downey <steve.downey@globeinvestment.com>
> wrote:
>
> > Would it be possible to take an approach analagous to Ant's optional
> > tasks?
>
> I'm pretty sure there is no optional task that depends on an LGPLed
> library.
>
> > That is, distribute the code that _uses_ the API, but not distribute
> > the library itself?
>
> See this mail
>
>
<http://archives.apache.org/eyebrowse/ReadMsg?listName=community@apache.org&
msgNo=1419>
>
> where Roy clearly states that one import statement is too much.
>
> > Based on what Ken posted, it looks like linking against a LGPL
> > library is OK, while distributing it is not.
>
> Please read Ken's mail again.
>
> Stefan
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>
>
>


---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org