Mailing-List: contact general-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: general@incubator.apache.org
Received-SPF: neutral (hermes.apache.org: local policy)
Subject: RE: Harmony: project purpose
From: Simon Kitching <skitching@apache.org>
Reply-To: skitching@apache.org
To: general@incubator.apache.org
In-Reply-To: <1115437948.4400.59.camel@blackbox>
References: <NBBBJGEAGJAKLIDBKJOPCEGHAPAC.noel@devtech.com>
	 <1115437528.4400.52.camel@blackbox>  <1115437948.4400.59.camel@blackbox>
Content-Type: text/plain
Date: Sat, 07 May 2005 16:05:51 +1200
Message-Id: <1115438751.4400.70.camel@blackbox>
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit

On Sat, 2005-05-07 at 15:52 +1200, Simon Kitching wrote:
> Sorry, the previous email was sent incomplete. I'll try again..
> 
> On Sat, 2005-05-07 at 15:45 +1200, Simon Kitching wrote:
> > On Fri, 2005-05-06 at 23:10 -0400, Noel J. Bergman wrote:
> > > Simon Kitching wrote:
> > > 
> > > > legally isn't it impossible for a GPL'd project and an
> > > > ASF'd project to *have* "synergies"?
> > > 
> > > Not at all.  Individual authors may contribute their own original works, and
> > > do not give up that right.  Furthermore, we can design architectures and
> > > interface specifications that permit pluggability while isolating client
> > > code from the implementation (and license) of the pluggable.  Think how JDBC
> > > or JNDI isolate the code from the service provider classes.  That doesn't
> > > solve distribution issues caused by licensing, but it does address a coding
> > > issue.
> > > 
> > > Right now we're putting a structure -- process and community -- in place.
> > > The goal is to work WITH others.  As with all other ASF projects, we'll be
> > > very careful about provenance when accepting code.
> > 
> But why bother to "work with others"? Why not just join the existing GNU
> Classpath and Kaffe projects and work within them?
> 
> Classpath appears to have no current competitors; it is clearly *the*
> free java class library implementation. And while the GPL/LGPL may not
> be the perfect license for every situation it seems perfectly reasonable
> to me here. Geir indicated in a reply to my earlier posting that there
> were no specific objections to the Classpath license.
> 
> Creating a new project whose purpose is to implement the java core
> libraries surely *must* draw developers away from contributing to GNU
> Classpath, as well as wasting vasts amount of programmer time (unless
> major relicensing from GNU Classpath is possible). I still don't
> understand what benefits might arise from this.

Sorry, I misrepresented Geir a bit here. Geir *did* indicate a
hypothetical situation in which a company could generate a proprietory
product based on an APL classlib but not a GPL'd one.

The example is fairly unlikely, though. I personally feel that the
possible gain by allowing this doesn't make up for the damage likely to
be done to GNU Classpath by drawing developers/users from that project.

Note that Classpath implements *exactly* the Sun specs. So there isn't
much room for proprietory innovation (which is what APL would allow).

> 
> The JVM (ie reimplementing what Kaffe does) is a similar situation. What
> gain is there to create another JVM rather than joining the existing
> Kaffe project and working within it?

Kaffe *is* a little different. I can see companies adapting an existing
JVM to perform proprietory stuff, even to implementing proprietory
(non-java) languages (or, as in Geir's example, optimising for a
particular hardware platform). And an APL'd version would allow
developers to learn how a VM implementation works without any worries
about future accusations of violating the GPL by copying into a later
proprietory project.

I still personally would like to see Kaffe complete before a competing
project is started, though.

Regards,

Simon


---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org