NOTE: THIS PAGE IS NOT CURRENT

This page is no longer the working draft; please use the DEP process (this proposal is numbered DEP 5) for further discussion.

(As of 2009-03-25, DEP 5 is in preparation.)

(Existing discussions are archived at Proposals/CopyrightFormat/Archive.)


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.

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.

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 bug 478930 -- ?MathieuParent

Implementation

Sections

Header Section (Once)

The header should be rfc2822 compliant, consisting of multiple fields.

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.

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

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]

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 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 Commercial *)
        "-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-2.0

Apache license, version 2.0 only

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. License notice text must be copied verbatim.

Notes:

TODO: If author did not specify version and version cannot be decoded from the context or other files, how the license should be expressed?

Consult FSF's page for GPL compatibility of particular license.

The is no difference between regular versions and point-zero versions. E.g. keyword CC-3 is identical to CC-3.0 notation. The point-zero syntax can be used in cases where there are minor releases of the same license available; like in case of GFDL-1.2.

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 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 "The OpenSSL License and The GPL" by Mark McLoughlin and message "middleman software license conflicts with OpenSSL" by Mark McLoughlin in Debian legal mailing list. Any GPL source that uses OpenSSL and does not contain an openSSL exception notice is REJECTED by the Debian FTP admistrators. 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.

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

keyword

GPL compatible

meaning

BSD-C2

Yes

Two-clause BSD license

BSD-C3

Yes

Three-clause BSD license, with no-endorsement clause, as seen in /usr/share/common-licenses/BSD

BSD-C4

No

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 License listJariAalto:

keyword

GPL compatible

meaning

BSD

No

Also known as the “Original 4-clause BSD license”. Contains the “obnoxious BSD advertising clause”.

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.

FreeBSD

Yes

Also known as the “2-clause BSD license”. Original BSD license with the advertising clause and another clause removed. Theis is safe, simple, permissive non-copyleft free software license.

OpenBSD

Yes

Also known by name "ISC License". This license does have an unfortunate wording choice.

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 basis of these keywords should be wide recognition. Something based on lists like Open Source Initiative: Licenses by Name, Wikipedia: List of FSF approved software licences, FSF: Various Licenses and Comments about Them and Open Source Initiative: Licenses by Name

This list does not yet represent all widely used licenses. Good candicates are those listed in FSF or OSI pages mentioned above. The column "Version needed" means that the license keyword should always be accompanied with version number. E.g. plain keyword Artistic is to be avoided in favor of more explicit Artistic-2 keyword.

The GPL compatible field indicates compatibility in respect to license's version. E.g in case of Apache, the "2.0+ (v3)" means that Apache license version 2.0 was the first GPL v3 compatible license. The Apache licenses are not GPL v2 compatible. In case of CPL, the "No (1.0)" means that license version 1.0 is GPL incompatible; no information about other versions is known. If the field is linked to somewhere else, it means that the opinion has not been verified by FSF, but external source is being cited.

keyword

Version needed?

GPL compatible

meaning

Apache

Yes

2.0+ (v3)

Apache license. For versions, consult Apache Software Foundation.

Artistic

Yes

2.0+ (v2+)

The Perl Artistic license. For versions, consult Perl Foundation

CDDL

Yes

No

Common Development and Distribution License, For verions, consult Sun Microsystems. Based on MPL 1.1.

Eiffel

Yes

2+

The Eiffel Forum License. For versions, consult Open Source Initative

CPL

Yes

No 1.0

For versions, consult IBM Common Public License (CPL) Frequently asked questions. See also Wikipedia

ISC

No

Yes

The Internet Software Consortium's “ISC license”. Sometimes also known as the OpenBSD License

MPL

Yes

No

Mozilla Public License. For versions, consult Mozilla.org

PSF

Yes

No 1.6b1-2.1

For versions, consult Python Software Foundation License

W3C-Software

Yes (YYYMMDD)

Yes

The W3C Software License. For more information, consult W3C Intellectual Rights FAQ and 20021231 W3C Software notice and license

ZLIB

