Proposal: establish a discussion forum separate from the specification page

Comment: I have been considering that we may need to alter how we develop this standard. Editing on a wiki, with inline comments is pretty frustrating. It becomes troublesome when people make large changes without much discussion beforehand. What do people think to moving or locking this place so that it cannot be arbitrarily edited and starting a mailing list for discussion, so that we can reach consensus about changes before making them. I would like to have an threadable and searchable discussion archive for this. -- ?NoahSlater

Comment: I think that the proposal got developed and popularised enough that a DEP could be proposed (but after Lenny release, please!). The discussion of the DEP will be more efficient to resolve out the remaining issues that are debated now using the wiki as a medium. Also, the more I think about, to more I have the feeling that we should aim at making this format not only popular in Debian, but also upstram, beacause this would save us lots and lots of work… -- CharlesPlessy

Comment: This sounds like a fine idea. I think that the wiki is starting to hinder, rather than promote, the development of this standard. Let's wait for Lenny and move forward from there. -- ?NoahSlater

Similar work in other projects

Comment: apparently, 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

Information about re-packaged original source archive

Comment: The Developers Reference Section 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

Verbatim inclusion of explicit grant of license

Comment: There is currently a 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

Comment: 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

The FTPMasters simply do not care about this format, or the old one. We only do care about everything being listed correctly. And no matter which format you use, you have to do it. And none of these formats will ever help us in checking this, no matter how developed they are - or not. Thats why you never heard anything from us. And what I wrote back then is still true. [Ganneff]

Proposal: Full RFC822 specification

I propose that debian/copyright is fully in RFC822 format. I have added the following construction to a few of my packages:

X-Format-Specification: http://wiki.debian.org/Proposals/CopyrightFormat
X-Debianized-By: Morten Kjeldgaard <mok@bioxray.au.dk>
X-Debianized-Date: Sun, 10 Jun 2007 16:13:07 +0000.
X-Source-Downloaded-From: http://sourceforge.net/projects/btk/
X-Upstream-Author: Tim Robertson <kid50@users.sourceforge.net>,
    Chris Saunders <ctsa@users.sourceforge.net>

If formally adopted in the standard, the "X-" in front of each label can be dropped. One of the arguments for doing it this way, is that it is important to be able to see the author (copyright owner) of the original debianization.

I find that given a copyright template with the above lines, plus a template set of [Files:, Copyright:, License:] it becomes quite fast and easy to write the copyright file.

One might object that this makes debian/copyright less "humanly" readable. OTOH, the standardized formatting makes it feasible to make a nice "copyright browser" with beautifully formatting of the file.

Please note that the RFC822 examples above are not correctly indented in the Wiki.

-- ?MortenKjeldgaard

I propose an additional field, X-Non-Free-Autobuild, to fullfill the requirements for the use of the non-free autobuilders from release.net team. Here is for example what I use in non-free/clustalw:

X-Non-Free-Autobuild: yes
  The licence does not forbid Debian from using autobuilders to create binary
  packages.

-- CharlesPlessy

Where the upstream tarball is not versioned or no watch file is available you can use the following:

X-Source-Downloaded-From: http://www.intertwingly.net/code/venus/
X-Source-Get-Original: ./debian/rules get-orig-source
X-Source-Size: 389120
X-Source-MD5: 934d927eecfdb5a1a4a17798de3ed60f

Also, for any dependances the get-orig-source target you should use:

X-Source-Original-Depends: autoconf, automake, libtool, subversion-tools

The Copyright field should be separated by newlines and not commas as this would be troublesome to parse when the copyright details also included commas.

Good:

Files: src/js/editline/*
Copright: Copyright 1993, Simmule Turner
 Copyright 1993, Rich Salz

Bad:

Files: src/js/editline/*
Copright: Copyright 1993, Simmule Turner, Copyright 1993, Rich Salz

The Licence field can be used in isolation to supplement the main File blocks.

This provides two benefits:

An example is included below:

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]

-- ?NoahSlater

Proposal: License aliases

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.

Files: *
License: Perl
License-Alias: Perl
Licenses: GPL-2+ | Artistic-2.0
License: GPL-2+
 [LICENSE TEXT]
License: Artistic-2.0
 [LICENSE TEXT]

Comment: This seems overly complex to me, lets keep it simple. Using "GPL-2+ | Artistic-2.0" 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

Comment: It doesn't have anything to do with saving characters, but to declare, that it's infact, per example, the "perl" license. This could be extended to include the exact copyright note that the upstream had placed while delegating it to two licenses.

I did though of other names, "Multi-License", "Merged-License" etc... but though "License-Alias" was sufficient. -- ?AzaToth

Comment: 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

Ugliness

I find the file format is very ugly to look at. [… different example file, non-conformant with the rest of this document] — ChristophBerg

Christoph, your suggestion isn't very clear. As far as I can tell, you want the fields in the header to change completely? If so, the best thing to do is to discuss the specific changes you want to see, with your reasoning for each change, in the appropriate places for each change. — BenFinney

Suppose a package foo was released in 1985 containing foo.c, and later in 2002 containing both foo.c and a new file, bar.c. Both files were created by Fred Nurk. By my understanding the required declarations are respectively "Copyright 1985, Fred Nurk" for foo.c and "Copyright 2002, Fred Nurk" for bar.c. Am I allowed to have a single "Files: foo.c, bar.c" for the 2002 release's debian/copyright file? If so, what is its Copyright field supposed to contain? – ?TrentBuck

Answer: Note that the Copyright field is repeatable in a stanza. For mutliple copyright statements applicable to a group of files, quote verbatim each copyright statement in a separate Copyright field in that group's stanza. In your example (assuming the copyright holder grants recipients the terms of the WTFPL):

Files: foo.c
Copyright: Copyright 1985, Fred Nurk
Copyright: Copyright 2002, Fred Nurk
License: WTFPL

Files: bar.c
Copyright: Copyright 2002, Fred Nurk
License: WTFPL

License: WTFPL
 <complete text of WTFPL terms>

BenFinney

Suppose a package has three files. Each has a slightly different license (or rather, non-license) declaration: "this file is in the public domain", "This file is in the public domain." and "This file is in the Public Domain.". Am I allowed to have a single Files stanza for all three files? If so, what should the License field's body look like? – ?TrentBuck

Answer: I would expect the capitalisation to be irrelevant. As for how to phrase a public domain declaration, you'd be best researching the debian-legal archives on the likely legal impracticability of effectively executing an explicit PD grant. —BenFinney

Suppose a source file lacks a license declaration, but is probably trivial (for example, a four-line example config file). Do I (the DD) have the right to decide that this file is trivial? If so, what should I put for that file in debian/copyright? If not, must I demand that upstream adds a license declaration to that file before I can upload the package to Debian? –?TrentBuck

Answer: Questions of what you should do by law or by Debian policy are best discussed on the appropriate lists. As for what to put in the debian/copyright file for a work not subject to copyright, that sounds like a good candidate for “public domain” to me but I'm not clear on that. —BenFinney

Suppose a source file lacks a copyright declaration, or does not mention the year (e.g. just "Written by Fred Nurk"), or only has a CVS-type last-changed-by header (e.g. "$OpenBSD: echo.c,v 1.46 2006/04/02 17:18:58 kjell Exp $"). Am I (the DD) responsible for determining the correct copyright declaration? –?TrentBuck

Answer: That's outside the scope of the discussion of this file format; take it to debian-legal or debian-devel. —BenFinney

Suppose a source file has a copyright declaration that's inaccurate or out of date. Am I (the DD) responsible for ensuring the accuracy of debian/copyright above and beyond upstream's copyright declarations? –?TrentBuck

Answer: That's outside the scope of the discussion of this file format; take it to debian-legal or debian-devel. —BenFinney

While *I* recognize that attempting to put a work into the public domain is a dicey move at best, the upstream maintainers do not. Must I (the DD) wait until upstream changes their mind (probably never) before uploading the packages? –?TrentBuck

Answer: That's outside the scope of the discussion of this file format; take it to debian-legal or debian-devel. —BenFinney

Requirements to present license text to the user for inspection

Question: I am not quite sure this is the right place... Some licenses must be presented to the *user* that install the system (like sun-java, AFAIK), and forbid preseeding. Some other licenses simply must be presented(like intel ipw2200 license). Some other licenses should be presented and allow special case for automated installation. A filed like LicenseAcceptation could then be used in preinst/postinst script. FranklinPiat

Information not covered by specified fields

Question: The current version now requires that the entire file be in RFC 2822 format, which leaves no place for additional commentary that doesn't fit into the existing fields. I have some packages that use the older version of this format that allowed free-form text with such text to explain issues like PDF files for which no other source still exists. Where do I put those comments now? Can we perhaps add a new field to the header section for such free-form commentary about issues relevant to the licensing but not fitting into a license section or one of the existing header fields? -- RussAllbery

Answer: It sounds like this information should be put in the README.source file. -- ?NoahSlater

Answer2: It was suggested before to use arbitrary fields prefixed by X-. I routinely use X-Debian-Comment for instance. -- CharlesPlessy

Putting such information in README.source doesn't make any sense to me. It has nothing to do with the purpose of that file; it's information about the source and licensing of the upstream software, which is the purpose of debian/copyright, not information about how to work with the source package.

Another example of information that is supposed to go into debian/copyright for which this proposal doesn't currently leave room is information about how the upstream source has been repacked for DFSG purposes. After several discussions on debian-devel and debian-mentors, my impression is that consensus was reached that such information should be in debian/copyright. See devref 6.7.8.2. I see that's already noted in a comment above, though. -- RussAllbery