Re: Amendment: GFDL is compatible with DFSG
On Mon, Jan 23, 2006 at 12:59:54PM +0200, Anton Zinoviev wrote:
> 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",
Yes, they will. The definition of "secondary section" in the FDL reads
as follows:
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. (Thus, if the Document is in
part a textbook of mathematics, a Secondary Section may not explain
any mathematics.)
If you write a document that talks for 99% about using a program, and
for 1% about software freedom, then that 1% is a secondary section
according to this definition.
If you then remove most of the content from that document so that only
the relevant bits for a manual page and those secondary sections are
left behind, then it could very well be that 10% of the resulting text
is your technical documentation while 90% of your text is that section
about software freedom.
At this point, you can no longer reasonably say that the "Document's
overall subject" is the technical documentation; rather, at that point
the Document's overall subject will be software freedom.
It will then fail the definition of "Secondary Section" as explained in
the FDL. QED.
> but that is not relevant here, because you don't have to include all
> invariant sections in every single man-page.
Does not follow. You have to include them all; whether or not you have
to include them on every manpage in a given package is not relevant.
[...]
> > > 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.
There is; see also Kalle's reply. Moreover, I personally would not
accept a license that contains a preamble which is three times as long
as the actual license text and which claims that Free Software is a
virus (or something similar) as a Free License.
[...]
> > > 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.
Of course; and the point of this whole excercise is to find out what
exactly the common stance of the Debian project on this question is.
We would not impose anything on anyone by defining for ourselves what
"free software" is; rather, we would put forward our position; other
people would be allowed to either agree or disagree.
Sure, there will be practical effects to that.
> 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.
It is not because they think that the FDL is a free license that we have
to agree.
> > However, the requirements regarding transparent copies become onerous if
> > you are offering printed (i.e., on paper) versions of the manual.
>
> Not, at all.
... because?
> > > > (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
First, the GPL says "reasonable", not "minimal".
Second, maintaining a website with the transparent versions of your
opaque copies in such a way that they are ready for download at any time
for a whole year sounds like more effort to me than the requirement to
be able to, somehow, find that patch that you applied somewhere in your
version control system, and then mail it to someone asking you for it,
together with a source tarball which you could then download again from
the project's website of which you used the 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 is not a bug, it is a wrong interpretation of the license.
It is indeed an interpretation of the license that does not match up
with the intended meaning of said license.
However, I do not think that the interpretation that I gave you here is
inconsistent with the text of the license. As such, it is a valid
interpretation of the license text and, since it was not intended to be
the meaning of this license, a bug.
Again, the intention of the license's author are irrelevant to the
actual meaning of the license up to the day that you are able to use "I
can read your mind!" as an argument in court.
> > > 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.
No, that is not correct. If it ever happens with the GFDL, you can then
prevent the situation from occurring again for future documents.
You cannot undo whatever a judge decided; if this involves fines for
some party who acted in accord with the license's intend, you cannot
undo those fines.
You cannot prevent it from happening to already-existing documents under
the same license; anyone could use the old version of the document under
the old terms, and sue you.
> With that I do not claim the rules of GFDL are more clear than the
> rules of some other licenses - maybe they are not.
You can drop the "maybe" here.
> 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.
We clearly disagree here.
[...]
> > > 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.
Uh, go find a dictionary somewhere. If you do not allow the reading or
further copying to happen, then you are, effectively, controlling the
reading or further copying of the document.
--
.../ -/ ---/ .--./ / .--/ .-/ .../ -/ ../ -./ --./ / -.--/ ---/ ..-/ .-./ / -/
../ --/ ./ / .--/ ../ -/ ..../ / -../ ./ -.-./ ---/ -../ ../ -./ --./ / --/
-.--/ / .../ ../ --./ -./ .-/ -/ ..-/ .-./ ./ .-.-.-/ / --/ ---/ .-./ .../ ./ /
../ .../ / ---/ ..-/ -/ -../ .-/ -/ ./ -../ / -/ ./ -.-./ ..../ -./ ---/ .-../
---/ --./ -.--/ / .-/ -./ -.--/ .--/ .-/ -.--/ .-.-.-/ / ...-.-/
Reply to: