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 18:25:04 GMT

On Oct 11, 2005, at 1:24 PM, Leo Simons wrote:

> On Tue, Oct 11, 2005 at 07:54:04AM -0400, Geir Magnusson Jr. wrote:
>
>>>> 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.
>>
>
> OK. I think the minimum set of guidelines is "produce a compliant J2SE
> implementation which can be licensed under the Apache License only".

I think we're talking about two different things.  Yes, that's  
clearly the project goal.

The goal of the legal framework is to support that in a way that  
people are sure of the code they get from us because we are taking  
extra steps to ensure that bulk contributions from outside have some  
pedigree check beyond "do you own the copyright".

All of what we setup is basically a set of questions to get people to  
think about things we believe are important to letting our users be  
comfortable with the pedigree of what we produce.  What I'm saying is  
that right now, the questions are such that for "innocent" cases,  
people will have to answer no.  I want to find a set of questions  
that are a little more reasonable yet still gives us the same level  
of comfort.

> We
> are being extra careful here because of that "only" that's in  
> there. We
> are worried about patents 'n stuff, no?

We are worried about all sorts of things.  Patents are one.  Trade  
secrets are another ("Bob worked on Sun's JIT while at Sun...").   
Copyright is another - but one I believe we can mitigate through  
automated surveillance comparing the codebase against others.

We'll never be 100% sure, but these steps we have no are fairly low  
cost, and provide a fairly substantive base of information to help  
support our pedigree.

>
> So the alternative to our established process is "anything which fits
> the original goal". I don't care one bit whether we'll get accused of
> stuff -- the fact that this project exists causes lots of  
> accusations of
> various kinds.
>
>
>>> 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..
>>
>
> really? From what I hear, they tend to start building an airplane
> even before they know how long or how heavy it will be. They just
> have some educated guesses (which, to be fair, fill like several
> thousand pages) and start building stuff. Fascinating. But very
> off-topic :-)
>

I find that hard to believe... we'll chat about this offline...

>
>> 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.
>>
>
> I don't see the actual bug yet.
>
> In any case, did the above make sense as a yardstick?

Well, no, at least not where I'm coming from.  let me illustrate.

Right now, the question is :

"Can every author of the code you are contributing be considered an  
"Authorized Contributor", meaning that they can sign our document and  
assert they have had no exposure to implementations that either  
weren't under an OSS license, or have the copyright owners permission  
to work on other implementations?"

We've been lucky so far.  For David, Archie and Daniel, they each  
could say "yes",  because each was the solo author.

Now suppose that Dalibor has the ability and desire to contribute the  
Kaffe codebase.  There's no way he could answer that question  
affirmatively, because he can't go off and get all the ACQs.  But  
suppose there was  project policy like ours that prevented  
contributions in areas for which people had prior exposure.  
(Classpath has this, sorta..)  I'd be happy with that.  So we could  
have questions like :

1) Do you know the origin of all the source you are contributing?

2) Did any of the authors have access to another non-OSS  
implementation within X years of authoring the contribution?  If so,  
did they contribute in areas for which they had access?

etc...

I'll need some more time to invent more questions...

So given the answers to questions like this, we as a project could  
decide that we're willing to accept the codebase and be able to  
defend our pedigree.  I hope this makes things a tad clearer...   
Sorry for the confusion...

geir

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



Mime
View raw message