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.
?TableOfContents
Rationale
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.
Proposal
I suggest to add simple RFC2822 multiline fields to debian/copyright containing machine-interpretable values for copyright holders, known licenses, upstream URLs etc. -- SamHocevar
These fields should be clear enough to obviate duplicating their information somewhere else in the file.
Compatiblity and human-readability
It is important to have debian/copyright remain human-readable, and thus not to overengineer this proposal by adding too many fields. However I believe that as it is, it remains clear enough to a human (as suggested by the examples at the end).
It should be encoded UTF-8.
For clarity we should recommend separating machine-interpretable parts with empty lines. This is not mandatory.
Also, it is important to allow any form of free text in the file, be it before or after the machine-interpretable part. I therefore suggest that fields can be interspread anywhere in the file. Lines that do not start with a known field name or that do not start with a space and follow a valid line should be ignored by an interpreter. -- SamHocevar
Its probably a good idea to keep a human-readable (traditional) part in the copyright file. Because while the proposed format is quiet easily readable to people, who are actually technically experienced, it might not be so easily readable for not so technically experienced people. And these people should not be barred from understanding the copyright situation for a given package. I know tht this is extra work, but its a good practice IMHO and probably can be dropped, once there exist interpreters for the copyright file. -- PatrickSchoenfeld
I think it is important to keep the files strictly RFC2822 format and I think that including the human-readable licence text certainly seems to be readble with only "." seperating the paragraphs. If we are going to make this machine parsable we should go all the way. If interpreters are needed, they can and will be built. - ?NoahSlater
I also agree that all should be machine parsable. See the Notice section. -- ?MathieuParent
Implementation
I have proposed some lintian checks. You can discuss implementation details in [http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=478930 bug 478930] -- ?MathieuParent
Sections
Header section (once)
Why have Format-Specification and Upstream-Author had the "only once" requirement removed? Multiple values can be placed on new lines within the same field. -- ?NoahSlater
The header should be rfc2822 compliant.
- format specification
- mandatory
Suggested name: Format-Specification
Suggested format: url of the specification (like http://wiki.debian.org/Proposals/CopyrightFormat)
I propose to include the revision number as long as there is no official versioning, like http://wiki.debian.org/Proposals/CopyrightFormat?action=recall&rev=102 - CharlesPlessy
Hopefully, once this proposal makes policy it would no longer be hosted on the wiki. -- ?NoahSlater
- upstream author(s)
- optional
Suggested name: Upstream-Author
- Suggested format: see the Copyright field (multiple lines)
- current upstream maintainer
- optional
Suggested name: Upstream-Maintainer
- Suggested format: see the Copyright field
I do not see the need for the two fields Upstream-Author and Upstream-Maintainer together. We should choose one and use that for whoever the upstream contact/author is. Are there prior examples of both of these being used/needed? -- ?NoahSlater
My intention was to include some kind of authorship credit in the copyright file, since copyright holders are not always authors and vice versa. On second thought, it would be perhaps better to have an optional Author: field in the Files-section, instead of multiple Upstream-Authors in the header section. If the purpose of this field in the header is to give a single contact address to upstream, then I would prefer the field name to be Upstream-Maintainer. -- ?TeemuIkonen
- packager(s)
- mandatory
Suggested name: Packaged-By
- Suggested format: see the Copyright field
- original date of packaging
- only once
- optional
Suggested name: Packaged-Date
- Suggested format: RFC2822
I don't think there's any reason to use the obsolete RFC 2822 time format in new standards. I changed date format to ISO 8601 -- ?TeemuIkonen
I have reverted your edits. I think this is a big change and needs to be discussed first. I don't see why you call RFC2822 an obsolete format, it is still used by many different technologies. Debain uses RFC2822 in many other places and I think it's very important to maintain consistency between things. Having one date format for debian/copyright but another date format for debian/changelog (for example) is a Bad Thing. If any change to the standard date format was made, it should be made across the board and preferably use something like W3CDTF. -- ?NoahSlater
Hi Teemu, what is the command for genearting ISO 8601 dates? -- CharlesPlessy
- where the original source was downloaded from
- only once
- mandatory
Suggested name: Original-Source-Location
- Suggested format: URI
- where the original source was downloaded from
- only once
- optional
Suggested name: Original-Source-Command
- Suggested format: shell command
For what this should be useful and why do you think it should be mandatory? Enhance uscan to support the get-orig-source target and make the target mandatory, if a simple uscan is not enough. Then you can always put the command uscan into this field. I'm therefor in favour of removing this field from the proposal and instead fix uscan. -- DanielLeidert
I have changed the field to optional, this was a mistake on my part. As long as the get-orig-source target is optional this field should remain optional. -- ?NoahSlater
- the size of the original source tarball
- only once
- optional
Suggested name: Original-Source-Size
- Suggested format: size in bytes
- the MD5 hash of the original source tarball
- only once
- optional
Suggested name: Original-Source-MD5
- Suggested format: hexadecimal MD5 hash
- package dependencies for building the original source tarball
- only once
- optional
Suggested name: Original-Source-Depends
- Suggested format: see control Depends/Build-Depends fields
I don't like putting the [above three] fields in debian/copyright, neither mandatory nor optional. IMO, this kind of data belongs in debian/control instead. -- baszoetekouw
The above three fields are only intended for a small minority of packages. The first two fields are useful when the upstream tarball is not versioned (such as http://example.org/foobar.tgz) because in these cases it is handy to have some metadata in the copyright file to verify that the upstream source has not changed. The third field is only useful when the get-orig-source target of debian/rules requires specific packages to prepare the upstream tarball, such as checking the source out of a Subversion repository and building the dist-check target of an Autotools package. In both use cases this information should be kept well away from debian/control.
Even if upstream provides this information, how do you want to make sure, they are complete? If they arenot, why this should be useful? In which format do you want to mention package names? Debian package names? -- DanielLeidert
I'm not quite sure what you're asking here. In some cases the get-orig-source command itself may require that additional packages are installed, such as Automake or Autoconf for building a distribution tarball from a direct source checkout. In this case it would be a human that is satisfying the dependencies by hand. The above proposal mentions that this should be formatted as the control Depends/Build-Depends fields, including full Debian package names. -- ?NoahSlater
Ah, ok. My understanding of this field wasn't correct then. But I think, README.source and/or control is the better place for this. If we put all this information into debian/copyright, README.source IMHO becomes obsolete. -- DanielLeidert
- baszoetekouw, I think you're mistaken about how this is meant to be used. These fields are not for use when building the package, else I would agree with you. They are used by humans when manually preparing the package BEFORE building. This information is already used by debian/copyright files but in a non-machine format. See the policy/status-quo on specifying the get-orig-source rules, the packages dependancies for completing the get-orig-source rule is a natural extention.
Example:
Format-Specification: http://wiki.debian.org/Proposals/CopyrightFormat Upstream-Author: John Soft <some.email@example.com> Packaged-By: Robert Package <some.email@example.org> Packaged-Date: Sun, 10 Jun 2007 16:13:07 +0000 Original-Source-Location: http://sourceforge.net/projects/software/ Original-Source-Command: ./debian/rules get-orig-source Original-Source-Size: 389120 Original-Source-MD5: 934d927eecfdb5a1a4a17798de3ed60f Original-Source-Depends: autoconf, automake, libtool, subversion-tools
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:
- List of files sharing copyright holders and licensing terms
Repeatable field, like the Package field in debian/control
Suggested name: Files
- Suggested format: list of files or patterns, see "File patterns" below
Also useful to store information about the packaging, use Files: debian/*
Copyright holders for the files listed in the previous Files field
Suggested name: Copyright
- Suggested format: free content, one line per copyright holder
- A valid copyright statement declares all of: "Copyright", the year(s) the work was created, the full name of the copyright holder; email address is also recommended
- Note that "(c)" is legally null; the only recognised abbreviations for "Copyright" in a copyright declaration are "Copr." or "©"
Licensing terms for the files listed in the previous Files field
Suggested name: License
- Suggested format:
- First line: see "License keywords" below
- Remaining lines (in the case of a multiline field): additional information, when one or several licenses are not amongst the known ones
If the Licence is also used for other Files sections the use of a simple keyword (or set of keywords) is permited as long as this is expanded by one or more independant Licence fields later in the file. (See below)
- This does not apply to the 'other' license
License section (repeatable)
Where multiple sets of files use the same licence you can avoid repetition by using multiple Licence fields with keywords only and use a separate set of Licence fields to expand the licence description.
Files: src/js/editline/* Copright: Copyright 1993, Simmule Turner Copyright 1993, Rich Salz License: MPL-1.1 | GPL-2 | LGPL-2.1 Files: src/js/fdlibm/* Copright: Copyright 1993, Sun Microsystems Corporation License: MPL-1.1 | GPL-2 | LGPL-2.1 Licence: MPL-1.1 [LICENCE TEXT] Licence: GPL-2 [LICENCE TEXT] Licence: LGPL-2.1 [LICENCE TEXT]
Hi Mathieu, and Noah, and thanks for your work on this page. I have a question about multiple license fields: often the GPL statements will use the actual name of the program used instead of "This package". Do you think that it is possible to handle this correctly with the proposed multiple license fields, and if yes, how ? -- CharlesPlessy
Note that the GPL licence does not permit modification so you find a modified GPL licence it is not correct to call it GPL. What I think you may be refering to is customised boilerplate text such as "Copyright 1999, Jim Bob. Available under the GPL" which is no problem as you are not expected to put this kind of information in the copyright file. -- ?UnknownAuthor
Fields detail
Files: field
Field format
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
Pattern syntax
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 Makefile.am files in the tree and all Python scripts:
Files: */Makefile.am, *.py
But this will only match the top-level Makefile.am:
Files: ./Makefile.am
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.
Matches should be exclusive (a file can only match one rule). The final rule that should be considered is the most specific one (the one that matches the fewer files), or if this is ambiguous, the last one in the file.
What is the most specific one ? Can you propose an algorithm? -- ?MathieuParent
- For reasons of simplicity, it might be best to change this to simply taking the last matching rule. -- baszoetekouw
Yes, for each file, take the last match available in the debian/copyright file. -- ?NoahSlater
Thus, in this case of getopt.c, it is the second rule that has to be taken into account:
Files: * Copyright: [the main work’s author] License: [the main work’s license] Files: getopt.* Copyright: © 2000 the NetBSD Foundation, Inc. License: other-BSD [text of the NetBSD license]
License: field
License keywords
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:
keyword |
meaning |
GPL-any |
GNU General Public License, author did not specify version ?BR (probably the same as GPL-1+) |
GPL-1 |
GNU General Public License, version 1 only |
GPL-1+ |
GNU General Public License, version 1 or later ?BR (probably the same as GPL-any) |
GPL-2 |
GNU General Public License, version 2 only |
GPL-2+ |
GNU General Public License, version 2 or later |
GPL-3 |
GNU General Public License, version 3 only |
GPL-3+ |
GNU General Public License, version 3 or later |
LGPL-any |
GNU Library/Lesser General Public License, author did not specify version |
LGPL-2 |
GNU Library General Public License, version 2 only |
LGPL-2+ |
GNU Library General Public License, version 2 or later |
LGPL-2.1 |
GNU Lesser General Public License, version 2.1 only |
LGPL-2.1+ |
GNU Lesser General Public License, version 2.1 or later |
LGPL-3 |
GNU Lesser General Public License, version 3 only |
LGPL-3+ |
GNU Lesser General Public License, version 3 or later |
PSF |
Python License, author did not specify version |
PSF-2 |
Python License, version 2 only |
GFDL-any |
GNU Free Documentation License, author did not specify version ?BR (maybe this needs mention of the fact that we accept no invariant sections, etc.) |
GFDL-1.1 |
GNU Free Documentation License, version 1.1 only ?BR (same note as above) |
GFDL-1.1+ |
GNU Free Documentation License, version 1.1 or newer ?BR (same note as above) |
GFDL-1.2 |
GNU Free Documentation License, version 1.2 only ?BR (same note as above) |
GFDL-1.2+ |
GNU Free Documentation License, version 1.2 or newer ?BR (same note as above) |
GAP |
GNU All-Permissive license, http://www.gnu.org/prep/maintain/maintain.html#License-Notices-for-Other-Files |
BSD-2 |
Two-clause BSD license |
BSD-3 |
Three-clause BSD license, with no-endorsement clause, as seen in /usr/share/common-licenses/BSD?BR |
BSD-4 |
Four-clause BSD license, with no-endorsement clause and advertising clause; GPL-incompatible (need exact text) |
Apache-1.0 |
Apache license, version 1.0; not GPL-compatible |
Apache-1.1 |
Apache license, version 1.1; not GPL-compatible |
Apache-2.0 |
Apache license, version 2.0; GPL-3-compatible, not GPL-2-compatible |
MPL-1.1 |
Mozilla Public License, version 1.1 only, http://www.mozilla.org/MPL/MPL-1.1.html |
Artistic |
The original Artistic license, as seen in /usr/share/common-licenses/Artistic |
Artistic-2.0 |
The Artistic license, version 2.0, http://www.perlfoundation.org/artistic_license_2_0 |
LPPL-1.3a |
The LaTeX Project Public License, version 1.3a, http://www.latex-project.org/lppl/lppl-1-3a.txt; GPL-incompatible?BRNote that works under any version of the LPPL often have additional restrictions attached; check carefully. |
ZPL |
Zope Public License, author did not specify version |
ZPL-2.1 |
Zope Public License, version 2.1 only |
EPL-1.1 |
Erlang Public License, version 1.1 only |
EFL-2 |
Eiffel Forum License, version 2 only |
CPL |
IBM Common Public License |
CC-BY-3 |
Creative Commons Attribution License (Unported), version 3.0 only |
CC-BY-SA-3 |
Creative Commons Attribution-?ShareAlike Licence (Unported), version 3.0 only |
ZLIB |
The zlib/libpng license as in http://www.opensource.org/licenses/zlib-license.php |
Expat |
The terms of the Expat license, http://www.jclark.com/xml/copying.txt ?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 |
W3C-Software |
The W3C Software License, http://www.w3.org/Consortium/Legal/2002/copyright-software-20021231 |
... |
add your favourite license here |
other |
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:
other-BSD |
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") |
MIT |
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. |
MIT-any |
When the work is licenced under an unspecified MIT style licence. |
PD |
In the public domain, not applicable everywhere |
syntax
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."
Examples
Simple example
Here is a very simple example. This is the original copyright file for xsol:
This package was debianized by Josip Rodin <jrodin@jagor.srce.hr> on Sun, 8 Nov 1998 18:00:00 +0100 Original source may be found at: ftp://sunsite.unc.edu/pub/Linux/X11/games/ Upstream author: Brian Masney <masneyb@newwave.net>. Licensed under the terms of GNU GPL v2 (or later). On Debian systems, the complete text of the GNU General Public License can be found in file "/usr/share/common-licenses/GPL".
And this is a possible machine-interpretable format:
Format-Specification: http://wiki.debian.org/Proposals/CopyrightFormat Debianized-By: Josip Rodin <jrodin@jagor.srce.hr> Debianized-Date: Sun, 8 Nov 1998 18:00:00 +0100 Original-Source: ftp://sunsite.unc.edu/pub/Linux/X11/games/ Files: debian/* Copyright: Copyright 1998, Josip Rodin <jrodin@jagor.srce.hr> License: other [LICENCE TEXT] Files: * Copyright: Brian Masney <masneyb@newwave.net> License: GPL-2+ This package 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. . On Debian systems, the complete text of the GNU General Public License can be found in file "/usr/share/common-licenses/GPL".
Complex example
Can we please get another example? As funny as the WTFPL is, I think there are better choices for this section. -- ?NoahSlater
This is the original copyright file for monsterz:
This package was downloaded from http://sam.zoy.org/monsterz/ monsterz.c, monsterz.py: Copyright (c) 2004-2005 Sam Hocevar <sam@zoy.org> | DO WHAT THE FUCK YOU WANT TO PUBLIC LICENSE | Version 2, December 2004 | | Copyright (C) 2004 Sam Hocevar | 22 rue de Plaisance, 75014 Paris, France | Everyone is permitted to copy and distribute verbatim or modified | copies of this license document, and changing it is allowed as long | as the name is changed. | | DO WHAT THE FUCK YOU WANT TO PUBLIC LICENSE | TERMS AND CONDITIONS FOR COPYING, DISTRIBUTION AND MODIFICATION | | 0. You just DO WHAT THE FUCK YOU WANT TO. music.s3m: Copyright (c) 1998 MenTaLguY <http://moonbase.rydia.net/> | music.s3m was put in the public domain by MenTaLguY. applause.wav, pop.wav: Copyright (c) 2002, 2005 Sun Microsystems, Inc. | applause.wav was taken from OpenOffice.org's applause.wav and pop.wav was | taken from OpenOffice.org's laser.wav. This product is made available | subject to the terms of GNU Lesser General Public License Version 2.1. click.wav: Copyright (c) Michael Speck <kulkanie@gmx.net> | click.wav was taken from Barrage's click.wav. 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. boing.wav, ding.wav, duh.wav, grunt.wav, laugh.wv, whip.wav: Copyright (C) 2003 by David White <davidnwhite@optusnet.com.au> and the Battle for Wesnoth project Copyright (C) 2006 Sam Hocevar <sam@zoy.org> | boing.wav was taken from Wesnoth's spear.wav and reworked by Sam | Hocevar, ding.wav was taken from receive.wav, duh.wav was taken from | female-strong-hit.wav, grunt.wav was taken from dwarf-die.wav, laugh.wav | was taken from zombie-hit.wav, whip.wav was taken from dagger-swish.wav. | This program is free software; you can redistribute it and/or modify | it under the terms of the GNU General Public License. This program is | distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY. warning.wav: Copyright (c) Mike Kershaw <dragorn@kismetwireless.net> | warning.wav was taken from Kismet's alert.wav. It is distributed under | the terms of the GNU General Public License. On Debian GNU/Linux systems, the complete text of the GNU General Public License can be found in `/usr/share/common-licenses/GPL' and the complete text of the GNU Lesser General Public License can be found in `/usr/share/common-licenses/LGPL'.
Proposed format:
Format-Specification: http://wiki.debian.org/Proposals/CopyrightFormat Original-Source: http://sam.zoy.org/monsterz/ Files: debian/* Copyright: © 2004-2007 Sam Hocevar <sam@zoy.org> License: GPL-2+ The Debian packaging information is under the GPL, version 2 or later Files: *.c, *.py Copyright: © 2004-2005 Sam Hocevar <sam@zoy.org> License: other-BSD DO WHAT THE FUCK YOU WANT TO PUBLIC LICENSE Version 2, December 2004 . Copyright (C) 2004 Sam Hocevar 22 rue de Plaisance, 75014 Paris, France Everyone is permitted to copy and distribute verbatim or modified copies of this license document, and changing it is allowed as long as the name is changed. . DO WHAT THE FUCK YOU WANT TO PUBLIC LICENSE TERMS AND CONDITIONS FOR COPYING, DISTRIBUTION AND MODIFICATION . 0. You just DO WHAT THE FUCK YOU WANT TO. Files: music.s3m Copyright: © 1998 MenTaLguY <http://moonbase.rydia.net/> License: PD music.s3m was put in the public domain by MenTaLguY. Files: applause.wav, pop.wav Copyright: © 2002, 2005 Sun Microsystems, Inc. License: LGPL-2.1 applause.wav was taken from OpenOffice.org's applause.wav and pop.wav was taken from OpenOffice.org's laser.wav. This product is made available subject to the terms of GNU Lesser General Public License Version 2.1. Files: click.wav Copyright: © Michael Speck <kulkanie@gmx.net> License: GPL-2+ click.wav was taken from Barrage's click.wav. 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. Files: boing.wav, ding.wav, duh.wav, grunt.wav, laugh.wav, whip.wav Copyright: © 2003 by David White <davidnwhite@optusnet.com.au> and the Battle for Wesnoth project © 2006 Sam Hocevar <sam@zoy.org> License: GPL-any boing.wav was taken from Wesnoth's spear.wav and reworked by Sam Hocevar, ding.wav was taken from receive.wav, duh.wav was taken from female-strong-hit.wav, grunt.wav was taken from dwarf-die.wav, laugh.wav was taken from zombie-hit.wav, whip.wav was taken from dagger-swish.wav. This program is free software; you can redistribute it and/or modify it under the terms of the GNU General Public License. This program is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY. Files: warning.wav Copyright: © Mike Kershaw <dragorn@kismetwireless.net> License: GPL-any warning.wav was taken from Kismet's alert.wav. It is distributed under the terms of the GNU General Public License. On Debian GNU/Linux systems, the complete text of the GNU General Public License can be found in `/usr/share/common-licenses/GPL' and the complete text of the GNU Lesser General Public License can be found in `/usr/share/common-licenses/LGPL'.
This is how it could look like in vim:
attachment:debian-copyright-vim-syntax.png
Recent changes
2008-05-28: Changed Packaged-Date time format to ISO 8601. Corrected examples as well. -- ?TeemuIkonen
2008-05-26: Added Upstream-Maintainer field, which should point to the current upstream contact (some packages have retired authors which should be named in the Upstream-Author field, but are not active anymore) -- ?TeemuIkonen
2008-05-19: Implement ?NoahSlater's suggested change, "Can we take this oportunity to use the word "packaged" instead of "debianized"?
2008-05-02: Removed the section on Notice because I don't see a use case for this. Any licences in /usr/share/common-licenses should be expressed using a regular Licence field with the standard Debian notice text being used as the long description. Unknown or uncommon licences can be expressed using the "other" licence type with the long description serving as normal.
2008-05-01: Once more: reorganisation (by sections, by fields) -- ?MathieuParent
2008-04-29: Added TOC, recent changes at bottom, separing sections with empty lines is mandatory to parse "Multiple licence fields" -- ?MathieuParent
2008-04-28: Added clarified multiple Licence field behaviour
2008-04-28: Added back Original-Source-* style header fields as these are required for packages where the upstream source is taken directly from a repository or an unversioned tarball. -- ?NoahSlater
2008-04-28: Simplify, make it rfc2822 compatible, disambiguation (I've changed/removed stuff from other people, please don't be upset !, old is in ["Proposals/CopyrightFormat/Archive"] ) -- ?MathieuParent
- 2008-04-01: Added proposal to use Licence independantly to avoid repetition.
2008-03-30: Added GFDL 1.1 and 1.1+ -- ?GustavoMontesino
2008-03-26: Added CC-BY-SA-3 license. -- ?NoritadaKobayashi
2008-03-19: Proposed X-Non-Free-Autobuild field for non-free packages -- CharlesPlessy
Comment: Today's format is XS-Autobuild: yes as announced [http://lists.debian.org/debian-devel-announce/2006/11/msg00012.html here] -- SteffenMoeller
2008-02-29: Added EFL-2 license. -- ?NoahSlater
- 2008-02-14: Added ZLIB license (the zlib/libpng one). -- Kaeso
2008-01-12: Added section describing proposal for full RFC822 specfication. -- ?MortenKjeldgaard, Discussion on -devel http://lists.debian.org/debian-devel/2007/08/msg00242.html
2007-10-20: Added CC-BY-3 license. -- ?NoahSlater
2007-10-09: Added proposal for all-permisive licenses. -- ?NoahSlater
2007-10-09: Added the MPL-1.1 and EPL-1.1 licenses. -- ?NoahSlater
2007-08-09: replaced "GPLvX" with "GPL-X" to match /usr/share/common-licenses filenames. Replaced "BSD" with "BSD-3". --Sam
2007-08-09: reverted the parentheses proposal for /usr/share/common-licenses, it made lines too long. --Sam
- 2007-08-06: add Artistic-2.0. -- Josh Triplett
- 2007-08-06: added MIT licenses to the "Stuff that we might want" section; needs disambiguation. -- Josh Triplett
- 2007-08-06: clarified "Artistic" with a specific reference to the original license as found in common-licenses. -- Josh Triplett
- 2007-08-06: added several more licenses; suggested changing BSD to BSD3; refer to the Library or Lesser GPL as appropriate to the version. -- Josh Triplett
- 2007-08-05: suggested a way to get rid of the "On Debian GNU/Linux systems, the text of the GPL blahblah" text.
2007-08-05: changed the Files behaviour as suggested by several people on debian-devel.
Aug 2007-08-05: removed Packaging-Copyright and Packaging-License in favour of the Files: debian/* technique. --Sam
2007-08-05: dropped the Source field. It was not really needed for any machine-interpretable work, there's the watch file for that. --Sam