Contents
- Proposal: establish a discussion forum separate from the specification page
- Similar work in other projects
- Information about re-packaged original source archive
- Verbatim inclusion of explicit grant of license
- Proposal: Full RFC822 specification
- Proposal: License aliases
- Ugliness
- Overlapping copyright and license for different parts of a work
- Responsibility of package maintainer with regard to copyright
- Requirements to present license text to the user for inspection
- Information not covered by specified fields
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
It is possible to restrict modification to a group of users... but so far, we could avoid using it (open an RT ticket if needed). The final page should be published on www.d.o, IMHO. -- FranklinPiat
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
Comment: Add such info as X-Upstream-Source-Repackaged or similar until concensus is reached. Tools like Lintian (bug:478930) can then optionally warn about any X-* fields in use for future unification cleanup. -- JonasSmedegaard
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.
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:
- The legalese is kept at the bottom of the file making it easier to read.
- When a package contains many components that are licenced to different people but all use the same licence including the Licence blocks seperatly lets you avoid repetition.
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.
License-Alias: Perl Licenses: GPL-2+ | Artistic-2.0 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".
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
I dislike the proposed format on a more general level. Changing individual fields wouldn't help much. I find the proposed format very ugly. Sorry, I know that this isn't a constructive remark. -- ChristophBerg (Raising a voice for some fraction of the silent majority)
Can you help us help you then? What specifically is ugly? Would you rather not use an rfc822 format file? Can you suggest another format in that case (remembering that the rest of the files in Debian are rfc822 format)? If it's not rfc822 that offends, then is the idea of stanzas? Or the specific field names? The use of camel case vs hyphens for the field names? Please give us something to work on... this proposal is the suggestion "best so far" that manages to mix human readabilty with machine readability. I feel that it seems to do pretty well at both although it's perhaps not as human readable as it could be. At the same time, many of the completely free-form copyright files already in the archive aren't really human readable in that they don't actually contain any useful information or make it really hard to find said information. -- ?StuartPrescott
822 format is fine, we use that everywhere. I had an example for nicer field names that got delete as "unclear": http://wiki.debian.org/Proposals/CopyrightFormat?action=diff&rev2=423&rev1=422. It summarizes as "don't use ugly field names, don't invent new terms" (s/Upstream-Name/Package/ etc.), "omit redundant info" (Files: * could just be replaced by void, that's even parsable if it's the first section), and "don't repeat stuff" (s/Copyright: Copyright/Copyright/ - the first copyright is already in the header).
I also think that the current format ist really ugly, I even think that the current spec is that ugly that I will not use the current spec in my packages unless the policy tells me to do so. Myon's Proposal is much nicer to read, e.g. "Format:" instead of "Format-Specification:", a version number (could be a revision number prefixed by r until the first version is finished) instead of a URI, one "Copyright:" instead of many. "Files: *" is unnecessary, it should be default and thus could be obmitted, declaration of special cases should be satisfactory. Myon's "Package:" is IMHO also unnecessary.I'm not sure what the current consensus about additional comments is but I think they should be allowed since no format spec can be broad enough to catch all corner cases, regarding the indication of comments, they should not needed to be prefixed with something special, seperating by blank lines should be enough. — ?CarstenHey
Package: or ?UpstreamName: could be useful when there is more than one upstream (e.g. hnb in Debian will merge some patches from a hnb fork called lhnb, so there are actually two upstreams) or when the upstream name differs from the source package name, but in most cases it should be omitet since it is redundant information. — ?CarstenHey
- . . s/Format-Specification/Format/: I have no problem with that, sounds sensible. AIUI it was always the intention to use something nice and short later on once the specification had settled down as no-one really wants to see a wiki revision number there.
- . . s/Upstream-//: I disagree with this. The point of the copyright file is to bridge between the names that Debian uses for things and the names that upstream uses for them. There are many many examples in the archive where the name of the upstream project, their tarballs, the source packages in Debian and then the binary packages that come from them all use different names. Clearly stating that it is the upstream name that is being referred to here is important. Moreover, the copyright file should have the name of the package in it; it's not redundant information at all. "Upstream" is hardly inventing a new term either; it is widely used throughout Debian and as we work harder to separate upstream source from Debian patches, it will be used even more.
- . . "one Copyright: instead of many": Each copyright line needs to be allowed to line wrap. If we're using rfc822, then multiple values for the field require repetitions of the field name. Your suggestion is actually how the specification used to read; this requirement came from actually trying to apply the specification to real packages and seeing how it did or didn't work.
- s/(Files: *//: maybe. I quite like that idea as it's quite explicit about what it's talking about. But perhaps it can be implicit or even optional. s/Copyright: Copyright/Copyright/: (a) that's no longer rfc822 format and (b) the feeling was that the field name was insufficient to actually mark it as a copyright field. If debian-legal etc are happy with that then sure. The copyright symbol was also allowed to make this shorter.
-- ?StuartPrescott (who is sick of MoinMoin and its hopeless gui editor)
Please can we HALT discussion on the wiki. This is an absurd way of talking to each other. -- ?NoahSlater
--
Overlapping copyright and license for different parts of a work
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>
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
Responsibility of package maintainer with regard to copyright
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