This page is about a proposal to make debian/copyright machine-interpretable. It is one of the most important files in Debian packaging, yet its format is vague and varies tremendously across packages, making it difficult to automatically parse.

This is not a proposal to change the policy in the short term.



The diversity of free software licenses means that Debian does not only need to care about the freeness of a given work, but also its license's compatibility with the other parts of Debian it uses.

The arrival of the GPL version 3, its incompatibility with version 2, and our inability to spot the software where the incompatibility might be problematic is the most recent occurrence of this limitation.

There are a few precedents, also. One is the GPL/OpenSSL incompatibility. Apart from grepping debian/copyright, which is prone to numerous false positives (packaging under the GPL but software under another license) or negatives (GPL software but with an "OpenSSL special exception" dual licensing form), there is no reliable way to know which software in Debian might be problematic.

And there is more to come. There are issues with shipping GPLv2-only software with a CDDL operating system such as Nexenta. The GPL version 3 solves this issue, but not all GPL software can switch to it and we have no way to know how much of Debian should be stripped from such a system.

Compatibility and Human-Readability

The file MUST be encoded as UTF-8 and must be strictly RFC2822, no free-form text is alowed.

The debian/copyright file MUST be machine-interpretable, yet human-readable, while communicating all mandated upstream information, copyright notices and licensing details.

For the sake of human-readablilty and this proposal avoids any complex field names or syntax rules.

For clarity it is recommended that separate logical sections are seperated with empty lines.


You can discuss implementation details in [ bug 478930] -- ?MathieuParent



Header Section (Once)

The header should be rfc2822 compliant.


Upstream-Name: SOFTware
Upstream-Maintainer: John Soft <>

Files Section (Repeatable)

The details are yet to be discussed. Here is a list of what is needed, and which fields I suggest to add:

License Section (Repeatable)

Where multiple sets of files use the same license you can avoid repetition by using a License field with keywords only and use a separate set of Licence-Terms fields to expand the license description.

Files: src/js/editline/*
Copyright: Copyright 1993, Simmule Turner
 Copyright 1993, Rich Salz
License: MPL-1.1 | GPL-2 | LGPL-2.1

Files: src/js/fdlibm/*
Copyright: Copyright 1993, Sun Microsystems Corporation
License: MPL-1.1 | GPL-2 | LGPL-2.1

License-Terms: MPL-1.1

License-Terms: GPL-2

License-Terms: LGPL-2.1

[...] propose using one License field for each section and expand their terms with a License-Terms. -- ?AndresMejia

What is the rationale for using Licence-Terms instead of Licence? As far as I can see both forms a equally parseable with the benefit that using the single Licence for both is only on field to remeber instead of two. -- ?NoahSlater

Fields Detail



The contents of the Files field should be a list of comma-separated values:

Files: foo.c, bar.*, baz.[ch]

Files containing spaces or commas should be put within double quotes. The backslash character is an escaping character, be it inside or outside double quotes:

Files: "Program Files/*", manual\[english\].txt


Patterns are the ones recognised by the find utility's -name and -wholename flags. They behave as if find had been called in the following way from the top source directory:

find . -wholename "$PATTERN"

This will match all files in the tree and all Python scripts:

Files: */, *.py

But this will only match the top-level

Files: ./

Special rule: if a pattern $PATTERN does not match any file in the source, it is implicitly considered to be expanded to */$PATTERN. This is to avoid insane verbosity when referring to a unique file buried deep in the tree.

Match Order

It is quite common for a work to have most of its files under a given license, and only a few files (for instance, embedded getopt.c and getopt.h) under another. However it makes more sense to have the copyright file list the "main" license first: the one matching the most files.

If multiple Files declarations match same file, then only the last match counts.

Thus, in this case of getopt.c, it is the second rule that has to be taken into account, and debian files are (wrongly!) interpreted as having same copyright holder and license as main work:

Files: *
Copyright: [the main work’s author]
License: [the main work’s license]

Files: debian/*
Copyright: [the debian package author]
License: [the debian package license]

Files: getopt.*
Copyright: © 2000 the NetBSD Foundation, Inc.
License: other-BSD



The "License" field format should not contain random values. Which is why there needs to be a list of accepted keywords which have a very specific, unambiguous meaning. Here is a non-exhaustive list, please help fill it with popular license names we're likely to meet in Debian:




GNU General Public License, author did not specify version ?BR (probably the same as GPL-1+)


GNU General Public License, version 1 only


GNU General Public License, version 1 or later ?BR (probably the same as GPL-any)


GNU General Public License, version 2 only


GNU General Public License, version 2 or later


GNU General Public License, version 3 only


GNU General Public License, version 3 or later


GNU Library/Lesser General Public License, author did not specify version


GNU Library General Public License, version 2 only


GNU Library General Public License, version 2 or later


GNU Lesser General Public License, version 2.1 only


GNU Lesser General Public License, version 2.1 or later


GNU Lesser General Public License, version 3 only


GNU Lesser General Public License, version 3 or later


Python License, author did not specify version


Python License, version 2 only


GNU Free Documentation License, author did not specify version ?BR (maybe this needs mention of the fact that we accept no invariant sections, etc.)


GNU Free Documentation License, version 1.1 only ?BR (same note as above)


GNU Free Documentation License, version 1.1 or newer ?BR (same note as above)


GNU Free Documentation License, version 1.2 only ?BR (same note as above)


GNU Free Documentation License, version 1.2 or newer ?BR (same note as above)


GNU All-Permissive license,


Two-clause BSD license


Three-clause BSD license, with no-endorsement clause, as seen in /usr/share/common-licenses/BSD?BR


Four-clause BSD license, with no-endorsement clause and advertising clause; GPL-incompatible (need exact text)


Apache license, version 1.0; not GPL-compatible


Apache license, version 1.1; not GPL-compatible


Apache license, version 2.0; GPL-3-compatible, not GPL-2-compatible


Mozilla Public License, version 1.1 only,


The original Artistic license, as seen in /usr/share/common-licenses/Artistic


The Artistic license, version 2.0,


The LaTeX Project Public License, version 1.3a,; GPL-incompatible?BRNote that works under any version of the LPPL often have additional restrictions attached; check carefully.


Zope Public License, author did not specify version


Zope Public License, version 2.1 only


Erlang Public License, version 1.1 only


Eiffel Forum License, version 2 only


IBM Common Public License


Creative Commons Attribution License (Unported), version 3.0 only


Creative Commons Attribution-?ShareAlike Licence (Unported), version 3.0 only


The zlib/libpng license as in


The terms of the Expat license, ?BR This license is what many people mean by "the MIT license", but that term is too ambiguous as there is more than one "MIT license" in the wild


The W3C Software License,


CEA-CNRS-INRIA-Logiciel Libre, version 1,


CEA-CNRS-INRIA-Logiciel Libre, version 2,


CEA-CNRS-INRIA-Logiciel Libre B,


CEA-CNRS-INRIA-Logiciel Libre C,


add your favourite license here


Anything else not covered in this list, should be clarified in the following lines of the field

Can we have other-non-free and other-gpl[2|3]-[in]compatible? The latter would help to automate a GPL-compatibility check. The former could help with mixed free/non-free source packages -- the whole package would of course go in non-free, but it could be worth noting for a later effort to separate out the non-free parts. -- ?AdamPowell

Stuff that we might want but that needs to be clarified:


a BSD-like license ?BR (not sure it's wise to have this keyword, especially since it might be GPL-incompatible; if in doubt, let's stick with "other")


Several variants of the MIT license exist: the standard version with three paragraphs (blanket permission, keep this notice, NO WARRANTY), a version with a no-endorsement clause, and other versions with slight wording differences.


When the work is licenced under an unspecified MIT style licence.


In the public domain, not applicable everywhere


License names are case-insensitive.

The syntax of the field should follow debian/control's Depends field. The pipe character "|" is used for code that can be used under the terms of either licenses. The comma "," is used for code that must be used under the terms of both licenses (for rare cases where a single file contains code under both licenses).

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

License: GPL-2+

This is a dual-licensed GPL/Artistic work such as Perl:

License: GPL-1+ | Artistic

This is for a file that has both GPL and classic BSD code in it:

License: GPL-any, BSD-3

And this is for a file that has Perl code and classic BSD code in it:

License: GPL-1+ | Artistic, BSD-3

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 GPL-2+ with the OpenSSL exception. It is thus expressed as "GPL-2+ | other":

License: GPL-2+ | other
 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."



A possible copyright file for xsol:

Upstream-Name: X Solitaire

Files: *
Copyright: Brian Masney <>
License: GPL-2+
 On Debian systems the full text of the GNU General Public License can be found
 in the `/usr/share/common-licenses/GPL' file.

Files: debian/*
Copyright: Copyright 1998, Josip Rodin <>
License: other


A possible copyright file for planet-venus:

Upstream-Name: Planet Venus
Upstream-Maintainer: Sam Ruby <>

Files: *
Copyright: Copyright 2008, Sam Ruby <>
 Copyright 2007, Scott James Remnant <>
 Copyright 2007, Jeff Waugh <>
 Copyright 2007, Eric van der Vlist <>
License: PSF-2

Files: debian/*
Copyright: Copyright 2008, Noah Slater <>
License: GAP
 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 preserved.

Files: debian/patches/theme-diveintomark.patch
Copyright: Copyright 2008, Mark Pilgrim <>
License: MIT

Files: planet/vendor/compat_logging/*
Copyright: Copyright 2002, Vinay Sajip <>
License: MIT

Files: planet/vendor/
Copyright: Copyright 2007, Mark Pilgrim <>
License: MIT

Files: planet/vendor/httplib2/*
Copyright: Copyright 2006, Joe Gregorio <>
License: MIT-any
 Unspecified MIT style licence.

Files: planet/vendor/
Copyright: Copyright 2004, Tomas Styblo <>
License: GPL-any
 On Debian systems the full text of the GNU General Public License can be found
 in the `/usr/share/common-licenses/GPL' file.

Files: planet/vendor/
Copyright: Copyright 2001, Timothy O'Malley <>
License: MIT


Recent Changes