Re: Towards a new LPPL draft
Frank Mittelbach <frank.mittelbach@latex-project.org> 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 <nowan@nowan.org>
PGP fingerprint: 748F 4D16 538E 75D6 8333 9E10 D212 B5ED 37D0 0A03
--
To UNSUBSCRIBE, email to debian-legal-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Reply to: