Re: Encoding the name in the file contents (was Re: Towards a new LPPL draft)
Henning Makholm writes:
> > As I said earlier, I guess we could be persuaded to provide two
> > kernels within LaTeX distribution, one as it is now, and one with
> > the remapping feature already available. If that kernel would be
> > used then you would perhaps get
>
> I'm not keen about a solution which needs two kernels because the
> regular kernel was considered "not free enough". It would mean the
> Debian would end up distributing the non-regular kernel in its main
> section; not a desirable outcome for any of us.
Just to make one point clear here:
It wasn't my intention at all to provide two kernel because I thought that
one of them was not free enough. That interpretation would indeed lead to an
desirable outcome.
I consider already the normal kernel complient as it allows you to produce
such a second kernel. You can consider such kernels as implementing command
line options if you like (as that is something TeX/LaTeX is doing somewhat
poorly).
Anyway I agree with you that several kernel's are not necessary.
> However, what about:
>
> A. Distribution terms that say that
> "You can redistribute files if one of the following hold:
> 1) The contents of the file is completely unchanged.
> 2) Certain file name restrictions are observed .. yadda yadda
> yadda.
> Also, you must change any human-readable identification
> strings in the file to note that you have changed it.
> [This is by far the recommended option if you want to
> change the behavior of The Program. See xxguide.tex for an
> explanation of why we think so.]
> 3) You make sure that when TeX reads the file, the VERY FIRST
> token it finds is "\NotACanonicalSourceFile".
> Also, you must change any human-readable identification
> strings in the file to note that you have changed it.
> [This option is provided because in certain extremely
> unlikely situations somebody MAY need it. Please think
> at least twice before deciding you're that somebody.]"
> Here option (2), while its DFSG-freedom is debatable, will still
> be used by the vast majority of sane people who want to change
> something. Option (3) is there to make DFSG-freedom undeniable.
>
> B. Only one kernel. This kernel will, however, be extended to define
> \NotACanonicalSourceFile as a macro that
> i) Screams bloody murder on stdout and the log file.
> (unless this has already been done once).
> ii) Arranges for a similar warning to be emitted at the
> \end{document}.
> iii) Except for that, _continues processing_ the document.
>
> When one combines A(3) and B(iii), it shows that inserting
> \NotACanonicalSourceFile is only a way to flag the source file as
> having been changed, in a way that will be obvious to a human user.
> It is important that the presence of \NotACanonicalSourceFile _does
> not change the .dvi output_; this means that A(3) does not ask for a
> _functional_ change as a prerequisite for same-filename changes.
>
> I have reason to hope that such a scheme would satisfy all of the
> interests and principles stated in the discussion so far.
that seems to be the case as far as I can see. I would however use
\NeedsTeXFormat in place of \NotACanonicalSourceFile as that would be more
flexible and is already available.
> The only thing that's not completely covered are the integrated
> environments that Frank speaks about where users do not see any of
> TeX's output to the terminal at all. Could that be solved by
> masquerading the warning messages as regular TeX errors/warnings
> (surely users of such environments get told about overfull/underfull
> boxes, or what)?
there are probably ways to mend that problem as well
frank
--
To UNSUBSCRIBE, email to debian-legal-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Reply to: