Re: Amendment: GFDL is compatible with DFSG
- To: Anton Zinoviev <email@example.com>
- Cc: firstname.lastname@example.org, email@example.com
- Subject: Re: Amendment: GFDL is compatible with DFSG
- From: Wouter Verhelst <firstname.lastname@example.org>
- Date: Tue, 24 Jan 2006 12:17:24 +0100
- Message-id: <[🔎] 20060124111724.GA19352@rock.grep.be>
- In-reply-to: <20060124092133.GA13476@debian.inet>
- References: <20060122234540.GA11375@debian.inet> <20060123012938.GB7011@country.grep.be> <20060123084124.GA11819@debian.inet> <20060123092818.GB11458@country.grep.be> <20060123105954.GD11819@debian.inet> <20060123153209.GF18442@country.grep.be> <20060123214039.GA12502@debian.inet> <20060123224904.GB30811@country.grep.be> <20060124092133.GA13476@debian.inet>
On Tue, Jan 24, 2006 at 11:21:34AM +0200, Anton Zinoviev wrote:
> On Mon, Jan 23, 2006 at 11:49:04PM +0100, Wouter Verhelst wrote:
> > >
> > > 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 gave two examples.
I could also produce examples that have nothing to do with the matter at
hand, that doesn't prove anything.
> > > 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?
> These examples show that my opinion about "overall subject" can be
> confirmed by a more authoritative source, namely the libraries.
I submit that things like medieval texts and poetry are special cases;
in the case of medieval text, a lot of research goes into this; in the
case of any art form (including poetry), there are always people who
think it is nice to give a whole lot of comments on the thing. For both
your examples, it is normal that there is quite some accompanying text.
It is not common for the accompanying text to be longer than the subject
matter itself, but it indeed is not unheard of.
The same cannot be said about technical documentation. I have never seen
technical documentation accompanied by lots of text about different
subject matters, except in the case of the FSF's documentation (and even
then it never amounted to more than the technical documentation itself).
> BTW, I chose these examples because these are books I realy have, not
> because I can not imagine technical book that proves the same.
Well, I can't. If you can give me an actual example of a technical book
that talks more about non-technical stuff than about the actual
technical subject matter, I'll agree with you. Until that time, I think
it's reasonable to say that the length of both texts is fairly important
in deciding what the overall subject matter really is.
> > 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.
> Well, if you ask the people that use this man-page they will tell.
Uh. You'll have to make a choice here: either the text is the entirety
of _all_ manpages (in which case you can split off the invariant
sections and the FDL text to different manpages, but you have to
consider all of them together in order to decide what the overall
subject matter is), or the text is one manpage specifically (in which
case you cannot split off the invariant sections and the FDL text to
different manpages, but you can consider each of them individually in
order to decide what the overall subject matter is).
You do not try to weasel out of admitting you're wrong by changing your
definition of 'the whole document' when it suits your purpose better.
> > > but the question is why we shouldn't accept [the unmodifiable
> > > sections]? What basic freedoms of our users we will protect by
> > > doing so?
> > The freedom to modify the text as they see fit.
> With respect to that freedom GPL is also non-free.
It is not. See below.
> > Note that you even have the freedom to take a license text and modify
> > it, including any preamble such a license text might have.
> Not exactly. The BSD-alike licenses allow you do this but other
> licenses state that "everyone is permitted to copy and distribute
> verbatim copies of this license document, but changing it is not
You're referring to the GPL, right?
Let me show you this, then:
In short: you are allowed to change it provided you do a few specific
things; one of them is that you must rename your license.
The full copyright statement to the copyright license is not included in
the copyright license itself, probably for reasons of practicality; but
that shouldn't matter.
In fact, the GPL _has_ been modified in the past. See
> > > 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".
> No, it doesn't but in that case there must exist more solid
> argumentation than just "we don't agree becase we don't want to".
There have been years of discussion prior to this GR. I think that
amounts to a fair bit more than "we don't agree because we don't want
> But regardless of that, the relevance of GNU's four basic freedoms is
> not zero in a Debian context.
Yes, it is; the DFSG is something _all_ Debian Developers agreed to
uphold, so it is the very thing that binds us. In contrast, since nobody
asked Debian Developers to agree to the four freedoms, there is no
guarantee that all Debian Developers do, in fact, agree with them. While
some (or, probably, many) Debian Developers see the four freedoms as
something important and use it as guidance for their personal actions,
they cannot be used as a guidance for the Debian project as a whole.
If you want to change that, you'll have to propose a GR which would make
the four freedoms a foundation document. Not that I would oppose that (I
might even second it), but before such a GR is accepted, the four
freedoms have no relevance to the Debian Project as a whole.
> > If so, then I would submit that you're wrong. I, for one, understand
> > that section to mean exactly that: it does require arbitrary
> > modifications.
> You already agreed that section does not mean exactly that in your
> message on "Mon, 23 Jan 2006 10:28:18 +0100". Citing: "That, I can
> agree with. So let's do that: let's see at what restrictions are
> imposed, and whether they would allow me...".
No. I meant there that I agree that the actual, practical results of a
license restriction are more important than whether or not they happen
to be okay according to some DFSG-guideline; but I do still think that
DFSG3 requires arbitrary modifications.
> > > 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.
> It does not make the useful types of modification impossible. I
> already demonstrated why we don't have to put all invariant sections
> and the full text of GFDL in every single GFDL-covered man-page.
You failed to do so in a logically and legally sound way.
> > The latter would not allow anyone to make some profit out of selling
> > CD-ROMs with source; the former does.
> GPL says: "for a charge no more than your cost of physically
> performing source distribution". This does not seam to allow making
Hmm, right; sorry. I must've misremembered.
> > > The preposition "along" in the license does not mean "with".
> > 'along with'...
> OK. Let's check again the dictionary. Acording to it the "along" from
> the license should mean "in company, in addition" (the other meanings
> are not applicable). So this is what the license says: "include a
> machine-readable Transparent copy in addition with each Opaque copy".
> If you include the transparent copy in the web-server in addition to
> the opaque copy, then you are ready with the requirements of GFDL.
I was specifically talking about selling printed copies.
Oh well. I guess it's clear you won't agree with me, and I'm fed up with
the same rehash of this very same discussion that's been done for years
now. It isn't getting us anywhere.
All I can do is hope that Debian Developers have their act together and
do not vote for your mindless amendment.
.../ -/ ---/ .--./ / .--/ .-/ .../ -/ ../ -./ --./ / -.--/ ---/ ..-/ .-./ / -/
../ --/ ./ / .--/ ../ -/ ..../ / -../ ./ -.-./ ---/ -../ ../ -./ --./ / --/
-.--/ / .../ ../ --./ -./ .-/ -/ ..-/ .-./ ./ .-.-.-/ / --/ ---/ .-./ .../ ./ /
../ .../ / ---/ ..-/ -/ -../ .-/ -/ ./ -../ / -/ ./ -.-./ ..../ -./ ---/ .-../
---/ --./ -.--/ / .-/ -./ -.--/ .--/ .-/ -.--/ .-.-.-/ / ...-.-/