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 [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