No

Yes

The zlib/libpng license

Zope

Yes

2.0, 2.1

Zope Public License. For versions, consult Zope.org

Problematic Licenses

keyword

Version needed?

GPL compatible

meaning

CC

Yes

No

Creative Commons Attribution License. You should not upload anything prior 3.x. Read Debian Creative Commons Workgroup report by Evan Prodromou. CC license can easily lead to repackaging; CC-licensed material that does not meet DFSG have to be removed. This license is neither GPL nor GFDL compatible

MIT

No

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. License notice text needs to be copied verbatim

PD

No

Being in the public domain is not a license. See Linux journal article "Why the Public Domain Isn't a License" by Lawrence Rosen. License notice text needs to be copied verbatim

PHP

Yes

No 3.01

For versions, consult PHP license. The PHP license may cause Debian FTP admin staff to REJECT the package. The PHP license was designed for code contibuted to PHP language itself and not for developing PHP Web applications. It might be good idea to contact the author with suggestion to change to more safer LGPL or BSD license. See Debian mailing list threads 1, 2, 3, 4, 5

QPL

Yes

No 1.0

For versions, consult Trolltech. This is obsolete license for Qt. Suggest the author of the sources to study page http://doc.trolltech.com/4.0/qpl.html

License keyword "other"

Examples of licenses not listed OSI, FSF pages. Should use License keyword other. The license notice is copied verbatim.

License

Erlang Public License

The Expat license. This license is equivalent to what many people mean by "the MIT license" or "the MIT/X11 license", but those names are too ambiguous as there are multiple incompatible versions of an "MIT/X11 license" in the wild. For clarity, it is better to refer to "the Expat license" as that name refers only to these license terms.

The LaTeX Project Public License. For versions, consult Latex project. GPL-incompatible. Note that works under any version of the License often have additional restrictions attached; check carefully.

Discussion

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

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

Comment: I still do not think we need a formal grammar for this. A few guidelines and a review process is all that we should need. We need to make this specification friendly to developer and this unnecessary grammar does not help us with that goal. I say it is unnecessary because neither Debian package developers, implementers of software that uses this specification, nor end users will ever make any use of the grammar. The only time this grammar would ever conceivably be used is when adding a new licence to the specification. I am confident in the current proficiency level of contributors to this effort that we could reasonably decide what is and isn't appropriate without going to this length. I am also struggling to understand the importance of GPL compatibility. Why has this been included? -- ?NoahSlater

Comment: The previous work was based on proposal of "list all licences, and combinations of them with versions". It didn't have structure, it didn't have rules how the licence keywords were supposed to be used and added, it unnecessarily listed every combination of versions, it didn't address problems associated with the license extensions of which "OppenSSL" issues and various other issues with the GPL licenses are examples. The Grammar is compact and handles all these now and in the future. It has been demonstrated to adapt to new requirements easily, like adding a "-Font" clarification for GPL by a user request. The grammar provides rules for machine parseability (lintian), where the original lists didn't. The GPL compatibility is very much an issue, when sources are combined from various licenses. -- JariAalto

Resolved issues:

2008-11-21: <License keyword well known> was broadened to answer to these. New topic <<License keyword "other">> was also added

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 license name and text copied verbatim. -- JariAalto

Comment: There is a major problem with the current suggestion. In the case of some files being dual licensed, where one of those licenses is a non-cannon license per this list, you can use the "other" keyword. However, if you have two sets of files, both in the same situation, they cannot both use the "other" keyword because a) the licence block would have to be seperate due to it being dual licensed and b) the keyword "other" can only be used once for a license block. What I would like to suggest is a) we scrap the EBNF as specification bloat, b) restore a single table enumerating every officially recognised (i.e. for better integration with machine processing) keywords, and c) let developers use arbitary keywords to cover the edge cases. A good way to make sure people know the importance of using the cannonical list is to get lintian to warn about non-cannon keywords. These warninings can be overridden when needed. -- Noah Slater

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

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: Does it instead need to be written explicitly like this:

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.

Recent Changes