On Dec 23, 2005, at 2:26 PM, Justin Erenkrantz wrote:
--On December 23, 2005 1:33:34 PM -0800 "Roy T. Fielding"
<[EMAIL PROTECTED]> 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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]