Bug#183860: RMS's comment on this bug is mostly irrelevant. :-/
Russ Allbery wrote:
Nathanael Nerode <neroden@twcny.rr.com> writes:
The issue is entirely about generated files which contain elements of a
GFDL'ed texinfo file *and* elements of the GPL'ed texinfo.tex; such
files are presumably derivative works of both, but that means they can't
be distributed.
I'm not sure that I understand. Here's how I look at this; please let me
know where I'm wrong:
* texinfo is a formatting language. It happens to be implemented in some
particular cases (but not others) by using TeX macros, but that's just
an internal implementation technique. It could be implemented as a
separate binary program for all we know.
Yup.
* texinfo documentation is given as input to a texinfo formatting
program, which then produces some output; the most interesting in this
particular case is DVI or PostScript output.
Yep.
* 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.
To me, this situation seems exactly parallel to what would happen if
texinfo were implemented in Perl. The texinfo program (texinfo.tex or the
Perl texinfo script) is fed to an interpretor (TeX or Perl), takes the
documentation as input, and uses the functionality of that interpretor to
generate some output.
Except that's not actually the way it works. texinfo.tex is \include'd
by the texinfo document.
The situation is *exactly* parallel to header files in C, which are
#include'd by files using them.
If texinfo.tex can be \included without subjecting the combination and
the resulting object file to the GPL, then any C header file under the
GPL can be #include'd without subjecting the combination and the
resulting DVI or PostScript file to the GPL.
Either there needs to be a clear distinction between the two cases,
or the FSF needs to announce that they agree that C header files can be
used to circumvent the GPL, or we need a more freely licensed
replacement for texinfo.tex, or an implementation that doesn't dump
inline/macro-expanded bits in in the same manner.
(The ideal license would state that \include'ing texinfo.tex is
considered normal use and not subject to the license. Actually,
ideally, 'normal use' would *never* be subject to copyright issues, but
apparently it is, since otherwise the LGPL would be quite unnecessary.)
As long as substantial chunks that are included vertabim in the output
(the old bison case) are licensed appropriately, and I don't see any
reason to think that they're not since they come from TeX and PostScript
documents generated by TeX don't seem to have license issues in general, I
don't see the issue.
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'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. (And I think they're
sufficiently freely licensed that they are compatible with normal use.)
Maybe the mechanism whereby TeX loads the texinfo program is confusing?
It does load the program and the data into the same input stream due to
the way that TeX is implemented, but isn't this just an accident of
implementation irrelevant to licensing concerns since it happens internal
to the TeX process?
Well, if that's the case, then the combination of C header files (the
GPL'ed 'program') and your program (the 'data' being used by the
compiler to generate a .o file) is 'just an accident of implementation
irrelevant to licensing concerns since it happens internal to the CC
process', in your words.
As far as I know, the FSF has never claimed that this was the case.
Although it would certainly be convenient. Maybe I've missed something.
:-)
It's not like the concatenated texinfo.tex and texinfo source is
distributed as such. Rather, texinfo.tex is *run* and used to produce
output. (But even if that were distributed, is it a license violation to
cat together two files with different licenses and distribute the results?
That still sounds like mere aggregation to me.)
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. So how is it not a
derivative work?....
I think it's generally well-accepted that, in the *common* case where no
substantial portion of the implementation is included in the output, the
output of a program is not inherently a derivative work of that program.
Yep.
I don't see the argument for declaring the output of the texinfo program
to be a derivative work of its implementation.
Um, the output is full of bits from the implementation? :-/
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. :-) Maybe this is in fact true, since I'm far from an expert, but
it didn't look true at a cursory glance. :-/
GCC has a special 'libgcc' license for routines which are part of GCC
but which get incorporated into resulting programs because of this sort
of issue.
If what you're saying is true, it would seem to imply that it is a license
violation to write any document in texinfo and redistribute the formatted
result unless the document is licensed under the GPL,
Not unless the 'formatted result' incorporates part of a GPL'ed
document. In this case, the point is that it appears to do so. I guess
there's a factual question here; maybe it can be shown that it doesn't
incorporate a meaningful amount.
and that more
generally it would be a license violation to distribute the output of
*any* formatting program unless the input document was license-compatible
with the implementation of the formatting program. This seems wrong to
me.
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.
Again, though, I may be missing some major issue, and would certainly
welcome correction.
I think the major issue is a matter of fact.
Reply to: