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

Re: Amendment: invariant-less in main (Re: GR Proposal: GFDL statement)



Seconded.

> > On Tue, Jan 10, 2006 at 04:55:43AM +0100, Adeodato Simó wrote:
> > > Debian and the GNU Free Documentation License
> > > =============================================
> > >
> > > This is the position of Debian Project about the GNU Free
> > > Documentation License as published by the Free Software Foundation:
> > >
> > >   1. We consider that the GNU Free Documentation License version
> > > 1.2 conflicts with traditional requirements for free software in a
> > > variety of ways, explained in detail in the "Problems of the GFDL"
> > > section below.
> > >
> > >      The most grave of these problems are the so-called "invariant
> > >      sections", which are non-removable, non-modifiable parts of
> > > the document that the GFDL allows in works under this license.
> > > However, modifiability is a fundamental requirement of the Debian
> > > Free Software Guidelines, so this restriction is not acceptable for
> > > us.
> > >
> > >   2. We believe that works licensed under the GFDL that include no
> > > such unmodifiable sections do fully meet the spirit of the Debian
> > > Free Software Guidelines, and have a place in our distribution
> > > despite the other problems (minor, in comparison) that the GFDL
> > > has.
> > >
> > >      Formally, the Debian Project will include in the main section
> > > of its distribution works licensed under the GNU Free Documentation
> > > License that include no Invariant Sections, no Cover Texts, no
> > > Acknowledgements, and no Dedications, unless permission to remove
> > > them is granted.
> > >
> > >   3. Despite the compromise above, GFDL'd documentation is still
> > > not free of trouble: as an example, it is incompatible with the
> > > major free software licenses, which means that GFDL'd text can't be
> > > incorporated into free programs.
> > >
> > >      For this reason, we encourage documentation authors to license
> > >      their works (or dual-license, together with the GFDL) under a
> > > well known free software license like the the GPL or the BSD
> > > license.
> > >
> > >
> > > Problems of the GFDL
> > > --------------------
> > >
> > >  I. The DRM Restriction
> > >
> > >   Section 2 (Verbatim Copying) of the GFDL goes beyond the
> > > traditional source requirement in copyleft licenses in an important
> > > way: according to the GFDL no copy may ever be subject to
> > > "technical measures to obstruct or control" reading and copying.
> > > This means that:
> > >
> > >     (a) It is not limited to the act of distribution (i.e., it
> > > applies to private copies as well).
> > >
> > >     (b) It rules out the possibility that a version be distributed
> > > on some form of DRM media (for technical reasons, perhaps), even
> > > while providing source (i.e., a transparent copy) in an
> > > 	unencumbered way at the same time.
> > >
> > >     (c) As written, it would outlaw actions like changing the
> > > permission of a copy of the document on your machine, storing it on
> > > an encrypted file system, distributing a copy over an encrypted
> > > link (Obstruct or control the reading is not clarified to apply
> > > merely to the recipient), or even storing it on a file-sharing
> > > system with non-world-readable permissions.
> > >
> > >   Consider that the GFDL currently prohibits distribution on DRM
> > > media, as compared to the GPL which requires distribution on
> > > non-DRM media. This is a serious additional restriction.
> > >
> > >  II. Transparent And Opaque Copies
> > >
> > >   Section 3 (Copying in Quantity) of the GFDL states that it is not
> > >   enough to just put a transparent copy of a document alongside
> > > with the opaque version when you are distributing it (which is all
> > > that you need to do for sources under the GPL, for example).
> > > Instead, the GFDL insists that you must somehow include a
> > > machine-readable Transparent copy (i.e., not allow the opaque form
> > > to be downloaded without the transparent form) or keep the
> > > transparent form available for download at a publicly accessible
> > > location for one year after the last distribution of the opaque
> > > form.
> > >
> > >   It is our belief that as long as you make the source and binaries
> > >   available so that the users can see what's available and take
> > > what they want, you have done what is required of you. It is up to
> > > the user whether to download the transparent form.
> > >
> > >   The requirements for redistributors should be to make sure the
> > > users can get the transparent form, not to force users to download
> > > the transparent form even if they don't want it.
> > >
> > >  III. Invariant Sections
> > >
> > >   This is the most troublesome part of the GFDL.
> > >
> > >    The GNU FDL includes a number of conditions that apply to all
> > >    modified versions that disallow modifications. Specifically,
> > > Section 4 of the GFDL describes the invariant sections that must be
> > > unaltered in their text and in their titles in any derived works.
> > > These invariant sections must be secondary sections; a secondary
> > > section is a named appendix or a front-matter section of the
> > > Document that deals exclusively with the relationship of the
> > > publishers or authors of the Document to the Document's overall
> > > subject (or to related matters) and contains nothing that could
> > > fall directly within that overall subject. These parts include:
> > >
> > >      * Invariant Sections
> > >      * Cover Texts
> > >      * Acknowledgements
> > >      * Dedications
> > >
> > >   However, modifiability is a fundamental requirement of the Debian
> > > Free Software Guidelines, which state:
> > >
> > >      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.
> > >
> > >   As such, we cannot accept works that include "Invariant Sections"
> > > and similar unmodifiable components into our distribution.

-- 
Wesley J. Landaker <wjl@icecavern.net> <xmpp:wjl@icecavern.net>
OpenPGP FP: 4135 2A3B 4726 ACC5 9094  0097 F0A9 8A4C 4CD6 E3D2

Attachment: pgprst31QiADW.pgp
Description: PGP signature


Reply to: