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 11:54:04 GMT

On Oct 11, 2005, at 5:10 AM, Leo Simons wrote:

> On Mon, Oct 10, 2005 at 06:08:20PM -0400, Geir Magnusson Jr. wrote:
>
>> See http://incubator.apache.org/harmony/
>> bulk_contribution_checklist.html  Part III
>>
>> This is a very high standard,
>>
>
> I thought it was a checklist.

Yes.

>
>
>> 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?
>>
>
> Just-in-time revise the process when the problem arrives?

I thought of that at first, but worry that without some objective  
starting point - some minimum set of guidelines - we'd either get  
accused of playing favorites, or not be able to defend a minimum  
provenance standard for our entire codebase.

>
> They check the appropriate checkboxes. For example, Sun donating J2SE
> would check the box "no" and then provide details along
> the lines of
>
> "authors are sun employees."
>
> "attached is a list of sun's employees over the last 10 years who we
> believe have worked on this contribution. Also attached is a list of
> companies which we have agreement such and so forth with."
>
> Now, if and when Sun states that they want to contribute something
> for which they can't fill in the template, we create a new one (its
> versioned isn't it) which they can fill in.
>

Right - the issue isn't "who wrote this" - we assume that if Sun or  
any company brings us code and says "we have the right to donate  
this" we simply take them at their word as expressed by the Software  
Grant or CCLA.  That's the easy part, and what we already do today.   
No problem there.

The issue is "did those that write this have access to an  
implementation for which the owner of that implementation could claim  
an interest in our code if written by those people."  For example,  
suppose some key Sun HotSpot people came to work on a JIT here....

Now, Sun is a terrible example, because our chief worry is that  
someone was exposed to Sun code in a way that creates problems for  
us, and if Sun is donating the code this chief worry goes away.

Choose another company - like my employer, IBM, or BEA or Apple or  
Nokia - all are Sun code licensees - and if not, have their own code  
that they've written....

>
>> 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?
>>
>
> We'll have to change other bits of process too. If sun contributes  
> J2SE
> I doubt we'll want to make all J2SE developers at sun, past and  
> present,
> committers to the project. That's gotta be lots of people!

:)

No - it's not about committers either, but about the contributed  
sourcebase.

>
> I know very little about any of this, but I'll suggest that designing
> ahead of need is not a good idea. If and when we run into problems  
> with
> this process, we will know exactly what the problem actually is and
> what steps would fix that problem.
>
> Software developers will recognize this is as the "extreme  
> programming"
> approach :-)

Erm, yeah.  Like I've said before, a little upfront design goes a  
long way... There's reasons why people don't do XP for anything  
material that has any permanence, like skyscrapers or roads or  
airplanes..  First, it's just too embarrassing and expensive to  
refactor a skyscraper "windows?  you never said anything about  
windows...", and you want to make sure that you can meet the basic  
design goals "What do you mean 'land'?"..

We have a basic legal/process design goal of creating a body of work  
for which we've taken reasonable care to ensure clean origins and no  
encumbrance by 3rd parties.

In our case, when we get contributions, they are in a sense building  
blocks for our work here - depending on the technology, it could be  
very difficult or expensive to go back later and fix, or ensure we  
treat all comers fairly.

Anyway, we don't have a problem now, but this struck me as a bug when  
doing it, so lets at least think about this a bit and suggest some  
possible yardsticks to use.

geir

-- 
Geir Magnusson Jr                                  +1-203-665-6437
geirm@apache.org



Mime
View raw message