![[LWN Logo]](/images/lwn.banner.gif)
From: Ian Jackson <ian@chiark.greenend.org.uk>
Date: Fri, 27 Nov 1998 02:56:25 +0000 (GMT)
To: Debian developers list <debian-devel@lists.debian.org>
Subject: Draft new DFSG - r1.4
There are substantial changes here to the periphery, but the core
remains largely unchanged.
Important changes include: a new rationale section at the end; a new
purpose section at the beginning; a new set of allowed restrictions
for various non-software works (mainly some kinds of documentation).
FYI, I append below the new text a diff between the previous posted
version (CVS revision 1.2) and this one.
PACKAGE MAINTAINERS: please check your licences to see if there are
harmless restrictions in your packages that need to be added to
section 3.
EVERYONE: please read through the new section 4 on special kinds of
works which allow extra restrictions.
EVERYONE WHO DIDN'T READ IT BEFORE: please read it ! You'll miss out
on your chance to participate, otherwise.
I don't want this to take as long as the Constitution. In particular,
I plan to formally propose a resolution by the end of the year, before
the end of my term as leader.
DRAFT
$Id: dfsg2.text,v 1.4 1998/11/27 02:47:09 ian Exp $
Debian Free Software Guidelines
version 2
DRAFT
0. Purpose
(a) This document describes what the Debian Project considers free
software. Only free software is part of Debian, as described in
Debian's Social Contract. The term `DFSG-free' will be used to mean
`free software according to the Debian Free Software Guidelines'.
(b) The purpose of the Debian Free Software Guidelines is to ensure
that software which is part of Debian can be freely used, distributed,
and maintained, so that copyright problems and other legal
restrictions play as little a part as possible in the technical
development of Debian and the software packages which make it up.
(c) The DFSG are written not just to ensure that the Debian Project
can do with the software the things that we, our users, and our
distributors, want or need to do. They are also intended to ensure
that any third party free software developer can, given a piece of
software from Debian, do all the things that they might reasonably
expect to do with it in order to use and further develop free
software.
1. Licence
DFSG-free works are either in the public domain, or come with a
copyright licence, and with any necessary patent licences.
2. Permissions
(a) For a work to be DFSG-free, anyone must be permitted to use it.
(b) The source code must be available.
(c) Anyone must be permitted to distribute it in whole or part, in its
original form or in modified forms, both as source code and/or as
executables, on its own or together with other works.
(d) Anyone must be permitted to reverse-engineer it.
(e) These activities must be permitted regardless of from whom the
work was obtained, and must be permitted without having to refer to
or notify anyone else.
(f) There must be no restrictions on these activities other than kinds
of restrictions explicitly allowed by these guidelines; any other
restriction means that the work is not DFSG-free.
(g) The licence(s) must not allow the copyright or patent holder(s) to
terminate the licence(s).
3. Exemptions
(a) Requirement to distribute source code
The licence may require source code for the work to be distributed
whenever the executable is distributed, provided that:
i. When distribution is made by public anonymous download, the
licence restriction is satisfied if the source code is made available
on the same site as the executable, at all times when the executable
is available.
ii. The licence allows the distributor of executables to offer to
distribute the source code instead of actually distributing it. The
licence
(1) may require the offer to be in writing;
(2) may require that the offer remain valid for some specified
period of time (not more than 3 years);
(3) may require the offer to be open to all third parties.
(b) Requirement for onward distribution to use particular licence
The licence may make requirements about the kinds of licence (or other
contract or similar document) under which people distribute the
work (or its modified versions), so long as it is still possible to
distribute the work under according to these guidelines.
(c) Requirements for placing notices
The licence may require notices to be placed in the source code,
documentation, and/or to cause the work to display notices at
appropriate points during its execution (in the case of a work which
can be executed) or content (in the case of a work which can be
displayed and/or printed).
It must be possible to write such notices so that they are truthful,
not offensive, and not unreasonably long for the context in which they
are required, without the implied requirement to do so imposing any
restrictions which are not compatible with these guidelines.
(d) Requirements made to apply to whole work
The licence may make its requirements (falling under the other
exceptions) apply to the whole work when the original work is
combined with a second work to make a new whole work and the
resulting whole work (or part of it) is distributed.
(The licence may not make any requirements about other works or data
that are distributed as separate works but are merely distributed on
the same disk, tape, network site, or whatever.)
(e) Restrictions on misrepresentation
The licence may restrict the use (without permission) of the names of
the authors and copyright holders to endorse or promote products
derived from the work.
The licence may also restrict other kinds of misrepresentation.
(f) Limitation of liability
It may be a condition of the licence that the authors and copyright
holders are not held legally responsible for errors and omissions in
the work (in so far as permitted by applicable law).
(g) Non-binding requests
The licence or other documentation may make other requests of users
and redistributors, provided that these requests are not legally
binding, and that there is no suggestion that failing to honour the
request is unethical or immoral.
(h) Different name or version number for certain version
The licence may require the work to be distributed under a different
name or with a different version number under some circumstances
defined in the licence, provided that this doesn't interfere with
using the modified version as a replacement for the original.
(i) Advertising restriction (deprecated)
The licence may require advertising materials which mention features
or use of the work to contain a short notice specified by the
software.
This exception is only available if the restriction was imposed no
later than the 1st of January 1999, and if no modified version of the
work has been published since then by anyone who could remove the
restriction.
This exception is likely to be removed in a future version of these
guidelines. For rationale, see Appendix C.
4. Documentation and other non-software works
Certain kinds of documentation or other non-software works may have
further restrictions.
(a) None of the exceptions listed in this section apply to a work
which is documentation for software. Documentation for software is
documentation to which a conscientious programmer would wish to make
corresponding changes when they modify the software.
(b) A document which states an opinion, as an opinion, need not be
modifiable.
(c) The licence for a document which specifies a standard of some kind
(for example a Standards Track RFC) need not be modifiable, provided
that the licence still permits the creation and distribution of
modified versions, for at least the purposes of developing new
standards, according to the procedures for the standards process in
question.
(d) An artwork which is expressive and not functional need not be
modifiable.
(e) When we say that a work need not be modifiable, we mean that
restrictions may be placed on:
i. the creation and/or distribution of modified versions;
ii. the distribution of parts of the work, rather than the whole;
iii. distribution of the source code, if this is different from the
form of the work usually distributed (and, we also mean that the
source code need not be available); and
iv. reverse-engineering.
5. Restrictions due to law
(a) If in a particular jurisdiction any of the activities mentioned in
section 1 are restricted by law, then the work is not DFSG-free in
that jurisdiction. However, legal restrictions which would apply to
any work which has the same general nature as the work in question do
not prevent a work from being DFSG-free.
(b) A work is still DFSG-free in other jurisdictions, provided that
those who control (directly or indirectly) the work and the conditions
under which it is distributed, do not have the power to lift the
restrictions other than by changing the nature of the work, and
express a desire that the legal restrictions be lifted.
(c) In the case of restrictions due to patents, the work can in any
case not be DFSG-free if any of those who control the work and the
conditions under which it is distributed are software patent
aggressors.
6. Glossary
In these guidelines:
(a) Source code has the meaning given for it in the GNU General Public
Licence, version 2.
(b) Executables means a derived version of the work which is not the
source code.
(c) A software patent aggressor is a person or organisation who
enforces patents against software patent nonaggressor(s), with respect
to infringement by software, or profits from such enforcement.
APPENDICES AND RATIONALE
A. Why is a change from DFSG1 necessary ?
The current DFSG (version 1) have a number of problems.
Its most serious problem is that they are far too vague. Very often a
new copyright licence is brought up on one of the Debian mailing
lists, and a long discussion ensues. These discussions usually hinge
on trying to guess the meaning of the text of the DFSG.
Unfortunately, the DFSG1 are not sufficiently clear, precise or
self-consistent for this to work well.
Another problem with DFSG1 is that they state that certain
restrictions make software not DFSG-free, rather than listing the
permitted restrictions. The effect of this is that when a novel but
unhelpful licence is compared with the DFSG1, it is often found to
meet the letter of the guidelines despite the fact that its licence
has unreasonable restrictions for free software.
The combination of these two effects mean that Debian developers are
tempted towards `creative' interpretations of the DFSG - for example,
involving the `no discrimination against fields of endeavour' clause.
This can only lead to flamewars, an appearance of arbitrariness, and
the unwise inclusion or exclusion of software.
Finally, the free software community is now encountering a number of
individuals and organisations who would like to give away as little
freedom as possible. The DFSG1 were not written to withstand hostile
interpretation. In the current climate it is necessary to have
guidelines whose interpretation is clear, and which cannot easily be
bent or subverted.
B. Why are `modifications as patch only' licenses not allowed ?
(DFSG1 paragraph 4 `Integrity of The Author's Source Code' allows a
licence to require that modifications be distributed only as original
sources plus patches. The DFSG2 do not allow this. Here is why.)
The following examples are things you should be legally able to do
with free software, even if you're not the original author:
* Run an anon-CVS service for your working tree.
* Use a shared CVS server for your internal development.
* Fork the software and competely reorganise the sources even though
the original author hates you for it.
* Take over maintenance after the original author has died, been
bought, lost access to the 'net or whatever, and completely reorganise
the source tree.
* Copy parts of the software into another program (unfortunately we
don't have complete ability to do this anyway, at the moment).
* Repackage the original source package into a different distribution
format (eg, better archive utility, better compression program,
whatever).
None of these things can be done if the licence takes full advantage
of the DFSG1 patch clause.
It might be possible to write a wording for an exception, to allow a
requirement that distribution of modified versions be accompanied by
distribution of the original source code. Such an exception wouldn't
initially greatly impede the activities I mention above, but would
make distribution of the source on CD (for example) excessively bulky
after a while. Imagine if for every program you'd taken some code
from you had to supply a complete source archive of that program; with
increasing code reuse the amount of source being distributed would
quickly become unreasonable.
Also, any such exception would have to be written very carefully so
that (eg) CVS servers are still allowed.
All in all, it is better not to have the exception at all.
C. Why the limitations on the advertising clause exception (3.i) ?
Richard Stallman has written an excellent article about this subject,
The BSD License Problem, <URL:http://www.fsf.org/philosophy/bsd.html>.
In summary, the so-called `obnoxious BSD advertising clause', while
fine for the distribution of a single package, makes advertising a
program or operating system which may have thousands of contributors a
real problem (if the clause is enforced).
New free software should not contain this clause. In deference to the
body of existing software with this clause, and also out of practical
motives, software with this clause in a `legacy' licence is
permitted.
The clause is less of a problem in old software than in new software,
because in the past there were only a handful of copyright holders
whose names appear on such licences and which are therefore required
to appear in advertising.
D. Future exceptions
It is expected that the Debian developers may choose to add additional
kinds of permitted restriction to the list in section 3. This is
likely to happen if software with such a restriction is encountered,
or a free software author approaches the project about the matter, but
in any case only if the restriction would not obstruct the use,
development and distribution of free software.
Index: dfsg2.text
===================================================================
RCS file: /usr/src/CVS/chiark-misc/dfsg2.text,v
retrieving revision 1.2
retrieving revision 1.4
diff -u -r1.2 -r1.4
--- dfsg2.text 1998/11/23 14:58:14 1.2
+++ dfsg2.text 1998/11/27 02:47:09 1.4
@@ -1,14 +1,30 @@
- DRAFT
- $Id: dfsg2.text,v 1.2 1998/11/23 14:58:14 ian Exp $
- Debian Free Software Guidelines
+ DRAFT
+ $Id: dfsg2.text,v 1.4 1998/11/27 02:47:09 ian Exp $
+ Debian Free Software Guidelines
version 2
- DRAFT
+ DRAFT
-This document describes what the Debian Project considers free
+0. Purpose
+
+(a) This document describes what the Debian Project considers free
software. Only free software is part of Debian, as described in
Debian's Social Contract. The term `DFSG-free' will be used to mean
`free software according to the Debian Free Software Guidelines'.
+(b) The purpose of the Debian Free Software Guidelines is to ensure
+that software which is part of Debian can be freely used, distributed,
+and maintained, so that copyright problems and other legal
+restrictions play as little a part as possible in the technical
+development of Debian and the software packages which make it up.
+
+(c) The DFSG are written not just to ensure that the Debian Project
+can do with the software the things that we, our users, and our
+distributors, want or need to do. They are also intended to ensure
+that any third party free software developer can, given a piece of
+software from Debian, do all the things that they might reasonably
+expect to do with it in order to use and further develop free
+software.
+
1. Licence
DFSG-free works are either in the public domain, or come with a
@@ -20,9 +36,9 @@
(b) The source code must be available.
-(c) Anyone must be permitted to distribute it in its original form and
-in modified forms, both as source code and as executables, on its own
-or together with other works.
+(c) Anyone must be permitted to distribute it in whole or part, in its
+original form or in modified forms, both as source code and/or as
+executables, on its own or together with other works.
(d) Anyone must be permitted to reverse-engineer it.
@@ -52,9 +68,9 @@
ii. The licence allows the distributor of executables to offer to
distribute the source code instead of actually distributing it. The
licence
- (1) may require the offer to be in writing
- (2) may specify some minimum length of validity of the offer (not
- more than 3 years)
+ (1) may require the offer to be in writing;
+ (2) may require that the offer remain valid for some specified
+ period of time (not more than 3 years);
(3) may require the offer to be open to all third parties.
(b) Requirement for onward distribution to use particular licence
@@ -85,7 +101,7 @@
resulting whole work (or part of it) is distributed.
(The licence may not make any requirements about other works or data
-that are distributed as separate works but is merely distributed on
+that are distributed as separate works but are merely distributed on
the same disk, tape, network site, or whatever.)
(e) Restrictions on misrepresentation
@@ -109,12 +125,12 @@
binding, and that there is no suggestion that failing to honour the
request is unethical or immoral.
-(h) Changed name or version number for modified version
+(h) Different name or version number for certain version
-The licence may require modified versions to be distributed under a
-different name or with a different version number, provided that this
-doesn't interfere with using the modified version as a replacement for
-the original.
+The licence may require the work to be distributed under a different
+name or with a different version number under some circumstances
+defined in the licence, provided that this doesn't interfere with
+using the modified version as a replacement for the original.
(i) Advertising restriction (deprecated)
@@ -128,25 +144,64 @@
restriction.
This exception is likely to be removed in a future version of these
-guidelines.
+guidelines. For rationale, see Appendix C.
+
+4. Documentation and other non-software works
+
+Certain kinds of documentation or other non-software works may have
+further restrictions.
+
+(a) None of the exceptions listed in this section apply to a work
+which is documentation for software. Documentation for software is
+documentation to which a conscientious programmer would wish to make
+corresponding changes when they modify the software.
+
+(b) A document which states an opinion, as an opinion, need not be
+modifiable.
+
+(c) The licence for a document which specifies a standard of some kind
+(for example a Standards Track RFC) need not be modifiable, provided
+that the licence still permits the creation and distribution of
+modified versions, for at least the purposes of developing new
+standards, according to the procedures for the standards process in
+question.
+
+(d) An artwork which is expressive and not functional need not be
+modifiable.
-4. Restrictions due to law
+(e) When we say that a work need not be modifiable, we mean that
+restrictions may be placed on:
-(a) If in a particular jurisdiction the distribution, modification or
-use of a work is restricted by law, then the work is not
-DFSG-free in that jurisdiction.
+ i. the creation and/or distribution of modified versions;
-(b) It is still DFSG-free in other jurisdictions, provided that those
-who control (directly or indirectly) the work and the conditions under
-which it is distributed, do not have the power to lift the
+ ii. the distribution of parts of the work, rather than the whole;
+
+ iii. distribution of the source code, if this is different from the
+form of the work usually distributed (and, we also mean that the
+source code need not be available); and
+
+ iv. reverse-engineering.
+
+5. Restrictions due to law
+
+(a) If in a particular jurisdiction any of the activities mentioned in
+section 1 are restricted by law, then the work is not DFSG-free in
+that jurisdiction. However, legal restrictions which would apply to
+any work which has the same general nature as the work in question do
+not prevent a work from being DFSG-free.
+
+(b) A work is still DFSG-free in other jurisdictions, provided that
+those who control (directly or indirectly) the work and the conditions
+under which it is distributed, do not have the power to lift the
restrictions other than by changing the nature of the work, and
express a desire that the legal restrictions be lifted.
-(c) In the case of restrictions due to patents, a work can in any case
-not be DFSG-free if those who control the work and the conditions
-under which it is distributed are software patent aggressors.
+(c) In the case of restrictions due to patents, the work can in any
+case not be DFSG-free if any of those who control the work and the
+conditions under which it is distributed are software patent
+aggressors.
-5. Glossary
+6. Glossary
In these guidelines:
@@ -159,3 +214,110 @@
(c) A software patent aggressor is a person or organisation who
enforces patents against software patent nonaggressor(s), with respect
to infringement by software, or profits from such enforcement.
+
+APPENDICES AND RATIONALE
+
+A. Why is a change from DFSG1 necessary ?
+
+The current DFSG (version 1) have a number of problems.
+
+Its most serious problem is that they are far too vague. Very often a
+new copyright licence is brought up on one of the Debian mailing
+lists, and a long discussion ensues. These discussions usually hinge
+on trying to guess the meaning of the text of the DFSG.
+Unfortunately, the DFSG1 are not sufficiently clear, precise or
+self-consistent for this to work well.
+
+Another problem with DFSG1 is that they state that certain
+restrictions make software not DFSG-free, rather than listing the
+permitted restrictions. The effect of this is that when a novel but
+unhelpful licence is compared with the DFSG1, it is often found to
+meet the letter of the guidelines despite the fact that its licence
+has unreasonable restrictions for free software.
+
+The combination of these two effects mean that Debian developers are
+tempted towards `creative' interpretations of the DFSG - for example,
+involving the `no discrimination against fields of endeavour' clause.
+This can only lead to flamewars, an appearance of arbitrariness, and
+the unwise inclusion or exclusion of software.
+
+Finally, the free software community is now encountering a number of
+individuals and organisations who would like to give away as little
+freedom as possible. The DFSG1 were not written to withstand hostile
+interpretation. In the current climate it is necessary to have
+guidelines whose interpretation is clear, and which cannot easily be
+bent or subverted.
+
+B. Why are `modifications as patch only' licenses not allowed ?
+
+(DFSG1 paragraph 4 `Integrity of The Author's Source Code' allows a
+licence to require that modifications be distributed only as original
+sources plus patches. The DFSG2 do not allow this. Here is why.)
+
+The following examples are things you should be legally able to do
+with free software, even if you're not the original author:
+
+* Run an anon-CVS service for your working tree.
+
+* Use a shared CVS server for your internal development.
+
+* Fork the software and competely reorganise the sources even though
+the original author hates you for it.
+
+* Take over maintenance after the original author has died, been
+bought, lost access to the 'net or whatever, and completely reorganise
+the source tree.
+
+* Copy parts of the software into another program (unfortunately we
+don't have complete ability to do this anyway, at the moment).
+
+* Repackage the original source package into a different distribution
+format (eg, better archive utility, better compression program,
+whatever).
+
+None of these things can be done if the licence takes full advantage
+of the DFSG1 patch clause.
+
+It might be possible to write a wording for an exception, to allow a
+requirement that distribution of modified versions be accompanied by
+distribution of the original source code. Such an exception wouldn't
+initially greatly impede the activities I mention above, but would
+make distribution of the source on CD (for example) excessively bulky
+after a while. Imagine if for every program you'd taken some code
+from you had to supply a complete source archive of that program; with
+increasing code reuse the amount of source being distributed would
+quickly become unreasonable.
+
+Also, any such exception would have to be written very carefully so
+that (eg) CVS servers are still allowed.
+
+All in all, it is better not to have the exception at all.
+
+C. Why the limitations on the advertising clause exception (3.i) ?
+
+Richard Stallman has written an excellent article about this subject,
+The BSD License Problem, <URL:http://www.fsf.org/philosophy/bsd.html>.
+
+In summary, the so-called `obnoxious BSD advertising clause', while
+fine for the distribution of a single package, makes advertising a
+program or operating system which may have thousands of contributors a
+real problem (if the clause is enforced).
+
+New free software should not contain this clause. In deference to the
+body of existing software with this clause, and also out of practical
+motives, software with this clause in a `legacy' licence is
+permitted.
+
+The clause is less of a problem in old software than in new software,
+because in the past there were only a handful of copyright holders
+whose names appear on such licences and which are therefore required
+to appear in advertising.
+
+D. Future exceptions
+
+It is expected that the Debian developers may choose to add additional
+kinds of permitted restriction to the list in section 3. This is
+likely to happen if software with such a restriction is encountered,
+or a free software author approaches the project about the matter, but
+in any case only if the restriction would not obstruct the use,
+development and distribution of free software.
--
To UNSUBSCRIBE, email to debian-devel-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org