Machine-readable debian/copyright file.

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.

Whitespace-separated lists

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

Another kind of list value has one value per line. For example, Copyright can list many copyright statements, one per line.

Text formatted like package long descriptions

Formatted text fields use the same rules as the long description in a package's Description field, possibly also using the first line as a synopsis, like Description uses it for the short description. See Debian Policy's section 5.6.13, "Description", for details. For example, Disclaimer has no special first line, whereas License does.

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.

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)

The declaration of copyright and license for files is done in 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.

The following fields may be present in a Files paragraph.

• Files: required.

• Copyright: required.

• License: required.

• Comment: optional.

Files: *
Copyright: 1975-2010 Ulla Upstream
License: GPL-2+

Files: debian/*
Copyright: 2010 Daniela Debianizer
License: GPL-2+

Files: debian/patches/fancy-feature
Copyright: 2010 Daniela Debianizer
License: GPL-3+

Files: */*.1
Copyright: 2010 Manuela Manpager
License: GPL-2+

Stand-alone License Paragraph (Optional, Repeatable)

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 stand-alone License paragraphs to expand the license short names.

The following fields may be present in a stand-alone License paragraph.

• License: required.

• Comment: optional.

Files: src/js/editline/*
Copyright: 1993, John Doe
           1993, Joe Average
License: MPL-1.1 or GPL-2 or LGPL-2.1

License: MPL-1.1
 [LICENSE TEXT]

License: GPL-2
 [LICENSE TEXT]

License: LGPL-2.1
 [LICENSE TEXT]

Files: src/js/editline/*
Copyright: 1993, John Doe
           1993, Joe Average
License: MPL-1.1

Files: src/js/fdlibm/*
Copyright: 1993, J-Random Corporation
License: MPL-1.1

License: MPL-1.1
 [LICENSE TEXT]

Format

Single-line: URI of the format specification, such as: http://www.debian.org/doc/packaging-manuals/copyright-format/1.0/.

Upstream-Name

Single-line: the name upstream uses for the software

Upstream-Contact

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.

Source

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.

Disclaimer

Formatted text, no synopsis: this field can be used in the case of non-free and contrib packages (see 12.5).

Comment

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.

License

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.

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

Copyright

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

Copyright 2010 Angela Watts

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.

Files

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.

Multiple Files paragraphs are allowed. The last paragraph that matches a particular file applies to it.

Exclusions are done by having multiple Files paragraphs.

Short name

Much of the value of a machine-parseable copyright file lies in being able to correlate the licenses of multiple pieces of software. To that end, this spec defines standard short names for a number of commonly used licenses, which can be used in the first line of a License field.

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 compare the full license text.

From time to time, licenses may be added to or removed from the list of standard short names. Such changes in the list of short names will always be accompanied by changes to the recommended Format value. Implementers who are parsing copyright files should take care not to assume anything about the meaning of license short names for unknown Format versions.

Use of a standard short name does not override the Debian Policy requirement to include the full license text in 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 files paragraph.

For licenses which have multiple versions in use, the version number is 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 "2.0" and "2").

Currently, the full text of the licenses is only available in the SPDX Open Source License Registry.

There are many versions of the MIT license. Please use Expat instead, when it matches.

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 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 license notice of each file as specified at How does the GPL apply to fonts. The precise text corresponding to this exception is:

As a special exception, if you create a document which uses this font,
and embed this font or unaltered portions of this font into the
document, this font does not by itself cause the resulting document to
be covered by the GNU General Public License. This exception does not
however invalidate any other reasons why the document might be covered
by the GNU General Public License. If you modify this font, you may
extend this exception to your version of the font, but you are not
obligated to do so. If you do not wish to do so, delete this exception
statement from your version.

The GPL OpenSSL exception gives permission to link GPL-licensed code with the OpenSSL library, which contains GPL-incompatible clauses. For more information, see The -OpenSSL License and The GPL by Mark McLoughlin and the message middleman software license conflicts with OpenSSL by Mark McLoughlin on the debian-legal mailing list. The text corresponding to this exception is:

In addition, as a special exception, the copyright holders give
permission to link the code of portions of this program with the
OpenSSL library under certain conditions as described in each
individual source file, and distribute linked combinations including
the two.

You must obey the GNU General Public License in all respects for all
of the code used other than OpenSSL. If you modify file(s) with this
exception, you may extend this exception to your version of the
file(s), but you are not obligated to do so. If you do not wish to do
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.

Syntax

License names are case-insensitive, and may not contain spaces.

In case of multi-licensing, the license short names are separated by or when the user can chose between different licenses, and by and when use of the work must simultaneously comply with the terms of multiple licenses.

For instance, this is a simple, "GPL version 2 or later" field:

License: GPL-2+

License: GPL-1+ or Artistic

License: GPL-2+ and BSD

A or B and C means A or (B and C).

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+ with OpenSSL exception
 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 option) any later
 version.
 .
 In addition, as a special exception, the author of this
 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
 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,
 delete this exception statement from your version.
 .
 This program is distributed in the hope that it will be
 useful, but WITHOUT ANY WARRANTY; without even the implied
 warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR
 PURPOSE.  See the GNU General Public License for more
 details.
 .
 You should have received a copy of the GNU General Public
 License along with this package; if not, write to the Free
 Software Foundation, Inc., 51 Franklin St, Fifth Floor,
 Boston, MA  02110-1301 USA
 .
 On Debian systems, the full text of the GNU General Public
 License version 2 can be found in the file
 `/usr/share/common-licenses/GPL-2'.

SPDX

SPDX is an attempt to standardize a format for communicating the components, licenses and copyrights associated with a software package. It and the machine-readable debian/copyright format attempt to be somewhat compatible. However, the two formats have different aims, and so the formats are different. The DEP5 wiki page will be used to track the differences.