|
Size: 47519
Comment: File::Format::Syntax adjust text.
|
Size: 3842
Comment:
|
| Deletions are marked like this. | Additions are marked like this. |
| Line 1: | Line 1: |
| ''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 | DEP 5 is a [[DEP]] currently in CANDIDATE stage. |
| Line 3: | Line 3: |
| ''Comment:'' I think that the proposal got developed and popularised enough that a [http://dep.debian.net/deps/dep0/ 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.-- CharlesPlessy | It is being developed within the DEP process and it is available at its canonical web address http://dep.debian.net/deps/dep5 |
| Line 5: | Line 6: |
| ''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 | <<TableOfContents(2)>> |
| Line 7: | Line 8: |
| 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. | = Archived discussion = |
| Line 9: | Line 10: |
| This is not a proposal to change the policy in the short term. | Prior to 2009-03-25, the proposal was being developed on this wiki-page. Discussions that were ongoing on this wiki from that point in time archived at [[Proposals/CopyrightFormat/Archive]]. |
| Line 11: | Line 13: |
| [[TableOfContents]] | = Open topics for DEP-5 = |
| Line 13: | Line 15: |
| = Rationale = | The DEP-5 drivers use this wiki page to manage the "to do" list for it. Please don't edit it in a way that will confuse them. This page is public in the interest of transparency. If you have opinions or suggestions or patches, please bring them up on the debian-project mailing list. Thanks. |
| Line 15: | Line 21: |
| 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. | Success criteria for DEP-5: |
| Line 17: | Line 23: |
| 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. | * people no longer find things to argue about on an ongoing basis |
| Line 19: | Line 25: |
| 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. | Current topics: |
| Line 21: | Line 27: |
| 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. | * There are no current topics. |
| Line 23: | Line 29: |
| ''Comment:'' 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 | Things that need to be done before DEP-5 is ready: |
| Line 25: | Line 31: |
| = Compatibility and Human-Readability = | * Ask SPDX to drop spurious trailing .0 from version numbers. * Integrate the spec into debian-policy, and update it to have a stable Format URL. * see: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=609160 * http://lists.debian.org/debian-project/2010/08/msg00269.html |
| Line 27: | Line 36: |
| 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. | Things that might be good to have at some point, outside of the spec text: |
| Line 29: | Line 38: |
| The {{{debian/copyright}}} file must be machine-interpretable, yet human-readable, while communicating all mandated upstream information, copyright notices and licensing details. | * lintian warning for malformed DEP-5 files * lintian info level message for non-DEP-5 files * something to track DEP-5 adoption (perhaps by counting the non-DEP-5 lintian tag on lintian.debian.org?) * a tool to check that all files in a source package are covered by debian/copyright |
| Line 31: | Line 44: |
| For the sake of human-readability this proposal avoids any complex field names or syntax rules. | == Differences between DEP5 and SPDX == |
| Line 33: | Line 46: |
| == Lintian == | With current suggestions for what to do. |
| Line 35: | Line 48: |
| You can discuss implementation details in [http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=478930 bug 478930] -- MathieuParent | * SPDX sometimes adds a license version, when we don't, or adds a ".0" to license version * ignore? the difference should not matter much * maybe suggest to SPDX they drop the ".0" * SPDX does not have some licenses we do (CC0, Expat, Perl, GFDL without invariants) * ignore: it's OK for us to have names for more licenses * but remove Perl as a shortname in DEP5 * SPDX has BSD 3 and 4 clause licenses with placeholders * ignore: we'll just have many variants of BSD (called other-FOO or whatever) * BSD license versions * adopt SPDX naming: BSD-2-clause (from FreeBSD), BSD-3-clause, BSD-4-clause (do dashes clash with license version syntax?) * SPDX represents "or later" as a different license, where we have a generic syntax, but end result is same * ignore * SPDX treats each GPL exception as a separate license * ignore, and suggest to SPDX they adopt DEP5 approach * LGPL+ means in SPDX that no version was specified, but no such convention for the GPL * ignore, it's their problem, our syntax supports it anyway * SPDX calls it FDL, DEP5 calls it GFDL * ask SPDX to rename, since GFDL is the logical name, otherwise maintain a mapping table * SPDX calls it Python and Python-CNRI, DEP5 calls it PSF * rename in DEP5 * SPDX calls them EFL, W3C, Zlib * rename in DEP5 * SPDX links to http://www.opensource.org/licenses/mit-license.html * add link to DEP5 |
| Line 37: | Line 73: |
| = Implementation = | = Implementations = |
| Line 39: | Line 75: |
| == Sections == | (Tentative) index of DEP5 implementations: |
| Line 41: | Line 77: |
| === 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 * disclaimer for non-free and contrib packages (see [http://www.debian.org/doc/debian-policy/ch-docs.html#s-copyrightfile Policy 12.5]) * only once * optional * Suggested name: '''{{{Disclaimer}}}''' * Suggested format: free content explaining that the contrib or non-free package is not part of the Debian GNU/Linux distribution and briefly explain why. ''Comment:'' 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? -- Stuart''''''Prescott Examples: {{{ Format-Specification: http://wiki.debian.org/Proposals/CopyrightFormat?action=recall&rev=196 Upstream-Name: SOFTware Upstream-Maintainer: John Doe <john.doe@example.com> Upstream-Source: http://www.example.com/software/project }}} {{{ Format-Specification: http://wiki.debian.org/Proposals/CopyrightFormat?action=recall&rev=196 Upstream-Name: xyz Upstream-Maintainer: Jane Smith <jane.smith@example.com> Upstream-Source: http://www.example.com/gitwww }}} === Files Section (Repeatable) === 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. * 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 * Good place to add mandatory hints on original package authors: use '''{{{Files: debian/*}}}''' * Copyright holders for the files listed in the previous '''{{{Files}}}''' field * Repeatable field, one field per copyright statement * Suggested name: '''{{{Copyright}}}''' * Suggested format: a single valid copyright statement * Example Format: Copyright 2008, Holder <email@example.org> * A valid copyright statement MUST include the word "Copyright" and not an abbreviation. The copyright symbol, being "©", "(C)", or similar MAY be used in addition to the word "Copyright" but this is not necessary. The copyright statement SHOULD include copyright year(s) and the copyright holder's name. Real names or organisation names SHOULD be used instead of nicknames or "screen names" where available. Optional contact information or URI is recommended. Maintainers MAY reformat copyright statements for clarity or consistency as long as the legal meaning is not changed. For more information study [http://www.gnu.org/licenses/gpl-howto.html GPL Howto]. * 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: '''{{{License}}}''' * Suggested format: * First line: See ''Keywords'' section. * Remaining lines: One of the following: * If a single license keyword is used you must either: * Copy the full text of the license, or * Leave this section empty if a standalone '''{{{License}}}''' section exists (see the ''Standalone License Section'' section) that matches the license keyword. * 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. Example: {{{ Files: * Copyright: Copyright 2008, John Doe <john.doe@example.com> Copyright: Copyright 2007, Jane Smith <jane.smith@example.com> License: PSF-2 [LICENSE TEXT] }}} '''Resolved issues''' ''Comment:'' 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. -- Stuart''''''Prescott ''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 === Standalone License Section === Where a set of files are dual (tri, etc) licensed you must use a single line '''{{{License}}}''' field and use standlone '''{{{License}}}''' fields to expand the license keywords. {{{ Files: src/js/editline/* Copyright: Copyright 1993, John Doe Copyright: Copyright 1993, Joe Average 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] }}} Where multiple sets of files use the same license you can avoid repetition by using a single line '''{{{License}}}''' field and use a separate standalone '''{{{License}}}''' field to expand the license keyword. {{{ Files: src/js/editline/* Copyright: Copyright 1993, John Doe Copyright: Copyright 1993, Joe Average License: MPL-1.1 Files: src/js/fdlibm/* Copyright: Copyright 1993, J-Random Comporation License: MPL-1.1 License: MPL-1.1 [LICENSE TEXT] }}} === 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] }}} '''Discussion''' ''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 == Fields Detail == === Files === ==== Format ==== The value of the '''{{{Files}}}''' field should be a list of comma-separated values: {{{ Files: foo.c, bar.*, baz.[ch] }}} 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: {{{ Files: "Program Files/*", manual\[english\].txt }}} ==== Syntax ==== Patterns are the ones recognised by the {{{find}}} utility's {{{-name}}} option and in case of the pattern contains path separator "/", it can be used for {{{-path}}} option. The following matches 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 }}} The command for find from the first example would be: : {{{ find . -path "*/Makefile.am -o -name "*.py" }}} It is quite common for a work to have files with copyright held by different parties and received under different licenses. To allow this, '''multiple stanzas are allowed with different {{{Files}}} declarations'''. 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: '''If multiple {{{Files}}} declarations match the same file, then only the last match counts.''' 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: BSD-C2}}}. {{{contain arbitrary values Files: * Copyright: Copyright 2003-2005, John Doe <jdoe@xample.com> License: [the main work's license] [LICENSE TEXT] Files: getopt.* Copyright: Copyright 2000, The Corporation Foundation, Inc. License: BSD-C2 [LICENSE TEXT] Files: debian/* Copyright: Copyright [years], [the debian package copyright holder] License: [the debian package license] [LICENSE TEXT] }}} 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. === License === ==== Keywords ==== 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. The convention for license abbreviations keyword is {{{XYZ}}} for a license with only one version, and {{{XYZ-n}}} for *sequential version ''n''* of the XYZ license, where {{{XYZ-1}}} is chronologically earlier than {{{XYZ-2}}}. The syntax of the ''License keyword'' can be defined using similar to [http://en.wikipedia.org/wiki/Extended_Backus–Naur_form EBNF grammar]: {{{ License ::= <keyword>[<version>]["BY" {N* <clarification>}] <keyword> ::= <License keyword FSF> | <License keyword BSD> | <License keyword well known> | "other" <License keyword FSF> ::= GPL | LGPL | AGPL | GFDL <License keyword BSD> ::= ... to be decided, see table below for proposals. <License keyword well known> ::= ... to be decided, see table below for proposals. <version> ::= <License version>["+"] <License version> ::= <Numeric version> | <Other version> <Numeric version> ::= [0-9.]+ <Other version> ::= <Vendor's version> | <publication date> <Vendor's version> ::= string (* anything: "A", "B", "public" *) <publication date> ::= YYYYMMDD <clarification> ::= <clarification GPL> <clarification GFDL> | <clarification CC> | <clarification other> <clarification GPL> ::= "-CC" (* With Creative Commons' metadata and Commons Deed added to GPL *) "-OpenSSL" (* With openSSL exception added *) "-Font" (* With font exception added *) <clarification GFDL> ::= "-NIV" (* With no invariant sections *) "-CC" (* With Creative Commons' metadata and Commons Deed added to GFDL *) <clarification CC> ::= (* Creative Commons License variants *) "-NC" (* No Commerercial *) "-ND" (* No Derivative Works *) "-SA" (* Share Alike *) <clarification other> ::= Other list of license specific keywords that clarify optional parts included or exluded. }}} Examples of the above grammar: || '''keyword''' || '''meaning''' || || {{{Apache-1.0}}} || Apache license, version 1.0 only || || {{{CC-3.0-BY-SA-ND-NC }}} || Creative Commons Attribution License 3.0; with Share Alike, No Derivs, No commercial || || {{{GPL-2+}}} || GNU General Public License, version 2 or (at your option) any later version || || {{{GPL-3}}} || GNU General Public License, version 3 only || || {{{LGPL-2}}} || GNU Lesser General Public License, version 2 only || || {{{LGPL-2+-BY-OpenSSL}}} || GNU Lesser Public License, version 2 or (at your option) any later and with OpenSSL linkage exception added || || {{{GFDL-1.2}}} || GNU Free Documentation License, version 1.2 only || || {{{GFDL-1.2+-BY-NIV}}} || GNU Free Documentation License, version 1.2 or (at your option) any later, with no invariant sections || || {{{PSF-2}}} || Python Software License, version 2 only || || {{{other}}} || Any other custom license. Text must be copied verbatim. || Notes: The extra plus-sign in {{{<License version>["+"]}}} means that the License contains clauses similar to GPL's "version N or (at your option) any later version". The GPL {{{-Font}}} clarification refers to the text added to the license notice of each file as expressed at FSF's page [http://www.gnu.org/licenses/gpl-faq.html#FontException How does the GPL apply to fonts?]. The text needed is: {{{ ... As a special exception, if you create a document which uses this font, and embed this font or unaltered portions of this font into the document, this font does not by itself cause the resulting document to be covered by the GNU General Public License. This exception does not however invalidate any other reasons why the document might be covered by the GNU General Public License. If you modify this font, you may extend this exception to your version of the font, but you are not obligated to do so. If you do not wish to do so, delete this exception statement from your version. }}} The GPL {{{-OpenSSL}}} clarification gives permission in cases where GPL code is linked with OpenSSL library. For more information, see page [http://www.gnome.org/~markmc/openssl-and-the-gpl.html "The OpenSSL License and The GPL"] by Mark !McLoughlin and message [http://lists.debian.org/debian-legal/2004/05/msg00595.html "middleman software license conflicts with OpenSSL"] by Mark !McLoughlin in Debian legal mailing list. The license notice needs to include following or close to similar excerpt to qualify for {{{BY-OpenSSL}}} which allows linking with OpenSSL: {{{ ... In addition, as a special exception, the copyright holders give permission to link the code of portions of this program with the OpenSSL library under certain conditions as described in each individual source file, and distribute linked combinations including the two. You must obey the GNU General Public License in all respects for all of the code used other than OpenSSL. If you modify file(s) with this exception, you may extend this exception to your version of the file(s), but you are not obligated to do so. If you do not wish to do so, delete this exception statement from your version. If you delete this exception statement from all source files in the program, then also delete it here. }}} '''Discussion''' ''Comment:'' I am opposed this suggestion. I think introducing an EBNF grammar for the license keywords is totally unnecessary. This seems like complexity for complexities sake. No one is suggesting that this field contain arbitrary values, the original proposal was that the values would be explicitly enumerated. There is no technical reason why this is not sufficient for our needs. In the edit to add this proposal you have completely obliterated the existing list of keywords that were already within use in Debian. -- NoahSlater ''Comment:'' On the contrary. There is no need to list every possible case starting from GPL-1, GPL-1+, GPL-2, GPL-2+. LGPL-1...LGPL-2.1, LGPL-2.1+ etc. The grammar can sufficiently express how the license keywords are to be constructed. If the examples above are not sufficient, they can be extended as needed. The EBNF does not imply arbitrary values. What needs to be decided is the exact keywords that express the license names for slots "to be decided". -- JariAalto ''Comment:'' You say "there is no need", but this doesn't really make sense. We have two suggestions so far, enumerating every single licence using, essentially opaque, identifiers, or using your solution and making the identifiers themselves meaningful, constructing a grammar to do so. Two solutions, and varying positive and negative points. I prefer the first, and original, solution of explicitly enumerating each license, I find the alternate to be overcomplex, and buys us little for the additional complexity it adds for both implementors of this standard and those trying to produce conforming documents. ''Comment:'' The grammar can "enumerate" licenses because that's what EBNF does. This does does not exclude in any way that there could be a "whole list" if someone wished to write one with every possible combination. The idea is that when more and more licenses are added, there is a need to define syntax how the license keywords are to be constructed. -- JariAalto ''Comment:'' We had already written a whole list that you have subsequently removed. This list was already in use by a large number of Debian packages. Could you please restore it? -- NoahSlater ''Comment:'' That list is expressed in the grammar; the examples section demonstrates how to apply it. No license keywords should have been lost. For example you can read: GPL-1, GPL-1+, GPL-2, GPL-2+, GPL-3, GPL-3+ etc. which are all covered. -- JariAalto RESOLVED ISSUES: ''2008-10-21: This was implemented in EBNF. Thank you. -- JariAalto'' ''Comment:'' Another common GPL exception is [http://www.gnu.org/licenses/gpl-faq.html#FontException Font Exception]. Should it be added to the above EBNF? -- TheppitakKaroonboonyanan '''<License keyword BSD>''' ''Proposal 1:'' Comment: These licenses have no recognised version number. Perhaps the abbreviation should deliberately show the number of clauses in a way that doesn't indicate a version number: {{{BSD-C<N>}}}. 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. —BenFinney 2008-10-16: || {{{BSD-C2}}} || Two-clause BSD license || || {{{BSD-C3}}} || Three-clause BSD license, with no-endorsement clause, as seen in {{{/usr/share/common-licenses/BSD}}}[[BR]] || || {{{BSD-C4}}} || Four-clause BSD license, with no-endorsement clause and advertising clause; GPL-incompatible (need exact text) || ''Proposal 2:'' 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. 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 || {{{BSD-BY-LC}}} || forms requiring only the inclusion of copyright notice and condition || || {{{BSD-BY-LC-NE}}} || plus “no endorsement without permission” || || {{{BSD-BY-LC-NE-AD}}} || plus “advertising required” || ''Proposal 3:'' While mnemonics like {{{LC,NE,AD}}} may sound practical (where does LC abbreviation come from?), in BSD case I find them lacking wider recognition. The BSD licenses have been examined by FSF, so perhaps we could use names and definitions used at [http://www.gnu.org/philosophy/license-list.html#FreeBSD License list] —JariAalto: || '''keyword''' || '''GPL compatible''' || '''meaning''' || || [http://www.gnu.org/philosophy/license-list.html#OriginalBSD BSD] || No || Also known as the “[http://www.opensource.org/licenses/bsd-license.php Original 4-clause BSD license]”. Contains the “obnoxious BSD advertising clause”. || || [http://www.gnu.org/philosophy/license-list.html#ModifiedBSD ModifiedBSD] || Yes || This is the original BSD license, modified by removal of the advertising clause. It is a simple, permissive non-copyleft free software license. || || [http://www.gnu.org/philosophy/license-list.html#FreeBSD FreeBSD] || Yes || Also known as the “[http://www.freebsd.org/copyright/freebsd-license.html 2-clause BSD license]”. Original BSD license with the advertising clause and another clause removed. Simple, permissive non-copyleft free software license. || || [http://www.gnu.org/philosophy/license-list.html#ISC OpenBSD] || Yes || Also known by name "[http://www.opensource.org/licenses/isc-license.txt ISC License]". This license does have an unfortunate wording choice. || || [http://www.gnu.org/philosophy/license-list.html#clearbsd ClearBSD] || Yes || Based on the modified BSD license, and adds a term expressly stating it does not grant you any patent licenses.|| '''<License keyword well known>''' The basic of these keywords should be wide recognition. Something based on lists like [http://www.opensource.org/licenses/alphabetical Open Source Initiative: Licenses by Name], [http://en.wikipedia.org/wiki/List_of_FSF_approved_software_licences Wikipedia: List of FSF approved software licences], [http://www.gnu.org/philosophy/license-list.html FSF: Various Licenses and Comments about Them] and [http://www.opensource.org/licenses/alphabetical Open Source Initiative: Licenses by Name] ''Comment'': What do you mean by "wide recognition", I hardly see how this has any relevance. If we need to use a license, we need to use a license. -- NoahSlater ''Comment'': E.g. using label ''Apache'' to refer to particular type of license is widely recognized (cf. FSF, Open Source initiative). This list should include only licenses that are in wide use and refrain from listing all possible past and present licenses. The lesser known licenses can use category "other" with text copied verbatim. The list below is not yet complete. -- JariAalto TODO: This list needs better scrutiny: ''Comment:'' What do you mean better scrutiny? For what? -- NoahSlater ''Comment:'' This list does not yet represent a solid list of known licenses. That should probably be determined by a wider audience (poll in Debian Legal, Devel?). Good candicates are those listed in FSF or OSS pages mentioned above. -- JariAalto || '''keyword''' || '''meaning''' || || {{{Apache}}} || Apache license || || {{{Artistic}}} || The Perl Artistic license. Always spcify the version number, either [http://www.perlfoundation.org/artistic_license_1_0 1.0] or [http://www.perlfoundation.org/artistic_license_2_0 2.0] || || {{{CC}}} || [http://creativecommons.org/license Creative Commons Attribution License] || || {{{IBMCPL}}} || IBM Common Public License || || {{{CeCILL}}} || CEA-CNRS-INRIA-Logiciel Libre. See http://www.cecill.info/licences || || {{{Eiffel}}} || Eiffel Forum License || || {{{Erlang}}} || Erlang Public License || || {{{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”. See http://opensource.org/licenses/isc-license.txt || || {{{LatexPPL}}} || The LaTeX Project Public License. See e.g. http://www.latex-project.org/lppl/lppl-1-3a.txt; GPL-incompatible[[BR]]Note that works under any version of the License often have additional restrictions attached; check carefully. || || {{{MPL}}} || Mozilla Public License. See e.g. http://www.mozilla.org/MPL/MPL-1.1.html || || {{{PSF}}} || Python License || || {{{PHP}}} || PHP License || || {{{W3C-Software}}} || The W3C Software License. See http://www.w3.org/Consortium/Legal/2002/copyright-software-20021231 || || {{{ZLIB}}} || The zlib/libpng license. See http://www.opensource.org/licenses/zlib-license.php || || {{{Zope}}} || Zope Public License. || '''Things than need to be clarified''' If author did not specify version and version cannot be decoded from the context or other files, how the license should be expressed? || {{{MIT}}} || Several variants of the MIT license exist: (1) the standard version with three paragraphs (blanket permission, keep this notice, NO WARRANTY), (2) a version with a no-endorsement clause, and (3) other versions with slight wording differences. ''Text needs to be copied verbatim'' || || {{{PD}}} || [http://creativecommons.org/licenses/publicdomain/ In the public domain]. Not applicable everywhere in the world. ''Text needs to be copied verbatim'' || ''Comment:'' 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 ==== Syntax ==== 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: {{{ License: GPL-2+ }}} This is a dual-licensed GPL/Artistic work such as Perl: {{{ License: GPL-2+ | Artistic-2.0 }}} This is for a file that has both GPL and classic BSD code in it: {{{ License: GPL-2+, BSD-C2 }}} And this is for a file that has Perl code and classic BSD code in it: {{{ License: GPL-2+ | Artistic-2.0, BSD-C3 }}} 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+-BY-OpenSSL}}}: {{{ License: GPL-2+-BY-OpenSSL 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." }}} '''Discussion''' '''Resolved issues''' ''2008-11-21: The following below has been resolved by the use of EBNF grammar. The GPL/LGPL extensions are defined after "BY" keyword. In this case the {{{-OpenSSL}}}'' --JariAalto . 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: . {{{ Files: * Copyright: Copyright 1999-2007 John Doe License: GPL-2+ | other License: GPL-2+ On Debian systems, [...] License: other In addition, as a special exception, [...] }}} ''Comment:'' However, this description is still not what the author meant. If the field read {{{License: GPL-2 | Artistic-2.0}}} then the end-user has the choice of choosing to accept either the GPL-2 or Artistic 2.0 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. ''Comment:'' I disagree: It was indeed the intention of the author to license as either "GPL2+" or "GPL2+ adjusted to please OpenSSL", which is 2 separate distinct licensing terms, even if written more compact to not repeat the GPL2+ part. In other words, I believe the above is correct. -- JonasSmedegaard ''Comment:'' 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''''''Prescott ''Comment:'' Does it instead need to be written explicitly like this: . {{{ Files: * Copyright: Copyright 1999-2007 John Doe License: GPL-2+ + exception On Debian systems, [...] Exception: In addition, as a special exception, [...] }}} ''Comment:'' Notes: * 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. * This is related to the earlier question about the removal of the actual statement of how the code was released from the copyright file (e.g. the "This program is free software ... You should have received ..." text). This openssl exception is part of that statement and not part of a license. . -- Stuart''''''Prescott ''Comment:'' 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 ''Comment:'' 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''''''Prescott My only issue is with the use of spaces in the license keywords, how about: {{{GPL/extra}}}, {{{GPL2/extra}}}, {{{GPL2+/extra}}}, etc or similar? = Examples = == Simple == A possible {{{copyright}}} file for {{{xsol}}}: {{{ Format-Specification: http://wiki.debian.org/Proposals/CopyrightFormat?action=recall&rev=143 Upstream-Name: X Solitaire Upstream-Source: ftp://ftp.example.com/pub/games Files: * Copyright: Copyright 1998, John Doe <jdoe@example.com> 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, Jane Smith <jsmith@example.net> License: other [LICENSE TEXT] }}} == Complex == A possible {{{copyright}}} file for {{{planet-venus}}}: {{{ Format-Specification: http://wiki.debian.org/Proposals/CopyrightFormat?action=recall&rev=178 Upstream-Name: Planet Venus Upstream-Maintainer: John Doe <jdoe@example.com> Upstream-Source: http://www.example.com/code/venus Files: * Copyright: Copyright 2008, John Doe <jdoe@example.com> Copyright: Copyright 2007, Jane Smith <jsmith@example.org> Copyright: Copyright 2007, Joe Average <joe@example.org> Copyright: Copyright 2007, J. Random User <jr@users.example.com> License: PSF-2 [LICENSE TEXT] Files: debian/* Copyright: Copyright 2008, Dan Developer <dan@debian.example.com> 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, Joe Hacker <hack@example.org> License: GPL-2+ [LICENSE TEXT] Files: planet/vendor/compat_logging/* Copyright: Copyright 2002, Mark Smith <msmith@example.org> License: MIT [LICENSE TEXT] Files: planet/vendor/httplib2/* Copyright: Copyright 2006, John Brown <brown@example.org> License: other Unspecified MIT style license. Files: planet/vendor/feedparser.py Copyright: Copyright 2007, Mike Smith <mike@example.org> License: PSF-2 [LICENSE TEXT] Files: planet/vendor/htmltmpl.py Copyright: Copyright 2004, Thomas Brown <coder@example.org> 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. }}} = Questions = 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 [http://intellinuxwireless.org/?n=faq&s=license#license_1 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 = Recent Changes = * 2008-11-21: Removed '''{{{Upstream-Vcs-Browser}}}''' and '''{{{Upstream-Vcs-URI}}}''' from the proposal after informal consensus period resulting in one to keep and three to delete. A concern was raised that "[the] URL mentioned cannot be used alone to retrieve the sources in any machine automated way." The '''{{{Upstream-Source}}}''' field is meant for human consumption, and is intended to be used as a general pointer to the upstream source, not as a machine readable way of automating upstream source repackaging. If someone wants to develop a machine readable upstream source specification, perhaps using the {{{README.source}}} file, I would suggest that this is done separately to this specification. -- NoahSlater * 2008-11-21: Add to EBNF new topic ''Notes:''. Add OpenSSL exception excerpt and cite Mark McLoughlin. Add GPL {{{-Font}}} exception. Add {{{-path}}} to File::Format::Syntax. * 2008-11-20: Add to EBNF new "-OpenSSL" clarification for GPL, LGPL. Add version number to Artistic licenses; also add URLs to point to 1.0 and 2.0. Change obsolete GPL-1+ examples to more in use GPL-2+ examples. Change {{{other-BSD}}} keywords to proposed {{{BSD-C2}}} keywords in examples. Add new new section ''Resolved issues'' * 2008-11-08: Simplify ''Upstream-Vcs-URI''. Use example.{org,com,net} in all URLs. —JariAalto * 2008-11-07: License Keywords: Write generic EBNF. Divide BSD cases to proposals 1,2,3. Make generic keyword tables. Add BSD table for proposal 2. Add ''Comment:'' indicators. Add '''Discussion''' sections. Properly indent all comments. (MAJOR CHANGES). —JariAalto * 2008-11-02: License Keywords: Add table about FSF recognized names for use with BSD licenses. —JariAalto * 2008-10-21: Header Section: Add '''{{{Upstream-Vcs-Browser}}}''' and '''{{{Upstream-Vcs-URI}}}'''. —JariAalto * 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 '''{{{Format-Specification}}}''' URLs, and fix examples to avoid {{{lintian}}} warnings in packages that use the examples. —BenFinney * 2008-07-12: I propose a new header field, '''{{{Disclaimer}}}''', for contrib and non-free package to comply with the suggestion introduced by Policy 3.8.0 to state that they are not part of Debian. -- CharlesPlessy * 2008-07-11: Improved explanation around the '''{{{License}}}''' field. -- NoahSlater * 2008-07-11: Removed the mention of '''{{{License-Terms}}}''' field following no reply to criticisms. -- NoahSlater * 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 '''{{{Notice}}}''' because I don't see a use case for this. Any licenses in {{{/usr/share/common-licenses}}} should be expressed using a regular '''{{{License}}}''' field with the standard Debian notice text being used as the long description. Unknown or uncommon licenses can be expressed using the "other" license 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, separating sections with empty lines is mandatory to parse "Multiple license fields" -- MathieuParent * 2008-04-28: Added clarified multiple '''{{{License}}}''' field behaviour. -- NoahSlater * 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 License independently 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-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-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 ---- . CategoryDeveloper |
* [[http://cpansearch.perl.org/src/DDUMONT/Config-Model-1.226/lib/Config/Model/models/Debian/Dpkg/Copyright.pl|Perl's Config::Model]] * libconfig-model-perl 1.226-1 in unstable parses older draft. * lintian support: DebianBug:478930 * CDBS support: [[http://git.debian.org/?p=collab-maint/cdbs.git;a=blob;f=scripts/licensecheck2dep5;hb=HEAD|licensecheck2dep5]], used by copyright-check.mk snippet * cdbs 0.4.89 in testing generates older draft. * cdbs 0.4.90 in experimental generates current draft (at the time of DEP5 CANDIDATE status) * dh-make-perl creates debian/copyright files in DEP5 format (older draft) |
DEP 5 is a DEP currently in CANDIDATE stage.
It is being developed within the DEP process and it is available at its canonical web address http://dep.debian.net/deps/dep5
Contents
Archived discussion
Prior to 2009-03-25, the proposal was being developed on this wiki-page. Discussions that were ongoing on this wiki from that point in time archived at Proposals/CopyrightFormat/Archive.
Open topics for DEP-5
The DEP-5 drivers use this wiki page to manage the "to do" list for it. Please don't edit it in a way that will confuse them. This page is public in the interest of transparency. If you have opinions or suggestions or patches, please bring them up on the debian-project mailing list. Thanks.
Success criteria for DEP-5:
- people no longer find things to argue about on an ongoing basis
Current topics:
- There are no current topics.
Things that need to be done before DEP-5 is ready:
- Ask SPDX to drop spurious trailing .0 from version numbers.
- Integrate the spec into debian-policy, and update it to have a stable Format URL.
Things that might be good to have at some point, outside of the spec text:
- lintian warning for malformed DEP-5 files
- lintian info level message for non-DEP-5 files
- something to track DEP-5 adoption (perhaps by counting the non-DEP-5 lintian tag on lintian.debian.org?)
- a tool to check that all files in a source package are covered by debian/copyright
Differences between DEP5 and SPDX
With current suggestions for what to do.
- SPDX sometimes adds a license version, when we don't, or adds a ".0" to license version
- ignore? the difference should not matter much
- maybe suggest to SPDX they drop the ".0"
- SPDX does not have some licenses we do (CC0, Expat, Perl, GFDL without invariants)
- ignore: it's OK for us to have names for more licenses
- but remove Perl as a shortname in DEP5
- SPDX has BSD 3 and 4 clause licenses with placeholders
- ignore: we'll just have many variants of BSD (called other-FOO or whatever)
- BSD license versions
- adopt SPDX naming: BSD-2-clause (from FreeBSD), BSD-3-clause, BSD-4-clause (do dashes clash with license version syntax?)
- SPDX represents "or later" as a different license, where we have a generic syntax, but end result is same
- ignore
- SPDX treats each GPL exception as a separate license
- ignore, and suggest to SPDX they adopt DEP5 approach
- LGPL+ means in SPDX that no version was specified, but no such convention for the GPL
- ignore, it's their problem, our syntax supports it anyway
- SPDX calls it FDL, DEP5 calls it GFDL
- ask SPDX to rename, since GFDL is the logical name, otherwise maintain a mapping table
- SPDX calls it Python and Python-CNRI, DEP5 calls it PSF
- rename in DEP5
- SPDX calls them EFL, W3C, Zlib
- rename in DEP5
SPDX links to http://www.opensource.org/licenses/mit-license.html
- add link to DEP5
Implementations
(Tentative) index of DEP5 implementations:
- libconfig-model-perl 1.226-1 in unstable parses older draft.
lintian support: 478930
CDBS support: licensecheck2dep5, used by copyright-check.mk snippet
- cdbs 0.4.89 in testing generates older draft.
- cdbs 0.4.90 in experimental generates current draft (at the time of DEP5 CANDIDATE status)
- dh-make-perl creates debian/copyright files in DEP5 format (older draft)