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 Mon, 10 Oct 2005 22:33:30 GMT

On Oct 10, 2005, at 6:17 PM, Danese Cooper wrote:

> Geir,
> This is a special requirement of Harmony?


> Certainly there are plenty of Apache contributions in bulk for  
> which that wasn't the case (TomCat to name one) or where you  
> aggregating "authorship" to Sun in that case?

Yes - we are trying to go an extra step when it comes to harmony,  
because there are multiple implementations of the exact same thing  
out there that aren't under open source licenses, so we wish to be  
sure to protect both those holders of IP, as well as ourselves and  
our users/licensees.


> Danese
> On Oct 10, 2005, at 3:08 PM, 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?
>> -- 
>> Geir Magnusson Jr                                  +1-203-665-6437
>> geirm@apache.org

Geir Magnusson Jr                                  +1-203-665-6437

View raw message