Alex wrote: > Have others had the same questions before and come to good answers? Or are > these the wrong questions to ask in the first place?
You're not alone; as a contributor and Debian Maintainer I've asked this
question too and it's a very good one. To give a better example of the
phenomenon we're talking about, the first sentence of the GNU GPL 3.0 says
> Everyone is permitted to copy and distribute verbatim copies of this license
> document, but changing it is not allowed.
I share your concern that making a claim in debian/copyright that such a
license text *itself* is libre is technically wrong, and a lie at worst.
I don't recall if I ever uploaded such a package to the Debian archive or if
this were just a draft, but when deciding on the debian/copyright text for some
package I did something along the lines of
Files: COPYING
Copyright: 2007 Free Software Foundation, Inc.
License: FSF-verbatim (this is a name I made up)
Everyone is permitted to copy and distribute verbatim copies of this license
document, but changing it is not allowed.
This isn't something I'd recommend others do widely; in hindsight it's kind of
silly, but I was drove to it after seeing the Lintian warning and was feeling
creative.
Here are some similar issues we might get inspiration from:
• In general, when software requires retaining authorship information or
copyright statements (as most software does), this is still considered libre,
even though it is a prima facie limitation on your ability to redistribute such
a modified version. This policy, which I like to call "integrity of
authorship", is supreme. Even if by unspoken agreement, it is axiomatic that
authors have the right to make their authorship information forever†
inseparable from the work. This might be needed to enforce license terms.
‣ Please note, however, that the author can't require a passage to be
"cemented" into a libre work in general: see Debian's General Resolution about
the GNU Free Documentation License for an example. There it was decided that
"invariant sections"—sections that cannot be removed from the document, but
which contain text other than fundamental integrity of authorship info—do
infringe the freedom to modify and redistribute. Despite common
misunderstanding, GFDL-licensed works are allowed in Debian without additional
reservations as long as they don't have such invariant sections.
• I can't find a reference to the thread at the moment, but on some Debian
mailing list a predicament was pointed out with public keys like OpenPGP keys:
you could say that the private key is the preferred form for modification. In
that thread, the conclusion was similar: a key identifies an author, and as an
identifier and something used to assert integrity of a work (such as a
digitally signed one), it would be plainly absurd to expect the "preferred form
for modification" to be available. If it were to be, the keypair would cease to
be a keypair at all.
From this, I we may infer that specific limitations on modification are
acceptable for the Debian archive, and incorporated into the definition of
"free software" at least informally, when those limitations are minimal but
absolutely necessary to procure a free work. To put it frankly, licenses such
as the GNU GPL are non-free by the textualist interpretation of the definition
of a free work. However, its purpose in being the effective license for the
work it is coupled with makes it, in the circumstances, admissable "as if" it
were libre by the purposivist point of view.
The DEP-5 copyright file is intended to serve the same function as the
copyright and licensing statements in each of a package's files, and in
practice it's usually an aggregation of excerpts from the source files. Just
the same, it is up to the reader to decide if a license is amenable to them,
and as a downstream redistributor would *not* be Debian, by definition, it is
best to omit constructions that could mislead them (such as saying the GNU GPL
text is "free", because it's technically not, even though the DFSG Team may as
well think of it that way). It is important to keep debian/copyright accurate
then, and not embellish details about the "license of a license".
It is more safe to say nothing about the license of a license than to make up
something misleading. So how do we want to handle this?
• Remember that DEP-5 is mainly a proposal, a suggestion, and some situations
are so complex they can't be reflected in DEP-5 at all. For example, there are
situations where a binary package must have the Built-Using header to indicate
that its source is not completely drawn from its own source package, but
perhaps from other source packages. Usually, the built binary package is also
responsible for retaining license info *from those other binary packages from
which it incorporated portions of at build-time*, in which case some creativity
is needed... This is hard to describe succinctly, so if you want examples, look
for source packages that Build-Depends on binutils-source, say.
As DEP-5 doesn't handle the "license of licenses" situation in a
practical and scalable way, it is sensible to omit "license of license"
information altogether.
• Lintian is also just a suggestion. Lintian overrides should ideally not be
used to paper over Lintian bugs or misjudgments that can be fixed in Lintian
itself. Lintian could recognize when a file is a license text and forgive that
file being omitted from debian/copyright, or as an alternative to heuristics a
manual override could be justified. DEP-5 could also introduce a magic
null-like license name or convention for the problem.
Anywho, in conclusion, this mail of mine is an argument to do anything *except*
use a construct that suggests the license text itself is free, such as a broad
"Files: *; License: GPL-3.0". That is incorrect and would imply the user has
certain freedoms which they do not—which is the very worst case scenario for
anything involving curation of copyright and license info. Ben pointed out the
bug against Debian Policy to discuss a solution, and perhaps the Lintian folks
could tailor their checking some, but otherwise use your best judgment. For
your tool, simply omitting the LICENSES/ directory from debian/copyright and
letting Lintian complain about its omission (in the absence of precedent that
silencing it would be okay), is justified, I think, and perhaps your best
choice.
Thanks for your care in working on Debian.
† For this entire discussion, we presume that the author's copyright is still
sound and not expired or retroactively waived.
signature.asc
Description: This is a digitally signed message part
