Re: Documentation License

[Shaun McCance <shaunm gnome org>]

On Sat, 2009-04-25 at 20:02 -0500, Shaun McCance wrote:
> I don't really feel like rehashing all of the problems
> we've had with the GFDL, but I'll go into it if anybody
> is really interested.

I'm going to paste in the text of an email I sent to Luis
in January 2008 which lists all my gripes with the GFDL.
Note that a number of these gripes are things that affect
us as original authors.  Dual-licensing means we'd still
have to deal with this.

------------------------

Invariant sections suck as far as I'm concerned.  But we
have a standing policy of not using them in Gnome.  Since
we don't usually redistribute other people's documentation,
it doesn't really pose a problem for us.

Basically, our problems all stem from section 4, the part
that tells you all the things you have to do if you modify
the document and distribute your modified copy.  These are
the most egregious requirements, paraphrased from FDL v1:


A. Use a distinct title.
So I originally wrote the Sound Juicer Manual.  I own the
original copyright.  I put it into SVN (then CVS) and let
it bitrot.  Somebody else comes along, in the grand free
software tradition, and updates it.

>From a common sense perspective, that person is working
on the canonical version of the document, our version,
not some offshoot.  But from a purely legal perspective,
that person is modifying and redistributing my copyrighted
work under the terms of the FDL.

We don't do copyright assignment for documentation.  Since
people are transient (especially our writers), this means
that documents tend to accrue copyright holders.  Each new
person coming along is making a modified work.

When I took over as GDPFL, we were following this.  As a
result, all our document titles looked like "Sound Juicer
Manual v2.4".  Dumb dumb dumb.  (It's also not clear when
the title has to be changed, since "release" and "publish"
are murky concepts.  See next complaint.)  I made the call
to stop this insanity, hoping that none of the copyright
holders chose to be pedantic.


C. Name the publisher.
We've generally listed the GDP as the publisher in the past.
This has two problems.  First, the very idea of publishing
is stretched thin for what we do.  We put stuff into SVN
where the whole world can see it.  With a few exceptions,
we the writers don't even control when the documents are
"released" in tarballs.  What does publishing even mean?

Second, the GDP is not a legal entity.  Is it even valid
to list it as such?


H. Include an unaltered copy of the FDL.
It's not clear where this should be included.  Does it
have to be a section in the document itself.  Most of
our documents don't do this, in part because we already
have the FDL (and GPL and LGPL) available in Yelp.


I. Preserve "History" section.
K. Preserve "Acknowledgments" and "Dedications" sections.
M. Delete "Endorsements" section.
Special-casing section titles is insane.  First, this
effectively removes perfectly good titles we could use
for sections.  Second, translated documents would have
to retain the untranslated titles.  Crazy.  "History",
in particular, I could imagine using as a section title
for something other than the FDL's intended use.


I (again). The requirements for adding to "History".
Here are some other issues with the history requirements.
When you redistribute a modified document, you're supposed
to add an entry with the title, year, authors, and publisher
of your modified work to the history section.

In Gnome, we don't actually use a section, per se.  Instead,
we put the history information into the <revhistory> DocBook
element. Processors (like Yelp) put this information onto
the title page (or equivalent).  We're kind of skirting the
requirements, especially since documents don't have control
over how a processor entitles the revision history blurb on
the title page.

This is further complicated by the fact that what DocBook
provides for revision history doesn't include everything the
FDL requires us to state.  In Gnome, we sort of abuse DocBook
to make this work.  But our documents won't correctly display
the the FDL requires with anybody else's processing tools.

Add to this the fact that it's not clear what granularity is
required for the history.  Technically, every time I commit
to SVN, I'm redistributing a modified work.  Do I seriously
need to add a <revision> element each time?


All of these combined create requirements that we just can't
fulfill in Gnome.  We've been ignoring and skirting around
some of them for a while, but that's not the way I'd prefer
us to be working.

Honestly, for Gnome, I think we could strike 80% of the text
in section 4 and have a license we're happy with.  Perhaps
the FDL just isn't the right license for us.


--
Shaun