Re: Proposed statement wrt GNU FDL
On Sat, Apr 19, 2003 at 11:29:38PM +1000, Anthony Towns wrote:
> (Hrm, asking for someone to handle this results in a motion for it
> to be handled, and lots of seconds that aren't willing to actually do
> anything. How helpful.)
That comment was unhelpful, and just discourages people from helping.
Speaking for myself, I was waiting for Branden to conclude that he
had enough seconds. As for the people who said they wouldn't have
time to help -- would you prefer that they hadn't seconded the
proposal either? We could have had a nicely silent majority.
Also, remember that it's Easter. Lots of people are busy with
family stuff.
> Debian's stance on the GNU Free Documentation License
> ...OR NOT (completely unofficial, draft, blahblah)
[...]
> The GNU FDL includes a number of conditions that apply to all modified
> versions that disallow modifications, particularly:
I was confused by the pronouns here. How about this?
The GNU FDL includes a number of conditions, which apply to all modified
versions, that disallow modifications. In particular:
(Section I, 'Preserve the section entitled "History"', is also a candidate
for this list.)
[...]
I also have a list of other problems with the GFDL. They should
probably all be listed together, though we may want to skip some
as being too nitpicky. That is, if this is to be the "comprehensive"
list Branden mentioned.
It's easy to misapply the GNU FDL.
The GNU FDL says that only "Secondary Sections" (a term it defines)
may be marked Invariant, but does not say what should happen if a
section that is not Secondary is listed as an Invariant Section.
The FSF itself has made this mistake several times[1], so we know
it's an easy mistake to make.
[1] I remember two in the GDB manual and one in the Emacs manual.
(Un)fortunately these mistakes have been corrected and I no longer have
the old versions around. Does anyone have references?
Definition of "Transparent copy" is limiting
The GNU FDL defines the words "Transparent" and "Opaque" to
distinguish between source-like and object-like documents
(e.g. comparing LaTeX to PDF). Unfortunately, this definition
focuses on implementation rather than intent. It requires
that every component of a document is either text, or an image,
or a drawing. This leaves out for example sound files, which
can never be distributed as part of a document under the GNU FDL.
([Maybe insert rant about PostScript not being Opaque by definition.
In fact, PostScript is the perfect example for documentation ==
software.])
GNU FDL creates a wall between documentation and code
The GFDL is incompatible with the GPL, and many of its requirements
don't translate well to functional software. This makes it difficult
to embed such documents into a program, for example in order to
present on-line help. In the other direction, many documents contain
example code, sometimes sizeable chunks of it, which will be unusable
by default unless specifically licensed otherwise.
Obnoxious Accumulation of Cover Texts
Every contributor can add up to 5 words of Front-Cover Text and up to
25 words of Back-Cover Text. It won't take long before there is no
space for artwork on the front cover, just a dense list of short
texts.
([Nit: "The front cover must present the full title with all words
of the title equally prominent and visible". So no artistic license
allowed in title arrangement. "Nethack: Journey through the MAZES
of MENACE" is right out, especially if "MENACE" has little goblins
holding up the letters.])
Obnoxious Accumulation of Invariant Sections
If two documents under the GNU FDL are reorganized (producing two
new documents with parts from each), then the Invariant Sections
from each of them have to be duplicated in both, except for sections
that are identical. If they differ (for example, both documents
have a "Distribution" section, but one has the old FSF address and
another has the new one), then both have to be included. This can
become unmanageable as documents evolve.
([This point might be subsumed under "Invariant Sections are bad",
and in any case we might not care because DFSG#4 allows something
similar. Do we care?])
The GNU FDL restricts the presentation of documents
(This is a general point, I'm not sure how to word it. We accept
many limitations in free software licenses, such as changelog
requirements, because they affect the source code but not the
object code. It's still possible to create whatever technical
effect is desired, even if manipulating the source can get a little
awkward. The GFDL, by contrast, makes nearly all of its demands
on the "object" of a document, not its source. For example, its
requirements for Front-Cover Texts are very similar to the Zope
and PHP-Nuke requirements that we have rejected as non-free. This
point is also the root problem of the reference-card scenario.)
Languages other than English are poorly supported
The GNU FDL defines special roles for several kinds of sections
(such as "History" and "Dedications"), but refers to these
sections by their names in English. A document under the GNU FDL
will have to include a section with the title "History", regardless
of the language it's written in.
[...]
> 4) Update the GNU FDL to allow the removal of unmodifiable sections.
This should probably be "Convince the FSF to update ..."? Otherwise
it's strange to include it in a list of things the reader can do.
It took me a while to work out what you meant.
> While this does not prevent documents covered by the GNU FDL being
> non-free, it allows you to extract the non-free components from the
> document, leaving just the juicy DFSG-free goodness.
s/extract/remove/ here. Extract implies that the non-free components
are the ones you keep.
> Open Questions
> ~~~~~~~~~~~~~~
>
> We want to do a FAQ as well. Should the "documentation = software" thing
> be justified there? How about the practical examples we have? What other
> practical examples are there?
I'd say yes and yes. The justification can be done by practical examples.
(For example, the emacs manual being part of the emacs interface,
literate programs, and rendering code embedded in documents and fonts).
Examples I've seen so far:
Wikipedia / FOLDOC controversy
Emacs reference card
> What are we going to do about all the documentation with clearly non-free
> licenses, or that lack clear licenses? This seems to include things like
> the Debian Manifesto, that's part of doc-debian.
Frankly, I wouldn't mind distributing a nonmodifiable GNU Manifesto
(as part of the emacs package or even in doc-debian) as long as it's
not bolted to something useful like the emacs manual.
> Do we really want to recommend Creative Commons Licenses? They've very
> long and legalistic -- even the "do what you want, but keep my name"
> license is disgustingly complicated, to the point where it's not obviously
> DFSG-free.
I don't think we should recommend those, since we don't have any
experience with them yet. I also think that free software licenses
should be comprensible to programmers in order to be useful; by the
same token, free documentation licenses should be comprehensible
to technical writers.
> What else needs to be covered?
Why Invariant Sections Are Bad :)
- The problem of excerpts
- People can hijack documents by modifying them and then adding
Invariant Sections that the original author finds unpalatable.
From that point on, they can use the original author's improvements,
but not the reverse. This creates exactly the kind of one-way
wall that copyleft is supposed to prevent. (If you're happy
with this, you might as well use the MIT license.)
- Invariant Sections can become outdated, and there's no way to
update them. Even adding a note saying they're obsolete is
not allowed.
We also need a point-by-point rebuttal of the FSF's response page
about the GFDL feedback, but that's not something I'm going to
think about today.
Richard Braakman
Reply to: