[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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

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 <jonas@jones.dk> 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

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

> 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.


[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.

Attachment: signature.asc
Description: PGP signature

Reply to: