Re: copyright precision
On Wed, 10 Aug 2016 at 11:12:55 +0800, Paul Wise wrote:
> The only possible way to solve this in general terms is, accurate
> document the copyright/license of the source package using the
> machine-readable format and during builds, track the transformation of
> input files in the source package to output files in the binary
> package and then generate the copyright/license information for the
> binary package based on which input files from which source/binary
> packages ended up in the new binary package.
I'm sure this is a very interesting academic exercise, but pragmatically,
why do we want to require ourselves to go to all that effort? For that
matter, is everything we require *now* necessary or desirable?
Broadly, we have two reasons (that I'm aware of) to do legal stuff:
because we want to (it meets some goal that we care about - self-imposed
policy), and because lawyers tell us we are at risk of being sued if we
don't (it meets our goal of being able to continue making Debian -
license compliance).
For software with a reasonably helpful upstream and a reasonably sane
build system, I've often found that jumping through the necessary
hoops to write debian/copyright takes about as long as the rest of the
packaging put together. This is demotivating: I didn't join this project
to copy copyright information around, I joined this project to make an
operating system.
If I have to copy copyright information around to meet our project's
goals (including the goal of obeying copyright law, both because we
want to respect authors' rights and because we don't want to get sued)
then I'll put up with it - but I think we should be clear about why we
do this work, and only require maintainers to do exactly enough of it
to meet its actual goals.
In particular, if this thread comes to the conclusion that more needs to
be done than what maintainers currently do, then it should be something
actionable; and since it will likely create more work for a very large
number of people, it should be backed up by *why* that work is needed.
If the reason turns out to be a ftp-master saying "we have received
legal advice saying that you must do x, y and z, and we are not allowed to
explain further", then that would be unsatisfying but better than nothing;
and at least it would put a boundary on it.
---
Self-imposed policy of DFSG compliance:
One core value in Debian is that all of main is DFSG-compliant.
If we assume that maintainers (and ftpmasters) check the licenses of our
source packages as they are meant to do, and we build all of main's
binary packages from source code in main and other binaries from main,
then all of main that is distributable is trivially DFSG-compliant.
(Some of it might be non-distributable, for instance by being a derived
work of both OpenSSL and something GPL'd; but that's license-compliance,
and we frequently already detect it.)
---
Self-imposed policy of documenting copyright information:
<https://www.debian.org/doc/debian-policy/ch-docs.html#s-copyrightfile>
says "Every package must be accompanied by a verbatim copy of its
copyright information and distribution license", which contains an
implicit assumption that each package *has* a single distribution license.
This is clearly not actually true in practice. The DEP-5 specification
addresses this by allowing the copyright file to specify multiple licenses
which must be complied with simultaneously. Optionally, it also lets the
maintainer specify the licenses of individual source files matched by
filename or glob.
The ftp-masters appear to have interpreted "copyright information" to
require a verbatim quotation of the license grant, except in cases
where there are several similar license grants with trivial differences.
I'm still not clear on why this is, and whether it's because we want to
or because we'll get sued if we don't.
Some of our Policy-compliant copyright files are clearly absurd;
adwaita-icon-theme's is 88K and lists at least over 200 (potential)
copyright holders, mostly for l10n. I find it hard to believe that all
of that is actually necessary or achieving a desirable goal for us.
Meanwhile, linux's copyright file resorts to citing "Linus Torvalds
and many others" as copyright holders. If the kernel was held to the
same standard that is (anecdotally) applied to most other packages,
its copyright file would presumably be impractically huge (or perhaps
more likely, we would no longer have any volunteers willing to either
maintain a Linux kernel package or review it in NEW).
DEP-5 notably omits any syntax for describing the copyright or licenses of
the contents of the *binary* package, which suggests that its authors
(even those who consider it most valuable to specify the licenses of
individual source files) did not consider this to be a goal.
Are we aiming to go further than this by documenting, for instance,
which specific DFSG-compliant license applies to /usr/bin/dbus-daemon,
which specific DFSG-compliant license applies to
/usr/share/doc/dbus-1-doc/html/api/jquery.js, and who their copyright
holders are? If so, why?
I'm not convinced that anyone in Debian has both the necessary legal
expertise (definition of a derivative work in arbitrary jurisdictions)
and the necessary technical expertise (tracing what goes into a binary)
to make a reliable statement about who has a copyright interest in,
for example, /usr/bin/dbus-daemon. I would hope that Debian does not
aim to set policies that mean it will only accept contributions from
copyright lawyers who also happen to be software engineering experts.
At the moment, the best we can do is to provide an incomplete list of
people who have claimed that they *might* have a copyright interest in
that binary; hopefully that's more than enough to achieve our goals.
---
License compliance in general:
One argument for quoting the copyright holders and license information
is that it's for license compliance, particularly compliance with the
GPL.
I'm not sure to what extent this actually holds water: we are willing to
say that we satisfy the GPL's requirement to provide copies of the GPL,
and the source code, by pointing to the nearby copies of base-files.deb
(for the GPL) and the source package (for the GPL and the source
code). From a devil's-advocate point of view: can't we apply the same
reasoning to the copyright information and the license grant?
It is perhaps interesting to observe that Fedora, which is backed by a
well-funded US corporation (i.e. an attractive target for lawsuits),
limits itself to saying this about (for example) dbus:
# The effective license of the majority of the package, including the shared
# library, is "GPL-2+ or AFL-2.1". Certain utilities are "GPL-2+" only.
License: (GPLv2+ or AFL) and GPLv2+
whereas the corresponding Debian package has a 412-line copyright file.
Similarly, ikiwiki has:
# ikiwiki is licensed under GPLv2+, the Python code in plugins/ under
# BSD (2-clause)
License: GPLv2+ and BSD
in Fedora, and 386 lines in Debian.
---
License compliance in Doxygen's jquery.js specifically:
In the case of Doxygen's "jquery.js", if you look at the file itself
(for instance dbus-1-doc has a copy), you'll notice that it contains
copyright and license information for the libraries that went into it
(which is specifically preserved by the minification process). We have
not followed Debian's self-imposed requirement to document copyright
information centrally, but we have obeyed its (permissive) license.
---
Regards,
S
Reply to: