Re: Amendment: GFDL is compatible with DFSG
On Mon, Jan 23, 2006 at 02:29:38AM +0100, Wouter Verhelst wrote:
> On Mon, Jan 23, 2006 at 01:45:40AM +0200, Anton Zinoviev wrote:
> > For example the GNU General Public License contains the following
> > clause:
> > If the modified program normally reads commands interactively when
> > run, you must cause it, when started running for such interactive
> > use in the most ordinary way, to print or display an announcement
> > including an appropriate copyright notice and a notice that there
> > is no warranty (or else, saying that you provide a warranty) and
> > that users may redistribute the program under these conditions, and
> > telling the user how to view a copy of this License.
> This argument has been brought up a number of times already, but it does
> not hold.
It is possible that this argument does hold the way it has been used.
However here I am using it in a different way - to prove something you
will certainly agree. This is my point: many licenses, including GPL,
enforce some restrictions on the modifications and despite that we
consider them DFSG clean. Consequently when judging whether some
license is free or not, one has to take into account what kind of
restrictions are imposed (not just whether there are restrictions or
> The primary objection to the invariant sections in the GFDL is precisely
> that this is not possible; if you would want to synthesize a manual into
> something small, you would still not be allowed to remove the invariant
> sections. Worse; since after synthesizing the text the bits that are
> about the subject matter could end up being smaller than the cumulative
> amount of invariant sections, it might not even be legally possible to
> synthesize a manual.
We are not allowed to remove the copyright notices from many programs
and manuals but we don't claim they are non-free because of these
copyright notices. These notices can be very long as we see from
/usr/share/doc/x11-common/copyright. These notices can also contain
personal statements as we see from the preamble of GPL. What if
someone includes the GNU Manifesto in the preamble of a free
documentation license - we would not say that this license is
non-free, would't we?
> Synthesizing info manuals is something that Debian does regularly (or,
> at least, should do; our policy requires that every binary comes with a
> manpage, and that info documentation is not sufficient. Extracting the
> relevant bits from the info manual would be the logical choice to remedy
If the man-page is structured as a chapter from a bigger document,
then it would be unnecessary to include the invariant sections in it.
The man-pages of Perl show how a man-page can be a part from bigger
(I must admit it didn't occured to me that if we remove the
GFDL-licensed info-manuals from Debian, then we will have to remove
also the automatically generated man-pages...)
> > The licenses that contain the so called "advertising clause" give us
> > another example:
> > All advertising materials mentioning features or use of this
> > software must display the following acknowledgement: "This product
> > includes software developed by ..."
> Again, this analogy does not hold. Advertising clauses only apply to
> advertising material, not to the software (or the manual) itself;
> conversely, the requirements in the GFDL regarding invariant sections,
> acknowledgements and cover texts _do_ apply to the manual itself.
Nevertheless, the Advertising clauses can apply to components that
Debian distributes and considers 100% free.
The requirements in the GFDL are limited only to some special sections
from the manual. The requirements of the Advertising clause can
potentially apply to anything - for example to the Help/About dialogs
or to any manuals that mention features or use of the software. GFDL
restricts only directly derived documents, the Advertising clause
restricts all advertising materials.
> > Consequently when judging whether some license is free or not, one has
> > to take into account what kind of restrictions are imposed and how
> > these restrictions fit to the Social Contract of Debian:
> > 4. Our priorities are our users and free software
> This part of the Social Contract does not mean that we should bend the
> rules of freedom to accomodate for our users. As such, it cannot be an
> argument as to whether the GFDL is free or not.
Ofcourse it does not mean that. The point is that me can not impose
on the free software community alternative meaning of "free software".
> It says that you *must* either include a Transparent copy along with
> each opaque copy
If the website contains both the transparent and the opaque copy then
indeed the transparent copy will be _along_ with each opaque copy (not
with or in each opaque copy). If not, then the requirements of GPL
are more strong than the requirements of GFDL.
> (thus, if you print a book, you must include a CD-ROM), or maintain
> a website (or something similar) for no less than one year after
> distributing the opaque copy.
Sadly - many Debian developers consider this an argument against GFDL
even though the restrictions of GPL are way more severe. For printed
books GPL would require from you to include either CD-ROM or written
offer to distribute the transparent copy at minimal cost at least for
> It should also be noted that the intent of the original authors of a
> particular license is of no relevance for a license that can be used by
The lawyer of FSF is a professor in jurisprudence.
> > You may not use technical measures to obstruct or control the
> > reading or further copying of the copies you make or distribute
> > This clause disallows the distribution or storage of copies on
> > DRM-protected media only if a result of that action will be that the
> > reading or further copying of the copies is obstructed or controlled.
> > It is not supposed to refer the use of encryption or file access
> > control on your own copy.
> No; however, as written it can be interpreted as such.
If you do not have any access to my encrypted or "chmod -r" copy, then
I am not controllyng your reading or further copying - in such
circumstances there is no reading or further copying at all. I would
be in violation of the license only if I apply encryption to some
particular chapters of the document and I do so exactly in order to
control your reading or further copying.
> We all agree that this is a bug in the license, but agreeing on that
> does not mean that there is no problem.
It is the nature of the human languages that all texts can be
interpreted in many different ways. I don't think that the texts of
GFDL are so unclear that they can be misinterpreted in a court.