Debian Bug report logs - #885698
Update and document criteria for inclusion in /usr/share/common-licenses

Reply or subscribe to this bug.

Display info messages

Message #5 received at [email protected] (full text, mbox, reply):

From: Sean Whitton <[email protected]>

To: [email protected]

Subject: Update and document criteria for inclusion in /usr/share/common-licenses

Date: Fri, 29 Dec 2017 09:49:44 +0000

[Message part 1 (text/plain, inline)]

Package: debian-policy
Severity: important
X-debbugs-cc: [email protected]
Control: block 795402 by -1
Control: block 883966 by -1
Control: block 884223 by -1
Control: block 884226 by -1
Control: block 884227 by -1
Control: block 884228 by -1
User: [email protected]
Usertags: normative discussion

Hello [email protected],

Our current criteria for including licenses, as Markus Koschany smartly
puts it in #884228, is "[a]pparently something between gut feeling and
the popularity of our least preferred license in common-licenses."  We
can and should do better than this.

In the air is also the idea that we include licenses in common-licenses
to save disk space on low disk space systems: the license should be
popular enough such that the reduced size of d/copyright files will
outweigh the increased size of base-files.

We should write down our criteria in Policy, in section 12.5 (or
possibly in the Policy Changes Process appendix).  We should probably
say too that the application of the criteria is at the discretion of the
Policy Editors.  Before we can do that, however, we need to consider
whether the criteria need to be updated.

The only point of clear consensus -- at least among the Policy Editors
-- is that short licenses which have more than one popular variant
should never be included because of the risk that packages licensed
under one variant incorrectly refer to a different variant in
common-licenses.  This problem actually exists in the archive because a
BSD variant was included in common-licenses at some point.  We should
include this point the Policy Manual.

Otherwise, here are some of the arguments on the table:

(1) In a related d-devel thread, someone working with embedded systems
suggested that these days, either a system has enough disk space that
common-licenses isn't relevant, or it has so little disk space that all
of /usr/share/doc must be deleted.  If this is right, disk space
concerns should not decide what goes into common-licenses.  Is it right?

(2) Some people want more licenses in common-licenses because they find
it more convenient.  Convenient processes save our volunteers' time.  We
frequently get requests to expand common-licenses and I suspect that
many of them are motivated by the belief that it would make the
requestor's work more convenient.  If disk space issues aren't relevant
anymore, an increase in convenience might become a dominating criterion
for inclusion.  However, this point has been disputed: better tools
could provide license text formatted suitably for d/copyright, which
would be just as convenient (e.g., in Emacs: `C-u M-!
get-formatted-license GPL-3` would be about as convenient as it gets).
And there surely exist those who find common-licenses makes editing
d/copyright less convenient...

I'm not sure how to proceed.  It would be nice to verify (1) with other
people working with embedded systems.  Possibly we should ask on one of
our more specialised mailing lists.  And there are surely other
arguments besides (1) and (2).  We should gather those in this bug.

#884228 has further points of discussion, but I'd ask that we restrict
ourselves in this bug to discussing what the criteria for inclusion
should be.  In particular, let's not discuss the proposal to add all
known DFSG-free licenses to common-licenses.  Whether that proposal is
valid depends on our criteria for inclusion, so let's stick to hashing
our those criteria in this bug.

-- 
Sean Whitton

[signature.asc (application/pgp-signature, inline)]

Message #22 received at [email protected] (full text, mbox, reply):

From: Paul Hardy <[email protected]>

To: [email protected]

Subject: Re: Update and document criteria for inclusion in /usr/share/common-licenses

Date: Wed, 17 Oct 2018 20:03:01 -0700

Control: block 910548 by -1

Blocking my own bug report with this one, which I just noticed.

I submitted bug #910548 previously against the base-files package:
"base-files - please consider adding
/usr/share/common-licenses/Unicode-Data".

I had formatted the copyright and license information for Unicode data
files from the http://unicode.org website to put in the
debian/copyright file in a package that I created this summer.  The
copyright information is more involved than most copyright statements,
so I kept it in what I submitted with the bug report.

I thought if that license was something Debian found useful, there
would be no need for anyone else to duplicate the effort of formatting
that I had gone through once, and so I offered it.  Just the license
in isolation could be formatted like other licenses fairly quickly if
the copyright section is not wanted.  Or the whole thing can be left
out and that bug closed, as you wish.

Thanks,


Paul Hardy

Message #37 received at [email protected] (full text, mbox, reply):

From: "Accounts Receivable" <[email protected]>

To: Recipients <[email protected]>

Subject: Payment Advice Note from 05/11/2023

Date: Fri, 12 May 2023 07:36:05 -0700

[Message part 1 (text/plain, inline)]

Good morning,
  
 Attached please find your PDF account statement and invoice as of 05/11/2023. Please notice you have a past due balance  for invoice IN0099203.
  
 Please provide payment as soon as possible.
  
  
  
  
 Best Regards,
 Shawneen Chisholm
 Accounts Receivable Coordinator
  
 UNITED RENTALS, INC.
Branch L02 BONNYVILLE
4920 56TH AVE
BONNYVILLE AB T9N 2N8 CA
780-826-7610
  
  
 CONFIDENTIALITY NOTICE: The contents of this email message and any attachments are intended solely for the addressee(s). This may contain confidential and/or privileged information and may be legally protected from disclosure. If you are not the intended recipient of this message, please alert the sender immediately by reply email and then delete this message and any attachments. Any disclosure, reproduction, distribution or other use of this message or any attachments by an individual or entity other than the intended recipient is prohibited

[Message part 2 (text/html, inline)]

[Message part 3 (application/octet-stream, =?utf-8?q?attachment=3B_filename=3D=22Payment_Advice_N?=)]

Message #42 received at [email protected] (full text, mbox, reply):

From: "Accounts Receivable" <[email protected]>

To: Recipients <[email protected]>

Subject: Payment Advice Note from 05/11/2023

Date: Fri, 12 May 2023 07:36:19 -0700

[Message part 1 (text/plain, inline)]

Good morning,
  
 Attached please find your PDF account statement and invoice as of 05/11/2023. Please notice you have a past due balance  for invoice IN0099203.
  
 Please provide payment as soon as possible.
  
  
  
  
 Best Regards,
 Shawneen Chisholm
 Accounts Receivable Coordinator
  
 UNITED RENTALS, INC.
Branch L02 BONNYVILLE
4920 56TH AVE
BONNYVILLE AB T9N 2N8 CA
780-826-7610
  
  
 CONFIDENTIALITY NOTICE: The contents of this email message and any attachments are intended solely for the addressee(s). This may contain confidential and/or privileged information and may be legally protected from disclosure. If you are not the intended recipient of this message, please alert the sender immediately by reply email and then delete this message and any attachments. Any disclosure, reproduction, distribution or other use of this message or any attachments by an individual or entity other than the intended recipient is prohibited

[Message part 2 (text/html, inline)]

[Message part 3 (application/octet-stream, =?utf-8?q?attachment=3B_filename=3D=22Payment_Advice_N?=)]

Message #49 received at [email protected] (full text, mbox, reply):

From: Russ Allbery <[email protected]>

To: [email protected]

Cc: [email protected]

Subject: What licenses should be included in /usr/share/common-licenses?

Date: Sat, 09 Sep 2023 20:35:27 -0700

Hello everyone,

I come seeking your opinions.  Please cc [email protected] on replies
so that we can accumulate this discussion in a Debian Policy bug.

One of the responsibilities of the Policy Editors is to determine which
licenses should be included in /usr/share/common-licenses, and thus do not
have to be reproduced in the copyright file of every package that use
them.  We have never had a clear criteria for this.  We need one, so that
we can advertise a clear and transparent policy for inclusion without
having the conversation from first principles for each new license.

I was the one who made the last few decisions, and I based the decision
largely on the number of binary packages in Debian using the license.
When I was doing this, I set a fairly high threshold (more packages than
the least popular package currently in /usr/share/common-licenses, which
historically has been GFDL-1.3 although it now appears to be MPL-1.1).  No
one was entirely satisfied with that criteria, including me.

I have the following questions:

1. What criteria (besides the obvious one of being a DFSG-free license)
   should we apply when deciding what licenses to include?  Number of
   packages?  Length?  How positive we feel towards the license?  Some
   combination of these things?  Please be specific.

2. If we use number of packages as a criteria, what should the threshold
   be?  I have appended to the bottom of this message the current output
   of my ad-hoc license-count tool run against the current archive so that
   you have a feeling for how many packages use various licenses.

3. If we use number of packages, should that be source packages or binary
   packages?  Source packages represent maintainer effort; binary packages
   represent disk clutter.

4. Should there be a length cutoff for licenses, such that we do not
   include in /usr/share/common-licenses any license shorter than some
   number of lines or bytes?  The justification would be that telling
   people to go look elsewhere for the license has some inherent overhead
   and annoyance when they discover that the license is all of ten lines
   and could have just been included in the copyright file.

5. Should we exclude licenses that contain text that all or most users of
   the license customize when they use it?  For example, the existing
   /usr/share/common-licenses/BSD contains the clause:

      3. Neither the name of the University nor the names of its
         contributors may be used to endorse or promote products derived
         from this software without specific prior written permission.

   which users of this specific license usually change to instead include
   the name of their organization, or their name, or something else.  Full
   disclosure: it will be very hard to convince me that licenses used this
   way should be included in common-licenses, since I believe it is
   technically incorrect to omit a license and point to the
   common-licenses version when the provisions of the common-licenses
   version are different in detail due to naming different people or
   requiring or prohibiting mentioning of different names as endorsements.

Here are various concerns that people have had in this area in the past.
I'm neither indicating agreement nor disagreement with any of these
points, only listing them to provoke thought about some of the things
people have raised before.

* Including long legal texts in debian/copyright, particularly if one
  wants to format them for copyright-format, is tedious and annoying and
  doesn't benefit our users in any significant way, and therefore we
  should include as many licenses as possible in common-licenses to spare
  people that work.

* common-licenses consumes disk space on every installed Debian system of
  any size, and therefore should be kept small to avoid wasting system
  resources.

* Every appproved DFSG license should be included in common-licenses so
  that it serves as a repository of licenses the project has approved.

* Including a license in common-licenses implies that the project approves
  of that license, and therefore licenses such as the LaTeX Project Public
  License 1.0, which requires renaming derived works, should not be
  included even though DFSG #4 grudgingly allows for this type of license
  term.

* All licenses explicitly mentioned in the Debian Free Software Guidelines
  should be present in common-licenses (as justification for including the
  BSD license even though the current text is specific to the Regents of
  the University of California).

In order to structure the discussion and prod people into thinking about
the implications, I will make the following straw man proposal.  This is
what I would do if the decision was entirely up to me:

    Licenses will be included in common-licenses if they meet all of the
    following criteria:

    * The license is DFSG-free.
    * Exactly the same license wording is used by all works covered by it.
    * The license applies to at least 100 source packages in Debian.
    * The license text is longer than 25 lines.

I will attempt to guide and summarize discussion on this topic.  No
decision will be made immediately; I will summarize what I've heard first
and be transparent about what direction I think the discussion is
converging towards (if any).

Finally, as promised, here is the count of source packages in unstable
that use the set of licenses that I taught my script to look for.  This is
likely not accurate; the script uses a bunch of heuristics and guesswork.

AGPL 3                  277
Apache 2.0             5274
Artistic               4187
Artistic 2.0            337
BSD (common-licenses)    42
CC-BY 1.0                 3
CC-BY 2.0                15
CC-BY 2.5                13
CC-BY 3.0               240
CC-BY 4.0               159
CC-BY-SA 1.0              8
CC-BY-SA 2.0             48
CC-BY-SA 2.5             16
CC-BY-SA 3.0            425
CC-BY-SA 4.0            237
CC0-1.0                1069
CDDL                     67
CeCILL                   30
CeCILL-B                 13
CeCILL-C                  9
GFDL (any)              569
GFDL (symlink)           55
GFDL 1.2                289
GFDL 1.3                231
GPL (any)             20006
GPL (symlink)          1331
GPL 1                  4033
GPL 2                 10466
GPL 3                  6783
LGPL (any)             5019
LGPL (symlink)          265
LGPL 2                 3850
LGPL 2.1               2926
LGPL 3                 1526
LaTeX PPL                46
LaTeX PPL (any)          40
LaTeX PPL 1.3c           32
MPL 1.1                 165
MPL 2.0                 361
SIL OFL 1.0              11
SIL OFL 1.1             258

-- 
Russ Allbery ([email protected])              <https://www.eyrie.org/~eagle/>

Message #54 received at [email protected] (full text, mbox, reply):

From: Jonas Smedegaard <[email protected]>

To: [email protected]

Cc: [email protected]

Subject: Re: What licenses should be included in /usr/share/common-licenses?

Date: Sun, 10 Sep 2023 07:14:13 +0200

[Message part 1 (text/plain, inline)]

Quoting Russ Allbery (2023-09-10 05:35:27)
> In order to structure the discussion and prod people into thinking about
> the implications, I will make the following straw man proposal.  This is
> what I would do if the decision was entirely up to me:
> 
>     Licenses will be included in common-licenses if they meet all of the
>     following criteria:
> 
>     * The license is DFSG-free.
>     * Exactly the same license wording is used by all works covered by it.
>     * The license applies to at least 100 source packages in Debian.
>     * The license text is longer than 25 lines.

I fully support the above proposed criteria, and appreciate your
initiative to have this conversation.


 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/
 * Sponsorship: https://ko-fi.com/drjones

 [x] quote me freely  [ ] ask before reusing  [ ] keep private

[signature.asc (application/pgp-signature, inline)]

Message #59 received at [email protected] (full text, mbox, reply):

From: Enrico Zini <[email protected]>

To: Russ Allbery <[email protected]>

Cc: [email protected], [email protected]

Subject: Re: What licenses should be included in /usr/share/common-licenses?

Date: Sun, 10 Sep 2023 10:58:27 +0530

On Sat, Sep 09, 2023 at 08:35:27PM -0700, Russ Allbery wrote:

>     Licenses will be included in common-licenses if they meet all of the
>     following criteria:
> 
>     * The license is DFSG-free.
>     * Exactly the same license wording is used by all works covered by it.
>     * The license applies to at least 100 source packages in Debian.
>     * The license text is longer than 25 lines.

I like this. I'd say that even if a license is shorter than 25 lines I'd
appreciate to be able to link to it instead of copypasting it.

I like to be able to fill the license field with a value, after checking
that the upstream license didn't diverge from what it looks like. I'd
love to use SPDX IDs there, for example. In an ideal world, I'd like to
autofill debian/copyright with SPDX IDs from upstream metadata. Having a
link to a file goes closer to having a declarative license ID.

In general the less bytes I have to maintain in debian/* the happier I
am, and as a personal aesthetic sense I feel like the less bytes we all
have to maintain in debian/* the less is our collective maintenance
burden.


Enrico

-- 
GPG key: 4096R/634F4BD1E7AD5568 2009-05-08 Enrico Zini <[email protected]>

Message #64 received at [email protected] (full text, mbox, reply):

From: Russ Allbery <[email protected]>

To: [email protected]

Cc: [email protected]

Subject: Re: What licenses should be included in /usr/share/common-licenses?

Date: Sat, 09 Sep 2023 22:41:48 -0700

Hideki Yamane <[email protected]> writes:
> Russ Allbery <[email protected]> wrote:

>>     Licenses will be included in common-licenses if they meet all of the
>>     following criteria:

>  How about just pointing SPDX licenses URL for whole license text and
>  lists DFSG-free licenses from that? (but yes, we should adjust short
>  name of licenses for DEP-5 and SPDX for it).

Can we do this legally?  If we can, it certainly has substantial merits,
but I'm not sure that this satisfies the requirement in a lot of licenses
to distribute a copy of the license along with the work.  Some licenses
may allow that to be provided as a URL, but I don't think they all do
(which makes sense since people may receive Debian on physical media and
not have Internet access).

-- 
Russ Allbery ([email protected])              <https://www.eyrie.org/~eagle/>

Message #69 received at [email protected] (full text, mbox, reply):

From: Hideki Yamane <[email protected]>

To: Russ Allbery <[email protected]>

Cc: [email protected], [email protected]

Subject: Re: What licenses should be included in /usr/share/common-licenses?

Date: Sun, 10 Sep 2023 14:30:07 +0530

On Sat, 09 Sep 2023 22:41:48 -0700
Russ Allbery <[email protected]> wrote:
> >  How about just pointing SPDX licenses URL for whole license text and
> >  lists DFSG-free licenses from that? (but yes, we should adjust short
> >  name of licenses for DEP-5 and SPDX for it).
> 
> Can we do this legally?  If we can, it certainly has substantial merits,
> but I'm not sure that this satisfies the requirement in a lot of licenses
> to distribute a copy of the license along with the work.  Some licenses
> may allow that to be provided as a URL, but I don't think they all do
> (which makes sense since people may receive Debian on physical media and
> not have Internet access).

 Hmm, how about providing license-common package and that depends on
 "license-common-list", and ISO image provides both, then? It would be
 no regressions.


 I expect license-common-list data as below

 license-short-name: URL
 GPL-2: file:///usr/share/common-licenses/GPL-2
 Boost-1.0: https://spdx.org/licenses/BSL-1.0.html

-- 
Hideki Yamane <[email protected]>

Message #74 received at [email protected] (full text, mbox, reply):

From: Marco d'Itri <[email protected]>

Cc: [email protected], [email protected]

Subject: Re: What licenses should be included in /usr/share/common-licenses?

Date: Sun, 10 Sep 2023 10:49:28 +0200

[Message part 1 (text/plain, inline)]

On Sep 10, Enrico Zini <[email protected]> wrote:

> I like this. I'd say that even if a license is shorter than 25 lines I'd
> appreciate to be able to link to it instead of copypasting it.
Me too.

> I like to be able to fill the license field with a value, after checking
> that the upstream license didn't diverge from what it looks like. I'd
> love to use SPDX IDs there, for example. In an ideal world, I'd like to
> autofill debian/copyright with SPDX IDs from upstream metadata. Having a
> link to a file goes closer to having a declarative license ID.
Agreed.

-- 
ciao,
Marco

[signature.asc (application/pgp-signature, inline)]

Message #79 received at [email protected] (full text, mbox, reply):

From: Jonas Smedegaard <[email protected]>

To: [email protected], [email protected]

Subject: Re: What licenses should be included in /usr/share/common-licenses?

Date: Sun, 10 Sep 2023 11:25:56 +0200

[Message part 1 (text/plain, inline)]

Quoting Hideki Yamane (2023-09-10 11:00:07)
> On Sat, 09 Sep 2023 22:41:48 -0700
> Russ Allbery <[email protected]> wrote:
> > >  How about just pointing SPDX licenses URL for whole license text and
> > >  lists DFSG-free licenses from that? (but yes, we should adjust short
> > >  name of licenses for DEP-5 and SPDX for it).
> > 
> > Can we do this legally?  If we can, it certainly has substantial merits,
> > but I'm not sure that this satisfies the requirement in a lot of licenses
> > to distribute a copy of the license along with the work.  Some licenses
> > may allow that to be provided as a URL, but I don't think they all do
> > (which makes sense since people may receive Debian on physical media and
> > not have Internet access).
> 
>  Hmm, how about providing license-common package and that depends on
>  "license-common-list", and ISO image provides both, then? It would be
>  no regressions.
> 
> 
>  I expect license-common-list data as below
> 
>  license-short-name: URL
>  GPL-2: file:///usr/share/common-licenses/GPL-2
>  Boost-1.0: https://spdx.org/licenses/BSL-1.0.html

Ah, so what you propose is to use file URIs.

I guess Russ' response above was a concern over using http(s) URIs
towards a non-local resource.

What I practice since some years is the following syntax:

Files: foo/bar
Copyright:
  2022  Someone
License: Apache-2.0 or Expat

License: Apache-2.0
Reference: /usr/share/common-licenses/Apache-2.0

License: Expat
 [the full contents of the Expat license]

That syntax introduces a new field "Reference" (our copyright file
format permits new fields, despite lintian complaining about it).
Related discussion is at https://bugs.debian.org/786450


 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/
 * Sponsorship: https://ko-fi.com/drjones

 [x] quote me freely  [ ] ask before reusing  [ ] keep private

[signature.asc (application/pgp-signature, inline)]

Message #84 received at [email protected] (full text, mbox, reply):

From: Hideki Yamane <[email protected]>

To: Russ Allbery <[email protected]>

Cc: [email protected], [email protected]

Subject: Re: What licenses should be included in /usr/share/common-licenses?

Date: Sun, 10 Sep 2023 11:04:43 +0530

On Sat, 09 Sep 2023 20:35:27 -0700
Russ Allbery <[email protected]> wrote:
>     Licenses will be included in common-licenses if they meet all of the
>     following criteria:

 How about just pointing SPDX licenses URL for whole license text and
 lists DFSG-free licenses from that? (but yes, we should adjust short
 name of licenses for DEP-5 and SPDX for it).


-- 
Hideki Yamane <[email protected]>

Message #89 received at [email protected] (full text, mbox, reply):

From: Luca Boccassi <[email protected]>

To: [email protected]

Cc: [email protected]

Subject: Re: What licenses should be included in /usr/share/common-licenses?

Date: Sun, 10 Sep 2023 13:18:20 +0100

On Sun, 10 Sept 2023 at 04:36, Russ Allbery <[email protected]> wrote:
>     Licenses will be included in common-licenses if they meet all of the
>     following criteria:
>
>     * The license is DFSG-free.
>     * Exactly the same license wording is used by all works covered by it.
>     * The license applies to at least 100 source packages in Debian.
>     * The license text is longer than 25 lines.

+1, great work and great starting point.

I also agree with Enrico and I'd like lower limits too, but any
progress is good progress on this matter for me.

Message #94 received at [email protected] (full text, mbox, reply):

From: Russ Allbery <[email protected]>

To: [email protected]

Cc: [email protected]

Subject: Re: What licenses should be included in /usr/share/common-licenses?

Date: Sun, 10 Sep 2023 09:00:22 -0700

Jonas Smedegaard <[email protected]> writes:
> Quoting Hideki Yamane (2023-09-10 11:00:07)

>>  Hmm, how about providing license-common package and that depends on
>>  "license-common-list", and ISO image provides both, then? It would be
>>  no regressions.

I do wonder why we've never done this.  Does anyone know?  common-licenses
is in an essential package so it doesn't require a dependency and is
always present, and we've leaned on that in the past in justifying not
including those licenses in the binary packages themselves, but I'm not
sure why a package dependency wouldn't be legally equivalent.  We allow
symlinking the /usr/share/doc directory in some cases where there is a
dependency, so we don't strictly require every binary package have a
copyright file.

>>  I expect license-common-list data as below
>> 
>>  license-short-name: URL
>>  GPL-2: file:///usr/share/common-licenses/GPL-2
>>  Boost-1.0: https://spdx.org/licenses/BSL-1.0.html

> Ah, so what you propose is to use file URIs.

> I guess Russ' response above was a concern over using http(s) URIs
> towards a non-local resource.

Yes, I think the https URL is an essential part of the first proposal,
since it avoids needing to ship a copy of all of the licenses.  But I'm
dubious that would pass legal muster.

The alternative proposal as I understand it would be to haave a
license-common package that includes full copies of all the licenses with
some more relaxed threshold requirement and have packages that use one of
those licenses depend on that package.  (This would obviously require a
maintainer be found for the license-common package.)

> License: Apache-2.0
> Reference: /usr/share/common-licenses/Apache-2.0

This is separate from this particular bug, but I would love to see the
pointer to common-licenses turned into a formal field of this type in the
copyright format, rather than being an ad hoc comment.

-- 
Russ Allbery ([email protected])              <https://www.eyrie.org/~eagle/>

Message #99 received at [email protected] (full text, mbox, reply):

From: Russ Allbery <[email protected]>

To: [email protected]

Cc: [email protected]

Subject: Re: What licenses should be included in /usr/share/common-licenses?

Date: Sun, 10 Sep 2023 09:16:07 -0700

Russ Allbery <[email protected]> writes:

> In order to structure the discussion and prod people into thinking about
> the implications, I will make the following straw man proposal.  This is
> what I would do if the decision was entirely up to me:

>     Licenses will be included in common-licenses if they meet all of the
>     following criteria:

>     * The license is DFSG-free.
>     * Exactly the same license wording is used by all works covered by it.
>     * The license applies to at least 100 source packages in Debian.
>     * The license text is longer than 25 lines.

In the thread so far, there's been a bit of early convergence around my
threshold of 100 packages above.  I want to make sure people realize that
this is a very conservative threshold that would mean saying no to most
new license inclusion requests.

My guess is that with the threshold set at 100, we will probably add
around eight new licenses with the 25 line threshold (AGPL-2,
Artistic-2.0, CC-BY 3.0, CC-BY 4.0, CC-BY-SA 3.0, CC-BY-SA 4.0, and
OFL-1.1, and I'm not sure about some of those because the CC licenses have
variants that would each have to reach the threshold independently; my
current ad hoc script does not distinguish between the variants), and
maybe 10 to 12 total without that threshold (adding Expat, zlib, some of
the BSD licenses).  This would essentially be continuing current practice
except with more transparent and consistent criteria.  It would mean not
including a lot of long legal license texts that people have complained
about having to duplicate, such as the CDDL, CeCILL licenses, probably the
EPL, the Unicode license, etc.

If that's what people want, that's what we'll do; as I said, that's what I
would do if the choice were left entirely up to me.  But I want to make
sure I give the folks who want a much more relaxed standard a chance to
speak up.

-- 
Russ Allbery ([email protected])              <https://www.eyrie.org/~eagle/>

Message #104 received at [email protected] (full text, mbox, reply):

From: Bill Allombert <[email protected]>

To: Russ Allbery <[email protected]>, [email protected], [email protected]

Subject: Re: Bug#885698: What licenses should be included in /usr/share/common-licenses?

Date: Sun, 10 Sep 2023 18:29:36 +0200

On Sun, Sep 10, 2023 at 09:00:22AM -0700, Russ Allbery wrote:
> Jonas Smedegaard <[email protected]> writes:
> > Quoting Hideki Yamane (2023-09-10 11:00:07)
> 
> >>  Hmm, how about providing license-common package and that depends on
> >>  "license-common-list", and ISO image provides both, then? It would be
> >>  no regressions.
> 
> I do wonder why we've never done this.  Does anyone know?  common-licenses
> is in an essential package so it doesn't require a dependency and is
> always present, and we've leaned on that in the past in justifying not
> including those licenses in the binary packages themselves, but I'm not
> sure why a package dependency wouldn't be legally equivalent.  We allow
> symlinking the /usr/share/doc directory in some cases where there is a
> dependency, so we don't strictly require every binary package have a
> copyright file.

Or we could generate DEBIAN/copyright from debian/copyright using data in
license-common-list at build time. So maintainers would not need to manage the copying
themselves.

Cheers,
Bill

Message #109 received at [email protected] (full text, mbox, reply):

From: Jonas Smedegaard <[email protected]>

To: [email protected]

Cc: [email protected]

Subject: Re: What licenses should be included in /usr/share/common-licenses?

Date: Sun, 10 Sep 2023 18:30:52 +0200

[Message part 1 (text/plain, inline)]

Quoting Russ Allbery (2023-09-10 18:16:07)
> Russ Allbery <[email protected]> writes:
> 
> > In order to structure the discussion and prod people into thinking about
> > the implications, I will make the following straw man proposal.  This is
> > what I would do if the decision was entirely up to me:
> 
> >     Licenses will be included in common-licenses if they meet all of the
> >     following criteria:
> 
> >     * The license is DFSG-free.
> >     * Exactly the same license wording is used by all works covered by it.
> >     * The license applies to at least 100 source packages in Debian.
> >     * The license text is longer than 25 lines.
> 
> In the thread so far, there's been a bit of early convergence around my
> threshold of 100 packages above.  I want to make sure people realize that
> this is a very conservative threshold that would mean saying no to most
> new license inclusion requests.
> 
> My guess is that with the threshold set at 100, we will probably add
> around eight new licenses with the 25 line threshold (AGPL-2,
> Artistic-2.0, CC-BY 3.0, CC-BY 4.0, CC-BY-SA 3.0, CC-BY-SA 4.0, and
> OFL-1.1, and I'm not sure about some of those because the CC licenses have
> variants that would each have to reach the threshold independently; my
> current ad hoc script does not distinguish between the variants), and
> maybe 10 to 12 total without that threshold (adding Expat, zlib, some of
> the BSD licenses).  This would essentially be continuing current practice
> except with more transparent and consistent criteria.  It would mean not
> including a lot of long legal license texts that people have complained
> about having to duplicate, such as the CDDL, CeCILL licenses, probably the
> EPL, the Unicode license, etc.
> 
> If that's what people want, that's what we'll do; as I said, that's what I
> would do if the choice were left entirely up to me.  But I want to make
> sure I give the folks who want a much more relaxed standard a chance to
> speak up.

Good point.

Another way of reading the responses is that there was some interest in
including even more licenses.

I would also prefer inclusion of more licenses, simply had the
impression that a) we could do that step by step, and b) my habit of
writing copyright files (and other teksts) using [semantic linebreaks]
made me forget that Expat license is arguably only 3 lines long (whereas
in my style of writing it is 24-25 lines long).

If "include all SPDX licenses" is for some reason (space in minimal
systems?) problematic, then let me propose a threshold of 1000
characters - as that just about covers Expat ;-)


 - Jonas


[semantic linebreaks]: https://sembr.org/

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/
 * Sponsorship: https://ko-fi.com/drjones

 [x] quote me freely  [ ] ask before reusing  [ ] keep private

[signature.asc (application/pgp-signature, inline)]

Message #114 received at [email protected] (full text, mbox, reply):

From: Russ Allbery <[email protected]>

To: [email protected]

Cc: [email protected]

Subject: Re: What licenses should be included in /usr/share/common-licenses?

Date: Sun, 10 Sep 2023 12:41:59 -0700

Jeremy Stanley <[email protected]> writes:

> I'm surprised, for example, by the absence of the ISC license given that
> not only ISC's software but much of that originating from the OpenBSD
> ecosystem uses it. My personal software projects also use the ISC
> license. Are you aggregating the "License:" field in copyright files
> too, or is it really simply a hard-coded list of matching patterns?

It's only a hard-coded list of matching patterns, and it doesn't match any
of the short licenses because historically I wasn't considering them (with
the exception of common-licenses references to the BSD license, which I
kind of would like to make an RC bug and clean up so that we could remove
the BSD license from common-licenses on the grounds that it's specific to
only the University of California and confuses people).  If we go with any
sort of threshold, the script will need serious improvements.

That was something else I wanted to ask: I've invested all of a couple of
hours in this script, and would be happy to throw it away in favor of
something that tries to do a more proper job of classifying the licenses
referenced in debian/copyright.  Has someone already done this (Jonas,
perhaps)?

-- 
Russ Allbery ([email protected])              <https://www.eyrie.org/~eagle/>

Message #117 received at [email protected] (full text, mbox, reply):

From: Johannes Schauer Marin Rodrigues <[email protected]>

To: [email protected], Bill Allombert <[email protected]>, Russ Allbery <[email protected]>, [email protected]

Subject: Re: Bug#885698: What licenses should be included in /usr/share/common-licenses?

Date: Sun, 10 Sep 2023 21:47:36 +0200

[Message part 1 (text/plain, inline)]

Hi,

Quoting Bill Allombert (2023-09-10 18:29:36)
> On Sun, Sep 10, 2023 at 09:00:22AM -0700, Russ Allbery wrote:
> > Jonas Smedegaard <[email protected]> writes:
> > > Quoting Hideki Yamane (2023-09-10 11:00:07)
> > >>  Hmm, how about providing license-common package and that depends on
> > >>  "license-common-list", and ISO image provides both, then? It would be
> > >>  no regressions.
> > 
> > I do wonder why we've never done this.  Does anyone know?  common-licenses
> > is in an essential package so it doesn't require a dependency and is
> > always present, and we've leaned on that in the past in justifying not
> > including those licenses in the binary packages themselves, but I'm not
> > sure why a package dependency wouldn't be legally equivalent.  We allow
> > symlinking the /usr/share/doc directory in some cases where there is a
> > dependency, so we don't strictly require every binary package have a
> > copyright file.
> 
> Or we could generate DEBIAN/copyright from debian/copyright using data in
> license-common-list at build time. So maintainers would not need to manage
> the copying themselves.

I very much like this idea. The main reason maintainers want more licenses in
/usr/share/common-licenses/ is so that they do not anymore have humongous
d/copyright files with all license texts copypasted over and over again. If
long texts could be reduced to a reference that get expanded by a machine it
would make debian/copyright look much nicer and would make it easier to
maintain while at the same time shipping the full license text in the binary
package.

Does anybody know why such an approach would be a bad idea?

I have zero legal training so the only potential problem with this approach
that I was able to come up with is, that then the source package itself would
not anymore contain the license text and thus we would be shipping code covered
by a license that states that the code may only be distributed with the license
text alongside it without that text. So while auto-generating this would
probably create compliant binary packages, it would leave the source package
without the license text. Is that a problem?

Thanks!

cheers, josch

[signature.asc (application/pgp-signature, inline)]

Message #122 received at [email protected] (full text, mbox, reply):

From: Jeremy Stanley <[email protected]>

To: [email protected], [email protected]

Subject: Re: What licenses should be included in /usr/share/common-licenses?

Date: Sun, 10 Sep 2023 19:14:15 +0000

[Message part 1 (text/plain, inline)]

On 2023-09-09 20:35:27 -0700 (-0700), Russ Allbery wrote:
[...]
> Finally, as promised, here is the count of source packages in
> unstable that use the set of licenses that I taught my script to
> look for.  This is likely not accurate; the script uses a bunch of
> heuristics and guesswork.
[...]

I'm surprised, for example, by the absence of the ISC license given
that not only ISC's software but much of that originating from the
OpenBSD ecosystem uses it. My personal software projects also use
the ISC license. Are you aggregating the "License:" field in
copyright files too, or is it really simply a hard-coded list of
matching patterns?

Regardless, this is great work, thanks for kicking off the
reevaluation!
-- 
Jeremy Stanley

[signature.asc (application/pgp-signature, inline)]

Message #127 received at [email protected] (full text, mbox, reply):

From: "G. Branden Robinson" <[email protected]>

To: [email protected], Bill Allombert <[email protected]>, Russ Allbery <[email protected]>, [email protected]

Subject: Re: Bug#885698: What licenses should be included in /usr/share/common-licenses?

Date: Sun, 10 Sep 2023 15:20:07 -0500

[Message part 1 (text/plain, inline)]

At 2023-09-10T21:47:36+0200, Johannes Schauer Marin Rodrigues wrote:
> Quoting Bill Allombert (2023-09-10 18:29:36)
> > On Sun, Sep 10, 2023 at 09:00:22AM -0700, Russ Allbery wrote:
> > > Jonas Smedegaard <[email protected]> writes:
> > > >>  Hmm, how about providing license-common package and that
> > > >>  depends on "license-common-list", and ISO image provides both,
> > > >>  then? It would be no regressions.
> > > 
> > > I do wonder why we've never done this.  Does anyone know?
> > > common-licenses is in an essential package so it doesn't require a
> > > dependency and is always present, and we've leaned on that in the
> > > past in justifying not including those licenses in the binary
> > > packages themselves, but I'm not sure why a package dependency
> > > wouldn't be legally equivalent.  We allow symlinking the
> > > /usr/share/doc directory in some cases where there is a
> > > dependency, so we don't strictly require every binary package have
> > > a copyright file.
> > 
> > Or we could generate DEBIAN/copyright from debian/copyright using data in
> > license-common-list at build time. So maintainers would not need to manage
> > the copying themselves.
[...]
> I have zero legal training so the only potential problem with this approach
> that I was able to come up with is, that then the source package itself would
> not anymore contain the license text

...why wouldn't it?  Remember how a source package is defined:

A DSC file, an upstream source archive (maybe more than one in exciting
new source formats I haven't learned), and a compressed diff of Debian
changes.

Debian _source_ packages generally don't chop copyright notices and
license texts out the upstream distributions, and should not do so
unless those notices/texts are invalid or the material they cover has
been removed.  (Both of these do sometimes happen.)

Even if one worries about theoretical liability due to the existence of
separate files for .dsc, .tar.gz, and .diff.gz, then let us recall that
(1) the DSC is minimal, containing metadata that may not rise to the
threshold or originality required by copyright [in the U.S., anyway];
(2) the upstream archive has the notices and texts that the _original
distributor_ put in it, and as a rule, if permission to distribute the
work exists, it is not incumbent on redistributors to add notices/texts
where the rightsholder themselves neglected to do so; and (3) the
.diff.gz will not be in the business of removing notices/texts except as
contemplated in the previous paragraph (correcting erroneous
notices).[1]

> and thus we would be shipping code covered by a license that states
> that the code may only be distributed with the license text alongside
> it without that text.

I don't think that is a risk as long as people continue to follow
packaging practices that Debian has applied with little objection from
our upstreams for 25+ years.[2]

> So while auto-generating this would probably create compliant binary
> packages, it would leave the source package without the license text.

I am unable to imagine the mechanism by which that would happen, given
what Russ and Bill proposed.

Regards,
Branden

[1] When repackaging, e.g., to remove non-free material, affected
    content is removed altogether even from the source.  Nothing in
    copyright law can compel you to distribute copyright notices and
    texts that don't apply to work you're not distributing.[3]

[2] I don't know of Debian _ever_ having had a problem, as in receiving
    a cease-and-desist letter or other threat of legal action with what
    one might term an "institutional" copyright holder.  We've certainly
    had our share of nasty emails from cantankerous individual copyright
    holders, often who had their own perverse misreadings of licenses
    drafted by others (hello to the memory of Jörg Schilling).  There
    also was once an upstream who stuck a Trojan horse into the source
    code to try to get Debian's users to stop using versions we
    distributed, but to go directly upstream instead.  Nowadays, that
    seems quaint; you can today Trojan your machine much more
    conveniently with npm(1).

[3] At the same time a few non-free FSF manuals under the GNU FDL
    declaim the GNU _GPL_ text to be an Invariant Section.  Like most of
    the defects of the FDL, I think this is a pointless encumbrance; if
    you distribute GPL'ed software, a copy of its text must come along
    anyway.  The only rationale I can imagine is to mandate, for printed
    copies of the manuals, the inclusion of the GPL's preachy preamble.
    But I digress.

[signature.asc (application/pgp-signature, inline)]

Message #132 received at [email protected] (full text, mbox, reply):

From: Russ Allbery <[email protected]>

To: [email protected]

Cc: [email protected]

Subject: Re: Bug#885698: What licenses should be included in /usr/share/common-licenses?

Date: Sun, 10 Sep 2023 13:33:51 -0700

Johannes Schauer Marin Rodrigues <[email protected]> writes:

> I very much like this idea. The main reason maintainers want more
> licenses in /usr/share/common-licenses/ is so that they do not anymore
> have humongous d/copyright files with all license texts copypasted over
> and over again. If long texts could be reduced to a reference that get
> expanded by a machine it would make debian/copyright look much nicer and
> would make it easier to maintain while at the same time shipping the
> full license text in the binary package.

> Does anybody know why such an approach would be a bad idea?

I can think of a few possible problems:

* I'm not sure if we generate binary package copyright files at build time
  right now, and if all of our tooling deals with this.  I had thought
  that we prohibited this, but it looks like it's only a Policy should and
  there isn't a mention of it in the reject FAQ, so I think I was
  remembering the rule for debian/control instead.  Of course, even if
  tools don't support this now, they could always be changed.

* If ftp-master has to review the copyright files of each binary package
  separate from the copyright file of the source package (I think this
  would be an implication of generating the copyright files during build
  time), and the binary copyright files have fully-expanded licenses, that
  sounds like kind of a pain for the ftp-master reviewers.  Maybe we can
  deal with this with better tooling, but someone would need to write
  that.

* If we took this to its logical end point and did this with the GPL as
  well, we would add 20,000 copies of the GPL to the archive and install a
  *lot* of copies on the system.  Admittedly text files are small and
  disks are large, but this still seems a little excessive.  So maybe we
  still need to do something with common-licenses?

-- 
Russ Allbery ([email protected])              <https://www.eyrie.org/~eagle/>

Message #137 received at [email protected] (full text, mbox, reply):

From: Timo Röhling <[email protected]>

To: [email protected]

Cc: [email protected]

Subject: Re: What licenses should be included in /usr/share/common-licenses?

Date: Sun, 10 Sep 2023 22:42:04 +0200

[Message part 1 (text/plain, inline)]

* Russ Allbery <[email protected]> [2023-09-10 09:16]:
>> In order to structure the discussion and prod people into thinking about
>> the implications, I will make the following straw man proposal.  This is
>> what I would do if the decision was entirely up to me:
>
>>     Licenses will be included in common-licenses if they meet all of the
>>     following criteria:
>
>>     * The license is DFSG-free.
>>     * Exactly the same license wording is used by all works covered by it.
>>     * The license applies to at least 100 source packages in Debian.
>>     * The license text is longer than 25 lines.
>
>In the thread so far, there's been a bit of early convergence around my
>threshold of 100 packages above.  I want to make sure people realize that
>this is a very conservative threshold that would mean saying no to most
>new license inclusion requests.
>
>My guess is that with the threshold set at 100, we will probably add
>around eight new licenses with the 25 line threshold (AGPL-2,
>Artistic-2.0, CC-BY 3.0, CC-BY 4.0, CC-BY-SA 3.0, CC-BY-SA 4.0, and
>OFL-1.1, and I'm not sure about some of those because the CC licenses have
>variants that would each have to reach the threshold independently; my
>current ad hoc script does not distinguish between the variants), and
>maybe 10 to 12 total without that threshold (adding Expat, zlib, some of
>the BSD licenses).  This would essentially be continuing current practice
>except with more transparent and consistent criteria.  It would mean not
>including a lot of long legal license texts that people have complained
>about having to duplicate, such as the CDDL, CeCILL licenses, probably the
>EPL, the Unicode license, etc.
>
>If that's what people want, that's what we'll do; as I said, that's what I
>would do if the choice were left entirely up to me.  But I want to make
>sure I give the folks who want a much more relaxed standard a chance to
>speak up.

For me, this outcome would already be an improvement over the current
situation and alleviate my biggest pain point (CC licenses).
Still, I'd like to be significantly more relaxed.

I propose the following three criteria must be satisfied for
inclusion in /usr/share/common-licenses:

 * The license is DFSG-free.
 * Exactly the same license wording is used by all works covered by it.
 * The license is in the SPDX list of common licenses (https://spdx.org/licenses/)
   OR
   The license applies to at least 100 source packages in Debian.


I am not committed to the 100 source packages threshold, it is
mostly intended as fallback for a hypothetical future license which
is super popular but for some reason does not make it to the SPDX
list in a timely manner.

One very intentional side effect of my proposal is a nudge towards
using SPDX License Identifiers in d/copyright files.


Cheers
Timo

-- 
⢀⣴⠾⠻⢶⣦⠀   ╭────────────────────────────────────────────────────╮
⣾⠁⢠⠒⠀⣿⡁   │ Timo Röhling                                       │
⢿⡄⠘⠷⠚⠋⠀   │ 9B03 EBB9 8300 DF97 C2B1  23BF CC8C 6BDD 1403 F4CA │
⠈⠳⣄⠀⠀⠀⠀   ╰────────────────────────────────────────────────────╯

[signature.asc (application/pgp-signature, inline)]

Message #142 received at [email protected] (full text, mbox, reply):

From: Jonas Smedegaard <[email protected]>

To: [email protected]

Cc: [email protected]

Subject: Re: What licenses should be included in /usr/share/common-licenses?

Date: Sun, 10 Sep 2023 22:57:02 +0200

[Message part 1 (text/plain, inline)]

Quoting Russ Allbery (2023-09-10 21:41:59)
> Jeremy Stanley <[email protected]> writes:
> 
> > I'm surprised, for example, by the absence of the ISC license given that
> > not only ISC's software but much of that originating from the OpenBSD
> > ecosystem uses it. My personal software projects also use the ISC
> > license. Are you aggregating the "License:" field in copyright files
> > too, or is it really simply a hard-coded list of matching patterns?
> 
> It's only a hard-coded list of matching patterns, and it doesn't match any
> of the short licenses because historically I wasn't considering them (with
> the exception of common-licenses references to the BSD license, which I
> kind of would like to make an RC bug and clean up so that we could remove
> the BSD license from common-licenses on the grounds that it's specific to
> only the University of California and confuses people).  If we go with any
> sort of threshold, the script will need serious improvements.
> 
> That was something else I wanted to ask: I've invested all of a couple of
> hours in this script, and would be happy to throw it away in favor of
> something that tries to do a more proper job of classifying the licenses
> referenced in debian/copyright.  Has someone already done this (Jonas,
> perhaps)?

I have so far worked the most on identifying and grouping source data,
putting only little attention (yet - but do dream big...) towards
parsing and processing debian/copyright files e.g. to compare and assess
how well aligned the file is with the content it is supposed to cover.

So if I understand your question correctly and you are not looking for
the output of `licensecheck --list-licenses`, then unfortunately I have
nothing exciting to offer.


 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/
 * Sponsorship: https://ko-fi.com/drjones

 [x] quote me freely  [ ] ask before reusing  [ ] keep private

[signature.asc (application/pgp-signature, inline)]

Message #147 received at [email protected] (full text, mbox, reply):

From: Russ Allbery <[email protected]>

To: [email protected], [email protected]

Subject: Re: Bug#885698: What licenses should be included in /usr/share/common-licenses?

Date: Sun, 10 Sep 2023 14:24:24 -0700

Jonas Smedegaard <[email protected]> writes:

> I have so far worked the most on identifying and grouping source data,
> putting only little attention (yet - but do dream big...) towards
> parsing and processing debian/copyright files e.g. to compare and assess
> how well aligned the file is with the content it is supposed to cover.

> So if I understand your question correctly and you are not looking for
> the output of `licensecheck --list-licenses`, then unfortunately I have
> nothing exciting to offer.

I think that's mostly correct.  I was wondering what would happen if one
ran licensecheck debian/copyright, but unfortunately it doesn't look like
it does anything useful.  I tried it on one of my packages (remctl) that
has a bunch of different licenses, and it just said:

debian/copyright: MIT License

and apparently ignored all of the other licenses present (FSFAP, FSFFULLR,
ISC, X11, GPL-2.0-or-later with Autoconf-exception-generic, and
GPL-3.0-or-later with Autoconf-exception-generic).  It also doesn't notice
that some of the MIT licenses are variations that contain people's names.

(I still put all the Autoconf build machinery licenses in my
debian/copyright file because of the tooling I use to manage my copyright
file, which I also use upstream.  I probably should change that, but I
need to either switch to licensecheck or rewrite my horrible script.)

Also, presumably it doesn't know about copyright-format since it wouldn't
be expecting that in source files, so it wouldn't know to include licenses
referenced in License stanzas without the license text included.

-- 
Russ Allbery ([email protected])              <https://www.eyrie.org/~eagle/>

Message #152 received at [email protected] (full text, mbox, reply):

From: Jonas Smedegaard <[email protected]>

To: [email protected], [email protected]

Subject: Re: Bug#885698: What licenses should be included in /usr/share/common-licenses?

Date: Mon, 11 Sep 2023 06:45:22 +0200

[Message part 1 (text/plain, inline)]

Quoting Russ Allbery (2023-09-10 23:24:24)
> Jonas Smedegaard <[email protected]> writes:
> 
> > I have so far worked the most on identifying and grouping source data,
> > putting only little attention (yet - but do dream big...) towards
> > parsing and processing debian/copyright files e.g. to compare and assess
> > how well aligned the file is with the content it is supposed to cover.
> 
> > So if I understand your question correctly and you are not looking for
> > the output of `licensecheck --list-licenses`, then unfortunately I have
> > nothing exciting to offer.
> 
> I think that's mostly correct.  I was wondering what would happen if one
> ran licensecheck debian/copyright, but unfortunately it doesn't look like
> it does anything useful.  I tried it on one of my packages (remctl) that
> has a bunch of different licenses, and it just said:
> 
> debian/copyright: MIT License
> 
> and apparently ignored all of the other licenses present (FSFAP, FSFFULLR,
> ISC, X11, GPL-2.0-or-later with Autoconf-exception-generic, and
> GPL-3.0-or-later with Autoconf-exception-generic).  It also doesn't notice
> that some of the MIT licenses are variations that contain people's names.
> 
> (I still put all the Autoconf build machinery licenses in my
> debian/copyright file because of the tooling I use to manage my copyright
> file, which I also use upstream.  I probably should change that, but I
> need to either switch to licensecheck or rewrite my horrible script.)
> 
> Also, presumably it doesn't know about copyright-format since it wouldn't
> be expecting that in source files, so it wouldn't know to include licenses
> referenced in License stanzas without the license text included.

Right.  Licensecheck so far mostly scans for human prose stating "this
has been licensed as..." and "this is the license...", and rarely is
able to recognize "the default license of this project is..." or "that
folder over there is licensed as..." style prose.

That said, there is interest in covering that as well, and also interest
in improving on non-prose forms like "[this is YAML;] Copyright: ..." or
binary forms most commonly embedded in fonts and ICC data in images.

It is helpful if you (i.e. anyone reading this) have a good (as in
particularly rich/tricky/peculiar) case that you file a bugreport
pointing to its failure of being recognized by licensecheck.

Also, I hadn't thought of there being interest in statistics - it should
not be too hard to spit out numbers for variation in licenses or
copyright holders once licensecheck has recognized the information.
Again, if someone has suggestions for formats they'd particularly like
such statistisc to be served from licensecheck then please file a
bugreport.

Sorry this isn't helping anything for the topic being discussed.


 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/
 * Sponsorship: https://ko-fi.com/drjones

 [x] quote me freely  [ ] ask before reusing  [ ] keep private

[signature.asc (application/pgp-signature, inline)]

Message #157 received at [email protected] (full text, mbox, reply):

From: Hideki Yamane <[email protected]>

To: Bill Allombert <[email protected]>

Cc: Russ Allbery <[email protected]>, [email protected], [email protected]

Subject: Re: Bug#885698: What licenses should be included in /usr/share/common-licenses?

Date: Tue, 12 Sep 2023 12:57:12 +0530

Hi,

On Sun, 10 Sep 2023 18:29:36 +0200
Bill Allombert <[email protected]> wrote:
> Or we could generate DEBIAN/copyright from debian/copyright using data in
> license-common-list at build time. So maintainers would not need to manage the copying
> themselves.

 One problem is, that some software declares that they use some licenses
 (e.g. MIT), but sometimes they modify the license term itself a bit.
 So, there's a difference between words in the license list and some words
 in the included license in such software.

 It'd be better to find such software and ask upstream to fix it to use
 proper license terms, by tagging it at BTS. And, it's NOT Debian specific
 issues, so it may be better to ask folks to join such a movement then, IMHO.


-- 
Hideki Yamane <[email protected]>

Message #162 received at [email protected] (full text, mbox, reply):

From: Jonas Smedegaard <[email protected]>

To: [email protected], [email protected]

Subject: Re: Bug#885698: What licenses should be included in /usr/share/common-licenses?

Date: Tue, 12 Sep 2023 10:47:56 +0200

Quoting Hideki Yamane (2023-09-12 09:27:12)
> On Sun, 10 Sep 2023 18:29:36 +0200
> Bill Allombert <[email protected]> wrote:
> > Or we could generate DEBIAN/copyright from debian/copyright using data in
> > license-common-list at build time. So maintainers would not need to manage the copying
> > themselves.
> 
>  One problem is, that some software declares that they use some licenses
>  (e.g. MIT), but sometimes they modify the license term itself a bit.
>  So, there's a difference between words in the license list and some words
>  in the included license in such software.
> 
>  It'd be better to find such software and ask upstream to fix it to use
>  proper license terms, by tagging it at BTS. And, it's NOT Debian specific
>  issues, so it may be better to ask folks to join such a movement then, IMHO.

I can only assume that the proposal for an automated DEBIAN/copyright
file is limited to source files *possible* to automatically process, and
consequently only relates to debian/copyright files written in the
machine-readable format.

The problem you describe about ambiguous MIT-derived licensing cannot,
in by understanding, occur using the machine-readable format - only with
less strictly structured debian/copyright files.

If you mean to say that ambiguous MIT declarations exist in
debian/copyright files written using the machine-readable format, then
please point to an example, as I cannot imagine how that would look.


 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/
 * Sponsorship: https://ko-fi.com/drjones

 [x] quote me freely  [ ] ask before reusing  [ ] keep private

Message #167 received at [email protected] (full text, mbox, reply):

From: Russ Allbery <[email protected]>

To: [email protected], [email protected]

Subject: Re: Bug#885698: What licenses should be included in /usr/share/common-licenses?

Date: Tue, 12 Sep 2023 09:15:27 -0700

Jonas Smedegaard <[email protected]> writes:

> If you mean to say that ambiguous MIT declarations exist in
> debian/copyright files written using the machine-readable format, then
> please point to an example, as I cannot imagine how that would look.

I can see it: people use License: Expat but then include some license that
is essentially, but not precisely, the same as Expat.  If we then tell
people that they can omit the text of the license and we'll fill it in
automatically, they'll remove the actual text and we'll fill it in with
the wrong thing.

This is just a bug in handling the debian/copyright file, though.  If we
take this approach, we'll need to be very explicit that you can only use
whatever triggers the automatic inclusion of the license text if your
license text is word-for-word identical.  Otherwise, you'll need to cut
and paste it into the file as always.

-- 
Russ Allbery ([email protected])              <https://www.eyrie.org/~eagle/>

Message #172 received at [email protected] (full text, mbox, reply):

From: Jonas Smedegaard <[email protected]>

To: [email protected], [email protected]

Subject: Re: Bug#885698: What licenses should be included in /usr/share/common-licenses?

Date: Tue, 12 Sep 2023 19:21:15 +0200

[Message part 1 (text/plain, inline)]

Quoting Russ Allbery (2023-09-12 18:15:27)
> Jonas Smedegaard <[email protected]> writes:
> 
> > If you mean to say that ambiguous MIT declarations exist in
> > debian/copyright files written using the machine-readable format, then
> > please point to an example, as I cannot imagine how that would look.
> 
> I can see it: people use License: Expat but then include some license that
> is essentially, but not precisely, the same as Expat.  If we then tell
> people that they can omit the text of the license and we'll fill it in
> automatically, they'll remove the actual text and we'll fill it in with
> the wrong thing.
> 
> This is just a bug in handling the debian/copyright file, though.  If we
> take this approach, we'll need to be very explicit that you can only use
> whatever triggers the automatic inclusion of the license text if your
> license text is word-for-word identical.  Otherwise, you'll need to cut
> and paste it into the file as always.

Ah, right.  I see it now.

Strictly speaking it is not (as I was more narrowly focusing on) that
the current debian/copyright spec leaves room for *ambiguity*, but
instead that there is a real risk of making mistakes when replacing with
centrally defined ones (e.g. redefining a local "Expat" from locally
meaning "MIT-ish legalese as stated in this project" to falsely mean
"the MIT-ish legalese that SPDX labels MIT").

If you disagree, then please shout, as then I am still missing your
point here...


 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/
 * Sponsorship: https://ko-fi.com/drjones

 [x] quote me freely  [ ] ask before reusing  [ ] keep private

[signature.asc (application/pgp-signature, inline)]

Message #177 received at [email protected] (full text, mbox, reply):

From: Russ Allbery <[email protected]>

To: [email protected], [email protected]

Subject: Re: Bug#885698: What licenses should be included in /usr/share/common-licenses?

Date: Tue, 12 Sep 2023 10:49:02 -0700

Jonas Smedegaard <[email protected]> writes:

> Strictly speaking it is not (as I was more narrowly focusing on) that
> the current debian/copyright spec leaves room for *ambiguity*, but
> instead that there is a real risk of making mistakes when replacing with
> centrally defined ones (e.g. redefining a local "Expat" from locally
> meaning "MIT-ish legalese as stated in this project" to falsely mean
> "the MIT-ish legalese that SPDX labels MIT").

Right, the existing copyright format defines a few standard labels and
says that you should only use those labels when the license text matches,
but it doesn't stress that "matches" means absolutely word-for-word
identical.  I suspect, although I haven't checked, that we've made at
least a few mistakes where some license text that's basically equivalent
to Expat is labelled as Expat even though the text is not word-for-word
identical.  Given that currently all labels in debian/copyright are
essentially local and the full text is there (except for common-licenses,
where apart from BSD the licenses normally are used verbatim), this is not
currently really a bug.  But we could turn it into a bug quite quickly if
we relied on the license short name to look up the text.

To take an example that I've been trying to get rid of for over a decade,
many of the /usr/share/common-licenses/BSD references currently in the
archive are incorrect.  There are a few cases where the code is literally
copyrighted only by the Regents of the University of California and uses
exactly that license text, but this is not the case for a lot of them.  It
looks like a few people have even tried to say "use common-licenses but
change the name in the license" rather than reproducing the license text,
which I don't believe meets the terms of the license (although it's of
course very unlikely that anyone would sue over it).

A quick code search turns up the following examples, all of which I
believe are wrong:

https://sources.debian.org/src/mrpt/1:2.10.0+ds-3/doc/man-pages/pod/simul-beacons.pod/?hl=35#L35
https://sources.debian.org/src/gridengine/8.1.9+dfsg-11/debian/scripts/init_cluster/?hl=7#L7
https://sources.debian.org/src/rust-hyphenation/0.7.1-1/debian/copyright/?hl=278#L278
https://sources.debian.org/src/nim/1.6.14-1/debian/copyright/?hl=64#L64
https://sources.debian.org/src/yade/2023.02a-2/debian/copyright/?hl=78#L78

An example of one that probably is okay, although ideally we still
wouldn't do this because there are other copyrights in the source:

https://sources.debian.org/src/lpr/1:2008.05.17.3+nmu1/debian/copyright/?hl=15#L15

This problem potentially would happen a lot with the BSD licenses, since
the copyright-format document points to SPDX and SPDX, since it only cares
about labeling legally-equivalent documents, allows the license text to
vary around things like the name of the person you're not supposed to say
endorsed your software while still receiving the same label.

We therefore cannot use solely SPDX as a way of determining whether we can
substitute the text of the license automatically for people, because there
are SPDX labels for a lot of licenses for which we'd need to copy and
paste the exact license text because it varies.  At least if I understand
what our goals would be.

(License texts that have portions that vary between packages they apply to
are a menace and make everything much harder, and I really wish people
would stop using them, but of course the world of software development is
not going to listen to me.)

-- 
Russ Allbery ([email protected])              <https://www.eyrie.org/~eagle/>

Message #182 received at [email protected] (full text, mbox, reply):

From: Bill Allombert <[email protected]>

To: Russ Allbery <[email protected]>, [email protected]

Cc: [email protected]

Subject: Re: Bug#885698: What licenses should be included in /usr/share/common-licenses?

Date: Tue, 12 Sep 2023 20:50:25 +0200

On Tue, Sep 12, 2023 at 10:49:02AM -0700, Russ Allbery wrote:
> To take an example that I've been trying to get rid of for over a decade,
> many of the /usr/share/common-licenses/BSD references currently in the
> archive are incorrect.  There are a few cases where the code is literally
> copyrighted only by the Regents of the University of California and uses
> exactly that license text, but this is not the case for a lot of them.  It
> looks like a few people have even tried to say "use common-licenses but
> change the name in the license" rather than reproducing the license text,
> which I don't believe meets the terms of the license (although it's of
> course very unlikely that anyone would sue over it).

Note that my proposal makes detecting the discrepancy more visible rather
than less, since you can compare the generated copyright file with
the actual license statement without chasing files.

Also, overengineering aside, the copyright generator could support 
parameter substitution to accomodate small discrepancies in license.
For example an option to replace in /usr/share/common-licenses/BSD the
line 
"Copyright (c) The Regents of the University of California."
by whatever is required when generating DEBIAN/copyright.

Cheers,
Bill

Message #187 received at [email protected] (full text, mbox, reply):

From: Diederik de Haas <[email protected]>

To: [email protected], Russ Allbery <[email protected]>

Cc: [email protected]

Subject: Re: Bug#885698: What licenses should be included in /usr/share/common-licenses?

Date: Tue, 19 Sep 2023 12:55:18 +0200

[Message part 1 (text/plain, inline)]

Hopefully I'm not too late and I hope I won't make any ('dumb') mistakes as 
I'm not as well-versed in licenses and packaging as other participants.

On Sunday, 10 September 2023 18:16:07 CEST Russ Allbery wrote:
> > * The license is DFSG-free.
> > * Exactly the same license wording is used by all works covered by it.

I think both of these criteria are excellent.

> > * The license applies to at least 100 source packages in Debian.
> 
> In the thread so far, there's been a bit of early convergence around my
> threshold of 100 packages above.  I want to make sure people realize that
> this is a very conservative threshold that would mean saying no to most
> new license inclusion requests.

On Sunday, 10 September 2023 05:35:27 CEST Russ Allbery wrote:
> Here are various concerns that people have had in this area in the past.
> 
> * common-licenses consumes disk space on every installed Debian system of
>   any size, and therefore should be kept small to avoid wasting system
>   resources.

The only reason for not doing so that I've detected is worry about disk space? 
If we were talking about several Megabytes (or even larger) then I could see 
that point. But license text is max several Kilobytes?

diederik@bagend:/usr/share/doc$ find . -name copyright | wc -l
3759

I suspect I have an enormous amount of duplicate license texts on this system 
and replacing those with references to common-licenses will likely reduce the 
waste of system resources.

Optionally the license texts in common-licenses could be gz compressed (gzip 
is Priority: required) to reduce disk-space even further.

So I would be in favor of dropping the threshold.

> > * The license text is longer than 25 lines.

The primary reason I'm in favor of dropping this too is consistency.

On Sunday, 10 September 2023 05:35:27 CEST Russ Allbery wrote:
> Here are various concerns that people have had in this area in the past.
> 
> * Including long legal texts in debian/copyright, particularly if one
>   wants to format them for copyright-format, is tedious and annoying and
>   doesn't benefit our users in any significant way, and therefore we
>   should include as many licenses as possible in common-licenses to spare
>   people that work.

This is an important reason why I'd want to have most/all licenses that are 
used in Debian included in common-licenses.
It's not only tedious and annoying, but also (because of that) error prone. 
And then you run the risk of the included license text not being (word-for-
word) the same.
Getting rid of tedious/annoying/repeating busy work seems like a win for 
everyone.

And IMO it's not only not beneficial to our users, but actually provides extra 
work. If I want to make sure the license text is indeed the same as my 
(hopefully correct) local copy, I'd have to run a `diff` with the included text 
in the copyright file. And that applies to every user who'd want to do that. 
And also for a prospective (new) maintainer of a package.

I'm a (big) fan of SPDX because it simplifies and clarifies things (a lot IMO) 
and makes things more consistent. And I'm a sucker for consistency.

I do think that the license should be provided locally (and its availability 
not be dependent on a build step in some other tool).
Having a link to an online version may be a useful extra service, but having a 
working internet connection should not be a requirement (IMO).

Cheers,
  Diederik

[signature.asc (application/pgp-signature, inline)]

Message #192 received at [email protected] (full text, mbox, reply):

From: Sean Whitton <[email protected]>

To: Russ Allbery <[email protected]>

Cc: [email protected], [email protected]

Subject: Re: What licenses should be included in /usr/share/common-licenses?

Date: Mon, 09 Oct 2023 18:31:00 +0100

[Message part 1 (text/plain, inline)]

Hello Russ,

Thank you for working on this.

On Sat 09 Sep 2023 at 08:35pm -07, Russ Allbery wrote:

> In order to structure the discussion and prod people into thinking about
> the implications, I will make the following straw man proposal.  This is
> what I would do if the decision was entirely up to me:
>
>     Licenses will be included in common-licenses if they meet all of the
>     following criteria:
>
>     * The license is DFSG-free.
>     * Exactly the same license wording is used by all works covered by it.
>     * The license applies to at least 100 source packages in Debian.
>     * The license text is longer than 25 lines.

Something that hasn't been brought up yet is the effects on NEW review.
I would like to expand the idea of the same license wording being used
by all works, to include the additional requirement that there aren't
any very similar licenses that are easily confused with the license.

For, if it's a license with small variations of any kind, including
variations that are not project-specific things like the names of
copyright holders, then NEW review is much easier if all the text is
right there in d/copyright.

I would be in favour of the 25 lines criterion.  The main problem with
manipulating d/copyright is only the really long licenses, IME.

-- 
Sean Whitton

[signature.asc (application/pgp-signature, inline)]

Message #197 received at [email protected] (full text, mbox, reply):

From: "Mr. Edric Reed"<[email protected]>

To: [email protected]

Subject: For Your Detail

Date: Sat, 20 Jul 2024 00:25:32 +0100

Attention,

I do have a business which l know will be tremendously profitable to both of us, if you will be interested, please get back to me for more details.
Sincerely,
Mr. Edric Reed

Message #202 received at [email protected] (full text, mbox, reply):

From: Matthias Geiger <[email protected]>

To: [email protected], [email protected], [email protected]

Subject: Re: What licenses should be included in /usr/share/common-licenses?

Date: Mon, 30 Sep 2024 18:41:03 +0200

Hi Russ and Sean,

thanks for for working on this. Just today I worked on a package having
some CC-BY-SA-4.0 licensed content and wasn't too glad at having to copy
the full license. Are there any big blockers for this ? Reading the
previous discussion the techicalities seem to be mostly agreed upon
(unless I missed something ?). 
I think this would be a big improvement for packagers. Let me know if
you need help finalizing any discussion to make this policy.

best,

Matthias Geiger <werdahias>

Message #207 received at [email protected] (full text, mbox, reply):

From: Bill Allombert <[email protected]>

To: Matthias Geiger <[email protected]>, [email protected]

Cc: [email protected], [email protected]

Subject: Re: Bug#885698: What licenses should be included in /usr/share/common-licenses?

Date: Mon, 30 Sep 2024 20:23:41 +0200

On Mon, Sep 30, 2024 at 06:41:03PM +0200, Matthias Geiger wrote:
> Hi Russ and Sean,
> 
> thanks for for working on this. Just today I worked on a package having
> some CC-BY-SA-4.0 licensed content and wasn't too glad at having to copy
> the full license. Are there any big blockers for this ? Reading the
> previous discussion the techicalities seem to be mostly agreed upon
> (unless I missed something ?). I think this would be a big improvement for
> packagers. Let me know if
> you need help finalizing any discussion to make this policy.

I suggested a tool that would copy the full license inside the binary package copyright file
at build time. This seems a more sustainable option.

Cheers,
-- 
Bill. <[email protected]>

Imagine a large red swirl here. 

Message #212 received at [email protected] (full text, mbox, reply):

From: Christine Edward <[email protected]>

Subject: Greetings.

Date: Thu, 31 Oct 2024 22:00:56 +0700 (WIB)

[Message part 1 (text/plain, inline)]

Hello, 

I am Christine Edward, I have a proposal I believe would be of great interest to you. I would appreciate your swift response to enable me to share more details with you. 

Best regards, 
Ms. Christine Edward. 

[Message part 2 (text/html, inline)]

Send a report that this bug log contains spam.