Scripsit Jeff Licquia <[EMAIL PROTECTED]> > The license text would say something like this:
> ----- > The Program may be modified in any way as long as one of the following > conditions are met: > > - No part of Standard LaTeX is changed. > > - The Program does not represent itself as Standard LaTeX in any way, > including the name and any diagnostic output. > > The Project distributes a file with the Program, foo.tex, that describes > some procedures we have set up to allow derived works to fulfill these > conditions. > ----- There is a systematic problem here in that, as Frank has described, "Standard LaTeX" is a more slippery concept than the end-user of something like teTeX usually imagines. But that could probably be fixed somehow. > The procedures file would reference an API call. The exact API is up to > the LaTeX Project, of course; for now, we'll call it "register". All > macro packages, extensions, etc. that are a part of Standard LaTeX would > contain this API call, which would register the string "LaTeX". I may be dense, but even though I've followed the thread, I find this description hard to follow. It seems to me that the intended semantics of "register" is, "please kill me unless you happen to like this cookie". In that case, your scheme could be paraphrased as "If you want to modify a package [say, one that is not part of the core LaTeX distribution, but one whose author has independently put it under the LPPL], you must either 1) [do the renaming stuff], or 2) make sure that your modified package refuses to run on top of the standard LaTeX kernel." If this is correct, I don't think that option (2) is not a free option. As detailed before, I now think that the renaming option *is* free (just barely). > 3. Change or remove the behavior of the "register" call entirely (which > is a kernel modification), and make sure that the modified kernel does > not represent itself as LaTeX in name, diagnostic output, etc. > (Option 3 might be expressly discouraged by the LaTeX Project, but it is > important nevertheless.) I can't imagine that it would be acceptable for the LaTeX people that a change in the LaTeX *kernel* would make it legal to hack in another file that, from their point of wiev, is part of an entirely different, separately distributed work. Remember what the problem that the renaming thing is supposed to fix in the first place is. Basically it stems from the fact that the TeX language as specified by Knuth has a very feeble concept of filesystem organization, if any at all. Knuth had worthy portability reasons for doing it that way - after all, TeX was conceived of in an age where machines without hierarchical directory structure was not just relics in technical museums but systems that some people were using for getting work done. (PC-DOS had had directory trees for just a few months when the preface to the TeXbook was written in June 1983). The upshot of this is that, at least the web2c implementation of TeX that most people use in practice, largely ignores the directory structure and looks at the raw names only. When TeX macro code asks to have some named file read in, the implementation will search for *any file* with that name *anywhere* in the directories in its search path *or their subdirectories*, recursively. The first file found will be read. This means that if I hack a private copy of article.cls without changing its name, and by some weird chance my private file gets copied to a directory where TeX looks for files, there is a real risk that the changed file will be read by a process that was supposed to be ordinary LaTeX - even if the changed file is quite far away from the directory where *people* would look for LaTeX stuff. [Sheesh. Just by explaining these basic facts explicity, I feel I'm sounding like Boris in his Debian-people-are-completely-clueless-when- it-comes-to-TeX mode. Hope nobody will take offense]. Obviously there is quite a bit of room of disagreement about how likely it is for changed-but-not-renamed files to accidentally end up in unlikely places (as someone who has had the experience of running rm -rf on a directory containing two weeks' worth of source code that I was just about to back up for the first time, I can testify that any kind of havoc that can possibly be wrought using fileutils has a nonzero probablility of happening somewhere somewhen), and how much is reasonable to force someone who knows what he's doing to jump trough hoops to prevent it. But even if we don't *agree* that the fear justifies the means, we should nevertheless *understand* what it is. The "option 3" you propose would entail that two directory trees existed, one which is the original LaTeX, and one where the kernel is modified and renames but the rest of the files (say, third-party style files) may be modified *without* renaming. Thus there would still be a danger if the search path for the pristine software were to be contaminated with references to the hacked tree. Or am I misunderstanding what option 3 is about? -- Henning Makholm "... and that Greek, Thucydides" -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]