On Mon, 31 Oct 2016 at 17:02:53 +0200, Adrian Bunk wrote:
> The ChangeLog file in the "source" tarball of the hello package is
> generated from the git metadata.
>
> You are saying it is a bug that .git is not shipped in the source
> tarball of GNU hello?
I don't think it is, but I also can't articulate very clearly why I
think that, given that I think omitting git-version-gen *is* a bug.
I think the best I can do is to point out that there is a large
qualitative difference between the build system and the ChangeLog.
The scripts that make up the build system are executable code that we
are expected to run (so we have to be able to trust that they aren't
doing anything malicious), and they do something with functional effects
(so they can have bugs that we have a practical need to fix).
A ChangeLog is a piece of non-executable text describing historical
events: sure, it can have bugs too (changes that are described
incorrectly, or insufficiently clearly, perhaps even in ways that
indirectly cause functional bugs), but in practice we are never going
to fix those bugs (and indeed if we were to consider git history to be
its preferred form for modification, then we *couldn't* fix those bugs
without rewriting history).
If you look at the packages that I maintain in contrib, you'll notice
that I clearly have no problem with non-Free games, particularly
ones with Free engines. I think there's a spectrum between purely
practical/functional engineering at one end, and purely aesthetic art at
the other end, with the vast majority of software somewhere in between
(and game engines considerably closer to the functional end of that
scale than game artwork/levels are). The further something is from the
purely functional end of that scale, the more I'm prepared to tolerate
it being non-Free (although I recognise that this doesn't necessarily
match Debian consensus). I suppose I'm applying similar logic to
"social" documents like changelogs and licensing information: they
are not a piece of practical, functional engineering in the same way
that executable code is, so I don't see a need for them to be treated
entirely equally.
I realise that the Debian Social Contract officially doesn't draw any
distinction between classes of software - that's why we insist that
documentation is just as Free as executable code. However, I also think
that if we try to formulate simple rules based on what is desirable for
executable, functional code - closer to the "engineering" end of my
scale than to the "art" end - and apply them mechanistically to all
software, there's a danger of spending a lot of effort and goodwill
on solving purely theoretical problems for the sake of consistency,
and in the worst case legislating ourselves into irrelevance. The most
obvious example is that if we insisted that license texts must themselves
be released under a Free license, we wouldn't be able to ship anything
GPL'd at all, and that's clearly unacceptable for a Linux distribution :-)
Back to changelogs and git history: while I would prefer to have
complete history available for most software that I plan to modify,
I don't think the absence of that history makes it non-free, and
it is clearly not the case that the authors of the GPL (whose term
"preferred form for modification" we frequently refer to as our best
working definition of source code) considered complete history to be a
necessary part of a source release. Looking at its git history, GNU Emacs
doesn't appear to have even been stored in RCS until 1994, 5 years after
"the preferred form of the work for making modifications to it" appeared
in the GPL version 1. I sometimes think that "*the* preferred form for
modication" is an unhelpful meme, and we should instead be thinking about
"*a* preferred form for modification", acknowledging that the preferred
form is not necessarily unique.
In any case, we are not going to have complete git history shipped in
Debian any time soon, because the ftp-masters have (IMO correctly)
refused to deploy source formats where the entire git history of a
project is uploaded to Debian: they rightly don't want to be responsible
for verifying that the entire history of a project is Free (and in many
cases it isn't).
S
