Re: Encoding the name in the file contents (was Re: Towards a new LPPL draft)

[Henning Makholm <henning@makholm.net>]

Scripsit Frank Mittelbach <frank.mittelbach@latex-project.org>

> If
>    LaTex2e <1999/12/01> patch level 1
> would identify that the system you are using is ULL, then Mark has
> an argument that (after some education) it should be enough to have
> people check for that particular line. The counter argument is that
> there are many TeX front ends these days that hide all of that
> stuff, so it isn't that easy.
> 
> However, the point that both of you miss in this discussion (as well as in
> earlier posts about it by Thomas and Henning) is the following:
>  This line only identifies the LaTeX kernel

I wasn't missing the point (or at least, I don't hope so), merely
ignoring it temporarily while a subquestion was discussed.

> 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. 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. Legal
modifications would include

  - with name changes as in the current license.
  - content changes without changing the kernel. Which will cause
    the kernel to scream bloody murder, but won't harm functionality.
  - content changes *and* a change to the kernel, possibly changing
    it to \let\NotACanonicalSourceFile\relax. Since initex doesn't
    know \NotACanonicalSourceFile, option A(3) is not available for
    latex.ltx, but I think a name change for the format file will
    be acceptable, because the format name appears neither in .sty
    files or documents - the filename of the format is not an API.

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)?

-- 
Henning Makholm                    "It's kind of scary. Win a revolution and
                                a bunch of lawyers pop out of the woodwork."


-- 
To UNSUBSCRIBE, email to debian-legal-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org