Re: Amendment: GFDL is compatible with DFSG
On Mon, Jan 23, 2006 at 11:40:39PM +0200, Anton Zinoviev wrote:
> On Mon, Jan 23, 2006 at 04:32:09PM +0100, Wouter Verhelst wrote:
> > 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.
> The overall subject can be software freedom but not necesarily in all
> cases and certainly not in the case with the man-page. One can not
> use simple quantity calculations in order to determine what the
> overall subject of a book is.
I think you'll find you'll have a hard time convincing anyone that a
text that consists for 90% of a "secondary section" about free software
and for 10% of technical documentation that the "overall subject" of
that text is something technical.
> I have a book with poetry but the total length of its prefaces is more
> than the total length of all poems. I have also a book containing
> relatively short medieval story and a very long preface.
Can we stick to technical documentation? Medieval stories and poems are
nice, but they're fairly special-case texts, and in any case are not
likely to be licensed under the GFDL (especially not the medieval
> > > 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;
> In the specific case for the man-pages I think that the overal subject
> of every man-page will be its technical contents, no matter how short
> it is and how long the invariant sections we have to include are.
Still isn't relevant. If you have three very short manpages, or six very
short manpages, and then one copy of each of the invariant sections, and
the cumulative length of the invariant sections ends up being larger
than the cumulative length of the manpages, the question will arise what
the overall subject is.
> > > 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.
> There is no practical difference between the final results, the only
> differences are between the methods used to achieve the results. In
> both cases the result is that we have to distribute unmodifiable text
> with personal opinion. I agree with the Kalle's argument that "this
> does not mean that we should accept unmodifiable sections elsewhere in
> the works", but the question is why we shouldn't accept? What basic
> freedoms of our users we will protect by doing so?
The freedom to modify the text as they see fit.
Note that you even have the freedom to take a license text and modify
it, including any preamble such a license text might have. The only
thing you're not allowed to do with such a license text is claim that
that license text applies to the software as you received it.
> > > 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.
> If they think that something is a free license we have to agree
> acording to our social contract ("we will be guided by the needs of
> our users and the free software community").
"To be guided by" does not imply "to blindly follow whatever they say,
without having our own opinion".
Moreover, our definition of Freedom is laid out in the Debian Free
> There is however a reason, much more important than our social
> contract, why we should agree with them. It is because their opinion
> is based on the basis that GFDL does not infringe any of the basic
> freedoms for the users as they are described at
The relevance of GNU's four basic freedoms is absolutely zero in a
According to our own definition of software freedom, the DFSG, the GFDL
is not free.
> So far I haven't seen any solid argument why the invariant sections
> make GFDL a non-free license. All we agree the third item of DFSG
> does not require arbitrary modifications,
I'm not entirely sure I understand you correctly here, so, just for
clarity: are you saying that everyone agrees that the third item of the
DFSG does not require arbitrary modifications?
If so, then I would submit that you're wrong. I, for one, understand
that section to mean exactly that: it does require arbitrary
> all we agree that some restrictions are admissible. What makes the
> invariant sections not admisible?
It imposes a burden on some very useful types of modification, and makes
others legally impossible.
> The usual answer is "acording to
> DFSG the license must allow modifications". But why would someone
> accept the restrictions caused by the Advertising clause and not the
> restrictions caused by the invariant sections?
The restrictions of an advertising clause are no problem because it is
simply a stronger form of 'credit where credit is due'. I have no
problem with giving due credit.
> > > 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".
> I don't understand this.
"reasonable" means "you're allowed to ask money for the act of producing
the source, but you're not allowed to try and scare people away from
asking the source by setting the price extremely high".
"minimal" means "you must do your best to make sure the price is as low
The latter would not allow anyone to make some profit out of selling
CD-ROMs with source; the former does.
> > 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.
> Thats up to personal opinion.
It is a simple matter of fact.
To comply with the GPL's source requirement (without offering it along
with the binaries, or without passing on any offer you already
received), it suffices to take out a piece of paper, scribble an offer
on that for source until some date at least three years into the future,
and sign it (and to make sure you'll be able to actually get that
source, should anyone ever choose to excercise their rights -- but you
can deal with that if it is ever necessary). Total time required to
comply with the GPL: 45 seconds.
To comply with the GFDL's transparent copy requirement, you must have a
website large enough to hold the full transparent copy to the document,
and pay the bills for that webspace for at least a year. Total time
required to comply: impossible to say. Not everyone is a geek with their
own webserver; some people have a 20MB quota on their ISP's webserver.
Having to use 5MB for a transparent copy of a document which they just
printed out for a friend isn't very interesting. Having to pay some tens
of euros per month for a whole year for webspace at a commercial hoster
just so you'll be able to legally distribute a printed copy isn't much
> Anyway, its not this requirement what makes some people think GFDL is
I would think it is one of them.
> > > > 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.
> > 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.
> The preposition "along" in the license does not mean "with".
> > > 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.
> My dictionary says the meaning of "control" is "to have power to
> direct or restrain; to regulate". You can not control something that
> does not exist.
> To "control the reading" means to make you able to read the document
> today but not tomorow. To "control the further copying" means to make
> you unable to give a copy of the document to your friends.
It also means you try to 'direct or restrain' anyone who tries to make a
copy of your version. If you use technical measures to make the act of
making copies impossible, you 'control the further copying'.
If you chmod -r a file, you are use technical measures to make the act
of making copies impossible.
.../ -/ ---/ .--./ / .--/ .-/ .../ -/ ../ -./ --./ / -.--/ ---/ ..-/ .-./ / -/
../ --/ ./ / .--/ ../ -/ ..../ / -../ ./ -.-./ ---/ -../ ../ -./ --./ / --/
-.--/ / .../ ../ --./ -./ .-/ -/ ..-/ .-./ ./ .-.-.-/ / --/ ---/ .-./ .../ ./ /
../ .../ / ---/ ..-/ -/ -../ .-/ -/ ./ -../ / -/ ./ -.-./ ..../ -./ ---/ .-../
---/ --./ -.--/ / .-/ -./ -.--/ .--/ .-/ -.--/ .-.-.-/ / ...-.-/