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

Bug#649530: [copyright-format] DEP5: clearer definitions and more consistent License: stanza specification



Package: debian-policy
Severity: normal

Hi all,

When packaging mozilla extensions I ran some problems with DEP5. I talked this
issue over on #645696 which eventually resulted in encouragement to move forward
with a proposal for a change to be made.

The fundamental problem:

DEP5 is unclear about what is meant by a "license".

There are 3 pieces of information required to satisfy copyright requirements:
- WHO - which people have copyright 
- WHAT - which materials are subject to copyright
- TERMS - the conditions under which those materials can be used

WHO and WHAT change depending on the software, but in many cases the TERMS
remain constant (i.e. common published license texts), or are made up of a
simple combination (dual/tri/later-version) of common constants.

The standalone License stanza is poorly-specified by DEP5. Its intention seems
to be a way to eliminate redundancy (what else could it be?), but it does not
do this job well. It does not specify that the TERMS should be WHAT- and
WHO-neutral, which I think is a fundamental design flaw and the root cause of
the symptoms described further below.

If you need further convincing, you may want to scroll down and read more about
the problems. If you are bored and just want to hear the solution, here:

The solution:
- Specify that standalone License: stanzas are WHO- and WHAT- neutral.
- If clarification is required for a particular WHO/WHAT combination, such as
  the way in which re-licensing works *in addition* to the and/or/+/exception
  syntax (e.g. "GPL2+", "MPL or GPL"), this should be added to the relevant
  File: stanza, in the Comment: field, or perhaps we should add a new field for
  this specific purpose.

For standalone License: stanzas, this allows:
- published license texts such as the GPL and most other familiar things, which
  do not make reference to particular materials (WHAT-neutral) or authors
  (WHO-neutral)

For standalone License: stanzas, this forbids:
- author-specific preamble text
- dual/tri-relicensing permit text
- "later version"-relicensing permit text
- anything saying "This program is licensed under X" - this is not WHAT-neutral,
  as "this program" refers to a particular set of materials, and makes it
  problematic to re-use the License stanza for other sets of materials. This
  information should go in the File: stanza instead.
- similarly, anything saying "Copyright X".
- this includes some existing examples in the current DEP5.

This means we can eliminate redundancy better, allowing things like this:

| File: x
| License: MPL-1.1+ or GPL-2+ or LGPL-2.1+
| Comment: [standard MPL preamble, including the initial developer, other
|  contributors, etc etc etc]
| 
| File: y
| License: GPL-2 with X exception
| Comment: This program is released under GPL-2. As a special exception, you may
|  [etc].
| 
| File: z
| License: GPL-2 or LGPL-2.1
| 
| License: GPL-2
|  The GPL-2 is a strong copyleft license. [maybe summary of key points.]
|  [pointer to common-licenses.]
| 
| License: LGPL-2.1
|  The LGPL-2.1 is a permissive copyleft license. [maybe summary of key points.]
|  [pointer to common-licenses.]
| 
| License: MPL-1.1
|  The MPL-1.1 is a permissive copyleft license. [maybe summary of key points.]
|  [full text of MPL]

I see no particular reason not to do this. There is the inertia argument, but I
think that's a poor excuse to not iron out the rough edges in a specification,
especially that it's currently in CANDIDATE stage where changes are supposed to
be discussed. The problems I'm describing are only going to get worse, the more
packages with complex copyrights that are exposed to the current DEP5. With the
goal of being machine-parseable, consistency is a principle to aim for, even if
the cost seems quite high.

----

If you need convincing, here are details of some specific problems:

The symptoms:

- DEP5 suggests that identical licenses can be factored into their own License:
  stanzas, and sets out some rules for doing this.
- However, these rules are inconsistent and ambiguous about what a "license" is.
  - DEP5 requires us to split "MPL or GPL or LGPL" into 3 separate stanzas.
  - The standard interpretation (and current lintian) requires full text for
    GPL2 and GPL2+ to be in separate stanzas.

This is a problem, being:

- redundant, because it does not allow us to re-use identical full text.
- inconsistent, because GPL2+ is logically equivalent to (GPL2 or GPL3 or ...)
  - we are expected to explicitly mention the possibility of relicensing in the
    License: stanza for "GPL2+"
  - however, for "GPL or BSD", DEP5 allows us to imply relicensing simply by
    virtue of the "or" keyword, and quote the components verbatim without other
    qualifiers.

Other symptoms: 

- DEP5 uses something like the following as an example
  | License: GPL2+
  |  This program is free software; you can redistribute it
  |  and/or modify it under the terms of the GNU General
  |  Public License as published by the Free Software
  |  Foundation; either version 2 of the License, or (at your
  |  opinion) any later version.
  |  .
  |  [etc]
  and this was cited to me as an example of why we "should" have separate
  stanzas for GPL and GPL2+. I feel this is a bad patch on top of a problem.

- Treating author-specific preamble as part of the license means that we need to
  have multiple texts for the same "License" stanza, which DEP5 does not account
  for. For example, the MPL standard preamble lists all the different types of
  authors, which authors adapt as appropriate. If your package contains multiple
  such preambles, and they are also multi-licensed, DEP5 makes it impossible to
  represent this.


-- System Information:
Debian Release: wheezy/sid
  APT prefers testing
  APT policy: (990, 'testing'), (500, 'unstable'), (500, 'stable'), (1, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 3.0.0-1-amd64 (SMP w/2 CPU cores)
Locale: LANG=en_GB.utf8, LC_CTYPE=en_GB.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash



Reply to: