[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Texmacs-dev] GNU FSL and Debian FDL conflict
Re: [Texmacs-dev] GNU FSL and Debian FDL conflict
Wed, 8 Oct 2003 14:24:37 +0200
On Wed, Oct 08, 2003 at 12:16:05AM +0200, Joris van der Hoeven wrote:
> > It seems that such a committee is being formed:
> > http://lists.debian.org/debian-legal/2003/debian-legal-200309/msg01309.html
> > Let's hope they will reach an agrreement.
> Yes, let's hope so. If not, what license does the Debian project suggest?
> The GPL license is a bit problematic in my opinion, because its about
> software and not about documentation. Even though some people argue that
> the borderline can be vague, it seems to me that it is quite clear in
> the overwhelming majority of cases. Many clauses in the GPL, like the
> ability to run a program, obviously don't apply for documentation.
The GPL is in no way specific to "software but not documentation". It
is even explicit in the license:
This License applies to any program or other work which contains a
notice placed by the copyright holder saying it may be distributed
under the terms of this General Public License. The ``Program'',
below, refers to any such program or work, and a ``work based on the
Program'' means either the Program or any derivative work under
copyright law: that is to say, a work containing the Program or a
portion of it, either verbatim or with modifications and/or
translated into another language. (Hereinafter, translation is
included without limitation in the term ``modification''.) Each
licensee is addressed as ``you''.
Notice the repetitive mention of "any program or other work" and the
fact that a translation to "another language" is explicitely considered
a derivative work. Translation to "another language" may be understood
as translation to another "computer language" or "natural language".
Moreover, any documentation can be considered a program runnable by an
appropriate machine and producing an output. In the case of pure text,
the machine is trivial and the output may be the program itself. In the
case of TeXmacs or LaTeX, the document format can contain programming
constructs and can be considered a program whose output is a typeset
In the case of documentation, translation to another "computer language"
may be understood as a translation to another data format.
> There is a second point I would like to notice to both the Debian and
> GNU people because they seem to have an unquestioned consensus about it,
> whereas I am very allergic to this whole point: the definition of
> a transparant data format:
> It seems that we do not have *at all* an agreement about the preferred
> data format. To put it bluntly, I consider ASCII without markup or LaTeX
> as very bad, because they lack structure and thereby essential and useful
> information. In fact, the TeXmacs documentation might violate this
> transparency condition, since we do not provide any DTD (whatever
> this is for "non-standard" software! we have DRD's; what in the case of
> LaTeX by the way?).
This issue does not arises with the GPL. The only requirements are free
access to source code (whose precise term I am not going through).
The source code for a work means the preferred form of the work for
making modifications to it. For an executable work, complete source
code means all the source code for all modules it contains, plus any
associated interface definition files, plus the scripts used to
control compilation and installation of the executable. However, as
a special exception, the source code distributed need not include
anything that is normally distributed (in either source or binary
form) with the major components (compiler, kernel, and so on) of the
operating system on which the executable runs, unless that component
itself accompanies the executable.
Notice the explicit mention of "for an executable work". For a
non-executable work, the definition is not clearly written and as you
pointed out I do not think it can be.
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).
In short, the Source Code can be in any data format as long as the
software used by the author to produce it is distributed under the same
terms as the Program.
If you want to make your interpretation of "Source Code" clear, can you
add an appendix to the license. IANAL, but since it does not extend of
restrict the scope of the license or the rights it grants (unlike the
Guile exception) and merely clarify terms, it should allow incorporation
of works licensed under the standard GPL.
> I think that access to the text in the preferred form should be specified
> more precisely as the preferred form of the author(s): the author should
> never be obliged to transform writings in the preferred form of readers,
> yet he should not forbid anyone else to do so. Also, ideally speaking,
> the existence of a free tool for presenting the document should be
> a sufficient condition for a document format to be transparant.
> One might also consider the obligation that copies of the documentation
> in its original format (the source code, so to say) should remain
> available when redistributing.
All of this is addressed by the GPL already.
Re: [Texmacs-dev] GNU FSL and Debian FDL conflict, Ralf Treinen, 2003/10/07