Re: GR Proposal: GFDL statement
I'd like to propose a few, uh, editorial amendments ;-)
On Sun, Jan 01, 2006 at 03:02:04PM +1000, Anthony Towns wrote:
> ---
> Why the GNU Free Documentation License 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 Debian itself will
> continue distributing GFDL documentation in its "non-free" section.
I think the statement should contain a reference to "current version" or
"version 1.2 and below" in the above part. Rationale: even though the
text does mention the fact that these problems can be remedied by the
FSF by updating the GFDL, it is a fact that a long text is something
that not everyone will read head to bottom; those who will read it
diagonally might miss this (very important) bit of information, unless
it's mentioned in a part of the text that they will most likely not
miss, such as the title or a part designated "Summary".
Perhaps retitle it to
Why the current version of the GNU Free Documentation License is
not suitable for Debian main
> (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
Not sure here (not a native English speaker), but can you say "from a
documentation"? Shouldn't that be either "from documentation" or "from a
piece of documentation"?
> 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.
>
> (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,
> 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.
>
> (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.
> ---
I'll second this proposal, with or without those amendments.
> It's based on Manoj's draft position statement [2] with some notable
> changes (an explicit "why not just say docs != software" section, a
> "how can this be fixed" section, a "what is the GFDL?" section, and
> reordering the major problems). I've put the above draft on the wiki
> [3] so people can tweak it.
I don't think that's a good idea. There's a fairly strict procedure for
GR proposals, with amendments et al. You shouldn't try to work around
that.
--
.../ -/ ---/ .--./ / .--/ .-/ .../ -/ ../ -./ --./ / -.--/ ---/ ..-/ .-./ / -/
../ --/ ./ / .--/ ../ -/ ..../ / -../ ./ -.-./ ---/ -../ ../ -./ --./ / --/
-.--/ / .../ ../ --./ -./ .-/ -/ ..-/ .-./ ./ .-.-.-/ / --/ ---/ .-./ .../ ./ /
../ .../ / ---/ ..-/ -/ -../ .-/ -/ ./ -../ / -/ ./ -.-./ ..../ -./ ---/ .-../
---/ --./ -.--/ / .-/ -./ -.--/ .--/ .-/ -.--/ .-.-.-/ / ...-.-/
Reply to: