FDL again, was: My concerns about GPLv3 process

Frank Heckenbach frank at g-n-u.de
Sat Feb 11 15:44:44 UTC 2006


Alfred M. Szmidt wrote:

>    Why should a dedication of a manual deserve different restrictions
>    than one of a computer program?
> 
> Because a dedication isn't a computer program?  A computer program
> thrives on being modified.  A dedication doesn't.

And a dedication is not a manual. A manual thrives on being
modified. I don't see anything in your statement to justify why a
dedication of a manual should deserve different restrictions than
one of a computer program.

> Can you explain why you need the right to modify my poem
> about dragons?

I don't. I said so. The way I suggested (e.g., GPL for the main
work, and CC by-nd for the dedication) wouldn't give that right
either. Why do you keep arguing uncontroversial points?

> And why I shouldn't be allowed to attach it to a
> manual?

Who said you shouldn't be allowed to? I didn't. But why should
someone who reuses parts of the manual not be allowed to detach your
poem again?

>    Technical differences don't really apply in most cases. An
>    invariant part could be included in most kinds of programs without
>    hindering their normal performance, such as being shown by a
>    particular option or menu item, or even on a startup screen (that a
>    user who doesn't want to read it can click through, just like a
>    manual reader(*) can skip over the pages with the invariant
>    sections).
> 
> Alas, a menu item or a startup screen changes the _behaviour_ of the
> program, and you should always be allowed to change the behaviour of
> the program.

Are you aware that clause 2c) of the GPL also restricts changing the
behaviour of the program? Sure, in a very specific way, I'm aware of
that, and we don't need to argue about it. But according to your
statement that "you should *always* be allowed to change the
behaviour of the program" (my emphasis), the GPL doesn't satisfy
your requirements either. If you didn't mean your statement in such
an absolute way, please state it the way you mean it.

>    Secondly, the question whether someone should be allowed to modify
>    your expression (or your "thoughts", as you prefer to call it), is
>    beside the point. Even a GPL work can be accompanied by an
>    unmodifiable text (GPL, paragraph 2, last sentence).
> 
> I think you are misreading that paragraph.  It is about aggregation,
> and not putting specific bits into a GPLed work.  I.e. you can put
> GPLed software and non-free software on the same CD, but you cannot
> combine those two into one work.

So it's a different work then, what's the problem? If you have a GPL
program with FDL software in one package, these are also two works
(in the legal meaning of the term, as described, e.g., in GPL
paragraph 0).

>    2. In the FDL case, the invariant sections are tied to the main
>       part.
> 
> They aren't tied to the main part, infact, they cannot be tied to the
> main part in anyway or form.

Are you arguing about the meaning of the word "tie", or what are you
trying to say? Fact is that in many circumstances, you cannot reuse
parts of the main part of a FDL work without copying the invariant
sections. (You don't deny this fact, do you? It's the heart of the
FDL.) I called this "to tie". I could back this up with some
dictonary quotes, but I really don't care. If you don't like this
word, you can suggest another term. It doesn't change anything about
my original argument.

>       You can't reuse parts of the latter without including the
>       former. In the GPL+x case, you can. That's IMHO the main
>       difference, so I'd like to know why you think having to include
>       them is a good thing.
> 
> Having an "invariant section" in a program, makes it impossible to
> modify it so that it does something you want (say that it has a GUI,
> and you wish to remove this GUI and make it into a library, if the GUI
> splash screen was an `invariant section', then you would never be
> allowed to do this).  I think we can agree on this.

You mention a case of turning a program into a different form. A
valid scenario, indeed.

> Having an invariant section in a manual, doesn't cause the same
> dilema.  You can still modify the technical content of the manual so
> that it is synced with the program.  And still be able to make an
> manual that you can use.

So let's also here consider a case of turning a (FDL) manual into a
different form, to have a fair comparison. Examples such as
reference cards or posters have been given. If, e.g., the invariant
sections are longer than the physical space on a reference part
permits, then you would never be allowed to do this according to the
FDL. (And while I'm not a lawyer, I'm quite sure that citation or
fair use rights don't cover this case, if the copied material makes
up the major part of the new work.)

Frank

-- 
Frank Heckenbach, frank at g-n-u.de
http://fjf.gnu.de/
GnuPG and PGP keys: http://fjf.gnu.de/plan (7977168E)



More information about the Discussion mailing list