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)
Mime-Version: 1.0 (Apple Message framework v728)
In-Reply-To: <1115438751.4400.70.camel@blackbox>
References: <NBBBJGEAGJAKLIDBKJOPCEGHAPAC.noel@devtech.com>
 <1115437528.4400.52.camel@blackbox> <1115437948.4400.59.camel@blackbox>
 <1115438751.4400.70.camel@blackbox>
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-Id: <1D2A13A3-24E6-44C2-A771-92F0FBDD60FA@apache.org>
Content-Transfer-Encoding: 7bit
From: "Geir Magnusson Jr." <geirm@apache.org>
Subject: Re: Harmony: project purpose
Date: Sat, 7 May 2005 00:25:26 -0400
To: general@incubator.apache.org


On May 7, 2005, at 12:05 AM, Simon Kitching wrote:

> 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.
>

Thank you.  The GPL isn't ok for ASF project, and I don't believe  
that I have said anything to indicate otherwise.

The GPL isn't the license of choice for many people, including me,  
just like the AL isn't for many...  As you can see, I'm not  
interested in a license debate.  I had a long one with Dalibor and  
Simon Phipps in Brazil - the only solution we could come up with the  
resolve things was to eat more of the excellent beef they serve  
there.  We did that several nights in a row :)

> 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).

Well, I would think there are plenty of places for proprietary (and  
otherwise) innovation in the class library.  The API and behavior  
must be compatible, but how you get there is up to you.

>
>
>>
>> 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.

I personally wish Kaffe well, and have no interest in hurting it.  I  
have every interest in working with Dalibor and meeting other Kaffe  
people, and hope that where we can work together is productive for  
them, for us, and any other VM project out there.

I think that it's way too early in this "New Era of Managed Runtime  
Environments" to think that one is enough, no matter what the licensing.

geir

-- 
Geir Magnusson Jr                                  +1-203-665-6437
geirm@apache.org


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