Mailing-List: contact dev-help@avalon.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Avalon Developers List" <dev@avalon.apache.org>
From: Niclas Hedhman <niclas@hedhman.org>
Organization: Private
To: "Avalon Developers List" <dev@avalon.apache.org>
Subject: Re: [PROPOSAL] Avalon Components project
Date: Wed, 12 Nov 2003 17:11:27 +0800
User-Agent: KMail/1.5
References: <005301c3a849$af0b53e0$0746ca51@IQUITOS>
 <200311112301.39490.niclas@hedhman.org> <3FB1F141.5010202@apache.org>
In-Reply-To: <3FB1F141.5010202@apache.org>
MIME-Version: 1.0
Content-Type: text/plain;
  charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Message-Id: <200311121711.27826.niclas@hedhman.org>

On Wednesday 12 November 2003 16:37, Stephen McConnell wrote:
> Niclas Hedhman wrote:
> >On Tuesday 11 November 2003 19:48, Eric Pugh wrote:
> >>And, since I have lots of ideas for components that all have licensing
> >>issues, why not have a sf.net site?  Maybe instead of Avalonia, just call
> >>it avalon-components..
> >
> >I, for one, agree... I think the only issue with the more hard core Apache
> >guys (I'm not pointing a big finger at you Stephen) is the "endorsement",
> >implied or otherwise, that Avalonia or avalon-components, is given.
>
> IM[HC]O, there are a number of different subjects
>
> (a) the barrier to entry
> (b) licensing
> (c) endorcement

Agree.

> The barrier to entry is a pure policy decision that can be made by the
> entity that is asserting oversite[sic!].

Ok... "Contribute a component -> Committer status" ?

> Equally components using non-ASF
> compatible resources should not impact a ASF/SF decision bacause this is
> simply a question of development time downloading (and seperate from
> deployment). 

I think Cocoon have gone down that road and are a bit confused over what 
constitutes "derived work" in the GPL license. To compile against GPLd code, 
you need the JAR (or source), which you can't host/distribute. OTOH, if you 
make dummy classes just for the compilation, and if needed at deployment, the 
user have to pick up the GPLd elsewhere, then wouldn't the mock classes be 
"derived work"? GPL is also a very "weird" license, and open to a lot of 
interpretations, and I think that's the reason why ASF board decided to 
exclude all (L)GPL code dependency from the codebases. 


> Lastly - the question of endorcement - AFAICS, endorcement
> by Avalon requires oversite by Avalon which leads me to an alternative
> proposition.

That is arguable. Comparison, Tiger Woods endorse Nike products, but don't 
oversee the product development ;o)
Or more closer to home, MySQL officially endorsed the JDBC driver from (forgot 
who) long before it became an official driver.

It is a matter of "to which level"... But never mind.

> The proposal is a Avalon Component project here at Apache - seperate but
> aligned with Avalon.  The project would establish policies that
> facilitated a lower barrier to entry of new component iniatives
> (typically micro-projects dealing with a specific component
> implementation) much in the same way that common manages new projects.

OK. 

> In this scenario - the new project would establish a PMC responsible for
> oversite, content would be licensed under ASL, and the relationship
> between Avalon and the new project would include our focus on the tools
> and technologies dealing with aspects such as technical complicance,
> validation test suites, component repository tools, etc.

Ok.

Back to Eric's questions;
If we can make them "yes", I'm also in favour...

Niclas

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