Re: [Texmacs-dev] GNU FSL and Debian FDL conflict

[David Allouche]

On Wed, Oct 08, 2003 at 03:24:13PM +0200, Joris van der Hoeven wrote:
> You are a bit right, but not quite. The matter of documentation is never
> addressed explicitly. Translations might as well apply to the user interface.
> The notion of derivative work is very vague.

Right. And understanding what is a derivative work and what is not is at
the core of most GPL-related discussions (for example, the binary kernel
modules issue).

Actually, the notion of "derivative work" is an issue in all the
copyright law so I do not believe there is a way around it. Furthermore,
in many contries (including France) contract clauses which contradict
national law are considered void, so we might not even have the freedom
to state precisely and effectively what a derivative work is.

> The fact that you may take documentation as input of a program does
> not turn the documentation into a program. I very well understand that,
> theoretically speaking, everything can be considered to be a program,
> but, once again, in the overwhelming majority of cases there is a clear
> separation between programs and documentation. Do you really think that
> the FSF would have felt the need for the GNU FDL if this were not so?

Understanding the intent of the FSF with the GNU FDL is a hot topic.

One may understand that documentation should somehow be more protected
than source code because it is more likely to be printed. But this 
line of thought may lead us to consider that source code should not be
considered speech and should not enjoy fundamental freedoms attributed
to speech, and this is probably not where the FSF wants to go (even
though their public statements may be carefully worded not to hint the
casual reader).

The "political piggybacking" theory is plausible. That is the FSF wanted
to use documentation as a way of disseminating its political speech. In
this model, there is no need for the GPL to be inappriate for
documentation in order to explain the GFDL.

Since I have yet to see a convincing argument that the GPL is
inappropriate for technical documentation, I favor the "political
piggybacking" theory, but then it is only me.

> > IANAL but I believe that most stringent possible interpretation of
> > "preferred form of the work for making modifications to it" may include
> > the documentation itself in the format used by the author for editing it
> > and the tools used for making this modification. In the case of TeXmacs,
> > that would include the editor itself and any user extensions: plugins,
> > style files, scheme file or other data which can be placed in the
> > ~/.TeXmacs directory to alter the behaviour of the editor).
> 
> This *should* indeed be the interpretation, but it is not clear whether,
> legally speaking, this is indeed the case for the GNU FDL. Indeed,
> the license carefully does *not* state that a document which can be
> edited by free software should be considered to be transparent.
> This is actually one of the major points which bothers me.
> I think that we are better of with the GPL in this respect.

To play devil's advocate, one may also consider that there is a
distinction to be made between "commodity data formats" (what the GFDL
calls transparent) and "custom data formats" (opaque) because
information can generally be much more easily extracted from "commodity
data formats" than from custom ones. Extracting data from custom formats
require reverse engineering and special tools. The fact that the reverse
engineering has to be done on free software makes it easier but this
does not completely address the issue (consider the trouble people have
in understanding the TM data format...).

Then you can plausibly argue that TeX (and most real-world LaTeX) is an
opaque data format since only TeX can process it accurately.

> > All of this is addressed by the GPL already.
> 
> I know, but we still have the problem that the GPL is mainly about
> programs and not about documentation. Of course, we can speculate,
> and reason by anology, but it would be better if the FSF would come up
> with a suitably improved version of the GNU FDL.

I understand that you would feel more comfortable using the "official
right license from the FSF" and I share your concern.

So I second Álvaro in asking (Ralph?) what is the preferred free license
for documentation according to Debian.

-- 
                                                            -- ddaa