Mailing-List: contact general-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: general@incubator.apache.org
Received-SPF: neutral (asf.osuosl.org: local policy)
Mime-Version: 1.0 (Apple Message framework v746.2)
In-Reply-To: <8B8951EDDAF055F941932151@st-augustin.ics.uci.edu>
References: <4C2735AC-FA28-4584-BECD-4B43244852A5@apache.org>
 <B4DD9789EA5E3B0F11BD56B1@st-augustin.ics.uci.edu>
 <FF1AFB09-CA1E-4A7E-8F47-9083A2B63B6E@gbiv.com>
 <8B8951EDDAF055F941932151@st-augustin.ics.uci.edu>
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-Id: <F6015642-2747-409E-A50B-C32D840B689E@gbiv.com>
Content-Transfer-Encoding: 7bit
From: "Roy T. Fielding" <fielding@gbiv.com>
Subject: Re: [policy] bring in full code history on incubated project?
Date: Fri, 23 Dec 2005 22:38:57 -0800
To: general@incubator.apache.org

On Dec 23, 2005, at 2:26 PM, Justin Erenkrantz wrote:

> --On December 23, 2005 1:33:34 PM -0800 "Roy T. Fielding"  
> <fielding@gbiv.com> wrote:
>
>> I disagree with Justin on these points.  We must have a clean  
>> break when
>> the code comes from a private source repository, since the history  
>> may
>> contain information that has never been revealed to the public.
>>
>> However, when a public open source code base comes to the ASF, we can
>> and should keep the full history.  The history is already public, so
>> the ASF cannot be responsible for making it public.  Oversight is
>> irrelevant here because the ASF is not responsible for any of the
>> content within the history -- it is already public knowledge.  I  
>> does,
>> however, retain the author information, which is desired by us  
>> because
>> it allows credit to remain where it is due and allows everyone to
>> keep track of who needs to agree to the move.
>
> Is that a question of disclosure or responsibility?

Both.

> Is your argument predicated on the fact that the ASF assumes no  
> responsibility for the content of the imported history?

No, that is a fact -- the ASF doesn't acquire responsibility for past
acts simply by redistributing the code.  The entire repository is
simply licensed to us for redistribution.

> Are we shielded if it turns out that older releases did bad legal  
> things that no longer apply to our code?

Yes.  We are not responsible, and in any case we only have a license.

> Is it permissible to commit code to our repositories that were  
> under, say, GPL (for when a project, like SA, re-licenses)?

Yes. Relicensing means the copyright owners offer a different set
of terms for the same code -- they do not have to change the files
for that to take effect.

> To put my Roy hat(tm) on, I'll venture to guess that your response  
> will stem from the fact that the only cause for action is issuing a  
> release. Therefore, since we didn't release that old code (of which  
> we know nothing), it doesn't matter what we have in our code  
> repositories.  Even if external committers didn't approve their  
> changes to be a Contribution to the ASF when the project transfers,  
> as long as we don't issue a release with that offending code, then  
> we're fine.  Having items that are explicitly 'Not a Contribution'  
> are okay in our source control is fine as long as it doesn't get  
> released?  In fact, it'd be in our best interest to have the public  
> history at our disposal so that we can trace the lineage as needed  
> for purity purposes.
>
> Am I close?  If so, then yes, I understand your reasoning.

Close enough.  Also, if one of those people goes psychotic and tries
to sue the ASF for copyright infringement, we merely point out that
the publication in subversion is no different from the open source
license that they originally published under.

> However, I'm concerned with altering the perception that everything  
> in our code repositories was done on our lists.  Instead, we'll now  
> be conveying all of the oddball things that happened externally -  
> be it at codehaus, SourceForge, tigris.org, or wherever.

That's life.  How much code under httpd "was done on our lists"?
Probably more than any other project, yet I can still point to
several thousand lines that were not.

>>> There is a lesser point that taking in the author information from
>>> a separate project is awkward.  This presents conflicts with our
>>> user account information and muddy things up if we ever have to do
>>> an audit.  -- justin
>>
>> Why don't we just run a script on the package before import, e.g.
>>
>>     perl -pi -e 's/author/codehaus_author/g;' file
>>
>> for the case of codehaus usernames.
>
> Subversion will look for an svn:author revision property.  We could  
> change the svn:author field in the dumps to be an asf:external- 
> contributor field or whatever and leave svn:author blank ("no  
> author"), but I'm not quite sure how I feel about that.

I think you are missing the point.  Apache traditionally has said that
authors are given credit for their work within the changelog and
version history.  Removing the history from a previous open source
project scrubs the credits for the original authors.  At least one
potential contributor finds that offensive.

What I suggested was prefixing each author in the old dump with
something to indicate that author name came from some other subversion
or cvs namespace, thereby avoiding the conflict with our own names
while still retaining credit for the original developers.

....Roy


---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org