[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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 ==

  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
  ([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: