Re: Question(s) for clarifications with respect to the LPPL discussion
At 12.15 +0200 2002-07-19, Frank Mittelbach wrote:
>What I now would like to ask you about these four blocks is:
>
> on a): have i missed any important concerns or any important sub-argument
> within a concern?
The discussion between Jeff and me turned up another main concern,
regarding the distribution of modified works. In his opinion (which I now
suspect holds for at least those jurisdictions where copyright is something
which just arises rather than has to be claimed) it could be a problem that
the LPPL does not say anything about the copyrights of the authors of the
original (LPPLed work) to a modified derivative thereof. It appears that
they in principle could later demand that an arbitrarily restrictive
license should be applied for the derivative work.
I think we can agree that the LaTeX community practice here is that authors
give up all copyright to derivative work. Appearently e.g. the GPL and the
BSD license instead handle this matter implicitly, by requiring that any
derivative is licensed in the same way.
>Concern 3: the uselessness of the approach taken by LPPL
>========================================================
>
>Argument 3.1: write a new (unrelated/related?) package from scratch
> and give it the same name as the original one.
>
>Argument 3.3: If the core can be changed in any way without changing it
> directly, then you can break output exactly as well by this
> mechanism as you could by editing it directly.
>(http://lists.debian.org/debian-legal/2002/debian-legal-200207/msg00190.html)
>
The problem isn't really that it is _possible_ to mess up LaTeX (or some
other LPPLed package), but that people would be _tempted_ to (in tiny
steps) mess things up if the filename restrictions were simply removed.
There could be other ways of getting the same effect, but this one has the
advantage of being in line with popular sense of justice because it follows
a tradition (for better or worse; mostly better) that exists for many
related pieces of software.
To elaborate this point for the Debians, here is (yet) another analogy to
explain what kind of software LaTeX is: the huge collection of macros for
an assembler, that makes it possible to use that assembler as if it was a
compiler. With respect to this analogy, I think most *ML rendering software
are rather normal compilers: most of the constructions in the programming
environment are not possible to change from within the source. David
Carlisle's XML-TeX package becomes in this scheme something like a
collection of macros for the assembler that enables it to process correct C
(or perhaps Pascal would make a better analogy) code like a proper compiler
for that language would, but (of course) its error handling is much cruder
than what one would expect from a proper compiler.
The underlying assembler (MAsm, say) itself corresponds to TeX. What
corresponds to LaTeX is as mentioned a macro package, which I'll here call
CoMAsm. Invoking MAsm with the command "comasm" causes MAsm to load the
definitions that is in the so-called core of CoMAsm before it starts
processing the main source file, but it would be equally possible to start
up MAsm without any definitions at all. Other parts of CoMAsm are only
\input'ted (or #include'd, if you prefer that) if there is an explicit
command in some source file processed that causes this to happen. Of
course, any macro definition or parameter setting made by CoMAsm can be
changed at any time that MAsm permits this (and it practically always
does); MAsm treats standard CoMAsm code in exactly the same way as it would
any user code. It follows that packages from authors other than the authors
of CoMAsm can be loaded on top of CoMAsm and that these packages can
override definitions made by CoMAsm. In fact an important part of the
CoMAsm kernel is a package mechanism which is designed to facilitate this.
Now to an example of the problem which has led to the authors of CoMAsm
(and most other MAsm macro packages, whether these are designed to work
with CoMAsm or not) to require that files must be renamed before they are
modified.
Amongst other things, the CoMAsm package contains macros for making loops
("for" loops, "while" loops, "repeat-until" loops, or whatever) and the
code for this is in (say) loops.mac, which is part of CoMAsm. These macros
lets you write for example
for.b (i)(1)(200)(
<some lines of code>
)
to get the effect of C's
for (i=1; i<=200; i++) {
<some lines of code>
}
by expanding to something like (this is sort of 68000-assembler, in case
someone wonders, which means the target operand is last, but I probably
haven't got the mnonics 100% correct):
move.b #1,i
bra _FORLOOP_20_TEST
_FORLOOP_20_BODY:
<some lines of code>
move.b i,D0
add.b #1,D0
move.b D0,i
_FORLOOP_20_TEST:
cmp.b #200,D0
ble _FORLOOP_20_BODY
Now, there is potentially a problem with this implementation in that if the
upper limit is 255 instead of 200 then the stop condition is never met
since adding 1 to 255 in a byte returns 0, quite in accordance with the C
example. (Does it seem like an unlikely example? I've actually encountered
a Pascal compiler which suffered from exactly this bug. It took me ages to
figure out.) Now, the person who encounters this "for loop that does not
terminate" bug (if it is a bug, it might be a feature) can fix it in a
number of ways. In addition to those available in a compiler he might
(a) Make his own definition (which fixes this bug) of the for macro.
This can be done by copying the standard definition from
loops.mac into his sources and changing it so that the above
rather expands to something like
move.b #1,i
bra _FORLOOP_20_BODY
_FORLOOP_20_TEST:
move.b i,D0
cmp.b #255,D0
bge _FORLOOP_20_BREAK
add.b #1,D0
move.b D0,i
_FORLOOP_20_BODY:
<some lines of code>
bra _FORLOOP_20_TEST
_FORLOOP_20_BREAK:
(b) Instead put this redefinition in a separate file myloops.mac
(or whatever), which he may or may not want to distribute as
a package.
The problem is however that it is almost always quicker to do
(c) Change the definition of for in loops.mac.
since the definition of the for macro can easily be some 50 lines, of which
maybe only five need to be changed to effectuate the above redefinition.
The rest are needed to parse the arguments, increment some counter so that
the labels in this for loop are distinct from the labels in other for
loops, and so on. Since programmers tend to be lazy (no offense meant),
they will often tend to do (c) rather than (a) or (b), unless they've been
clearly told not to.
Why is (c) bad? If this loops.mac is used by other people then their
sources will suddenly start to produce code which behaves differently, and
they won't know of this. In most cases the change is not harmful, but if
some program e.g. uses the "i is larger than the upper limit" as a flag for
that a search was unsuccessful then the program will probably malfunction
due to this change. Since (a) or (b) is only slightly more work than (c)
however, it is not a serious restriction.
The "uselessness" argument is that forbidding (c) has no effect unless you
also forbid for example:
(d) Do (b), and in addition replace loops.mac with a symlink to
myloops.mac.
(e) Develop from scratch a set of macros for loops, and put them
in a file named loops.mac.
However both of these require _more_ work than (a) or (b), and hence
programmers will (in all likelihood) not do this unless they really mean
to. Forbidding (c) mainly serves to bring the attractiveness of
(unreflectingly) messing up CoMAsm in parity with that of messing up a C
compiler.
Of course, an important difference between the LaTeX community and the
hypothetical CoMAsm community is that LaTeX is to a large extent a system
for document exchange. This means that LaTeX code (as well as DVI, PS, or
PDF output) is not trusted code---it is not unlikely that I would recieve a
paper from my greatest enemy to referee---and hence security issues have to
be handled at the TeX level rather than at the LaTeX level. Indeed, if
LaTeX was set up so that it would handle security then it would in practice
feel considerably less free than it does today, even if that LaTeX was
GPLed or whatever.
So why is "don't modify unless you change the name first" the method used
in the TeX community to prohibit (c)? Becuase it works! Merely changing
banners and comments, adding modification flag files, and most other things
that have been suggested are things typically done _after_ modification
(when one has tested that the modification "works"), and hence it would
frequently be forgotten. Making a copy with a different name is however
something you do _before_ you're done with the modifications, and hence it
is much more reliable.
Lars Hellström
--
To UNSUBSCRIBE, email to debian-legal-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Reply to: