Bug#183860: RMS's comment on this bug is mostly irrelevant. :-/
Nathanael Nerode <neroden@twcny.rr.com> writes:
> Russ Allbery wrote:
>> * For DVI and PostScript output, the TeX macros (GPL-licensed) tell TeX
>> how to take a texinfo document and turn it into DVI or PostScript
>> output. TeX then generates those DVI and PostScript documents via the
>> same means that it would use to generate any other DVI or PostScript
>> document.
> Not quite. The TeX macros are combined with the texinfo document, and
> TeX uses the result to produce a DVI or PostScript doument.
So would you consider the output of a text to HTML converter to be subject
to the license of the converter code? After all, it does something very
similar; it takes input text, combines it with text that's part of the
converter (the HTML tags at the very least), and produces a combined
document.
This seems like an analogous situation to me, and that conclusion seems
wrong. But maybe not?
> Except that's not actually the way it works. texinfo.tex is \include'd
> by the texinfo document.
Suppose that you didn't actually know about texinfo's internal
implementation. How would you know that? What part of the output leads
you to draw that conclusion?
> The situation is *exactly* parallel to header files in C, which are
> #include'd by files using them.
Well, that's controversial in and of itself. :) But setting that aside
and assuming for the moment that that *is* a licensing problem (since
that's the conservative line that Debian has taken)....
I think you're getting caught up on unimportant details; the reason why
header files in C may need to be license-compatible is not because they're
included in the process of compilation, but rather because the resulting
executable is a derivative work of both of the library and the main
program (assuming that one buys that interpretation; I think this is only
clear for static linking and the situation is very murky for dynamic
linking). The mere inclusion of the header file doesn't necessarily make
the resulting executable a derivative work. You have to look a little bit
closer. Consider, for example, the trivial case where a header file is
included but none of the symbols it defines are ever actually used in the
program.
I would agree with this line of argument for texinfo if texinfo.tex were
just a TeX macro package, like a LaTeX style package or the like, that's
used by a regular TeX document. In that case, you're writing a TeX
document that's using the macro set as a library, and that looks a lot
like the standard library issues.
However, that's not the case. A texinfo document is *not* TeX; it's a
completely different language that bears little resemblence to TeX. There
is essentially only one TeX command in the entire document, the initial
\input command, and the texinfo documentation tells you to treat that like
a magic string like #!/bin/sh rather than a part of the language. The
*intention* is completely different; a texinfo document is not written to
use the texinfo macros as a library, but rather is written in a completely
different language that's interpreted and transformed by texinfo.tex into
TeX code.
This is one of those cases where I think the intention is actually
significant (and unfortunately, as that always does, it makes the whole
thing confusing).
> Uh, right, except texinfo.tex isn't part of TeX. TeX can't tell the
> difference between it and the file which \include's it; it treats them
> as part of one document.
I don't think this matters, any more than it matters that the processor
can't tell the difference between your compiled Perl script and the Perl
interpretor. TeX is just the implementation platform; it doesn't matter
what TeX's internal view of the process is. US copyright law (and it
seems that that's normally the metric used -- if other metrics are being
used, I realize that this argument may not hold) explicitly does not cover
internal transformations required to run a program.
What matters is whether the resulting PostScript or DVI document is a
derivative work of texinfo.
> I'm not sure what the licenses for the 'standard' TeX macros are, but
> I'd want to make sure they were license-compatible with what I was
> producing.
I bet they generally aren't for any GPL-covered work. I'm pretty sure the
authors of TeX macros by and large don't even think about this (nor
probably consider it important, unfortunately). The licensing culture of
TeX has a few issues (it comes up on legal from time to time).
> Hmm. Texinfo.tex is concatenated with the texinfo source. The
> concatenated result is then run through the "tex" program. The result
> contains hunks of (transformed) material from texinfo.tex, intermixed
> with the rest of the (transformed) result.
What hunks of texinfo.tex are you thinking of?
> Actualy, I suppose that's a point which is arguable as a matter of
> facts. If you show that no substantial amount of the text of
> texinfo.tex ever ends up in output files, then fine, I'll agree with
> you. :-)
Well, I'm interested in your answer to the above question about a text to
HTML converter, since I think that would affect the answer to this
question. I don't believe there is much from texinfo.tex that occurs in
the output other than words and phrases like "Table of Contents", but
certainly texinfo.tex tells TeX how to format the source document. I
don't consider that equivalent to inclusion of actual code from
texinfo.tex in the output (which doesn't happen so far as I know), but I
guess I can see why someone might.
> No, not really arguing this. In the case of a formatting program with
> significant 'inline' segments which get expanded into the result,
> however, *they* had better be license-compatible.
The difference here is that the compiled version of that code exists in
the output executable, whereas nothing of the texinfo.tex code exists in
the output document, just the results of *executing* that code inside the
TeX interpretor.
My argument in a nutshell is this: The output of a program is not
considered covered by the license of that program in general, and I
believe the DVI output from a texinfo document processed with TeX is most
naturally viewed as the output of the texinfo.tex *program* given the
document as input. That the program happens to be written in interpreted
TeX commands is an accident of implementation not relevant to evaluating
the license status of its output.
--
Russ Allbery (rra@stanford.edu) <http://www.eyrie.org/~eagle/>
Reply to: