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] Bulk contribution barrier to entry
Date Tue, 11 Oct 2005 10:35:08 GMT

On Oct 11, 2005, at 4:53 AM, Dermot Dunnion wrote:

> Ooh, my first post. I've been lurking for a few weeks.
> It seems to me that you don't need the permission of every author,  
> what you need is permission of every copyright owner.
> So, if Sun gave you full rights to use J2SE source in any fashion,  
> you would not also need permission from every Sun employee and  
> contractor that ever wrote any code for J2SE. The permission from  
> each author is more applicable to an OSS-developed codebase.

You are absolutely right that we require the permission of the  
copyright owner - that's standard ASF practice - but we got a step  
further in Harmomny : we want to be sure that the software we receive  
_for Harmony_ was written by people with acceptable exposure to other  

We do this latter step to ensure that we can produce software that  
truly is an independent implementation of J2SE, and contains no code  
improperly obtained from other implementations, or have code that  
could be subject to come kind of claim by the copyright holder of  
another implementation.

We are interested in protecting both other copyright holders by  
respecting their rights, and our downstream users by ensuring that  
what they receive under the Apache License has no unforeseen or  
unknown encumbrance, or at least do the best job we can.  (The  
absolute "best job we can" would involve taking monks or some other  
group of people that have been living in isolation, training them to  
be programmers, and getting them to write a full, clean  
implementation from scratch.  That may have it's advantages if said  
monks produced good wine or beer or something, but probably not  
something in scope for this project)

> This distinction may help to define what we need to accept code.
> My personal viewpoint is that if we receive code for which we can't  
> get clear permission, it's a significant risk to use it and we  
> shouldn't.
> However, other may be less risk-averse and therefore we should vote.

Understand that not having copyright owner permission is a total non- 
starter.  We won't even get as far as a vote if we don't have that.


> My idea of an outline process is:
> - get code
> - verify our right to use
> - one of the following:
>      accept (clear right to use)
>      reject (tainted code or (unclear permissions and moderate- 
> value) )
>      vote(valuable code and unclear permissions)
> Dermot Dunnion
> ddunnion@cryptall.com
> Geir Magnusson Jr. wrote:
>> We've now accepted three contributions so far, and I think we have  
>> a  small problem that isn't easy to solve.
>> The problem is that for a bulk contribution - something created   
>> elsewhere and being contributed to harmony - we require that all   
>> authors of that work are Authorized Contributors, meaning that  
>> they  hadn't been exposed to implementations of Java that weren't  
>> either  available under an open source license, or were owned by  
>> an entity  willing to give the author permission to work on other   
>> implementations elsewhere.
>> See http://incubator.apache.org/harmony/  
>> bulk_contribution_checklist.html  Part III
>> This is a very high standard, one that helps ensure clean IP   
>> provenance for our codebase.
>> However, I suspect it will be too high of a standard.  For  
>> example,  suppose the Kaffe project wanted to offer a copyright  
>> license to  their codebase to Harmony?  I bet it can't be done -  
>> we'd have to  chase down every contributor to the codebase and get  
>> the signed  agreement.  Suppose Sun wanted to donate J2SE?  :)   
>> I'm betting they  couldn't provide the necessary documentation  
>> either...
>> So what do we do?
>> We need to balance a few things:
>> 1) Make this flexible enough that the project can choose to  
>> accept  software for which ACQs aren't obtainable from all authors.
>> 2) Make this strong enough that we don't put the project at   
>> unreasonable risk, and that the consumers of the software have   
>> confidence that the codebase is clean.
>> Suggestions?  One possibility is that for those that can't  
>> satisfy  the status quo framework, we have a set of questions that  
>> allow us to  understand the source of the code and the manner in  
>> which it was  developed.  We'd like this to be somewhat objective  
>> yet still give  the project room to reject if it doesn't "feel  
>> right", we want the  process used and information obtained to be  
>> available to the public  so that any interested consumer of our  
>> software can understand where  it came from.
>> Ideas?
> -- 
> No virus found in this outgoing message.
> Checked by AVG Anti-Virus.
> Version: 7.0.344 / Virus Database: 267.11.14/128 - Release Date:  
> 10/10/2005

Geir Magnusson Jr                                  +1-203-665-6437

View raw message