harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tim Ellison <t.p.elli...@gmail.com>
Subject Re: [legal] Mailing list policy
Date Fri, 22 Jul 2005 09:18:58 GMT
It seems that all roads lead back to the discussion of licensing and
philosophy.  Even that has degenerated into name calling which is
unhelpful for building a harmonious and inclusive community.

While I understand perfectly that unifying the existing efforts in
J2SE-space is a goal of Harmony, I believe we need more visibility on
this list of the progress and successes in this space.  Without such
visibility we appear to be going in circles, and many people who
initially expressed great interest in the project will walk away.

To maintain interest and momentum we need to identify some aspect of the
*technology* that we can progress in parallel.  I'd love to have a full
and open discussion on the inter-VM and VM / Class libraries interface.
 If people feel excluded from that discussion then we need a clear
indication that the collaboration blocks will be resolved shortly, or we
propose an alternative topic where we can work together.

Hopefully we can all discuss something like the relative importance of
tools and capabilities in an SDK (javac, javadoc, apt, browser plug-in,
etc), which of these exists and what order to implement those that do
not.  If that doesn't suit, how about a discussion of the classlib
modularity?

Regards,
Tim


-- 

Tim Ellison (t.p.ellison@gmail.com)
IBM Java technology centre, UK.


Mark Wielaard wrote:
> Hi,
> 
> On Fri, 2005-07-15 at 02:40 -0400, Geir Magnusson Jr. wrote:
> 
>>On Jul 14, 2005, at 11:18 AM, Mark Wielaard wrote:
>>
>>>On Thu, 2005-07-14 at 10:17 -0400, Geir Magnusson Jr. wrote:
>>>
>>>>I really understand where you are coming from, and really thought
>>>>about how to present this, because there is no intent to stir up the
>>>>license wars again :)  I had just been receiving questions from many
>>>>people and organizations, and felt that we should just make it clear.
>>>
>>>I would love to discuss and exchange ideas with people  
>>>about core library issues. How to best setup interfaces between the
>>>native platform, runtime and core libraries. And I saw some
>>>suggestions that I was about to comment on. But clearly if we are
>>>going the ASLv2 or the high-way route I won't participate in that
>>>(or at least not through this list).
>>
>>Ok - before we jump to this conclusion, can I ask why?  Can we come  
>>up with some use-cases that illustrate the downside for you?  Is it  
>>just "I won't grant a copyright license for code under AL2"?
> 
> 
> That and I cannot currently accept contributions under AL2 since almost
> all of the existing projects I work with cannot.
> 
> 
>>>Lets do that. Lets make a policy that means contributions can be
>>>shared with projects like GNU Classpath, GCC, Kaffe, CACAO, JamVM,  
>>>etc.
>>>It seems that is what a lot of people have been wanting for a long  
>>>time.
>>>To build a bridge between GNU and Apache. And that is why we started
>>>this Harmony effort in the first place.
>>
>>Any contribution *can* be shared with any other project.  If those  
>>other projects don't like AL2, the contributor can be approached for  
>>a license under GPL, for example.
> 
> 
> But why would we want to make it hard for people to cooperate. We know
> people will want to use the results of harmony in the existing GPL
> projects. So why insist on a GPL-incompatible default policy and not
> just make MIT/X (or some other commonly accepted and compatible license)
> the default for contributions?
> 
> 
>>Now, given that we're rather attached to the Apache License  
>>here at the ASF, I'm not sure we wish to tangle with getting dual  
>>licenses for contributions *here*.
>>
>>However, that said, I would certainly encourage that the code also be  
>>donated by the copyright holder under a mutually acceptable license  
>>for use w/ GPL, although it would be done elsewhere.
>>
>>All of the above is hypothetical - me thinking out loud, at the end  
>>of a long day, and I may have another opinion or a different idea in  
>>the morning.  However, I do want to discuss options...
>>
>>Lets illustrate with use cases?
> 
> 
> The use case is simple. Graeme and Tim posted some interesting ideas on
> class library interfaces. Having worked on GNU Classpath I obviously
> have some experiences with that. And they do have nice ideas, and I do
> think we can prevent some pitfalls that we fell into with GNU Classpath.
> Now I would love to exchange some larger code samples with them as
> Graeme suggested. And I would even like to do that as part of Harmony.
> But with the current "default" policy I have to negotiate about. I wish
> my time and energy was infinite. But since it isn't I like working and
> discussing code that I can actually use in my existing projects.
> 
> Really using ASLv2 as default for this project is like putting up a huge
> sign: "Proprietary software hoarders welcome! Long haired freaky GNU
> people stay out!". Which isn't fun since my best friends are long haired
> freaky GNU people :)
> 
> Cheers,
> 
> Mark

Mime
View raw message