Hello,

I want to extend the following section of 12.5 Debian Policy:

Recent Text:

Packages distributed under the Apache license (version 2.0), the Artistic
license, the Creative Commons CC0-1.0 license, the GNU GPL (versions 1, 2, or
3), the GNU LGPL (versions 2, 2.1, or 3), the GNU FDL (versions 1.2 or 1.3),
and the Mozilla Public License (version 1.1 or 2.0) should refer to the
corresponding files under /usr/share/common-licenses, (footnote 9) rather than
quoting them in the copyright file.

New Text:

Packages distributed under the Apache license (version 2.0), the Artistic
(versions 1.0 or 2.0) license, Boost Software License, Version 1.0, the
Creative Commons CC0-1.0 license,the Creative Commons CC-BY (version 3.0 or
4.0), the Creative Commons CC-BY-SA (version 3.0 or 4.0), the GNU Affero
General Public License (AGPLv3)  the GNU GPL (versions 1, 2, or 3), the GNU
LGPL (versions 2, 2.1, or 3), the GNU FDL-NIV (versions 1.2 or 1.3), the
Mozilla Public License (version 1.1 or 2.0), and the SIL Open Font License
(version 1.1) should refer to the corresponding files under /usr/share/common-
licenses, (footnote 9) rather than quoting them in the copyright file.

I can provide the license texts itself as merge request. I started to add them
to the base-files repository under

https://salsa.debian.org/mechtilde/base-
files/-/tree/master/licenses?ref_type=heads

I can also take care about the different bug reports for this task

kind regards

Mechtilde

+1 to the general proposal, although a little detail:

Mechtilde Stehmann <mechtilde@debian.org> writes:
...

What do you intend to convey by changing 'GNU FDL' to 'GNU FDL-NIV'
here?

Assuming you will add the entire verbatim GNU FDL license from upstream,
that license text covers both non-invariant section and invariant
section uses.

Shouldn't a package in non-free (e.g., emacs-non-dfsg) be able to
reference the GNU FDL from common-license?

I don't think it make sense to refer to the GFDL text in any partial
way.  Either something uses GFDL or it doesn't use the GFDL.  It may use
it with non-invariant sections (-> non-free) or without them (-> main),
but it is still the same license.

I suggest merely dropping '-NIV' from the proposed change above.

/Simon

I believe the readability of this paragraph could be greatly improved by
making the list of licenses into a proper bulleted list, each line
containing the description of a self-contained license, rather than
being inlined into a long-running sentence.

/Simon

Hello Simon,

Am 27.04.26 um 22:47 schrieb Simon Josefsson:
 > > I don't think it make sense to refer to the GFDL text in any partial

If all other changes are ok, please remove the addition NIV from my
proposal.

I wanted to make more clear that only the NIV version is DFSG-conform.

Regards

New concrete proposal, based on your proposal and 1) turn it into a
list, 2) dropping NIV.  Thoughts on this version?  Attaching diff-style
patch too if this is easier for review.

/Simon

Policy 12.5

OLD:

Packages distributed under the Apache license (version 2.0), the
Artistic license, the Creative Commons CC0-1.0 license, the GNU GPL
(versions 1, 2, or 3), the GNU LGPL (versions 2, 2.1, or 3), the GNU FDL
(versions 1.2 or 1.3), and the Mozilla Public License (version 1.1 or
2.0) should refer to the corresponding files under
/usr/share/common-licenses, (footnote 9) rather than quoting them in the
copyright file.

NEW:

Packages distributed under the any of the following licenses should
refer to the corresponding files under /usr/share/common-licenses,
(footnote 9) rather than quoting them in the copyright file.

- Apache License (version 2.0),
- Artistic license (versions 1.0 or 2.0)
- Boost Software License Version 1.0
- Creative Commons CC0-1.0 license
- Creative Commons CC-BY (version 3.0 or 4.0)
- Creative Commons CC-BY-SA (version 3.0 or 4.0)
- GNU Affero General Public License (AGPLv3)
- GNU GPL (versions 1, 2, or 3)
- GNU LGPL (versions 2, 2.1, or 3)
- GNU FDL (versions 1.2 or 1.3)
- Mozilla Public License (version 1.1 or 2.0)
- SIL Open Font License (version 1.1)

How much does this enlarge the size of /usr/share/common-licenses and
therefor every Debian system?

Bastian

