Re: GR Proposal: GFDL statement
Hi,
I have taken the liberty of re-adding bits to the position
statement I considered important, and I would be happy to hear
reasons why they should not be in the position statement we publish.
manoj
On Sun, 1 Jan 2006 15:02:04 +1000, Anthony Towns <aj@azure.humbug.org.au> said:
-> --- Why the GNU Free Documentation License is not suitable for
-> Debian main
+ Why the GNU Free Documentation License 1.2 is not suitable for
+ Debian main
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> (0) Summary
> Within the Debian community there has been a significant amount of
> concern about the GNU Free Documentation License (GFDL), and whether
> it is, in fact, a "free" license. This document attempts to explain
> why Debian's answer is "no".
> It should be noted that this does not imply any hostility towards
> the Free Software Foundation, and does not mean that GFDL
> documentation should not be considered "free enough" by others.
- and
+. It merely is meant to clarify that Debian itself does not consider
+ it free. However,
> Debian itself will continue distributing GFDL documentation in its
> "non-free" section.
> (1) What is the GFDL?
> The GFDL is a license written by the Free Software Foundation, who
> use it as a license for their own documentation, and promote it to
> others. It is also used as Wikipedia's license. To quote the GFDL's
> 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.
> (2) How does it fail to meet Debian's standards for Free Software?
> The GFDL conflicts with traditional requirements for free software
> in a variety of ways, some of which are expanded upon below. As a
> copyleft license, one of the consequences of this is that it is not
> possible to include content from a documention directly into free
> software under the GFDL.
> The major conflicts are:
> (2.1) Invariant Sections
> The most troublesome conflict concerns the class of invariant
> sections that, once included, may not be modified or removed from
> the documentation in future. Modifiability is, however, a
> fundamental requirement of the DFSG, which states:
> 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.
> Invariant sections create particular problems in reusing small
> portions of the work (since any invariant sections must be included
> also, however large), and in making sure the documentation remains
> accurate and relevant.
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).
> (2.2) Transparent Copies
> The second conflict is related to the GFDL's requirements for
> "transparent copies" of documentation (that is, a copy of the
> documentation in a form suitable for editing). In particular,
> Section 3 of the GFDL requires that a transparent copy of the
> documentation be included with every opaque copy distributed, or
> that a transparent copy is made available for a year after the
> opaque copies are no longer being distributed.
> For free software works, Debian expects that simply providing the
> source (or transparent copy) alongside derivative works will be
> sufficient,
+ instead of forcing users to download the transparent
+ form whether they want it or not,
> but this does not satisfy either clause of the GFDL's
> requirements.
> (2.3) Digital Rights Management
> The third conflict with the GFDL arises from the measures in Section
> 2 that attempt to overcome Digital Rights Management (DRM)
> technologies. In particular, the GFDL states that "You may not use
> technical measures to obstruct or control the reading or further
> copying of the copies you make or distribute". This inhibits freedom
> in three ways: it limits use of the documentation as well as
> distribution, by covering all copies made, as well as copies
> distributed; it rules out distributing copies on DRM-protected
> media, even if done in such a way as to give users full access to a
> transparent copy of the work; and, as written, it also potentially
> disallows encrypting the documentation, or even storing it on a
> filesystem that supports permissions.
> (3) Why does documentation need to be Free Software?
> There are a number of obvious differences between programs and
> documentation that often inspire people to ask "why not simply have
> different standards for the two?" For example, books are often
> written by individuals, while programs are written by teams, so
> proper credit for a book might be more important than proper credit
> for a program.
> On the other hand, free software is often written by a single
> person, and free software documentation is often written by a larger
> group of contributors. And the line between what is documentation
> and what is a program is not always so clear either, as content from
> one is often needed in the other (to provide online help, to provide
> screenshots or interactive tutorials, to provide a more detailed
> explanation by quoting some of the source code). Similarly, while
> not all programs demonstrate creativity or could be considered
> "works of art", some can, and trying to determine which is the case
> for all the software in Debian would be a distraction from our
> goals.
> In practice, then, documentation simply isn't different enough to
> warrant different standards: we still wish to provide source code in
> the same manner as for programs, we still wish to be able to modify
> and reuse documentation in other documentation and programs as
> conveniently as possible, and we wish to be able to provide our
> users with exactly the documentation they want, without extraneous
> materials.
Analogous to the software program freedoms, we need to
articulate the freedoms required for the subset of software called
documentation.
1. The freedom to read the text, for any purpose.
2. 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.
3. Freedom to reformat the document into a preferred format or
medium (converting to braille, or speech, or hardcopy, or
postscript, etc).
4. The freedom to redistribute copies so you can help your
neighbor.
5. 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.
6. Freedom to translate the text into any other language.
7. The freedom to keep your modifications, or even your possession
of a copy of the text, confidential.
> (4) How can this be fixed?
> What, then, can documentation authors and others do about this?
> An easy first step is to not include the optional invariant sections
> in your documentation, since they are not required by the license,
> but are simply an option open to authors.
> Unfortunately this alone is not enough, as other clauses of the GFDL
> render all GFDL documentation non-free. As a consequence, other
> licenses should be investigated; generally it is probably simplest
> to choose either the GNU General Public License (for a copyleft
> license) or the BSD or MIT licenses (for a non-copyleft license).
> As most GFDL documentation is made available under "the terms of the
> GNU Free Documentation License, Version 1.2 or any later version
> published by the Free Software Foundation", the Free Software
> Foundation is able to remedy these problems by changing the
> license. The problems discussed above require relatively minor
> changes to the GFDL -- allowing invariant sections to be removed,
> allowing transparent copies to be made available concurrently, and
> moderating the restrictions on technical measures. Unfortunately,
> while members of the Debian Project have been in contact with the
> FSF about these concerns for the past four years, these negotiations
> have not come to any conclusion to date. ---
manoj
--
If you can count your money, you don't have a billion dollars. Paul
Getty
Manoj Srivastava <srivasta@debian.org> <http://www.debian.org/%7Esrivasta/>
1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C
Reply to: