Gerardo Ballabio writes ("What is the source code (was: [RFC] General
Resolution to deploy tag2upload)"):
> Paul R. Tagliamonte wrote:
> > I wonder if we have a good idea of what the project believes to be the case
> > between #1 and #2:
> >
> > 1) Is the source of a package the debian source distribution?
> > 2) Is the source of a package the VCS where the source is held?
>
> Let me rewrite that in a different way:
>
> 1) is the source of a package the current version of the code? [*]
> 2) is the source of a package the complete history of the project? [**]
Yes, this ks the key question. I agree with you that the
representation doesn't matter for this purpose. [1]
My answer is that it depends on the development practices (mostly, the
development practices of upstream), but for most modern software the
answer is 2.
I should be clear that I thiknk there is room for reasonable
disagreement on this, particularly since the question is so
context-dependent.
> Speaking for myself, I believe the source is "the set of files that
> are required in order to build the package",
Well, *that's* certainly not sufficient. Because intermediate build
products like minified js or whatever, might be sufficient to build
the package.
We want to be able to *study* and *modify* and *share* the package.
Including sharing changes we make with other people working on other
distros or directly with upstream.
This is why the GPL defines "source code" as the "preferred form for
modification".
When upstream maintains the code in git, they (and their users)
typicaly sometimes *use* that git history to decide whether and how to
modify the program. That, after all, is one of the reasons the
history is useful.
In this sense, the history is like comments. You wouldn't think it
was still the source code if all the comments had been stripped out.
> that is, the current version, and only that.
So, I think, often, I would disagree with you about that.
> The history of the project may be useful information as it documents
> how the code was developed, but it is not necessary in order to build
> the package AND it is not necessary in order to develop a modified
> version. One could argue that the "preferred form for modification",
> as per the GPL, includes anything that might provide useful
> information to a developer.
I think it includes the information that upstream have, and which
upstream use as part of the representation of the project.
One way of looking at this is that the point of this rule is that the
upstream is not supposed to be in a better position than one of our
users - at least, not because they lack some of the computer data that
upstream has and uses.
I hope this explains my view. I won't be particularly surprised if
you're not convinced, TBH - as I say, there's definitely room for
disagreement. But I thought it worth setting out my reasoning.
Thanks,
Ian.
[1] If the cover messages contained in files in debian/patches are
part of "the source", they're still part of "the source" if they are
transformed into git commit messages and the actual patch files
deleted.
Conversely, if git commit messages and diffs aren't "source code",
then when they get converted into files in debian/patches they're
still not "source code" and you wouldn't be breaching any principles
if you converted the package to "3.0 (native)", retaining only the
unpacked state, and threw away the patch files.
--
Ian Jackson <ijack...@chiark.greenend.org.uk> These opinions are my own.
Pronouns: they/he. If I emailed you from @fyvzl.net or @evade.org.uk,
that is a private address which bypasses my fierce spamfilter.
