Frank Mittelbach <[EMAIL PROTECTED]> writes: > let me first qualify the suggestion that Jeff made above > > - the reason for it is to give the user the possibility to exchanges > documents with other using pristine LaTeX and obtain identical output > > - it therefore quite pointless to carry around some old pristine LaTeX from > the day of the fork; if the above suggestion has to have value to the goals > we try to achieve with the LPPL license, then the suggestion would be to > keep a copy of current pristine LaTeX, though I doubt that could or should > be codified except as a suggestion.
I certainly have no problem with a suggestion. I also don't really have a problem with the requirement of a pointer to a place to find a pristine latex (with the caveat, of course, that if no such place exists to the best knowledge of the distributor that requirement is void). > in a redraft of LPPL i wuold try to limit any renaming requirement to such > files that need to change their file names in order to make this distinction > (or use the requirement to distinguish as the requirement rather than the > file name and only remark that in most cases this might mean that certain > files need new names. -> readme.txt would not need to change. I like the idea of making the requirement to distinguish the requirement. That provides flexibility in the odd (and unlikely) edge-cases that might need it. It also maintains your intentions better in those situations, I suspect. > from that it also follows that if on an OS with a different type of > filestructure (say MVS) that revised requirement would have other effects > (i've forgotten what the things got called on mvs, but all the classes lived > a > single datastructures with members there, and so you wouldhave to chose a > different member name) > > does this answer the question? Yes. Thank you. > - if a file is not used by pristine LaTeX (that is a LaTeX kernel without the > remapping feature added) then there is no need for a renaming of any kind > > - otherwise, if it is an object used at some point in the game by the > underlying macroprocessor (ie loaded) then the "name" used for loading > should be different --- that is not thefile name though in most > implementation it is a one to one mapping (which is why we suggested to use > the filename rename as an requirement. If this is codified into the license, I see no issue with its DFSG-freeness. This states your intention (that a reference to 'foo' always reference the same thing) but creates an explicit (in the license) loophole in form of the filename remapping facility. -- Jeremy Hankins <[EMAIL PROTECTED]> PGP fingerprint: 748F 4D16 538E 75D6 8333 9E10 D212 B5ED 37D0 0A03 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]