X-Git-Url: https://git.donarmstrong.com/?a=blobdiff_plain;f=copyright-format%2Fcopyright-format.xml;h=36265a4a3acc802fb92c22102c5b5e7227a6ea9c;hb=2185e5d5e4d921bf2697d86a80c3cf1d91e8d398;hp=a62da994b103154fcb3041606395ab87829f77b4;hpb=90d1e66e5f190309a8402e57decad6b9997306dc;p=debian%2Fdebian-policy.git
diff --git a/copyright-format/copyright-format.xml b/copyright-format/copyright-format.xml
index a62da99..36265a4 100644
--- a/copyright-format/copyright-format.xml
+++ b/copyright-format/copyright-format.xml
@@ -25,18 +25,14 @@
- This specification was drafted as DEP-5, to establish a
- standard, machine-readable format for
- debian/copyright files within packages and
- facilitate automated checking and reporting of licenses for packages and
- sets of packages. The DEP drivers were Steve Langasek
- vorlon@debian.org and Lars Wirzenius
- liw@liw.fi.
+ Establish a standard, machine-readable format for
+ debian/copyright files within packages and to
+ facilitate automated checking and reporting of licenses for packages
+ and sets of packages.
-
+
Introduction
@@ -47,14 +43,16 @@
automatically extract licensing information.
- This is not a proposal to change the policy in the short term. In
- particular, nothing in this proposal supersedes or modifies any of the
+ Use of this specification is optional.
+
+
+ Nothing in this proposal supersedes or modifies any of the
requirements specified in Debian Policy regarding the appropriate detail
or granularity to use when documenting copyright and license status in
debian/copyright.
-
+
Rationale
@@ -83,9 +81,9 @@
no way to know how much of Debian should be stripped from such a system.
- A user might want to have a way to avoid software with certain licenses
- they have a problem with, even if the licenses are DFSG-free. For example,
- the Affero GPL.
+ Even where licenses are DFSG-free and mutually compatible, users might want
+ a way to avoid software with certain licenses, for example if they have a
+ problem with the Affero GPL.
@@ -104,7 +102,7 @@
Lars Wirzenius.
-
+
File syntax
@@ -123,39 +121,46 @@
avoid conflicting specifications for widely used extra fields.
- There are four kinds values for fields. Each field specifies which kind
- is allowed.
+ The file consists of two or more paragraphs. At minimum, the file
+ must include one header
+ paragraph and one Files
+ paragraph.
-
+
+ There are four types of fields. The definition for each field in this
+ document indicates which type of value it takes.
+
+
Single-line values
- A single-line value means that the whole value of a field must fit on a
- single line. For example, the Format field has a
- single line value specifying the version of the machine-readable format
- that is used.
+ A single-line value means that the whole value of a field must fit
+ on a single line. For example, the Format field
+ has a single-line value specifying the version of the
+ machine-readable format that is used.
-
+
- White space separated lists
+ Whitespace-separated lists
- A white space separated list means that the field value may be on one
- line or many, but values in the list are separated by one or more white
- space characters (including space, TAB, and newline). For example, the
- Filesfield has a list of filename patterns.
+ A whitespace-separated list means that the field value may be on one
+ line or many, but values in the list are separated by one or more
+ whitespace characters (including space, TAB, and newline). For
+ example, the Files field has a list of filename
+ patterns.
-
+
- Line based lists
+ Line-based lists
- Another kind of list value has one value per line. For example,
- Copyright can list many copyright statements, one per
+ This means that the field has one value per line. For example,
+ Upstream-Contact can list contact addresses, one per
line.
-
+
Text formatted like package long descriptions
@@ -169,277 +174,127 @@
-
+
Paragraphs
- There are three kinds of paragraphs: the first one is called the
- header paragraph. Every other
- paragraph is either a Files
- paragraph or a stand-alone
- license paragraph. This is similar to source and binary package
+ There are three kinds of paragraphs. The first paragraph in the file
+ is called the header paragraph.
+ Every other paragraph is either a Files paragraph or a stand-alone License
+ paragraph. This is similar to source and binary package
paragraphs in debian/control files.
-
+
- Header paragraph (Once)
-
- <varname>Format</varname>
-
- Required single line: URI of the format specification, such as:
- http://www.debian.org/doc/copyright-format/1.0
-
-
-
-
- <varname>Upstream-Name</varname>
-
- Optional single line: the name upstream uses for the software
-
-
-
-
- <varname>Upstream-Contact</varname>
-
- Optional line based list: the preferred address(es) to reach the
- upstream project. May be free-form text, but by convention will
- usually be written as a list of RFC5322 addresses or URIs.
-
-
-
-
- <varname>Source</varname>
-
- Optional formatted text, no synopsis: an explanation from where the
- upstream source came from. Typically this would be a URL, but it might
- be a free-form explanation. The Debian Policy section 12.5
- requires this information unless there are no upstream sources, which
- is mainly the case for native Debian packages. If the upstream source
- has been modified to remove non-free parts, that should be explained
- in this field.
-
-
-
-
- <varname>Disclaimer</varname>
-
- Optional formatted text, no synopsis: this field can be used in the
- case of non-free and contrib packages (see 12.5)
-
-
-
-
- <varname>Comment</varname>
-
- Optional formatted text, no synopsis: this field can provide
- additional information. For example, it might quote an e-mail from
- upstream justifying why the license is acceptable to the main archive,
- or an explanation of how this version of the package has been forked
- from a version known to be DFSG-free, even though the current upstream
- version is not.
-
-
-
-
- <varname>License</varname>
-
- Optional formatted text, with synopsis: in the header paragraph
- (no Files specification), this field gives the
- license information for the package as a whole, which may be different
- or simplified from a combination of all the per-file license
- information. License below in the Files paragraph section.
-
-
-
-
- <varname>Copyright</varname>
-
- Optional line based list: in the header paragraph (no
- Files specification), this field gives the
- copyright information for the package as a whole, which may be
- different or simplified from a combination of all the per-file
- copyright information. See also Copyright below
- in the Files paragraph
- section.
-
-
- The Copyright and License fields
- in the header paragraph may complement but do not
- replace the files paragraphs. They can be used
- to summarise the contributions and redistribution terms for the whole
- package, for instance when a work combines a permissive and a copyleft
- license, or to document a compilation copyright
- and license. It is possible to use only License in
- the header paragraph, but Copyrightalone makes no
- sense.
-
-
-
+ Header paragraph (once)
+
+ The following fields may be present in a header paragraph.
+
+
+
+
+ Format: required.
+
+
+
+
+ Upstream-Name:
+ optional.
+
+
+
+
+ Upstream-Contact:
+ optional.
+
+
+
+
+ Source: optional.
+
+
+
+
+ Disclaimer:
+ optional.
+
+
+
+
+ Comment: optional.
+
+
+
+
+ License: optional.
+
+
+
+
+ Copyright: optional.
+
+
+
+
+ The Copyright and License
+ fields in the header paragraph may complement
+ but do not replace the Files paragraphs. They
+ can be used to summarise the contributions and redistribution terms
+ for the whole package, for instance when a work combines a
+ permissive and a copyleft license, or to document a
+ compilation copyright and license. It is
+ possible to use only License in the header
+ paragraph, but Copyright alone makes no sense.
+
+
Example header paragraph
-Format: <VERSIONED_FORMAT_URL>
+Format: http://www.debian.org/doc/packaging-manuals/copyright-format/1.0/
Upstream-Name: SOFTware
Upstream-Contact: John Doe <john.doe@example.com>
Source: http://www.example.com/software/project
-
-
- Files paragraph (Repeatable)
+
+
+ Files paragraph (repeatable)
- The declaration of copyright and license for files is done in one or
+ The declaration of copyright and license for files may consist of one or
more paragraphs. In the simplest case, a single paragraph can be used
- which applies to all files and lists all applicable copyrights and
- licenses.
-
-
-
- <varname>Files</varname>
-
- Required white space separated list: list of patterns indicating files
- covered by the license and copyright specified in this paragraph.
-
-
- Filename patterns in the Files field are specified
- using a simplified shell glob syntax. Patterns are separated by white
- space.
-
-
-
- Only the wildcards * and ?
- apply; the former matches any number of characters (including
- none), the latter a single character. Both match a slash
- (/) and a leading dot.
-
-
-
-
- Patterns match pathnames that start at the root of the source
- tree. Thus, Makefile.in
- matches only the file at the root of the tree, but
- */Makefile.in matches at any
- depth.
-
-
-
-
- The backslash (\) is used to remove the magic
- from the next character; see table below.
-
-
-
-
-
-
-
- Escape sequence
- Matches
-
-
-
-
- \*
- star (asterisk)
-
-
- \?
- question mark
-
-
- \\
- backslash
-
-
-
-
- Any other character following a backslash is an error.
-
-
- Multiple Files paragraphs are allowed. The last
- paragraph that matches a particular file applies to it.
+ which applies to the whole package. Only the license and copyright
+ information required by the Debian archive is required to be listed
+ here.
- Exclusions are done by having multiple Files
- paragraphs.
+ The following fields may be present in a Files paragraph.
-
-
-
- <varname>Copyright</varname>
-
- Required line based list: one or more free-form copyright
- statement(s), one per line, that apply to the files matched by the
- above pattern. If a work has no copyright holder (i.e., it is in
- the public domain), that information should be recorded here.
-
-
- The Copyright field collects all relevant copyright
- notices for the files of this paragraph. Not all copyright notices
- may apply to every individual file, and years of publication for one
- copyright holder may be gathered together. For example, if file A
- has:
-Copyright 2008 John Smith
-Copyright 2009 Angela Watts
- and file B has:
-Copyright 2010 Angela Watts
- the Copyright field for a stanza
- covering both file A and file B need contain only:
-Copyright 2008 John Smith
-Copyright 2009, 2010 Angela Watts
-
-
- The Copyright field may contain the original
- copyright statement copied exactly (including the word
- Copyright), or it can shorten the text, as long
- as it does not sacrifice information. Examples in this specification
- use both forms.
-
-
-
- <varname>License</varname>
-
- Required formatted text, with synopsis: licensing terms for the files
- listed in Files field for this paragraph.
-
-
- First line: an abbreviated name for the license, or expression
- giving alternatives (see Short
- names section for a list of standard abbreviations). If there
- are licenses present in the package without a standard short name, an
- arbitrary short name may be assigned for these licenses. These
- arbitrary names are only guaranteed to be unique within a single
- copyright file.
-
-
- Remaining lines: if left blank here, the file
- must include a stand-alone
- License paragraph matching each license short
- name listed on the first line (see the Standalone License
- Paragraph section). Otherwise, this field should either
- include the full text of the license(s) or include a pointer to the
- license file under /usr/share/common-licenses.
- This field should include all text needed in order to fulfill both
- Debian Policy's requirement for including a copy of the software's
- distribution license (12.5),
- and any license requirements to include warranty disclaimers or other
- notices with the binary package.
-
-
-
-
- <varname>Comment</varname>
-
- Same as the
- Comment field in the header paragraph.
-
-
-
+
+
+
+ Files: required.
+
+
+
+
+ Copyright: required.
+
+
+
+
+ License: required.
+
+
+
+
+ Comment: optional.
+
+
+
+
Example files paragraphsFiles: *
@@ -467,15 +322,34 @@ License: GPL-2+
-
+
- Standalone License Paragraph (Optional, Repeatable)
+ Stand-alone License Paragraph (optional, repeatable)
+
+ Stand-alone License paragraphs can be used to
+ provide the full license text for a given license once, instead of
+ repeating it in each Files paragraph that refers to
+ it. The first line of the License field must be a
+ single license short name or a short name followed by a license
+ exception.
+
- Where a set of files are dual (tri, etc) licensed, or when the same
- license occurs multiple times, you can use a single line
- License field and standalone
- License paragraphs to expand the license short names.
+ The following fields may be present in a stand-alone License
+ paragraph.
+
+
+
+
+ License: required.
+
+
+
+
+ Comment: optional.
+
+
+ tri-licensed filesFiles: src/js/editline/*
@@ -490,9 +364,9 @@ License: GPL-2
[LICENSE TEXT]
License: LGPL-2.1
- LICENSE TEXT]
+ [LICENSE TEXT]
-
+
recurrent licenseFiles: src/js/editline/*
@@ -510,9 +384,223 @@ License: MPL-1.1
+
+ Fields
+
+ The following fields are defined for use in
+ debian/copyright.
+
+
+
+ <varname>Format</varname>
+
+ Single-line: URI of the format specification, such as:
+ http://www.debian.org/doc/packaging-manuals/copyright-format/1.0/.
+
+
+
+
+ <varname>Upstream-Name</varname>
+
+ Single-line: the name upstream uses for the software
+
+
+
+
+ <varname>Upstream-Contact</varname>
+
+ Line-based list: the preferred address(es) to reach the upstream
+ project. May be free-form text, but by convention will usually be
+ written as a list of RFC5322 addresses or URIs.
+
+
+
+
+ <varname>Source</varname>
+
+ Formatted text, no synopsis: an explanation of where the upstream
+ source came from. Typically this would be a URL, but it might be a
+ free-form explanation. The Debian Policy section 12.5
+ requires this information unless there are no upstream sources,
+ which is mainly the case for native Debian packages. If the
+ upstream source has been modified to remove non-free parts, that
+ should be explained in this field.
+
+
+
+
+ <varname>Disclaimer</varname>
+
+ Formatted text, no synopsis: this field can be used in the case of
+ non-free and contrib packages (see 12.5).
+
+
+
+
+ <varname>Comment</varname>
+
+ Formatted text, no synopsis: this field can provide additional
+ information. For example, it might quote an e-mail from upstream
+ justifying why the license is acceptable to the main archive, or an
+ explanation of how this version of the package has been forked from
+ a version known to be DFSG-free, even though the current upstream
+ version is not.
+
+
+
+
+ <varname>License</varname>
+
+ Formatted text, with synopsis. In the header paragraph, this field
+ gives the license information for the package as a whole, which may
+ be different or simplified from a combination of all the per-file
+ license information. In a Files paragraph, this field gives the
+ licensing terms for the files listed in the Files
+ field for this paragraph. In a stand-alone License paragraph, it
+ gives the licensing terms for those paragraphs which reference it.
+
+
+ First line: an abbreviated name for the license, or expression
+ giving alternatives (see Short
+ names section for a list of standard abbreviations). If
+ there are licenses present in the package without a standard short
+ name, an arbitrary short name may be assigned for these licenses.
+ These arbitrary names are only guaranteed to be unique within a
+ single copyright file.
+
+
+ If there are no remaining lines, then all of the short names
+ or short names followed by license exceptions making up the
+ first line must be described in stand-alone License
+ paragraphs. Otherwise, this field should either
+ include the full text of the license(s) or include a pointer to the
+ license file under /usr/share/common-licenses.
+ This field should include all text needed in order to fulfill both
+ Debian Policy's requirement for including a copy of the software's
+ distribution license (12.5),
+ and any license requirements to include warranty disclaimers or
+ other notices with the binary package.
+
+
+
+
+ <varname>Copyright</varname>
+
+ Formatted text, no synopsis: one or more free-form copyright
+ statement(s). Any formatting is permitted; see the examples below
+ for some ideas for how to structure the field to make it easier to
+ read. In the header paragraph, this field gives the copyright
+ information for the package as a whole, which may be different or
+ simplified from a combination of all the per-file copyright
+ information. In the Files paragraphs, it gives the copyright
+ information that applies to the files matched by the
+ Files pattern. If a work has no copyright holder
+ (i.e., it is in the public domain), that information should be
+ recorded here.
+
+
+ The Copyright field collects all relevant
+ copyright notices for the files of this paragraph. Not all
+ copyright notices may apply to every individual file, and years of
+ publication for one copyright holder may be gathered together. For
+ example, if file A has:
+Copyright 2008 John Smith
+Copyright 2009 Angela Watts
+ and file B has:
+Copyright 2010 Angela Watts
+ then the Copyright field for a paragraph covering both
+ file A and file B only needs to contain:
+Copyright 2008 John Smith
+Copyright 2009, 2010 Angela Watts
+
+
+ The Copyright field may contain the original
+ copyright statement copied exactly (including the word
+ Copyright), or it can shorten the text, as long as it
+ does not sacrifice information. Examples in this specification use
+ both forms.
+
+
+
+
+ <varname>Files</varname>
+
+ Whitespace-separated list: list of patterns indicating files covered
+ by the license and copyright specified in this paragraph.
+
+
+ Filename patterns in the Files field are
+ specified using a simplified shell glob syntax. Patterns are
+ separated by whitespace.
+
+
+
+ Only the wildcards * and ?
+ apply; the former matches any number of characters (including
+ none), the latter a single character. Both match a slash
+ (/) and a leading dot.
+
+
+
+
+ Patterns match pathnames that start at the root of the source
+ tree. Thus, Makefile.in
+ matches only the file at the root of the tree, but
+ */Makefile.in matches at
+ any depth.
+
+
+
+
+ The backslash (\) is used to remove the
+ magic from the next character; see table below.
+
+
+
+
+
+
+
+ Escape sequence
+ Matches
+
+
+
+
+ \*
+ star (asterisk)
+
+
+ \?
+ question mark
+
+
+ \\
+ backslash
+
+
+
+
+ Any other character following a backslash is an error.
+
+
+ Multiple Files paragraphs are allowed. The last
+ paragraph that matches a particular file applies to it.
+
+
+ Exclusions are only supported by adding Files
+ paragraphs to override the previous match.
+
+
+
+ License specification
-
+
Short name
@@ -523,7 +611,7 @@ License: MPL-1.1
License field.
- These short names have the specified meanings across all uses of this
+ These short names have the specified meanings across all uses of this
file format, and must not be used to refer to any
other licenses. Parsers may thus rely on these short names referring to
the same licenses wherever they occur, without needing to parse or
@@ -543,7 +631,7 @@ License: MPL-1.1
debian/copyright, nor any requirements in the
license of the work regarding reproduction of legal notices. This
information must still be included in the License
- field, either in a stand-alone license paragraph or in the relevant
+ field, either in a stand-alone License paragraph or in the relevant
files paragraph.
@@ -551,15 +639,14 @@ License: MPL-1.1
added, using a dash as a separator. If omitted, the lowest version
number is implied. When the license grant permits using the terms of any
later version of that license, the short name is finished with a plus
- sign. For SPDX compatibility, trailing
- dot-zeroes are considered to be equal to plainer
- version (e.g., 2.0.0 is considered equal to
+ sign. For SPDX compatibility, versions with trailing
+ dot-zeroes are considered to be equivalent to
+ versions without (e.g., 2.0.0 is considered equal to
2.0 and 2).
Currently, the full text of the licenses is only available in the working version
- of the SPDX license list.
+ url="http://spdx.org/licenses">SPDX Open Source License Registry.
@@ -582,9 +669,9 @@ License: MPL-1.1
Apache
- Apache license
- 1.0,
- 2.0.
+ Apache license
+ 1.0,
+ 2.0.
@@ -592,7 +679,7 @@ License: MPL-1.1
Artistic
- Artistic license
+ Artistic license
1.0,
2.0.
@@ -713,9 +800,8 @@ License: MPL-1.1
CC0
- Creative Commons Universal
- waiver.
+ Creative Commons Zero
+ 1.0 Universal.
@@ -723,8 +809,8 @@ License: MPL-1.1
CDDL
- Common Development
- and Distribution License.
+ Common Development and Distribution License
+ 1.0.
@@ -742,7 +828,8 @@ License: MPL-1.1
The Eiffel Forum License
- 1.0.
+ 1.0,
+ 2.0.
@@ -774,7 +861,6 @@ License: MPL-1.1
2.1,
3.0, or
GNU Library General Public License
- 1.0,
2.0.
@@ -783,8 +869,8 @@ License: MPL-1.1
GFDL
- GNU Free
- Documentation License.
+ GNU Free Documentation License 1.0, or
+ 1.1.
@@ -829,12 +915,13 @@ License: MPL-1.1
- Python-CNRI
+ Python
- Python
- license.
+ Python license
+ 2.0.
+
@@ -871,8 +958,8 @@ License: MPL-1.1
Zope
- Zope Public License
- 1.0,
+ Zope Public License 1.0,
+ 1.1,
2.0,
2.1.
@@ -887,10 +974,23 @@ License: MPL-1.1
matches.
- Exceptions and clarifications are signaled in plain text, by appending
+ An exception or clarification to a license is signaled in plain text, by appending
with keywords
exception to the short name. This document provides a list of
- keywords that refer to the most frequent exceptions.
+ keywords that must be used when referring to the most frequent
+ exceptions. When exceptions other than these are in effect that modify
+ a common license by granting additional permissions, you may use an
+ arbitrary keyword not taken from the below list of keywords. When a
+ license differs from a common license because of added restrictions
+ rather than because of added permissions, a distinct short name should
+ be used instead of with
+ keywords
+ exception.
+
+
+ Only one exception may be specified for each license within a given
+ license specification. If more than one exception applies to a single
+ license, an arbitrary short name must be used instead.
The GPL Font exception refers to the text added to the
@@ -933,7 +1033,7 @@ so, delete this exception statement from your version. If you delete
this exception statement from all source files in the program, then
also delete it here.
-
+
Public domain
@@ -962,7 +1062,7 @@ also delete it here.
-
+
Syntax
@@ -981,22 +1081,23 @@ also delete it here.
This is a dual-licensed GPL/Artistic work such as Perl:
License: GPL-1+ or Artistic
This is for a file that has both GPL and classic BSD code in it:
-License: GPL-2+ and BSD
- For the most complex cases, the comma is used to disambiguate the
- priority of ors and ands
- and has the priority over or,
- unless preceded by a comma. For instance:
+License: GPL-2+ and BSD-3-clause
+ For the most complex cases, a comma is used to disambiguate the
+ priority of ors and ands.
+ The conjunction and has priority over
+ or unless preceded by a comma. For
+ instance:
A or B and C means A or (B and C).
- A or B, and C means (A or B), and
+ A or B, and C means (A or B) and
C.
This is for a file that has Perl code and classic BSD code in it:
-License: GPL-2+ or Artistic-2.0, and BSD
+License: GPL-2+ or Artistic-2.0, and BSD-3-clause
A GPL-2+ work with the OpenSSL
exception is in effect a dual-licensed work that can be redistributed
either under the GPL-2+, or under the
@@ -1011,12 +1112,12 @@ also delete it here.
version.
.
In addition, as a special exception, the author of this
- program gives permission to link the code of its
+ program gives permission to link the code of its
release with the OpenSSL project's "OpenSSL" library (or
with modified versions of it that use the same license as
the "OpenSSL" library), and distribute the linked
- executables. You must obey the GNU General Public
- License in all respects for all of the code used other
+ executables. You must obey the GNU General Public
+ License in all respects for all of the code used other
than "OpenSSL". If you modify this file, you may extend
this exception to your version of the file, but you are
not obligated to do so. If you do not wish to do so,
@@ -1062,7 +1163,7 @@ also delete it here.
A possible debian/copyright file for the program
X Solitaire distributed in the Debian source package
xsol:
-
+
-License:
+License: GPL-2+
[LICENSE TEXT]]]>
@@ -1103,7 +1204,7 @@ License:
A possible debian/copyright file for the program
Planet Venus, distributed in the Debian source
package planet-venus:
-
+
Source: http://www.example.com/code/venus
@@ -1118,7 +1219,7 @@ License: PSF-2
Files: debian/*
Copyright: 2008, Dan Developer
-License:
+License: permissive
Copying and distribution of this package, with or without
modification, are permitted in any medium without royalty
provided the copyright notice and this notice are
@@ -1170,28 +1271,5 @@ License: GPL-2+
-
-
-
- Appendix: Note about the use of this format in Debian
-
-
- The Debian Policy (§12.5)
- demands that each package is accompanied by a file,
- debian/copyright in source packages and
- /usr/share/doc/package/copyright in binary packages,
- that contains a verbatim copy of its copyright and distribution license.
- In addition, it requires that copyrights must be extractable by mechanical
- means. This proposal for machine-readable copyright and license summary
- files has been crafted for Debian's use, but it is our hope that other
- software distributions, as well as upstream developers will adopt it, so
- that review efforts can be easily reproduced and shared.
-
-
- The copyright of the Debian packaging and the history of package
- maintainers is simply indicated in a Files: debian/*
- paragraph.
-
-
+