Hi gang,
I agree with Roy from a policy point of view. From a pragmatism point
of view I think the policy is "we SHOULD preserve history for existing
open source projects", but not a "MUST", because of the technical
difficulties (with SVN, no doubt solvable. With some other stuff (eg
bugzilla), less so).
I think for commercial projects, it'd be the ideal case that a commercial
party donates not just a code dump, but revision and development history
as well. Looking at OpenSolaris it is apparently sometimes possible to
retro-actively open source the "history" of a project too. I think in this
case its more a "MAY" than a "SHOULD" since there are a lot of "IF AND ONLY
IF"s.
cheers,
- Leo
On Fri, Dec 23, 2005 at 10:38:57PM -0800, Roy T. Fielding wrote:
> 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]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
