incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Simon Kitching <>
Subject RE: Harmony: project purpose
Date Sat, 07 May 2005 04:05:51 GMT
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.



To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message