harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Danese Cooper <dan...@gmail.com>
Subject Re: [legal] Bulk contribution barrier to entry
Date Mon, 10 Oct 2005 22:17:18 GMT
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?

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


Mime
View raw message