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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
