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

2023-09-10 Thread G. Branden Robinson
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  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
Description: PGP signature


Re: Shouldn't shipping broken symlinks be against policy?

2018-11-13 Thread G. Branden Robinson
At 2018-11-13T17:02:49+, Ian Jackson wrote:
> G. Branden Robinson writes ("Shouldn't shipping broken symlinks be against 
> policy?"):
> > Not reopening, but I have some questions for the Policy team.
> ...
> > I could have sworn you were incorrect, but sure enough, I read §10.5
> > carefully and grepped the rest of the policy manual and could find no
> > such prohibition.
> 
> I don't think there is anything *inherently* wrong in shipping a
> broken symlink.

I almost do. :-D

> But if a broken symlink causes some kind of malfunction then that
> seems to be just a bug.  Not every bug is a bug because it contravenes
> policy.  Some bugs are just bugs :-).
> 
> > Well, when a package ships a man page, I expect something more
> > illuminating to happen than:
> > 
> > $ man rust-gdb
> > /usr/bin/man: warning: /usr/share/man/man1/rust-gdb.1.gz is a dangling 
> > symlink
> > No manual entry for rust-gdb
> > See 'man 7 undocumented' for help when manual pages are not available.
> 
> I agree that this is untidy and undesirable.  I don't see any good
> reason why one would want to do this rather than shipping the
> rust-gdb.1.gz symlink in the same package as the thing it points to.
> 
> I guess the maintainer will also think this is a bug.

No; he closed it, and cited Policy's lack of a prohibition of shipping
broken symlinks in support of the present arrangement.

> Did anyone report it ?

That would be me.

-- 
Regards,
Branden


signature.asc
Description: PGP signature


Shouldn't shipping broken symlinks be against policy?

2018-11-13 Thread G. Branden Robinson
Not reopening, but I have some questions for the Policy team.

At 2018-11-13T16:26:00+, Ximin Luo wrote:
> Control: notfound -1 1.28.0+dfsg1-2
> 
> Closing, as far as I can tell it is not against Policy to ship a
> broken symlink,

I could have sworn you were incorrect, but sure enough, I read §10.5
carefully and grepped the rest of the policy manual and could find no
such prohibition.

It is certainly untidy.  So I ask the Policy team--_shouldn't_ it be
prohibited?

> if it doesn't affect the functionality of the package.

Well, when a package ships a man page, I expect something more
illuminating to happen than:

$ man rust-gdb
/usr/bin/man: warning: /usr/share/man/man1/rust-gdb.1.gz is a dangling symlink
No manual entry for rust-gdb
See 'man 7 undocumented' for help when manual pages are not available.

> The man page is available in the rust-doc package which is already in
> Suggests.

In that case, isn't a better fix to put the symlink in that package,
too?

On my buster system, this is the only one of over 4,300 symlinks in
/usr/share/man that is broken:

$ find /usr/share/man -type l | wc -l; for F in $(find /usr/share/man \
-type l); do if ! test -f "$F"; then file "$F"; dpkg -S "$F"; fi; done
4938
/usr/share/man/man1/rust-gdb.1.gz: broken symbolic link to gdb.1.gz
rust-gdb: /usr/share/man/man1/rust-gdb.1.gz

> X
> 
> G. Branden Robinson:
> > Package: rust-gdb
> > Version: 1.28.0+dfsg1-2
> > Severity: normal
> > File: /usr/share/man/man1/rust-gdb.1.gz
> > 
> > $ dpkg -S /usr/share/man/man1/rust-gdb.1.gz
> > rust-gdb: /usr/share/man/man1/rust-gdb.1.gz
> > 
> > $ file /usr/share/man/man1/rust-gdb.1.gz
> > /usr/share/man/man1/rust-gdb.1.gz: broken symbolic link to gdb.1.gz
[snip]

Thanks for your time.  Policy mavens, please CC me or the bug on
replies; I don't subscribe to a billion lists like I did in the old
days.

Regards,
Branden


signature.asc
Description: PGP signature