FDL again, was: My concerns about GPLv3 process

Alfred M. Szmidt ams at gnu.org
Sat Feb 11 11:56:03 UTC 2006


   > Because such restrictions make sense, you don't need the right to
   > modify my thoughts about why I wrote the book, or to whom I
   > dedicated the book.

   As this seems to be a center of your argument, can you back this up
   (to use your favourite expression)?

Do you really need the right to modify my essay about how I simply
love chocholate cookies, thoughts which I want to share with the
world?

I'd think that the right _not_ to modify such a piece is self evident

   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.

   You might say because a computer program is functional. But so is
   the main part of a manual (as has been pointed out to you).

And as I have also pointed out.  This is exactly why only secondary
sections can be invariants.

   So the question can be reformulated as: Why must a computer program
   be 100% functional, and a manual doesn't have to be?

Becasue the English language allows for writting non-functional
pieces.  Can you explain why you need the right to modify my poem
about dragons?  And why I shouldn't be allowed to attach it to a
manual?

   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.  A manual doesn't have a `behaviour'.

   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.

   There are two main differences compared to an FDL work with
   invariant sections:

   1. The former case would be two different licenses (GPL plus
      something else), the latter case would be "all FDL". But that's
      really just naming, as the FDL already gives two rather
      different sets of rights for the main part and secondary
      sections.

   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.

      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.

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.

Cheers.



More information about the Discussion mailing list