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.

>
> 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.
>            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

> 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