Simon Josefsson [28/Apr 10:08am +02] wrote:
license text is so common that deduplicating it in this way will save
disk space on the vast majority of Debian systems.  I doubt that all
those licenses meet that criterion.

Also generally the change to the base-files package takes place before
Policy.  The base-files maintainer is more important than the Policy
Editors for these decisions.

Santiago Vila [27/Apr  3:22pm +02] wrote:

I'm sorry, I just posted to #1135097 stating the opposite ..

I think that the "at least 100 packages" part of this proposal is too
low a bar.  But perhaps the traditional "deduplicating it would save
disk space on the majority of Debian installations" is too high a bar.

Any thoughts on something in between?

The last time new licenses were added to base-files was 2018 with #859649
(CC-1.0). First the policy was changed (in 4.1.3.0), then base-files was
changed (in 10.1).

I'm surprised to read this.

Andrey Rakhmatullin [28/Apr  2:26pm +05] wrote:

This was my mistake, please see my other message.

I think that the proposal if fine, since it adds a quite small number of
licenses. If people disagree then please bring measurements.

why do you think so? I think 100 is quite a high bar already.
(assuming we talk source packages.)

i'm surprised that diskspace (in base-files) is even a factor here,
we're talking about kilobytes or maybe a few megabytes.

i'd value maintainer time & ease much higher than a few hundred
or thousand kilobyes of diskspace.

Holger Levsen [28/Apr 10:08am GMT] wrote:

Those 100 could easily be packages that most systems don't have
installed -- or, in particular, that systems that are trying to be
really small almost never have installed.

Really we need to hear from the people who are trying to make the
minimal install of Debian small.  That's not me.

* Sean Whitton <spwhitton@spwhitton.name> [260428 12:26]:

I have a mild interest in keeping small installs small, but I'm
certainly not an expert. I've however done some poking.

Looking at the copyright files of packages installed by `mmdebstrap
forky /dev/null` - IOW a set of packages that can be expected that
every 'normal' install of Debian has (excluding container and
embedded usecases which can and will apply hacks) - yields a few
interesting things:

1) libc, sed have "Boost Software License - Version 1.0 - August
17th, 2003" in their copyright files. Adding this to common-licenses
seems a net positive and could IMO be done immediately without any
negative effects.

2) mawk, libunistring5 use CC-BY-SA 3.0
These packages can be uninstalled. However curl depends on
libunistring5, so once your install wants to talk to the Internet it
probably has to stay.

3) nftables uses CC-BY-SA 4.0
This package can be uninstalled, but again once you want network
connectivity, ...

4) AGPLv3 is NOT present

5) Deduplicating copyright files might be a meaningful disk space
saving, if we actually care about disk space savings.
The install per above has:

* 10 binary packages from src:util-linux adding 30KB copyright per binary
* 6 binary packages from src:systemd adding 13KB copyright per binary
* 5 binary packages from src:e2fsprogs adding 20KB copyright per binary
* 4 binary packages from src:pam adding 10KB copyright per binary
* 4 binary packages from src:krb5 adding 63KB copyright per binary
ff.

I haven't done a full calculation but it seems we could save 1MB in
such an install just by deduplicating the copyright files. Someone
else may be interested in running the same analysis on different
install scenarios, say Live ISOs, Desktop installs, etc.

With my src:util-linux maintainer hat on, I'd welcome tooling and a
corresponding policy change towards copyright file deduplication.

And/or compression might also be of interest.

6) Even in this install scenario we still have some packages not using
https://www.debian.org/doc/packaging-manuals/copyright-format/1.0/ :

   debian-archive-keyring
   gcc-16-base
   libcrypt1
   libgcc-s1
   libgssapi-krb5-2
   libk5crypto3
   libkrb5-3
   libkrb5support0
   libstdc++6


Best,
Chris

Could common-licenses directory be compressed?
That would save a lot of space.

common-licenses is 295k on my system,
but the whole of base files (compressed package) is only 73k

Cheers,
Peter

in Policy 12.5). That would save even more space, it's 63 MB in total on
my machine and 2.1 MB on the aforementioned minimal forky.

I've searched for a policy bug and of course there was one: #491055, filed
in 2008, no discussions after 2008, closed in 2017 for inactivity.

[ trimming Cc lines a little bit, I will read replies from the lists ]

Ok, let's make some kind of declaration here:

The base-files package has not had any new license added in a lot of
years, while the rest of the system has continued to grow exponentially,
as usual. Note that I'm using the word "exponentially" here in the pure
mathematical sense, not in the English sense that "it grows too much".

Most licenses are not really large files by today's standards.

To be consistent, compressing licenses would force all references to
be changed to the compressed version, IMO for very little gain.

I'm more concerned about people copying and pasting the same licenses
over and over again into debian/copyright, as pointed out by Mechtilde.

Therefore, please do not worry about the increased size in the
installed size of base-files after this proposal is approved.
I think we definitely can afford it.

Thanks.

The reason is that the Debian policy team expected this could only be settled
by the NEW team and the legal team so there was no point to debate either way.

Cheers,

I fully agree. My tool of choice here is dh_installdocs --link-doc.

E.g. from kmod:

override_dh_installdocs:
         dh_installdocs -pkmod -plibkmod-dev --link-doc=libkmod2
         dh_installdocs -plibkmod2

Beware: enabling this on an existing package also requires using
dpkg-maintscript-helper (debian/*.maintscript) with dir_to_symlink.

Hello,

Am 28.04.26 um 15:24 schrieb Santiago Vila:

ACk

I prepare a repository locally for the potential Merge Request.

All 8 licenses need ~150 KB

That is less space as they used in an Install ISO than it is published
with each package


If there is consent to follow the proposal with Simon's update in
#1135097 I can prepare a Merge Request with the additional license texts.

Thanks for the constructive discussion.

Kind regards

Santiago Vila <sanvila@debian.org> writes:

Yeah, I agree with this position. I think license texts are small even by
the standards of embedded systems these days. Disk space growth has
continued since previous rounds of this discussion, human time is more
valuable than a few extra bytes of disk consumption, and we're talking
about on the order of 1MiB at most (I suspect less than that). Compared to
the size of the Debian base image, this is very small.

Folks who actively work on embedded Debian should of course feel free to
correct me, but my recollection of past discussions is that they had
roughly the same position.

I think even in the worst case scenario of a system with a ton of Debian
chroots, the incremental size here is highly unlikely to be a significant
factor compared to, e.g., normal growth in the size of the utilities in
the base image. And of course the local system administrator can always
rm -r /usr/share/common-licenses if they really want to. (I doubt anything
important uses files there at runtime.)

On Tue, Apr 28, 2026 at 09:29:56AM -0700, Russ Allbery wrote:
[..]

It might be sensible to have policy allow for this, and thus require
that no packages *use* these files during their normal operation
(and also not in maintscripts, etc).

Except maybe for tools explicitly designed to operate on them (say,
license checkers, devscripts). I hope there is pre-established
wording in policy that could be reused for such an exception.

Chris

I was one of these people. I just deleted /usr/share/doc entirely so I
don't think a couple kb more in there would make any difference.
Certainly it wouldn't have made it for me.

We are talking about /usr/share/common-licenses which is not in
/usr/share/doc ;-)

cu Andreas

Is there objections to using SPDX abbreviations for the file names of
licenses in base-files?

I didn't double-check if that's in the proposal, but I think that's how
it should be done.

If we already deviate from SPDX names, then maybe moving existing files
to SPDX-names, and recommending use of those names, and set up a symlink
would be an improvement.  Or grandfather in them as exceptions, to avoid
unnecessary debian/copyright churn.

It would be nice if SPDX names was mentioned in debian-policy or
base-files/debian/README.source, so we don't forget about this aspect in
the future.  We can always change that policy later on if it turns out
to be a bad idea for some reason (if someone registers FOO`rm -rf /` as
a SPDX license name, perhaps).

/Simon

More generally we could have two packages:
base-files with /usr/share/common-licenses/
and a new package
spdx-license with /usr/share/spdx-licenses/ with all SPDX license used by Debian.
and have a tool that build debian/copyright from spdx-license at build time, so
spdx-license would only be needed when building packages.

Cheers,

Bill Allombert <ballombe@debian.org> writes:

I think that is orthogonal -- but I also think the suggestion is good.

Doesn't 'spdx-licenses' provide this, though?  Maybe not the "tool that
build debian/copyright" part though, but that could be done separately.

https://tracker.debian.org/pkg/spdx-licenses

/Simon

Simon Josefsson <simon@josefsson.org> writes:

In general, I think this is a good idea, but I think it's mostly
meaningful in combination with adopting SPDX license abbreviations across
the board, including in the copyright-format standard. To be clear, I
agree with doing that, but I think it has the most value if it's not done
piecemeal, since ideally the file names in common-licenses should match
the names we use in copyright-format.

(Some symlinking may be required if we have to rename anything; I haven't
checked if that would be the case.)

Chris Hofstaedtler [28/Apr  1:11pm +02] wrote:

Thank you for the feedback.  Seems to me we can prioritise developer
time by adding more licenses to common-licenses, then, with the possible
exception of the AGPL.

Hello all,

Am 30.04.26 um 11:35 schrieb Sean Whitton:

This exception of the AGPL means we will only add 120 KB instead of 150
KB to /usr/share/common-licenses ?


Kind regards

In case my opinion counts:

I think AGPL is common enough and will still save developer time if
added to common-licenses, even if it's not present in the absolutely
minimum Debian system shown by Chris.

Thanks.

This is a different concern that can be solved with better tooling to
generate the copyright file, by automatically including the AGPL when needed.

Cheers,

However, that was never the idea of the original report, and not what I would
like to do.

Does somebody else believe that adding 30k to base-files is too much because
there are not packages in the base system using AGPL?

AFAIK, "common licenses" means just that, common licenses, not "common licenses
in the base system". I believe we would still benefit from adding the AGPL.

Thanks.

Le Fri, May 01, 2026 at 05:05:12PM +0200, Santiago Vila a écrit :

Hi all,

yes, please add the AGPL-3 and the other licenses suggested by Mechtilde
to the common licenses.

For reference, I just ran license-count on coccia after applying the
attached patch.  Here is the output.  By the way, it runs takes only a
few seconds and not 30 minutes as indicated in the source code comments.

AGPL 3                  313
Apache 2.0             7087
Artistic               4270
Artistic 2.0            365
BSD (common-licenses)     3
BSL-1.0                 302
CC-BY 1.0                 3
CC-BY 2.0                16
CC-BY 2.5                11
CC-BY 3.0               256
CC-BY 4.0               249
CC-BY-SA 1.0              9
CC-BY-SA 2.0             46
CC-BY-SA 2.5             19
CC-BY-SA 3.0            461
CC-BY-SA 4.0            352
CC0-1.0                1544
CDDL                     66
CeCILL                   33
CeCILL-B                 16
CeCILL-C                 11
GFDL (any)              588
GFDL (symlink)           53
GFDL 1.2                285
GFDL 1.3                254
GPL (any)             20356
GPL (symlink)           947
GPL 1                  4168
GPL 2                 10658
GPL 3                  7321
LGPL (any)             5310
LGPL (symlink)          192
LGPL 2                 4093
LGPL 2.1               3184
LGPL 3                 1771
LaTeX PPL                52
LaTeX PPL (any)          42
LaTeX PPL 1.3a            1
LaTeX PPL 1.3c           34
MPL 1.1                 178
MPL 2.0                 502
SIL OFL 1.0              10
SIL OFL 1.1             309

The AGPL-3 and Artistic-2.0 are among the licenses promoted as
'standard' for R packages (together with GPL-2 GPL-3 LGPL-2 LGPL-2.1
LGPL-3 BSD_2_clause BSD_3_clause and MIT), which I handle a lot
recently.  https://cran.r-project.org/doc/manuals/R-exts.html#Licensing

And while I aggree to the opinions expressed here that there seems to be
no objections raised directly by users of systems under space
constraints, please note that adding CC-BY-SA-3.0 will not increase the
size of systems using GRUB, and that CC-BY-SA-4.0 licenses are found on
systems that use nftables.
https://lists.debian.org/debian-policy/2026/01/msg00010.html

It is not uncommon that I find these four license when I have to write
new debian/copyright files for r-cran-* and r-bioc-* packages, or when
their upstreams relicense their work.  I would deeply appreciate if they
could be added to the common licenses.

By the way, for the point of view of saving the time of writing, reading
and scrolling to maintainers and reviewers of new packages, maybe the
DFSG, Licensing and New packages team could run license-count regulary
and see which licenses are trending up?   Being proactive would have the
highest impact.

Have a week-end,

Charles

* Santiago Vila <sanvila@debian.org> [260501 17:05]:

I *guess* it's gonna be fine.

As always people likely have different ideas how this selection
came to be and what the presence of the files mean. Maybe this
should be spelled out somewhere, if it's not already done.

Chris