This is a proposal to make debian/copyright machine-interpretable. This file is one of the most important files in Debian packaging, yet its existing 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 needs to care not only 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 one prominent occurrence of this limitation.
There are earlier 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.
Note: apparently, [http://fedoraproject.org/wiki/Licensing Fedora started a very similar project]: on of my upstreams (the Samba Team) pointed me to the very few differences in the way to name licenses, particularly the short-form and the method to combine licenses. —ChristianPerrier
Compatibility and Human-Readability
The file must be encoded as UTF-8 and strictly formatted as a superset of RFC2822 including significant newlines. Free-form text is not allowed.
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-readability this proposal avoids any complex field names or syntax rules.
Lintian
You can discuss implementation details in [http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=478930 bug 478930] -- ?MathieuParent
Implementation
Sections
Header Section (Once)
The header should be rfc2822 compliant, consisting of multiple fields.
- format specification
- only once
- mandatory
Suggested name: Format-Specification
- Suggested format: URI of the format specification, such as:
http://wiki.debian.org/Proposals/CopyrightFormat?action=recall&rev=REVISION
- Note that the unwieldy length of the URL should be solved in future by hosting the specification at a shorter URL (including specification version).
Currently (2008-07-25) this field can trigger a lintian warning about excessive line length; an exception for the Format-Specification line is pending in [http://bugs.debian.org/491302 bug 491302].
- name of the software as spelled upstream
- only once
- optional
Suggested name: Upstream-Name
- Suggested format: single line (in most cases a single word)
- preferred way(s) to reach current upstream maintainer
- only once
- optional
Suggested name: Upstream-Maintainer
- Suggested format: line(s) of RFC2822 address or URIs or free text, one line per preferred way
- where the upstream sources (if any) were downloaded from
- only once
- optional
Suggested name: Upstream-Source
- Suggested format: line(s) of URIs, one line per upstream source
- where the upstream VCS repository can be browsed online
- only once
- optional
Suggested name: Upstream-Vcs-Browser
- Suggested format: line(s) of HTTP URLs, one line per upstream Version Control Repository
- where the upstream VCS repository can be accessed
- only once
- optional
Suggested name: Upstream-Vcs-URI
Suggested format: line(s) of MIME type definitions delimited by type..uri tags per Version Control Repository. Example: {{{Upstream-Vcs-URI: type=git; priority=100; desc="Primary site";
uri=http://git.example.com/project.git; type=svn; priority=50; desc="Svn Mirror"; uri=svn://svn.example.com/project}}}
I am not convinced that Upstream-Vcs-Browser or Upstream-Vcs-URI belong in debian/copyright. Perhaps debian/READEME.source would be a better place for this. In either case, this is way too complex as it stands. What purpose does it serve? Can we just stick with vanila URIs please? -- Noah Slater
It is machine readable data, similar to Upstream-Source. MIME-like tags are easy for machine processing. -- JariAalto
Jari, the question (as I understand it) is not about the *format* of this proposed data, but rather whether it belongs in debian/copyright at all, rather than, say, debian/README.source. I'm in agreement with Noah on this: it doesn't seem debian/copyright is the right place for this. —BenFinney
Correct. I was (perhaps confusingly) picking up on two issues here. The proposal for Upstream-Vcs-URI as it stands is way too complex for any use case I can imagine. Who would care about the "priority=50" value, for example? Being machine readable alone is not justification for it's inclusion in any part of the Debian packaging. The second issue I see is that I think this belongs in debian/README.source. -- ?NoahSlater
Well, the debian/copyright file is shown in the packages.debian.org, whereas the content of debian/README.source is not. In addition I would see the Upstream-Source field being analogous to Upstream-Vcs-URI only differing in scheme of more modern access method. The upstream VCS information and download location is tightly coupled and it would be beneficial to keep them at the same place. The fields were only examples of how the information is extendable if presented using the MIME notation (most likely there only will be need for type and uri). -- JariAalto disclaimer for non-free and contrib packages (see [http://www.debian.org/doc/debian-policy/ch-docs.html#s-copyrightfile Policy 12.5]) Suggested name: Disclaimer The Developers Reference Section [http://www.debian.org/doc/developers-reference/best-pkging-practices.html#bpp-origtargz 6.7.8.2] requires that debian/copyright contain additional information about repackaged .orig.tar.gz files. This might, for example, be a statement to the effect that all precompiled java class files were removed (this is pretty common!). All the Original-Source-* fields have now been removed though. So where does this fit into these machine-readable copyright files? -- StuartPrescott Example:
The declaration of copyright and license for files is done in one or more stanzas, formatted as RFC2822-style fields. Each stanza is separated from others by a blank line. Repeatable field, like the Package field in debian/control Suggested name: Files Good place to add mandatory hints on original package authors: use Files: debian/* Copyright holders for the files listed in the previous Files field Suggested name: History of package maintainers can optionally be reflected as multiple copyright fields for Files: debian/* Licensing terms for the files listed in the previous Files field Suggested name: First line: See Leave this section empty if a standalone License section exists (see the If multiple licenses apply you must not copy any text into the remaining lines. A standalone License section must be used for each license keyword mentioned. There is currently a [http://lists.debian.org/debian-devel-announce/2006/03/msg00023.html rather definite request (requirement?)] that copyright files include not just an assertion that the code is under a particular licence but to include the text that states that this is the case (e.g. the standard GPL statement used by many "This program is free software ... You should have received ..."). It appears that this is inconsistent with the the currently proposed format. Are the ftp-masters happy with the format as described here and what amounts to the removal of this statement from the copyright file? Or is it envisaged that the text after the "License:" include this statement? If this is the case, then some clarification is required and the examples should do this. -- StuartPrescott That email is over two years old now. I can only assume, given the large number of people and packages using this copyright format as it stands, that the FTP Masters are happy with it to date. -- ?NoahSlater Example:
Where a set of files are dual (tri, etc) licensed you must use a single line Where multiple sets of files use the same license you can avoid repetition by using a single line
If a common type of license is a combination of multiple licenses (like the perl license), an alias can be made, so that it can be clear that it's the particular combination of licenses and not just any combination. This seems overly complex to me, lets keep it simple. Using "GPL-1+ | Artistic" for Perl licensing is fine and should cause no confusion. Adding an extra field to save 13 characters on the odd occasion that the Perl style licensing is chosen is a bad decision. -- ?NoahSlater I did though of other names, "Multi-License", "Merged-License" etc... but though "License-Alias" was sufficient. -- ?AzaToth I disagree, this isn't the "Perl license" - it's the combination of licenses that Perl uses. Just like the Mozilla tri-licensed MPL|GPL|LGPL stuff, I don't see any reason why this needs to be given a distinct name. -- ?NoahSlater
The value of the File names containing spaces or commas should be put within double quotes. The backslash character is an escaping character, be it inside or outside double quotes:
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: This will match all Makefile.am files in the tree and all Python scripts: But this will only match the top-level 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.
It is quite common for a work to have files with copyright held by different parties and received under different licenses. To allow this, However it makes for easier reading if the copyright file lists the "main" license first: the one matching the "top level" of the work, with others listed as exceptions. To allow this, the following precedence rule applies for matching files: As a result, it is recommended for clarity that the stanzas appear in order from most general (e.g. Files: *) first, through to most specific. In the following example, the file getopt.c matches both Files: * and Files: getopt.*; only the last match counts, so the file getopt.c has the license declaration License: other-BSD. It is very common for the Debian packaging work to have a different copyright holder and/or license from the upstream work. In these cases, it is important that the debian/* pattern is placed after any other conflicting patterns.
The "License" field, to be machine-parseable, should not contain arbitrary values. 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) The convention for license abbreviations seems to be settling on XYZ for a license with only one version, and XYZ-n for *sequential version Perhaps the abbreviation should deliberately show the number of clauses in a way that doesn't indicate a version number: BSD-3C. But that still sounds vaguely like a version number; it still suggests sequence in the different versions that doesn't actually match the true chronology; it also fails to indicate *which* clauses are included. In the absence of a clear succession of differently-numbered consecutive versions of a license text, my proposal is: we could come up with abbreviations similar to those used for indicating active clauses in the Creative Commons licenses: BSD-BY-LC for the forms requiring only the inclusion of copyright notice and conditions; BSD-BY-LC-NE for the same as BSD-BY-LC plus “no endorsement without permission”; BSD-BY-LC-NE-AD for the same as BSD-BY-LC-NE plus “advertising required”; This way, no false impression of chronological sequence is implied, and the abbreviation provides a mnemonic for what the terms of the license actually are, not just the number of clauses in them. -- BenFinney 2008-10-15 What about just using BSD2, BSD3 and BSD4? -- ?NoahSlater 2008-10-15 Those labels still strongly, and falsely, imply a version number. I would prefer to choose labels that avoid that false implication. —BenFinney 2008-10-16 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 License (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 ISC The Internet Software Consortium's “ISC license”, http://opensource.org/licenses/isc-license.txt W3C-Software The W3C Software License, http://www.w3.org/Consortium/Legal/2002/copyright-software-20021231 CeCILL-1 CEA-CNRS-INRIA-Logiciel Libre, version 1, http://www.cecill.info/licences/Licence_CeCILL_V1.1-US.html CeCILL-2 CEA-CNRS-INRIA-Logiciel Libre, version 2, http://www.cecill.info/licences/Licence_CeCILL_V2-en.html CeCILL-B CEA-CNRS-INRIA-Logiciel Libre B, http://www.cecill.info/licences/Licence_CeCILL-B_V1-en.html CeCILL-C CEA-CNRS-INRIA-Logiciel Libre C, http://www.cecill.info/licences/Licence_CeCILL-C_V1-en.html WTFPL-2 Do What The Fuck You Want To Public License, version 2, http://sam.zoy.org/wtfpl/COPYING ... 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 licensed under an unspecified MIT style license. PD In the public domain, not applicable everywhere
License names are case-insensitive. The value of the field should follow the syntax of 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: This is a dual-licensed GPL/Artistic work such as Perl: This is for a file that has both GPL and classic BSD code in it: And this is for a file that has Perl code and classic BSD code in it: 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": The syntax of this example is not consistent with the syntax description above. The use of GPL-2+ | other is only permissible in a Files section and not in a stand-alone License section. The inclusion of free-form text in the remaining lines of the Licence field of a Files section is not permitted if more than one license keyword is being used. As currently written in this proposal, this needs to be: However, this description is still not what the author meant. If the field read License: GPL-2 | Artistic then the end-user has the choice of choosing to accept either the GPL-2 or Artistic licenses, but this is not the case and this "other" is not really a separate license as it is instead an exception that is added to notice putting the code under the GPL in the first place. There is no choice between "GPL-2+" and "other" as indicated by the use of the | between the license keywords. The problem stems from conflating the statement of what licenses the code is under with the licenses themselves. You are right in that license can be reduced to "GPL-2" | "GPL-2 with exception" because the exception is separable for derived works. But expressing "other" as being purely the exception is wrong as it is not a self-contained licence. The way the example is written above illustrates this... the field starts with the words "In addition" and the reader is left wondering "in addition to what?". The human-readable aspect of the copyright file is lost if such ambiguities are left in it and the machine-parsable aspect is also lost if some other licenses are really a self-contained license while others are actually an addition to another section elsewhere in the document. However, this may be the way of solving these problems: can it be expressed as GPL-2+ | GPL-2+ with exceptions where the License stanza for "GPL-2+ with exceptions" states that it is "GPL-2 In addition, as a special exception..."? It would presumably be desirable to make "GPL-2+ with exceptions" into something that doesn't contain whitespace to be consistent with the other keywords though -- Stuart I considered GPL-2+, exception, but I think it's important to distinguish between the exception being a separate license and it modifying the previously listed licence hence "+" seems better than "," which already has another meaning in this field. Perhaps resurrecting the License-Terms field would be better than creating an Exception field for this. -- Stuart I do not like the "+" syntax or the "Exception" field. I think this should be indicated with the "other" keyword exlusively, with an explanation. It is misleading to claim this is still GPL. -- ?NoahSlater To do so would mean that, as JonasSmedegaard noted, we lose the information that GPL+Exception == GPL | GPL+Exception. So while saying "GPL+Exception" == "other" has merits, it would throw away a lot of information from this copyright format, especially since (as noted above) derived works need not follow the exception. Since GPL+Exception are common enough terms for permitting code to be distributed, it would be worth having a syntax that actually allows us to express these terms both accurately and succinctly. Perhaps writing it explicitly as GPL | GPL+Exception rather than just GPL | other is both accurate and self-contained. -- Stuart My only issue is with the use of spaces in the license keywords, how about: GPL/extra, GPL2/extra, GPL2+/extra, etc or similar?
A possible copyright file for xsol:
A possible copyright file for planet-venus:
2008-10-21: Header Section: Add 2008-10-15: Proposal for abbreviations that indicate *which* BSD-style license is referenced. —BenFinney 2008-09-27: Re-work some of the provisional language, as this is shaping up more as a specification to be recommended (not there yet, but the document wording should get ready for this). —BenFinney 2008-09-27: Clarify the "match order" explanation and example, using positive rather than negative examples; negative examples proved confusing to multiple readers. —BenFinney 2008-07-25: Show that "©" is valid for copyright statement but use "Copyright" in most examples, as the latter is easier for most people to type. -- ?NoahSlater, BenFinney 2008-07-25: Incorporate suggestion of repeatable Copyright field, as no significant drawbacks have been raised. —BenFinney 2008-07-22: Note line-length problems with long 2008-07-12: I propose a new header field, 2008-07-11: Improved explanation around the 2008-07-11: Removed the mention of 2008-06-14: Moved discussion of broader change to date+time format to ["Proposals/DatetimeFormat"] -- BenFinney 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 2008-05-01: Once more: reorganisation (by sections, by fields) -- ?MathieuParent 2008-04-29: Added TOC, recent changes at bottom, separating sections with empty lines is mandatory to parse "Multiple license fields" -- ?MathieuParent 2008-04-28: Added clarified multiple 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-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-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-permissive 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-05: changed the Aug 2007-08-05: removed 2007-08-05: dropped the Format-Specification:
http://wiki.debian.org/Proposals/CopyrightFormat?action=recall&rev=196
Upstream-Name: SOFTware
Upstream-Maintainer: John Soft <some.email@example.com>
Upstream-Source: http://sourceforge.net/projects/software/
Files Section (Repeatable)
Copyright
License Files: *
Copyright: Copyright 2008, Sam Ruby <rubys@intertwingly.net>
Copyright: © 2007, Scott James Remnant <scott@netsplit.com>
Copyright: Copyright 1998, 2000, 2002-2008 John William Aaron van der Smith
<john.william.van.der.smith@somereally.reallylong.example.com>
License: PSF-2
[LICENSE TEXT]
Standalone License Section
Files: src/js/editline/*
Copyright: Copyright 1993, Simmule Turner
Copyright: Copyright 1993, Rich Salz
License: MPL-1.1 | GPL-2 | 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: Copyright 1993, Simmule Turner
Copyright: Copyright 1993, Rich Salz
License: MPL-1.1
Files: src/js/fdlibm/*
Copyright: Copyright 1993, Sun Microsystems Corporation
License: MPL-1.1
License: MPL-1.1
[LICENSE TEXT]
License Aliases
License-Alias: Perl
Licenses: GPL-1+ | Artistic
It is free software; you can redistribute it and/or modify it under the terms of either:
.
a) the GNU General Public License as published by the Free Software Foundation;
either version 1, or (at your option) any later version, or
.
b) the "Artistic License".
Files: *
License: Perl
License-Alias: Perl
Licenses: GPL-1+ | Artistic
License: GPL-1+
[LICENSE TEXT]
License: Artistic
[LICENSE TEXT]
Fields Detail
Files
Format
Files: foo.c, bar.*, baz.[ch]
Files: "Program Files/*", manual\[english\].txt
Syntax
find . -wholename "$PATTERN"
Files: */Makefile.am, *.py
Files: ./Makefile.am
Match Order
Files: *
Copyright: Copyright 2003-2005, Fred J. Bloggs <fred@example.com>
License: [the main work's license]
[LICENSE TEXT]
Files: getopt.*
Copyright: Copyright 2000, the NetBSD Foundation, Inc.
License: other-BSD
[LICENSE TEXT]
Files: debian/*
Copyright: Copyright [years], [the debian package copyright holder]
License: [the debian package license]
[LICENSE TEXT]
License
Keywords
Syntax
License: GPL-2+
License: GPL-1+ | Artistic
License: GPL-any, BSD-3
License: GPL-1+ | Artistic, BSD-3
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."
Prescott Does it instead need to be written explicitly like this: Files: *
Copyright: Copyright 1999-2007 Jane Smith
License: GPL-2+ | other
License: GPL-2+
On Debian systems, [...]
License: other
In addition, as a special exception, [...]
Files: *
Copyright: Copyright 1999-2007 Jane Smith
License: GPL-2+ + exception
On Debian systems, [...]
Exception:
In addition, as a special exception, [...]
Notes:Examples
Simple
Format-Specification: http://wiki.debian.org/Proposals/CopyrightFormat?action=recall&rev=143
Upstream-Name: X Solitaire
Upstream-Source: ftp://sunsite.unc.edu/pub/Linux/X11/games/
Files: *
Copyright: Copyright 1998, Brian Masney <masneyb@newwave.net>
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 <jrodin@jagor.srce.hr>
License: other
[LICENSE TEXT]
Complex
Format-Specification: http://wiki.debian.org/Proposals/CopyrightFormat?action=recall&rev=178
Upstream-Name: Planet Venus
Upstream-Maintainer: Sam Ruby <rubys@intertwingly.net>
Upstream-Source: http://www.intertwingly.net/code/venus/
Files: *
Copyright: Copyright 2008, Sam Ruby <rubys@intertwingly.net>
Copyright: Copyright 2007, Scott James Remnant <scott@netsplit.com>
Copyright: Copyright 2007, Jeff Waugh <jdub@perkypants.org>
Copyright: Copyright 2007, Eric van der Vlist <vdv@dyomedea.com>
License: PSF-2
[LICENSE TEXT]
Files: debian/*
Copyright: Copyright 2008, Noah Slater <nslater@bytesexual.org>
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 <mark@diveintomark.org>
License: MIT
[LICENSE TEXT]
Files: planet/vendor/compat_logging/*
Copyright: Copyright 2002, Vinay Sajip <vinay_sajip@yahoo.co.uk>
License: MIT
[LICENSE TEXT]
Files: planet/vendor/feedparser.py
Copyright: Copyright 2007, Mark Pilgrim <mark@diveintomark.org>
License: MIT
[LICENSE TEXT]
Files: planet/vendor/httplib2/*
Copyright: Copyright 2006, Joe Gregorio <joe@bitworking.org>
License: MIT-any
Unspecified MIT style license.
Files: planet/vendor/htmltmpl.py
Copyright: Copyright 2004, Tomas Styblo <tripie@cpan.org>
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/timeoutsocket.py
Copyright: Copyright 2001, Timothy O'Malley <timo@alum.mit.edu>
License: MIT
[LICENSE TEXT]
Questions
Recent Changes
Upstream-Vcs-Browser and Upstream-Vcs-URI. —JariAalto