Bug#562920: Including Create Commons v3.0 licenses in /usr/share/common-licenses
Modestas Vainius <modestas@vainius.eu> writes:
> On the other hand, 130+ packages is not such a small number so those
> licenses are still "common" just to a lesser extent. I tend not to view
> "common" as "very popular" but rather "shared by multiple things". So I
> wonder what are the disadvantages of including them in common-licenses?
> What would Debian lose by doing so? They are supposedly DFSG free, more
> than a hundred of packages share it so copyright files of 130+ binary
> packages may potentially become smaller and easier to understand.
There are a few reasons why we generally lean against including licenses
in common-licenses.
First, it's clearer and generally better to keep legal material with the
package and have the license information in a standard and reliable
location. If it's in the copyright file, it's available no matter where
the Debian package goes. When it refers to common-licenses, people have
to go to a different location and it also relies on the package being used
as part of the Debian system and hence having base-files available.
Given that, the primary motivation for common-licenses is not to collect
all the licenses we use but to save some space in the archive and, more
importantly, on users' disks (particularly in embedded environments) for
licenses that are in huge and widespread use in the archive. To take the
obvious example, 19,893 binary packages in Debian refer to some version of
the GPL. We don't want to include 19,893 copies of the GPL in the
archive, and we don't want to install hundreds or thousands of copies of
the GPL on everyone's computer, including embedded systems. This is more
the problem that common-licenses was designed to solve.
But secondly, base-files is a mandatory package on every Debian system,
which means that if we put a license in base-files, we install it on
everyone's system regardless of whether any of the packages on that system
use it or not, in addition to the other drawbacks mentioned above. So the
inclusion criteria, at least from my perspective, is mostly based on
whether it feels just ludicrous to include separate copies of the license
in every package.
Here, for the record, are the usage counts for the licenses currently
included in common-licenses:
Apache 2.0 1119
Artistic 2285
BSD (common-licenses) 1556
GFDL (any) 875
GFDL (symlink) 389
GFDL 1.2 499
GFDL 1.3 67
GPL (any) 19893
GPL (symlink) 10116
GPL 2 9073
GPL 3 2797
LGPL (any) 7183
LGPL (symlink) 2524
LGPL 2 4679
LGPL 2.1 3189
LGPL 3 691
If I had to do it over again, I would have argued against including the
GFDL. At the time, I think we expected it to be used a lot more than it
was because it was FSF-blessed and the other FSF licenses are quite
heavily used, but in practice it seems to be used almost exclusively by
FSF projects and doesn't have much general uptake the way that the GPL and
even the LGPL have had. Apart from the brand new version of the LPGL, to
which people are still migrating, the GFDL family is the only family in
triple digits for binary package counts.
--
Russ Allbery (rra@debian.org) <http://www.eyrie.org/~eagle/>
Reply to: