From harmony-dev-return-2168-apmail-incubator-harmony-dev-archive=incubator.apache.org@incubator.apache.org Tue Oct 11 18:25:52 2005
Return-Path:
Delivered-To: apmail-incubator-harmony-dev-archive@www.apache.org
Received: (qmail 56338 invoked from network); 11 Oct 2005 18:25:50 -0000
Received: from hermes.apache.org (HELO mail.apache.org) (209.237.227.199)
by minotaur.apache.org with SMTP; 11 Oct 2005 18:25:50 -0000
Received: (qmail 71268 invoked by uid 500); 11 Oct 2005 18:25:42 -0000
Delivered-To: apmail-incubator-harmony-dev-archive@incubator.apache.org
Received: (qmail 71209 invoked by uid 500); 11 Oct 2005 18:25:41 -0000
Mailing-List: contact harmony-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
List-Help:
List-Unsubscribe:
List-Post:
List-Id:
Reply-To: harmony-dev@incubator.apache.org
Delivered-To: mailing list harmony-dev@incubator.apache.org
Received: (qmail 71198 invoked by uid 99); 11 Oct 2005 18:25:41 -0000
Received: from asf.osuosl.org (HELO asf.osuosl.org) (140.211.166.49)
by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 11 Oct 2005 11:25:41 -0700
X-ASF-Spam-Status: No, hits=0.0 required=10.0
tests=
X-Spam-Check-By: apache.org
Received-SPF: neutral (asf.osuosl.org: local policy)
Received: from [167.206.4.199] (HELO mta4.srv.hcvlny.cv.net) (167.206.4.199)
by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 11 Oct 2005 11:25:43 -0700
Received: from [10.0.1.47] (ool-43560634.dyn.optonline.net [67.86.6.52])
by mta4.srv.hcvlny.cv.net
(Sun Java System Messaging Server 6.2-2.06 (built May 11 2005))
with ESMTP id <0IO700H9CKHTN400@mta4.srv.hcvlny.cv.net> for
harmony-dev@incubator.apache.org; Tue, 11 Oct 2005 14:25:07 -0400 (EDT)
Date: Tue, 11 Oct 2005 14:25:04 -0400
From: "Geir Magnusson Jr."
Subject: Re: [legal] Bulk contribution barrier to entry
In-reply-to: <20051011172441.GA31055@localhost.localdomain>
To: harmony-dev@incubator.apache.org
Message-id:
MIME-version: 1.0
X-Mailer: Apple Mail (2.734)
Content-type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Content-transfer-encoding: 7BIT
References: <96F9F03B-12DD-4439-87A0-870195DEE8D9@apache.org>
<20051011091011.GA21839@localhost.localdomain>
<0895DA70-5FB9-4A89-B8FC-178662EE91C2@apache.org>
<20051011172441.GA31055@localhost.localdomain>
X-Virus-Checked: Checked by ClamAV on apache.org
X-Spam-Rating: minotaur.apache.org 1.6.2 0/1000/N
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