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 would propose putting the original "Expat" version of the MIT license
in /usr/share/common-licenses/MIT .

(I wouldn't currently suggest adding the MIT/X11 license, because many
common versions of it mention specific parties by name in the
non-endorsement clause, rather than using phrases like "the authors" or
"the copyright holders".  The MIT/Expat license doesn't have that
problem.)

For reference, the MIT/Expat license text:

Permission is hereby granted, free of charge, to any person obtaining a copy of
this software and associated documentation files (the "Software"), to deal in
the Software without restriction, including without limitation the rights to
use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of
the Software, and to permit persons to whom the Software is furnished to do so,
subject to the following conditions:

The above copyright notice and this permission notice shall be included in all
copies or substantial portions of the Software.

THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS
FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.  IN NO EVENT SHALL THE AUTHORS OR
COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER
IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN
CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.


Proposed diff to Policy in git-format-patch form:
----- 8< -----

---
 policy.sgml | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/policy.sgml b/policy.sgml
index 9cd182b..2026582 100644
--- a/policy.sgml
+++ b/policy.sgml
@@ -10932,8 +10932,8 @@ END-INFO-DIR-ENTRY
 	  Packages distributed under the Apache license (version 2.0), the
 	  Artistic license, the GNU GPL (versions 1, 2, or 3), the GNU
 	  LGPL (versions 2, 2.1, or 3), the GNU FDL (versions 1.2 or 1.3),
-	  and the Mozilla Public License (version 1.1 or 2.0) should refer
-	  to the corresponding files under
+	  the MIT/Expat license, and the Mozilla Public License (version 1.1
+	  or 2.0) should refer to the corresponding files under
 	  <file>/usr/share/common-licenses</file>,<footnote>
 	    <p>
 	      In particular,
@@ -10947,6 +10947,7 @@ END-INFO-DIR-ENTRY
               <file>/usr/share/common-licenses/LGPL-3</file>,
               <file>/usr/share/common-licenses/GFDL-1.2</file>,
               <file>/usr/share/common-licenses/GFDL-1.3</file>,
+              <file>/usr/share/common-licenses/MIT</file>,
               <file>/usr/share/common-licenses/MPL-1.1</file>, and
               <file>/usr/share/common-licenses/MPL-2.0</file>
 	      respectively.  The University of California BSD license is
-- 
2.8.1

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/msg00007.html
[3] https://lists.debian.org/debian-devel/2014/09/msg00708.html

Josh Triplett <josh@joshtriplett.org> writes:

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

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.

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

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

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

If the upstream source just says:

license = "MIT"

then that should suffice.

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

- Josh Triplett

Josh Triplett <josh@joshtriplett.org> writes:

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.

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.

Simon McVittie <smcv@debian.org> writes:

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.

Thanks for confirming.

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