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

Re: Amendment: GFDL is compatible with DFSG



On Mon, Jan 23, 2006 at 10:28:18AM +0100, Wouter Verhelst wrote:
> 
> That, I can agree with. So let's do that: let's see at what restrictions
> are imposed, and whether they would allow me to modify the document so
> that it would allow me to do anything I, as a Debian maintainer, would
> want to do with it in the name of improving the situation for our users.

Fine. :-)
 
> When we go ahead and do so, we find that it does not. If I would want to
> synthesize a GNU info document into a manual page, I would be forced to
> retain any and all invariant sections that this info document contains.
> In itself, that would not be a problem; however, it may be the case that
> after my modifications, the invariant sections end up being the majority
> of the text. At that point, they will fail the definition of 'secondary
> section' as defined by the GFDL itself, so I would not be allowed to
> distribute this manual page anymore.

They will not fail the definition of "secondary section", but that is
not relevant here, because you don't have to include all invariant
sections in every single man-page.

> Do you agree that the ability to take an info document and to extract
> the relevant bits for a manpage is a freedom that we should have for
> documentation? If you do, you should oppose invariant sections.

Yes, I agree.  However as I wrote in my previous email, you can
structure the man-pages in a way that makes every single man-page to
be only a part from a bigger document.  In order to fulfil the
requirements of the license you only need to include the invariant
sections in only one of your man-pages.  (You will also have to
distribute the man-pages as a whole.)

When the document is distributed in HTML-format, we do exactly this -
each chapter can have its own short sized html-page and the invariant
sections are separated in their own html-pages.  We do not include the
invariant sections in all chapters of the document.

> There is a fundamental difference between copyright notices and
> invariant sections.  One is required by law; the other is not.
> 
> > 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?
> 
> The problem is not about large opinionated sections in copyright
> statements; the problem is about immutable and non-removable sections in
> documentation.

The point is there is no practical difference whether the GNU
Manifesto is placed in the preamble of the license or it is placed in
an invariant section.

> > 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.
> 
> No, that is not how the GFDL is written.

I already wrote about the man-pages.  GFDL does not specify what
constitutes the whole document.  The copyright message of the document
should specify this when it is unclear.

> > Nevertheless, the Advertising clauses can apply to components that
> > Debian distributes and considers 100% free.
> 
> I did not contest that.
> 
> > The requirements in the GFDL are limited only to some special sections
> > from the manual.
> 
> That is completely besides the point. The requirements may be limited to
> some special sections, but they have an effect on the manual as a whole.

The requirements of the Advertising clauses also can have effect on
the manual as a whole.  Infact, the requirements of the Advertising
clause are much more severe because they have effect not only to one
particular manual but to any advertising material mentioning features
or use of the covered software whatsoever.  Potentially this can have
effect on any manual or program that mentions features or use of the
covered sofwere.

> > Ofcourse it does not mean that.  The point is that me can not impose
> > on the free software community alternative meaning of "free software".
> 
> There are as many different definitions of 'Free Software' as there are
> Free Software activists.

Strictly speaking, you may be right.

Anyway, the GNU project, GNOME, KDE and many other free software
developers consider and use GFDL as a free license.  Even if there are
different definitions of "Free Software" (and "Free Documentation")
most of them seem to acknowledge GFDL as free.

> However, the requirements regarding transparent copies become onerous if
> you are offering printed (i.e., on paper) versions of the manual.

Not, at all.

> > > (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
> > three years.
> 
> First, I do not consider a requirement to write a little text on a piece
> of paper and to sign it a more severe requirement than to either include
> a CD-ROM or maintain a website.

Acording to the licenses this is the choice here:

GPL: include CD-ROM or obligate myself to distribute the sources at
     minimal cost for three years

GFDL: include CD-ROM or maintain a website for one year

> While the GPL does indeed allow you to offer both and let the user
> take whatever he or she wants, the requirement as written in the
> GFDL does not allow that. Sure, that's a bug, but the fact that it
> is a bug does not make the problem go away.

It is not a bug, it is a wrong interpretation of the license.

> > The lawyer of FSF is a professor in jurisprudence.
> 
> So? He is not omnipotent, so can make errors. If a judge somewhere
> decides against the intent of the license, then the harm has been done.

This can happen with all licenses and if it happens the harm can be
irreparable.  If it ever happens with GFDL then the harm will be
reparable because FSF can release a new version of the license.

With that I do not claim the rules of GFDL are more clear than the
rules of some other licenses - maybe they are not.  What I claim is we
should not exaggerate the problems.  The rules of GFDL are not so
unclear to make a real danger for the license to be misinterpreted in
a court.

> > > >    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
> 
> Really. If you maintain a copy of a GFDL'ed work on one of your
> debian.org home directories without the world-writable read bit set, you
> are in violation of the license, as written.

You are not in violation of the license.  You can not control the
reading or further copying if you do not allow the reading or further
copying to happen.  You would be in a violation only if the
world-readable bit is not set for part of the document.

Anton Zinoviev



Reply to: