[Sussex] GFDL

[Simon Huggins]

Hi LUG,

On Mon, Apr 04, 2005 at 02:12:50PM +0100, Geoffrey J. Teale wrote:
> Simon Huggins <huggie at earth.li> writes:
> > Shame they made a mistake with the GFDL really with Invariant sections
> > and other problems.
> >
> > http://people.debian.org/~srivasta/Position_Statement.html [0]
> Hmm, seems to be a dead link.

*sigh*  I go to the trouble of getting the right link and writing a
footnote which explains that gluck (the host for people.debian.org) is
down and you snip it and then moan the link is dead.

Try
http://64.233.183.104/search?q=cache:SErldDCN1KMJ:people.debian.org/~srivasta/Position_Statement.html+gfdl+debian&hl=en&client=firefox
then.

> Anyhow there are many criticisms of the GFDL, however it is a really
> comes down to people not understanding the difference between software
> and documentation.  In particular paper based documentation has
> different legal requirements and practical considerations to
> electronic media.  RMS states:

[snip]

So RMS likes his own license then ;)

> The community as a whole is seeing the benefit of this license in
> terms of published books already.  Moreover if you don't want to use
> the GFDL you don't have to, it's perfectly acceptable to GPL your
> documentation (and indeed is preferable for electronic media).

The problem is that it's being foisted upon us for real documentation
not just dead-tree stuff.  Documentation for things like emacs,
autotools and so on uses this license.

Having the documentation under the GPL is fine.


Here are the points from the above URL:
	 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).

-- 
 ,--huggie-at-earth-dot-li--------stuff-thing-stuff----------DF5CE2B4--.
_|        "Step #1 in programming: understand people." -- Linus        |_
 |                                                                     |
 `- http://www.earth.li/~huggie/ - http://www.blackcatnetworks.co.uk/ -'