Bug#833709: Please add the MIT/Expat license to common-licenses

[Josh Triplett]

On Mon, Aug 08, 2016 at 06:37:41PM -0700, Russ Allbery wrote:
> Josh Triplett  writes:
> > On Mon, Aug 08, 2016 at 11:53:37AM -0700, Russ Allbery wrote:
> 
> >> I don't think this is a good idea.  This license is extremely short,
> >> and it has a ton of minor variations, so we'll get a lot of people
> >> using it even though the exactly licensing terms of their package don't
> >> match the canonical copy.
> 
> >> For example, it's very common to see "THE AUTHORS" replaced with a
> >> specific list of people or organizations in the license, which is a
> >> very small change that's easy for someone to miss when they know that
> >> the terms are just the Expat terms.
> 
> > In the various packages I looked at, I haven't seen any such variation
> > of the MIT/Expat license.  I've seen many variations of the MIT/X11
> > license, but not of Expat.
> 
> I just checked my (tiny) corpus and you're right, I haven't seen
> variations in the stuff I've analyzed in the Expat wording variation.  I
> was thinking of the MIT wording variation.

Thanks for confirming.

> > For many of the packages I'd hoped to use it for, the sum total of the
> > license information in the upstream source consists of the following
> > line in the package metadata:
> 
> > license = "MIT"
> 
> > No copyright notices, no license file, just a simple statement of the
> > license name using canonical SPDX license identifiers.
> 
> > For such packages, referencing a canonical copy of the license seems
> > preferable.
> 
> It really doesn't to me.  Copying the text that identifier refers to in
> whatever metadata scheme you're looking at seems much better to me, since
> you know for certain what text this is supposed to reference.  (There are
> a ton of licenses named "MIT", and I think far more people don't use SPDX
> than actually use it.)
> 
> I could see the argument if we were fully adopting SPDX and checking that
> these things mean something consistent, but I think we should do that in a
> broader way than just adding more licenses to common-licenses if we do
> that.

In the specific case of the MIT/Expat license, it's one of the most
popular FOSS licenses, and thousands of packages in Debian use it.  It's
certainly used by far more packages than other licenses already included
in common-licenses.  I realize it's a short license, but I find it quite
helpful to see references to common-licenses in debian/copyright files,
not least of which because I can assume they match the canonical
license.

- Josh Triplett

Bug#833709: Please add the MIT/Expat license to common-licenses

[Russ Allbery]

Simon McVittie  writes:

> It would be great if Policy described what the ftp-masters actually
> require and why, so that maintainers could provide everything that Debian
> needs to avoid legal trouble but no more. At the moment, Policy is rather
> more vague than the actual requirements to get software into Debian; there
> seems to be some (unwritten?) policy based on ftp-master consensus.

The prerequisite for this would be for ftp-master to publish what they
require and why.  There have been a lot of past discussions about that.
My understanding is that this document does not presently exist except
insofar as the REJECT FAQ could be said to be that document.

-- 
Russ Allbery (r...@debian.org)   

Bug#833709: Please add the MIT/Expat license to common-licenses

[Russ Allbery]

Josh Triplett  writes:
> On Mon, Aug 08, 2016 at 11:53:37AM -0700, Russ Allbery wrote:

>> I don't think this is a good idea.  This license is extremely short,
>> and it has a ton of minor variations, so we'll get a lot of people
>> using it even though the exactly licensing terms of their package don't
>> match the canonical copy.

>> For example, it's very common to see "THE AUTHORS" replaced with a
>> specific list of people or organizations in the license, which is a
>> very small change that's easy for someone to miss when they know that
>> the terms are just the Expat terms.

> In the various packages I looked at, I haven't seen any such variation
> of the MIT/Expat license.  I've seen many variations of the MIT/X11
> license, but not of Expat.

I just checked my (tiny) corpus and you're right, I haven't seen
variations in the stuff I've analyzed in the Expat wording variation.  I
was thinking of the MIT wording variation.

> For many of the packages I'd hoped to use it for, the sum total of the
> license information in the upstream source consists of the following
> line in the package metadata:

> license = "MIT"

> No copyright notices, no license file, just a simple statement of the
> license name using canonical SPDX license identifiers.

> For such packages, referencing a canonical copy of the license seems
> preferable.

It really doesn't to me.  Copying the text that identifier refers to in
whatever metadata scheme you're looking at seems much better to me, since
you know for certain what text this is supposed to reference.  (There are
a ton of licenses named "MIT", and I think far more people don't use SPDX
than actually use it.)

I could see the argument if we were fully adopting SPDX and checking that
these things mean something consistent, but I think we should do that in a
broader way than just adding more licenses to common-licenses if we do
that.

-- 
Russ Allbery (r...@debian.org)   

Bug#833709: Please add the MIT/Expat license to common-licenses

[Josh Triplett]

On Mon, Aug 08, 2016 at 05:10:52PM +0100, Simon McVittie wrote:
> On Sun, 07 Aug 2016 at 21:00:12 -1000, Josh Triplett wrote:
> > Numerous packages use the MIT/Expat license, and currently all of those
> > packages need to include it in their copyright files.
> 
> Although Policy does not say so, the ftp-masters require the license
> grant to be quoted in the copyright file, even for common-licenses. [1][2]

Can't quote something that doesn't exist in the upstream source.

> For the Expat license and other simple licenses, the license grant *is*
> the license, so putting it in common-licenses would make no difference
> to the length or complexity of copyright files unless the ftp-masters
> were willing to change their policy to accept something like
> 
> Files: foo
> Copyright: © 2000 Mickey Mouse
> License: Expat
> 
> (or its non-machine-readable equivalent) without any further text.

I wouldn't suggest making it quite *that* concise, because that leaves
out a human-readable cross-reference.  I'd suggest an explicit
reference, like this:

Debian systems provide the MIT license in /usr/share/common-licenses/MIT

> However, for the specific case of the Expat license, if I'm reading the
> license correctly you are required to include the license grant with the
> (binary form of the) software. For compiled code, the copyright file is
> likely the most convenient way to achieve that.

If the upstream source just says:

license = "MIT"

then that should suffice.

> It would be great if Policy described what the ftp-masters actually
> require and why, so that maintainers could provide everything that Debian
> needs to avoid legal trouble but no more. At the moment, Policy is rather
> more vague than the actual requirements to get software into Debian; there
> seems to be some (unwritten?) policy based on ftp-master consensus.

Agreed.  I'd prefer a written policy, and preferably one that doesn't
introduce any unnecessary boilerplate.

- Josh Triplett

Bug#833709: Please add the MIT/Expat license to common-licenses

[Josh Triplett]

On Mon, Aug 08, 2016 at 11:53:37AM -0700, Russ Allbery wrote:
> Josh Triplett  writes:
> 
> > Numerous packages use the MIT/Expat license, and currently all of those
> > packages need to include it in their copyright files.  I'd love to see
> > this license added to /usr/share/common-licenses/ ; this would require a
> > Policy change to section 12.5 to allow.
> 
> I don't think this is a good idea.  This license is extremely short, and
> it has a ton of minor variations, so we'll get a lot of people using it
> even though the exactly licensing terms of their package don't match the
> canonical copy.
> 
> For example, it's very common to see "THE AUTHORS" replaced with a
> specific list of people or organizations in the license, which is a very
> small change that's easy for someone to miss when they know that the terms
> are just the Expat terms.

In the various packages I looked at, I haven't seen any such variation
of the MIT/Expat license.  I've seen many variations of the MIT/X11
license, but not of Expat.

> I think the common-license infrastructure is designed for licenses that
> are small novels, like the GPL.  For something that's just three
> paragraphs, putting it directly in the copyright file has a simplicity and
> robustness that I think outweighs any minor one-time inconvenience during
> packaging or a bit of additional disk space usage.

For many of the packages I'd hoped to use it for, the sum total of the
license information in the upstream source consists of the following
line in the package metadata:

license = "MIT"

No copyright notices, no license file, just a simple statement of the
license name using canonical SPDX license identifiers.

For such packages, referencing a canonical copy of the license seems
preferable.

- Josh Triplett

Bug#833709: Please add the MIT/Expat license to common-licenses

[Russ Allbery]

Josh Triplett  writes:

> Numerous packages use the MIT/Expat license, and currently all of those
> packages need to include it in their copyright files.  I'd love to see
> this license added to /usr/share/common-licenses/ ; this would require a
> Policy change to section 12.5 to allow.

I don't think this is a good idea.  This license is extremely short, and
it has a ton of minor variations, so we'll get a lot of people using it
even though the exactly licensing terms of their package don't match the
canonical copy.

For example, it's very common to see "THE AUTHORS" replaced with a
specific list of people or organizations in the license, which is a very
small change that's easy for someone to miss when they know that the terms
are just the Expat terms.

I think the common-license infrastructure is designed for licenses that
are small novels, like the GPL.  For something that's just three
paragraphs, putting it directly in the copyright file has a simplicity and
robustness that I think outweighs any minor one-time inconvenience during
packaging or a bit of additional disk space usage.

(And if I could go back in time, I'd pull the BSD license from
common-licenses on the same grounds.)

-- 
Russ Allbery (r...@debian.org)   

Bug#833709: Please add the MIT/Expat license to common-licenses

[Simon McVittie]

On Sun, 07 Aug 2016 at 21:00:12 -1000, Josh Triplett wrote:
> Numerous packages use the MIT/Expat license, and currently all of those
> packages need to include it in their copyright files.

Although Policy does not say so, the ftp-masters require the license
grant to be quoted in the copyright file, even for common-licenses. [1][2]

For the Expat license and other simple licenses, the license grant *is*
the license, so putting it in common-licenses would make no difference
to the length or complexity of copyright files unless the ftp-masters
were willing to change their policy to accept something like

Files: foo
Copyright: © 2000 Mickey Mouse
License: Expat

(or its non-machine-readable equivalent) without any further text.

It is not clear to me why quoting the license grant is required, if the
license in question doesn't require it (the GPL doesn't seem to require
it for binaries). I asked for clarification in [3] but didn't see a reply.
However, for the specific case of the Expat license, if I'm reading the
license correctly you are required to include the license grant with the
(binary form of the) software. For compiled code, the copyright file is
likely the most convenient way to achieve that.

In practice, in packages like openjk with many superficially different
versions of the GPL boilerplate, I've had uploads accepted through NEW
quoting only one of them, and noting "and other superficially different
versions" alongside that... so it seems the ftp-masters aren't actually
quite as pedantic about verbatim license grants as [1], [2] might imply
(which is good, because if they were, copyright files would be even more
unwieldy than they are now).

It would be great if Policy described what the ftp-masters actually
require and why, so that maintainers could provide everything that Debian
needs to avoid legal trouble but no more. At the moment, Policy is rather
more vague than the actual requirements to get software into Debian; there
seems to be some (unwritten?) policy based on ftp-master consensus.

S

[1] https://lists.debian.org/debian-devel-announce/2006/03/msg00023.html
[2] https://lists.debian.org/debian-devel-announce/2003/12/msg7.html
[3] https://lists.debian.org/debian-devel/2014/09/msg00708.html