harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Geir Magnusson Jr." <ge...@apache.org>
Subject Re: [legal] Mailing list policy
Date Thu, 21 Jul 2005 09:52:52 GMT

On Jul 20, 2005, at 2:20 PM, 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.

I understand that, but that only applies to code contributions made  
explicitly on the mail list.

How about any other use cases?

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

No one wants to make it hard for people to cooperate, but we needed  
to clearly state the default policy.

That said, I'm certainly willing to work to accommodate.  I can't  
guarantee success, but I will work for it.

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

So far, I can't grok why you can't discuss those pitfalls.

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

What do you have to negotiate?  We want to define an interface for  
the VM and Class library that is 100% usable by anyone and everyone.   
I always imagined that we'd define the interface, and then each do an  
independent implementation.

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

You are one of my favorite long-haired freaky GNU people, and I'll  
note that no one will ever suggest that Dalibor has long hair...

Seriously... yes, proprietary "software hoarders" are welcome -  
remember, we're about freedom :)   Your problem with the ALv2 isn't  
that it allows hoarding, anyway...


Geir Magnusson Jr                                  +1-203-665-6437

View raw message