Draft Debian Position Statement about the GNU Free Documentation License(GFDL)
Social Contract
DFSG
DFSG FAQ
GFDL v1.2
An Annotated GFDL
Practical Problems with the GFDL
Survey on debian-legal
Related Links
Draft Debian Position Statement about the GNU Free Documentation License(GFDL)
This document is being put together to attempt to address some
concerns that members of the Debian legal team have about the
GNU Free Documentation License. This document attempts to
present the reasoning behind the conclusion that the GNU FDL
is not regarded as a license that can easily satisfy the
Debian Free Software Guidelines. The intention is to craft
a document that can be presented to the project
membership as a statement that can be issued under section
4.1.5 of the Debian constitution (the developers may issue
such position statements using the general resolution
protocol). Please note that only the first part of this
document shall be issued as the position statement — the
Contributions and Support Documents
section is
auxiliary, and it shall not be part of the position statement
issued by the project.
Introduction
Beginning in 2001, concerns regarding the compatibility of
the
GNU
Free Documentation License
with the
Debian
Free Software Guidelines
came to the attention of the
debian-legal mailing list.
In early 2002, the Free Software Foundation announced that
it would be revising the GNU FDL and producing a new
version, issued a draft, and solicited feedback from the
community.
Towards the end of 2002, the FSF released version 1.2 of the
GNU FDL, but their new version did not address several of
the DFSG-related concerns of the Debian Project. An
additional year's worth of discussions with representatives
of the FSF did not persuade the Debian Project that its
interpretation of the license or its own guidelines are
incorrect; neither did they persuade the FSF that
substantial alteration of the FDL's terms were warranted.
The problems with the GFDL fall into three major categories,
which are treated in detail below.
The
DRM
restriction
Section 2 (VERBATIM COPYING) of the GFDL goes beyond the
traditional source requirement in copyleft licenses in an
important way: according to the GFDL
no
copy may ever be subject to "
technical measures to
obstruct or control
" reading and copying. This means
that:
It is not limited to the act of distribution (i.e., it applies to
private copies as well).
It rules out the possibility that a version be distributed
on some form of DRM media (for technical reasons,
perhaps), even while providing source (i.e., a transparent
copy) in an unencumbered way at the same time.
As written, it would outlaw actions like changing the
permission of a copy of the document on your machine,
storing it on an encrypted file system, distributing a
copy over an encrypted link (
Obstruct or control the
reading
is not clarified to apply merely to the
recipient), or even storing it on a file-sharing system
with non-world-readable permissions.
Consider that the GFDL currently prohibits distribution on
DRM media, as compared to the GPL which requires
distribution on non-DRM media. This is a serious additional
restriction.
Transparent and Opaque copies
Section 3 (Copying in Quantity) of the GFDL states that it
is not enough to just put a transparent copy of a document
alongside with the opaque version when you are distributing
it (which is all that you need to do for sources under the
GPL, for example). Instead, the GFDL insists that you must
somehow
include a machine-readable Transparent
copy
(i.e., not allow the opaque form to be
downloaded without the transparent form) or keep the
transparent form available for download at a publicly
accessible location for one year
after
the
last distribution of the opaque form.
It is our belief that as long as you make the source and
binaries available so that the users can see what's
available and take what they want, you have done what is
required of you. It is up to the user whether to download
the transparent form.
This is a paraphrase from the GPL
FAQ
The requirements for redistributors should be to make sure the
users can get the transparent form, not to force users to
download the transparent form even if they don't want it.
Invariant Sections
This is the most troublesome part of the GFDL.
The GNU FDL includes a number of conditions that apply to
all modified versions that disallow modifications.
Specifically, Section 4 of the GFDL describes the invariant
sections that must be
unaltered in their text and in
their titles
in any derived works. These invariant
sections must be
secondary sections
; a
secondary sections is a named appendix or a
front-matter section of the Document that deals exclusively
with the relationship of the publishers or authors of the
Document to the Document's overall subject (or to related
matters) and contains nothing that could fall directly
within that overall subject.
. These parts include:
Invariant Sections
Cover Texts
Acknowledgements
Dedications
However, modifiability is a fundamental requirement of the
Debian Free Software Guidelines, which state:
3. Derived Works
The license must allow modifications and derived works, and
must allow them to be distributed under the same terms as the
license of the original software.
As such, we cannot accept works that include "
Invariant
Sections
" and similar unmodifiable components into our
distribution.
In addition to the simple restrictions of freedoms imposed by the
Invariant Sections, they also cause practical problems:
Incompatibility with the GPL. It's GPL-incompatible in
both directions. This means that you can't legally extract
text from a GFDL'ed manual and put it into integrated help
strings in a GPL'ed program. And you can't extract code or
comments from a GPL'ed program and put it into a GFDL'ed
manual. (Without getting explicit permission to relicense
from every copyright-holding contributor, that is.)
Being forced to retain inaccurate Invariant Sections (or
Cover Texts, or Dedications).
Being forced to retain obsolete Invariant Sections (or
Cover Texts, or Dedications). Dated invariant sections
would exacerbate this problem.
Possibility of obsolescence, via changes in technologies
(such as the disappearance of printed matter, or the
particulars of file formats and access restrictions).
Being forced to retain technically inappropriate Invariant
Sections or Cover Texts, etc.
Being forced to retain Invariant Sections even in
extremely space-tight environments (such as a rescue
disks, reference card, PDA's, or embedded devices).
Being forced to retain untranslated Invariant Sections in
a translation.
Being unable to use material from the document for a new
document whose primary topic is that of an Invariant
Section (because the Invariant Section must be retained,
and must be Secondary, but would no longer be
Secondary). This issue, where it can be very difficult or
impossible to repurpose chunks (eg copy a chapter about
regular expressions when one copies the just the regexp
code), is a significant degradation of freedom.
Invariant Section "bloat". The natural response to
several of the above problems is to add new Invariant
Sections, saying "I think the old Invariant Section is
inaccurate/obsolete/offensive" or "This is a translation
of the old Invariant Section". These will accumulate and
will also be non-removable.
Difficulty in modifying invariant sections of GFDLed
documents not under unified central control (need
permission from many contributors or their estates/agents,
which becomes more difficult with time).
There is some concern that the requirements to list the
authors of the modification on the title page and the
history sections of the GFDL covered work (especially since
these sections are otherwise invariant) appear to prohibit
anonymous modifications to a document. (This may fail the
Dissident Test
).
Freedoms for Documentation
Analogous to the software program freedoms, we need to
articulate the freedoms required for the subset of
software called documentation.
The freedom to read the text, for any purpose.
The freedom to study how the text is written, and adapt
it to your needs. Access to the text in the preferred
form for modification is a precondition for this. This
includes the ability to modify the work to fit in low
memory situations, reference cards, PDA's, embedded
devices, etc.
Freedom to reformat the document into a preferred format
or medium (converting to braille, or speech, or
hardcopy, or postscript, etc).
The freedom to redistribute copies so you can help your neighbor.
The freedom to improve the text, and release your
improvements to the public, so that the whole community
benefits. Access to the preferred form for modification
is a precondition for this. For program documentation,
this implies being able to change the documentation to
reflect the changes in the program.
Freedom to translate the text into any other language.
The freedom to keep your modifications, or even your
possession of a copy of the text, confidential.
Conclusion
It is not possible to borrow text from a GFDL'd manual and
incorporate it in any free software program whatsoever.
This is not a mere license incompatibility. It's not just
that the GFDL is incompatible with this or that free
software license: it's that it is fundamentally incompatible
with
any
free software license whatsoever.
So if you write a new program, and you have no commitments
at all about what license you want to use, saving only that
it be a free license, you cannot include GFDL'd text.
The GNU FDL, as it stands today, does not meet the Debian
Free Software Guidelines. There are significant problems
with the license, as detailed above; and, as such, we
cannot accept works licensed unde the GNU FDL into our
distribution.
Contributions and Support documents
The following are comments by Branden Robinson:
Beginning in 2001, concerns regarding the compatibility of
the
GNU
Free Documentation License
with the
Debian
Free Software Guidelines
came to the attention of the
debian-legal mailing list. (A version of the
word diff
between versions 1.1 and 1.2 of the GFDL may make for
easier reading -- Steven Augart).
In early 2002, the Free Software Foundation announced that
it would be revising the GNU FDL and producing a new
version, issued a draft, and solicited feedback from the
community.
Towards the end of 2002, the FSF released version 1.2 of the
GNU FDL, but their new version did not address several of
the DFSG-related concerns of the Debian Project. An
additional year's worth of discussions with representatives
of the FSF did not persuade the Debian Project that its
interpretation of the license or its own guidelines are
incorrect; neither did they persuade the FSF that
substantial alteration of the FDL's terms were warranted.
Unfortunately, most of this discussion has been confined to
the debian-legal mailing list, with the result that people
like me who do not follow debian-legal are not aware of the
situation, and, for the most part, do not know the details of the
issue involved.
If the concerns of the people on debian-legal are shared by
the developer body at large, we may have a potentially
serious issue. The first step to determine this is making
people aware of the issues involved. The next would be to
see if we can reach a determination of the position the
project at large want to take on this issue.
Having a common position for the project on this issue would
also help in trying to resolve the concerns; having a common
voice, and knowing what the project wishes to do about
packages that ship with GFDL licensed material would help
our representative to better project Debian's position.
This is the reason for this document; it encapsulates the
concerns that Debian folks have raised over in
debian-legal, along with an annotated version of the
GFDL. I have tried to be inclusive, and have incorporated
in this one document all the concerns that have been
voiced by various people on debian-legal. This is a work
in progress, it is meant to be discussed and modified by
the developer body. It needs to be integrated into a
coherent position statement, and the polish that it
currently lacks needs to be remedied.
At this stage, I have distinguished between my commentary
(which has largely not been honed in a discussion), and
mature commentary from mavens on debian-legal; and I have
attributed each contributor separately. Over time, I hope to
use this document as the basis for crafting a common
position statement by the developers, which we can issue
under section 4.1.5 of the
Debian
Constitution
I need your help to create and refine this position statement.
Overview
The problems with the GFDL fall into three major categories.
The "DRM" restriction
Transparent and Opaque copies
Invariant Sections
Annotated
GNU Free Documentation License
GNU Free Documentation License
Version 1.2, November 2002
Copyright (C) 2000,2001,2002 Free Software Foundation, Inc.
59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
Everyone is permitted to copy and distribute verbatim copies
of this license document, but changing it is not allowed.
0. PREAMBLE
The purpose of this License is to make a manual, textbook,
or other functional and useful document "free" in the sense
of freedom: to assure everyone the effective freedom to copy
and redistribute it, with or without modifying it, either
commercially or noncommercially. Secondarily, this License
preserves for the author and publisher a way to get credit
for their work, while not being considered responsible for
modifications made by others.
This License is a kind of "copyleft", which means that
derivative works of the document must themselves be free in
the same sense. It complements the GNU General Public
License, which is a copyleft license designed for free
software.
We have designed this License in order to use it for manuals
for free software, because free software needs free
documentation: a free program should come with manuals
providing the same freedoms that the software does. But
this License is not limited to software manuals; it can be
used for any textual work, regardless of subject matter or
whether it is published as a printed book. We recommend
this License principally for works whose purpose is
instruction or reference.
1. APPLICABILITY AND DEFINITIONS
This License applies to any manual or other work, in any
medium, that contains a notice placed by the copyright
holder saying it can be distributed under the terms of this
License. Such a notice grants a world-wide, royalty-free
license, unlimited in duration, to use that work under the
conditions stated herein. The "Document", below, refers to
any such manual or work. Any member of the public is a
licensee, and is addressed as "you". You accept the license
if you copy, modify or distribute the work in a way
requiring permission under copyright law.
A "
Modified Version
" of the Document means any work
containing the Document or a portion of it, either copied
verbatim, or with modifications and/or translated into
another language.
A "
Secondary Section
" is a named appendix or a
front-matter section of the Document that deals exclusively
with the relationship of the publishers or authors of the
Document to the Document's overall subject (or to related
matters) and contains nothing that could fall directly
within that overall subject. (Thus, if the Document is in
part a textbook of mathematics, a Secondary Section may not
explain any mathematics.) The relationship could be a
matter of historical connection with the subject or with
related matters, or of legal, commercial, philosophical,
ethical or political position regarding them.
Matthew Garrett Notes:
While not a Freeness issue, it should be noted that gdb at
one point included sections marked as secondary that did
not fit these criteria. Though possibly unsurprising that
a complicated license may be misused in the early days
before it is well understood, the fact that GNU could make
such mistakes suggests that many GFDL works may end up
with invalid licensing terms.
There is also evidence that people are using invariant
sections in a manner not envisaged by the authors of the
GFDL: Look at
Ralf Hildebrandt: /~hildeb/postfix/postfix_sobigf.shtml
with the following license statement:
Permission is granted to copy and/or distribute this
document under the terms of the GNU Free Documentation
License, Version 1.1 or any later version published by
the Free Software Foundation; with the Invariant
Sections being
THE WHOLE DOCUMENT
(each
section is invariant). No Front- or Back-Cover Texts are
provided.
Back to the GFDL:
The "
Invariant Sections
" are certain Secondary
Sections whose titles are designated, as being those of
Invariant Sections, in the notice that says that the
Document is released under this License. If a section does
not fit the above definition of Secondary then it is not
allowed to be designated as Invariant. The Document may
contain zero Invariant Sections. If the Document does not
identify any Invariant Sections then there are none.
The "
Cover Texts
" are certain short passages of
text that are listed, as Front-Cover Texts or Back-Cover
Texts, in the notice that says that the Document is released
under this License. A Front-Cover Text may be at most 5
words, and a Back-Cover Text may be at most 25 words.
A "
Transparent
" copy of the Document means a
machine-readable copy, represented in a format whose
specification is available to the general public, that is
suitable for revising the document straightforwardly with
generic text editors or (for images composed of pixels)
generic paint programs or (for drawings) some widely
available drawing editor, and that is suitable for input to
text formatters or for automatic translation to a variety of
formats suitable for input to text formatters. A copy made
in an otherwise Transparent file format whose markup, or
absence of markup, has been arranged to thwart or discourage
subsequent modification by readers is not Transparent. An
image format is not Transparent if used for any substantial
amount of text. A copy that is not "
Transparent
is called "
Opaque
".
Matthew Garrett Notes:
Awkward. Even if the Microsoft Word file format was well
described, it would not be modifiable in a "
generic text
editor
". The GPL requires distribution of source in
"The preferred format for modification" - the GFDL limits
what that preferred form may be. The lack of definition of
copy
" here makes things unclear - if my only
source is a formatted Word document, does a plain text
output of the contents qualify as a transparent version?
Without clarification, this may prevent certain types of
derivative work being produced, which would be a violation
of
DFSG
3.
Anthony DeRobertis elucidates:
You missed the requirement to include transparent copies
(more on that later -ms). You have used MS Word as the
problem with the definition of transparent sections. More
interesting ones are OpenOffice and Lyx. Also, music is
interesting, too.
Back to the GFDL:
Examples of suitable formats for Transparent copies include
plain ASCII without markup, Texinfo input format, LaTeX
input format, SGML or XML using a publicly available DTD,
and standard-conforming simple HTML, PostScript or PDF
designed for human modification. Examples of transparent
image formats include PNG, XCF and JPG. Opaque formats
include proprietary formats that can be read and edited only
by proprietary word processors, SGML or XML for which the
DTD and/or processing tools are not generally available, and
the machine-generated HTML, PostScript or PDF produced by
some word processors for output purposes only.
The "
Title Page
" means, for a printed book, the
title page itself, plus such following pages as are needed
to hold, legibly, the material this License requires to
appear in the title page. For works in formats which do not
have any title page as such, "
Title Page
" means the
text near the most prominent appearance of the work's title,
preceding the beginning of the body of the text.
A section "
Entitled XYZ
" means a named subunit of
the Document whose title either is precisely XYZ or contains
XYZ in parentheses following text that translates XYZ in
another language. (Here XYZ stands for a specific section
name mentioned below, such as "
Acknowledgements
",
Dedications
", "
Endorsements
", or
History
".) To "
Preserve the Title
" of
such a section when you modify the Document means that it
remains a section "
Entitled XYZ
" according to this
definition.
The Document may include Warranty Disclaimers next to the
notice which states that this License applies to the
Document. These Warranty Disclaimers are considered to be
included by reference in this License, but only as regards
disclaiming warranties: any other implication that these
Warranty Disclaimers may have is void and has no effect on
the meaning of this License.
The following is from Jeremy Hankins:
Various parts of a work under the GFDL can be both
unmodifiable and non-removable. These parts include:
Invariant Sections
Cover Texts
Acknowledgements
Dedications
We believe that certain restrictions on modification do pass
the
DFSG
. Such restrictions might include a requirement
that the name be changed from the original when it is
modified, or that a disclaimer be added (e.g., "This
document does not necessarily represent the opinion of
Mr. Foo"), or even that a changelog be kept. But in this
case both the fact that these sections are entirely
unmodifiable and that they are non-removable violate the
DFSG
Back to the GFDL:
2. VERBATIM COPYING
You may copy and distribute the Document in any medium,
either commercially or noncommercially, provided that this
License, the copyright notices, and the license notice
saying this License applies to the Document are reproduced
in all copies, and that you add no other conditions
whatsoever to those of this License. You may not use
technical measures
to obstruct or
control the reading or further copying of the copies you
make or distribute. However, you may accept compensation
in exchange for copies. If you distribute a large enough
number of copies you must also follow the conditions in
section 3.
The following is from Jeremy Hankins:
This goes beyond the traditional source requirement in
copyleft licenses in an important way: according to the GFDL
no
copy may ever be subject to
technical measures to obstruct or control
" reading
and copying. This means that:
It is not limited to the act of distribution (i.e., it applies to
private copies as well).
It rules out the possibility that a version be distributed
on some form of DRM media (for technical reasons,
perhaps), even while providing source (i.e., a transparent
copy) in an unencumbered way at the same time.
Matthew Garrett notes:
One of the big issues. Note "
Make or distribute
".
chmod a-r
'ing a GFDLed document that you have
downloaded could be against this term, as could distributing
a copy over an encrypted link ("
Obstruct or control the
reading
" is not clarified to apply merely to the
recipient).
Nathanael Nerode comments:
This was intended to attack DRM systems, but it is far too
broad. It applies to private copies made and not
distributed. "
Technical measures
" is not defined. The
natural interpretation includes activities like encrypting a
copy, storing it on an encrypted file system, or even storing
it on a file-sharing system with non-world-readable
permissions. This is evidently not free.
Hopefully the FSF will fix this some time -- in my opinion,
replacing "
make or distribute
" with "
make and
distribute
" would be a good start.
Responses to some of these concerns
In a reply to Josselin Mouette's message mentioning
restrictions on storing it on an encrypted file system,
Richard Stallman
said
That's a new one on me. I don't think the GFDL restricts
the use of encrypted file systems.
He further
clarified
the reason for this.
This means that you cannot publish them under DRM systems
to restrict the possessors of the copies. It isn't
supposed to refer to use of encryption or file access
control on your own copy.
I will talk with our lawyer and see if that sentence needs
to be clarified.
However, he has
declined
to comment on the changes that are being contemplated.
I've decided not to do that. The development of GNU
licenses is not a Debian issue.
The issue of outright banning DRM mechanisms remains a
concern. It has been argued that by itself it is a
violation of the DFSG.
Andrew Suffield comments:
Consider that the GFDL currently prohibits distribution on
DRM media, as compared to the GPL which requires
distribution on non-DRM media. I consider the GFDL to
have gone too far.
Back to the GFDL:
You may also lend copies, under the same conditions stated
above, and you may publicly display copies.
3. COPYING IN QUANTITY
If you publish printed copies (or copies in media that
commonly have printed covers) of the Document, numbering
more than 100, and the Document's license notice requires
Cover Texts, you must enclose the copies in covers that
carry, clearly and legibly, all these Cover Texts:
Front-Cover Texts on the front cover, and Back-Cover Texts
on the back cover. Both covers must also clearly and
legibly identify you as the publisher of these copies. The
front cover must present the full title with all words of
the title equally prominent and visible. You may add other
material on the covers in addition. Copying with changes
limited to the covers, as long as they preserve the title of
the Document and satisfy these conditions, can be treated as
verbatim copying in other respects.
Matthew Garrett notes:
This does apply to CDs as well, as they're considered to
have covers. However, section 7 prevents this from being an
extra issue with aggregated works.
Back to the GFDL:
If the required texts for either cover are too voluminous to
fit legibly, you should put the first ones listed (as many
as fit reasonably) on the actual cover, and continue the
rest onto adjacent pages.
If you publish or distribute Opaque copies of the Document
numbering more than 100, you must either include a
machine-readable
Transparent
copy
along with each Opaque copy, or state in or with
each Opaque copy a computer-network location from which
the general network-using public has access to download
using public-standard network protocols a complete
Transparent copy of the Document, free of added material.
If you use the latter option, you must take reasonably
prudent steps, when you begin distribution of Opaque
copies in quantity, to ensure that this Transparent copy
will remain thus accessible at the stated location until
at least one year after the last time you distribute an
Opaque copy (directly or through your agents or retailers)
of that edition to the public.
The following is from Jeremy Hankins:
Under certain circumstances the document may not have a
transparent version (for example, after being modified with
a proprietary word processor). This would make it
impossible to meet the requirements of section 3 ("Copying
in quantity") of the GFDL.
Anthony DeRobertis adds:
The perceived problem is this: Let's say I want to put a
GFDL document on my FTP site, in an opaque form. My FTP
site is popular, so it will distribute copies numbering
more than 100.
I think its reasonable that if I just put a transparent
form alongside the PDF, that should be all I have to
do. Instead, the GFDL seems to read that I must somehow
"include a machine-readable Transparent copy" (i.e., not
allow the opaque form to be downloaded without the
transparent form) or keep the transparent form available
for (forgive me if I'm mistaken about the time) one year.
Basically, the problem is if the answer to
this
question
from the GPL FAQ applies to the GFDL as well.
Back to the GFDL:
It is requested, but not required, that you contact the
authors of the Document well before redistributing any large
number of copies, to give them a chance to provide you with
an updated version of the Document.
4. MODIFICATIONS
You may copy and distribute a Modified Version of the
Document under the conditions of sections 2 and 3 above,
provided that you release the Modified Version under
precisely this License, with the Modified Version filling
the role of the Document, thus licensing distribution and
modification of the Modified Version to whoever possesses a
copy of it. In addition, you must do these things in the
Modified Version:
A.
Use in the Title Page (and on the covers, if any) a title
distinct from that of the Document, and from those of
previous versions (which should, if there were any, be
listed in the History section of the Document). You may
use the same title as a previous version if the original
publisher of that version gives permission.
Matthew Garrett notes:
A restriction, but free under
DFSG
4.
Back to the GFDL:
B.
List on the Title Page, as authors, one or more persons or
entities responsible for authorship of the modifications
in the Modified Version, together with at least five of
the principal authors of the Document (all of its
principal authors, if it has fewer than five), unless they
release you from this requirement.
C.
State on the Title page the name of the publisher of the
Modified Version, as the publisher.
D.
Preserve all the copyright notices of the Document.
E.
Add an appropriate copyright notice for your
modifications adjacent to the other copyright notices.
F.
Include, immediately after the copyright notices, a
license notice giving the public permission to use the
Modified Version under the terms of this License, in the
form shown in the Addendum below.
G.
Preserve in that license notice the full lists of
Invariant Sections
and required
Cover Texts given in the Document's license notice.
H.
Include an unaltered copy of this License.
I.
Preserve the section Entitled "
History
", Preserve
its Title, and add to it an item stating at least the
title, year, new authors, and publisher of the Modified
Version as given on the Title Page. If there is no
section Entitled "History" in the Document, create one
stating the title, year, authors, and publisher of the
Document as given on its Title Page, then add an item
describing the Modified Version as stated in the previous
sentence.
J.
Preserve the network location, if any, given in the
Document for public access to a Transparent copy of the
Document, and likewise the network locations given in
the Document for previous versions it was based on.
These may be placed in the "History" section. You may
omit a network location for a work that was published at
least four years before the Document itself, or if the
original publisher of the version it refers to gives
permission.
K.
For any section Entitled "
Acknowledgements
" or
Dedications
", Preserve the Title of the section,
and preserve in the section all the substance and tone of
each of the contributor acknowledgements and/or
dedications given therein.
Matthew Garrett notes:
Unmodifiable content - fails
DFSG
4.
Anthony DeRobertis adds:
Clauses b and i above seem to prohibit anonymous
modifications to a document.
If
the requirements about
listing authors on the title page and the history require
an actual name, it seems this might fail the
Chinese
Dissident Test
Back to the GFDL:
L.
Preserve all the Invariant Sections of the Document,
unaltered in their text and in their titles. Section
numbers or the equivalent are not considered part of the
section titles.
Matthew Garrett notes:
Unmodifiable content - fails
DFSG
4.
Anthony Towns states:
The GNU FDL includes a number of conditions that apply to
all modified versions that disallow modifications,
particularly sections K and L above. However, modifiability
is a fundamental requirement of the Debian Free Software
Guidelines, which state:
3. Derived Works
The license must allow modifications and derived works, and
must allow them to be distributed under the same terms as the
license of the original software.
As such, we cannot accept works that include "
Invariant
Sections
" and similar unmodifiable components into our
distribution, which unfortunately includes a number of
current manuals for GNU software.
Thomas Bushnell, BSG, has posted the following
Thomas Bushnell, BSG, in an email
message
commented, in part:
It is not possible to borrow text from a GFDL'd manual and
incorporate it in any free software program whatsoever.
This is not a mere license incompatibility. It's not just
that the GFDL is incompatible with this or that free
software license: it's that it is fundamentally incompatible
with
any
free software license whatsoever.
So if you write a new program, and you have no commitments
at all about what license you want to use, saving only that
it be a free license, you cannot include GFDL'd text.
First, GFDL'd manuals can contain "invariant sections"
which cannot be changed or removed. This is a
restriction on modification which isn't permitted for
free software licenses. Moreover, it is not a trivial
restriction or one that imposes minimal costs.
Invariant sections can be very large, and the pieces of
a GFDL'd manual that one wants to copy might be small.
(For example, a description of how to use a single
function, if copied from the Emacs manual, requires the
inclusion of many kilobytes of extraneous text from
invariant sections.) Such restrictions are not allowed
in free software licenses.
Second, there are restrictions on what formats a GFDL'd
manual can be distributed in, which work to prohibit
encryption and the like. No such restriction exists for
free software licenses.
It seems to me that the desire to have these sections is to
piggy back political sections on to technical
documentation. In other words, there is a captive audience,
and since they need the documentation, they are being forced
to also accept political speeches with it. This does not sit
well with a project like Debian, since our charter includes
keeping in mind the needs of our users; and protecting users
from being forced to accept contents unrelated to the code
the manual is documenting seems to be in line with what we
do.
This is an expansion of something that Brian T Sniffen suggested
Analogous to the software programs freedoms, we need to
articulate the freedoms required for the subset of
software called documentation
The freedom to read the text, for any purpose.
The freedom to study how the text is written, and adapt
it to your needs. Access to the text in the preferred
form for modification is a precondition for this. This
includes the ability to modify the work to fit in low
memory situations, reference cards, PDA's, embedded
devices, etc.
Freedom to reformat the document into a preferred format
or medium (converting to braille, or speech, or
hardcopy, or postscript, etc).
The freedom to redistribute copies so you can help your neighbor.
The freedom to improve the text, and release your
improvements to the public, so that the whole community
benefits. Access to the preferred form for modification
is a precondition for this. For program documentation,
this implies being able to change the documentation to
reflect the changes in the program.
Freedom to translate the text into any other language (Esperanto,
Hindi, Icelandic).
The freedom to keep your modifications, or even your
possession of a copy of the text, confidential.
Back to the GFDL:
M.
Delete any section Entitled "
Endorsements
". Such
a section may not be included in the Modified Version.
Matthew Garrett notes:
Unmodifiable content - fails
DFSG
4, but can be removed so
that's not a problem.
Back to the GFDL:
N.
Do not retitle any existing section to be Entitled
Endorsements
" or to conflict in title with any
Invariant Section.
Matthew Garrett notes:
Fails
DFSG
4?
Back to the GFDL:
O.
Preserve any Warranty Disclaimers.
If the Modified Version includes new front-matter sections
or appendices that qualify as Secondary Sections and contain
no material copied from the Document, you may at your option
designate some or all of these sections as invariant. To do
this, add their titles to the list of Invariant Sections in
the Modified Version's license notice. These titles must be
distinct from any other section titles.
You may add a section Entitled "
Endorsements
",
provided it contains nothing but endorsements of your
Modified Version by various parties--for example, statements
of peer review or that the text has been approved by an
organization as the authoritative definition of a standard.
You may add a passage of up to five words as a Front-Cover
Text, and a passage of up to 25 words as a Back-Cover Text,
to the end of the list of Cover Texts in the Modified
Version. Only one passage of Front-Cover Text and one of
Back-Cover Text may be added by (or through arrangements
made by) any one entity. If the Document already includes a
cover text for the same cover, previously added by you or by
arrangement made by the same entity you are acting on behalf
of, you may not add another; but you may replace the old
one, on explicit permission from the previous publisher that
added the old one.
Matthew Garrett notes:
Restrictions on the contents of things that are
special
" under the license. This doesn't prevent
you from putting extra stuff on the front cover anyway, so
isn't a problem.
Back to the GFDL:
The author(s) and publisher(s) of the Document do not by
this License give permission to use their names for
publicity for or to assert or imply endorsement of any
Modified Version.
Nathanael Nerode notes:
Invariant Sections and related problems
The other problems with freeness lie in the rules on
Invariant Sections
", "
Cover Texts
",
Acknowledgements
", and "
Dedications
".
These are not modifiable, and
not even
removable
. First of all, the Invariant Sections
are clearly not freely modifiable themselves, which means
that
they
are not free in the "
free
software
" sense of the GPL. Since they are
Secondary Sections
", off-topic by definition, some
people may not care about that.
But Invariant Sections and Cover Texts constitute a
restriction on the modifiability of the technical material
-- the documentation -- in the GFDL-covered document,
because they can't be removed, ever. The documentation is
forever shackled to the Invariant Sections. This makes
documentation licensed under the GFDL with Invariant
Sections not free (in the sense of 'free software' as used
in the GPL).
Clearly not all restrictions on modification make a work
non-free; some are trivial. (The requirement to accompany
any version of the work with accurate copyright notices and
copies of the license, for instance, is a trivial
restriction). But this is not a trivial restriction; it is
a troublesome one for many reasons:
Being forced to retain inaccurate Invariant Sections (or
Cover Texts, or Dedications).
Being forced to retain obsolete Invariant Sections (or
Cover Texts, or Dedications).
Being forced to retain technically inappropriate Invariant
Sections or Cover Texts, etc. (I had been informed that
this had happened with the Wikipedia, but this is
apparently not correct.)
Being forced to retain Invariant Sections even in
extremely space-tight environments (such as a reference
card). (The President of the FSF has indicated that he
believes this would be satisfied by accompanying the
reference card with a "second volume" containing the
Invariant Sections. This is, however, a very questionable
interpretation of the text of the license.)
Being forced to retain untranslated Invariant Sections in
a translation.
Being unable to use material from the document for a new
document whose primary topic is that of an Invariant
Sections (because the Invariant Section must be retained,
and must be Secondary, but would no longer be
Secondary).
Invariant Section "bloat". The natural response to
several of the above problems is to add new Invariant
Sections, saying "I think the old Invariant Section is
inaccurate/obsolete/offensive" or "This is a translation
of the old Invariant Section". These will accumulate and
will also be non-removable.
Because the GFDL with Invariant Sections or Cover Texts is
non-free, the
Debian
project
is considering removing all manuals under such
licenses from Debian.
Beyond its non-free status, the GFDL has additional serious
practical problems:
It's
GPL-incompatible
in
both
directions
. This means that you can't legally
extract text from a GFDL'ed manual and put it into
integrated help strings in a GPL'ed program. And you
can't extract code or comments from a GPL'ed program and
put it into a GFDL'ed manual. (Without getting explicit
permission to relicense from every copyright-holding
contributor, that is.)
Please see
Nathanael
Nerode's page
for additional details.
Back to the GFDL:
5. COMBINING DOCUMENTS
You may combine the Document with other documents released
under this License, under the terms defined in section 4
above for modified versions, provided that you include in
the combination all of the Invariant Sections of all of the
original documents, unmodified, and list them all as
Invariant Sections of your combined work in its license
notice, and that you preserve all their Warranty
Disclaimers.
Matthew Garrett notes:
If I submit a patch to GCC including documentation with an
invariant section describing why "
Open Source
" is a
preferable term to "
Free Software
", the invariant
section must be included if my documentation is to be
used. Theoretically, this may not be an issue -
pragmatically, it results in a situation where a patch under
the same license as the original documentation cannot be
accepted (although in the gcc case I'd have to sign over the
copyright to the FSF, who could then remove the invariant
section).
Back to the GFDL:
The combined work need only contain one copy of this
License, and multiple identical Invariant Sections may be
replaced with a single copy. If there are multiple
Invariant Sections with the same name but different
contents, make the title of each such section unique by
adding at the end of it, in parentheses, the name of the
original author or publisher of that section if known, or
else a unique number. Make the same adjustment to the
section titles in the list of Invariant Sections in the
license notice of the combined work.
In the combination, you must combine any sections Entitled
History
" in the various original documents,
forming one section Entitled "
History
"; likewise
combine any sections Entitled "
Acknowledgements
",
and any sections Entitled "
Dedications
". You must
delete all sections Entitled "
Endorsements
."
6. COLLECTIONS OF DOCUMENTS
You may make a collection consisting of the Document and
other documents released under this License, and replace the
individual copies of this License in the various documents
with a single copy that is included in the collection,
provided that you follow the rules of this License for
verbatim copying of each of the documents in all other
respects.
You may extract a single document from such a collection,
and distribute it individually under this License, provided
you insert a copy of this License into the extracted
document, and follow this License in all other respects
regarding verbatim copying of that document.
7. AGGREGATION WITH INDEPENDENT WORKS
A compilation of the Document or its derivatives with other
separate and independent documents or works, in or on a
volume of a storage or distribution medium, is called an
aggregate
" if the copyright resulting from the
compilation is not used to limit the legal rights of the
compilation's users beyond what the individual works permit.
When the Document is included in an aggregate, this License
does not apply to the other works in the aggregate which are
not themselves derivative works of the Document.
If the Cover Text requirement of section 3 is applicable to these
copies of the Document, then if the Document is less than one half of
the entire aggregate, the Document's Cover Texts may be placed on
covers that bracket the Document within the aggregate, or the
electronic equivalent of covers if the Document is in electronic form.
Otherwise they must appear on printed covers that bracket the whole
aggregate.
8. TRANSLATION
Translation is considered a kind of modification, so you may
distribute translations of the Document under the terms of
section 4. Replacing Invariant Sections with translations
requires special permission from their copyright holders,
but you may include translations of some or all Invariant
Sections in addition to the original versions of these
Invariant Sections. You may include a translation of this
License, and all the license notices in the Document, and
any Warranty Disclaimers, provided that you also include the
original English version of this License and the original
versions of those notices and disclaimers. In case of a
disagreement between the translation and the original
version of this License or a notice or disclaimer, the
original version will prevail.
Matthew Garrett notes:
Requires a potentially large body of (say) English text in a
foreign version. Awkward, but not really an issue for Debian
due to it only applying to invariant sections.
Back to the GFDL:
If a section in the Document is Entitled
Acknowledgements
", "
Dedications
", or
History
", the requirement (section 4) to Preserve
its Title (section 1) will typically require changing the
actual title.
9. TERMINATION
You may not copy, modify, sublicense, or distribute the Document except
as expressly provided for under this License. Any other attempt to
copy, modify, sublicense or distribute the Document is void, and will
automatically terminate your rights under this License. However,
parties who have received copies, or rights, from you under this
License will not have their licenses terminated so long as such
parties remain in full compliance.
10. FUTURE REVISIONS OF THIS LICENSE
The Free Software Foundation may publish new, revised versions
of the GNU Free Documentation License from time to time. Such new
versions will be similar in spirit to the present version, but may
differ in detail to address new problems or concerns. See
Each version of the License is given a distinguishing
version number. If the Document specifies that a particular
numbered version of this License "or any later version"
applies to it, you have the option of following the terms
and conditions either of that specified version or of any
later version that has been published (not as a draft) by
the Free Software Foundation. If the Document does not
specify a version number of this License, you may choose any
version ever published (not as a draft) by the Free Software
Foundation.
Practical problems with the GFDL
: Barak Pearlmutter
incompatibility with the GPL.
not a full copyleft (because people can add invariant
sections thus distributing the document under terms more
restrictive than those imposed on the materials they
received)
lack of clarity (even debian-legal can't figure it all
out; even the FSF makes mistakes in labeling invariant
sections; even wikipedia used it incorrectly; even with
lots of helpful explanations from RMS himself there is
considerable lack of understanding on just what the GFDL
actually requires)
possibility of obsolescence, via dated invariant sections
possibility of obsolescence, via changes in technologies
(such as the disappearance of printed matter, or the
particulars of file formats and access restrictions)
difficulty in modifying invariant sections of GFDLed
documents not under unified central control (need
permission from many contributors or their estates/agents,
which becomes more difficult with time)
can be very difficult or impossible to repurpose chunks
(eg copy regexp chapter)
does not "lead by example" (if all software used
the GPL, all code would be freely available and sharable.
if all documentation used the GFDL, differences in
invariant sections and cover matter would impede sharing.
perhaps licenses should lead by example to the world we
all want: a world where sharing is always unimpeded)
is causing a lot of fighting and bad feeling between
people who have the same goal and who should be
cooperating and helping each other
Some of these do not impact the FSF in its productions of
manuals, due to the FSF's possession of copyright
assignments, and its ability to "break the rules"
as necessary. They would however affect more distributed
groups attempting to communally maintain software that
includes GFDL'ed documentation. They would even affect
groups that want to exchange & share materials despite
having highly divergent technical goals. As we all know,
one of the FSF's central tenets is that everyone should
have the right to modify and share. So it seems to me that
these issues may concern the FSF even if they do not
directly affect it.
Anthony DeRobertis adds:
Let's say that I fork a version of GCC. I think we all
agree this is allowed under the GPL, and, indeed has been
done in the past. I make significant changes.
Now, I need a manual for my new compiler fork. I naturally
look to the GNU's GCC manual. However, there are two
problems I see in particular:
The FSF's Front-Cover Text is:
A GNU Manual
The FSF's Back-Cover Text is:
You have freedom to copy and modify this GNU Manual,
like GNU software. Copies published by the Free
Software Foundation raise funds for GNU development.
I see this as a problem because my new manual has to
include false statements on the covers. It isn't a GNU
manual anymore, and the FSF certainly doesn't publish
copies. Putting "
A GNU Manual
" on the cover
would, I think, be a violation of Title 15,
Sec. 1125(a). So, as a consequence, I can not distribute
my manual at all.
I'm not sure I can modify GNU manuals
at
all
with those front and back cover texts,
because the moment I do, those texts are no longer true.
Riku Voipio adds:
Adding a GFDL document to rescue disks may prove
impossible as the document may not fit in the disk with
the invariant sections included.
Survey
conducted on debian-legal mailing list by Branden Robinson
In August 2003, the following
survey
was posted to the debian-legal mailing list, requesting
the opinion of subscribers regarding one of a pair of
related questions that have been asked with increasing
frequency on that list, and in a few other forums around
the Internet.
Does the GNU Free Documentation License, in its current form, satisfy
the Debian Free Software Guidelines?
The survey included four possible answers to this question;
they included three answers that represented points of view
that I have seen on the debian-legal mailing list as the GNU
FDL has been discussed over the past two years, and a fourth
option was included so that people whose opinions were not
represented could indicate their dissatisfaction with the
alternatives.
The four possible answers were:
The GNU Free Documentation License, version 1.2, as
published by the Free Software Foundation, is not a
license compatible with the Debian Free Software
Guidelines. Works under this license would require
significant additional permission statements from the
copyright holder(s) for a work under this license to be
considered Free Software and thus eligible for inclusion
in the Debian OS.
The GNU Free Documentation License, version 1.2, as
published by the Free Software Foundation, is a license
compatible with the Debian Free Software Guidelines. In
general, works under this license would require no
additional permission statements from the copyright
holder(s) for a work under this license to be considered
Free Software and thus eligible for inclusion in the
Debian OS.
The GNU Free Documentation License, version 1.2, as
published by the Free Software Foundation, can be a
license compatible with the Debian Free Software
Guidelines, but only if certain restrictions stated in the
license are not exercised by the copyright holder with
respect to a given work. Works under this license will
have to be scrutinized on a case-by-case basis for us to
determine whether the work can be be considered Free
Software and thus eligible for inclusion in the Debian OS.
None of the above statements approximates my opinion.
The above answers can be crudely summarized as "no", "yes", "sometimes",
and "none of the above".
Each respondent was also asked to indicate whether he was a
Debian Developer as described in the Debian Constitution as
of the date of the survey, and asked that people who so
indicated GPG-sign their replies so that this claim could be
verified.
Here are the results of the survey.
DFSG and the GFDL Survey Results
developers
possible developers
non-developers
option 1 ("no")
18
22
option 2 ("yes")
option 3 ("sometimes")
option 4 ("none of the above")
Possible developers are people who claimed to be Debian
Developers but did not have a well-formed GPG signature on
their responses, so I was unable to verify their claims.
Possibly the most satisfying result for me personally is
that so few people selected option 4; I can have at least
some hope that my survey was not defective.
It would appear at present, though, that the GNU FDL is not regarded as
a license that can easily satisfy the Debian Free Software Guidelines,
if at all. The consensus among developers is approximately 2:1
(slightly more if the unvalidated votes don't count, slightly less if
they do) that the GNU FDL cannot be rendered DFSG-compliant with respect
to a given work unless the copyright holder is willing to extend
significant additional permissions. Even the "sometimes" votes among
our Developers do not indicate that we should stamp all GNU FDL-licensed
works as DFSG-free without a second glance. Instead, their responses
indicate that we must give GNU FDL-licensed works heightened scrutiny --
with even more care and diligence than we normally give the works we
include in our distribution. It may be the case that none of the GNU
FDL-licensed works currently distributed in Debian main satisfy even the
more (presumably) generous criteria that the Debian developer minority
would apply. More consideration is needed in this area.
Interestingly, it may be the case that our users, whom we claim to
prioritize co-equally with Free Software in clause four of
Social Contract, are asking us by an even larger
super-majority than we can muster,
not
to
overlook the defects in the GNU Free Documentation License
on their behalf. The non-Debian Developers who replied to
the survey expressed strong opposition (greater than 3:1) to
the notion that the GNU FDL is a DFSG-compliant license. I
personally find this data significant. We may be doing our
users
and
the Free Software community a
disservice by continuing to distribute GNU FDL-licensed
works in Debian main.
Software, as opposed to hardware, encapsulates documentation
This commentary is from Branden Robinson.
A recurring theme (the other of the "related questions" I
mentioned above) throughout recent discussions of the GNU
FDL on the -legal mailing list have been vigorous challenges
to the notion that we, the Debian Project, should bother to
apply the Debian Free Software Guidelines to "documentation"
at all. Advocates of this position frequently note that
clause one of the Debian Social Contract refers to
software
", not "
documentation
". These
advocates also just as frequently fail to indicate what
alternative guidelines, if any, should be used for
evaluating licenses on works in the Debian GNU/Linux
Distribution that are not "
software
". Bruce
Perens, the primary author of the Debian Social Contract and
Debian Free Software Guidelines, indicated in a
recent
message
that he "
intended for the entire contents of
that CD to be under the rights stated in the DFSG - be they
software, documentation, or data.
In my opinion, and in the opinion of several other people on
the debian-legal mailing list, if we are to deviate from the
understanding that "
everything
" in Debian main
(apart from legal notices that we are required to include
where applicable) must satisfy the DFSG, then we, as a
Project, must draft a General Resolution to alter the Social
Contract and say what we mean. If the best thing for the
Debian Project to do is not to apply the Debian Free
Software Guidelines to all works in our distribution, so
that our distribution is not "100% Free Software", but
rather "a collection of Free Software and other works", then
we should draft and vote upon a General Resolution amending
the Social Contract to that effect.
I, too, feel that the distinction between data, documentation, and
program code is far from clear, with large amounts of grey
areas. I have a program (for my day job), where we have
pluggable probes deployed by a sensor program, as and when the
sensor deems fit. Initially, the sensor does not know how many
probes have been installed on the local machine, it goes out and
discovers the number and nature of the probes in an initial
resource discovery phase.
Each probe, when installed, installs an XML document that can
be converted into HTML or PDF by applying a simple xsl transform;
this is where all the documentation about the probe
lives. Sounds like this is documentation, no?
The sensor reads the same file, applies another xsl transform,
and gets to know the capabilities of the probe, and how to
classify it, and publishes the data to a central trading
service. Sounds like configuration data, no?
Now, when a request for data comes in, a generic probe handler
is deployed, which reads the same file, applies a transform, and
is handed a series of instructions on how to deploy the probe and
communicate with it. Sure sounds like program code.
The documentation of the probe lists the access methods and
protocols that one can talk to the probe; this is the
documentation part. The sensor parses the same bits to determine
the capabilities of the probe, and publishes that as data to a
central trading service. The very same bits are read by the
generic probe handler, and with an xsl transform, is handed a
series of instructions to deploy the probe. In all these use
cases, exactly the same set of bits is used.
Then comes the matter of literate programming; I have a project
QMS
where
all the printed documentation, HTML pages, manual pages, etc are
extracted from program code using
doxygen
. There are
several other literate programming mechanisms, where the code
and documentation are inextricably entwined.
If we cannot disambiguate data, documentation, and program code,
we can't defend the premise that there are rigid classifications
of software which are feasible. If we cant distinguish between
code and documentation, how can we aver that different freedoms
are attached to libre documentation?
Related Links
: (provided by Branden Robinson)
the GNU FDL, version 1.1, in plain text
the GNU FDL, version 1.2 draft
(as published by the FSF), in plain text
the GNU FDL, version 1.2, in plain text
the FSF's summary and
responses to public comments on the FDL 1.2 draft
a unified diff
between the draft and final form of version 1.2 of the GNU
FDL
HTML'ized version of the above
word
diff
, thanks to Steven Augart.
a word diff between
the draft and final form of version 1.2 of the GNU
FDL
a unified diff between
versions 1.1 and 1.2 of the GNU FDL
a word diff between
versions 1.1 and 1.2 of the GNU FDL
Names of people who agree with this statement
Manoj Srivastava <
srivasta@debian.org
Daniel Stone <
daniels@debian.org
Denis Barbier <
barbier@linuxfr.org
Joerg Jaspert <
joerg@debian.org
Lukas Geyer <
lukas@debian.org
Gergely Nagy <
algernon@debian.org
Mario Lang <
mlang@debian.org
Kalle Kivimaa <
killer@debian.org
John H. Robinson, IV <
jaqque@debian.org
Frank Küster <
frank@debian.org
Thomas Bushnell, BSG <
tb@becket.net
Sam Couter <
eddie@debian.org
Andrew McMillan <
awm@debian.org
martin f. krafft <
madduck@debian.org
Manoj Srivastava