Re: Amendment: GFDL is compatible with DFSG
On Mon, Jan 23, 2006 at 10:41:25AM +0200, Anton Zinoviev wrote:
> 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
> not).
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.
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.
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.
> > 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.
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.
> > 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
> > this).
>
> 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.
> The man-pages of Perl show how a man-page can be a part from bigger
> document.
>
> (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...)
Well, yes, we will.
> > > 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.
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.
> > > 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".
There are as many different definitions of 'Free Software' as there are
Free Software activists.
> > 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 you are offering the manual through a website, then indeed there is
no problem.
However, the requirements regarding transparent copies become onerous if
you are offering printed (i.e., on paper) versions of the manual.
> 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
> 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.
Second, the wording in the GFDL regarding the required offer for
transparent copies is way more strict than the wording in the GPL
regarding the offer for source. 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 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
> > anyone
>
> 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.
> > > 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.
[...]
--
.../ -/ ---/ .--./ / .--/ .-/ .../ -/ ../ -./ --./ / -.--/ ---/ ..-/ .-./ / -/
../ --/ ./ / .--/ ../ -/ ..../ / -../ ./ -.-./ ---/ -../ ../ -./ --./ / --/
-.--/ / .../ ../ --./ -./ .-/ -/ ..-/ .-./ ./ .-.-.-/ / --/ ---/ .-./ .../ ./ /
../ .../ / ---/ ..-/ -/ -../ .-/ -/ ./ -../ / -/ ./ -.-./ ..../ -./ ---/ .-../
---/ --./ -.--/ / .-/ -./ -.--/ .--/ .-/ -.--/ .-.-.-/ / ...-.-/
Reply to: