[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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

I'm just got back online and found 100 messages or so. I will come to the
thread "Concluding the LPPL debate, try 2" at some point, but some of the
mails I read contain some misunderstanding that I think needs clearing up as
well (as they might help to come to a conclusion on the above thread) ... 

Henning Makholm writes:
 > Scripsit Mark Rafn <dagon@dagon.net>
 > > On 25 Jul 2002, Henning Makholm wrote:
 > > > pc-043:~/foo$ latex radio.tex
 > > > This is TeX, Version 3.14159 (Web2C 7.3.1)
 > > > (radio.tex
 > > > LaTeX2e <1999/12/01> patch level 1
 > > Cool.  Is it possible to simply add a requirement "the identification 
 > > string when used must state that it has been modified".  You'd then get
 > >   LaTex2e <1999/12/01> patch level 1 modified by markr 
 > > or whatever.  Users who wanted an unmodified version would then know to go 
 > > get one.
 > This is already required, but the LaTeX community does not trust this
 > mechanism enough to really provide users with knowledge. As I said
 > (and as you demonstrated in practise) hardly anybody ever looks at the
 > spew of boot-up messages that scrolls by after one starts latex.


   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

But that is identifying the starting point, a small fraction of what comprises
the ULL (Unique LaTeX Language). So that line doesn't tell anything about
whether or not a package written by some author and distributed under LPPL (ie
thereby being part of (ULL).

Thus if you fork the kernel, then this line is supposed to be telling that
this is not LaTeX but if the kernel stays unchanged then this line is
unchanged too. 

Thus, if you modify times.sty or mathptm.sty or whatever, then this line
will not change, even though these are individual works under LPPL and forming
part of the ULL. Eg this small document (which typesets a word and a formula
in Times Roman and Adobe symbol and changes the default LaTeX article page
layout to have different margins):

   Test $a=b$

 - first emits that kernel idenfication line

 - and then loads files from 4 (!) independ works (all under LPPL and thus all
 belonging to the ULL)

   article.cls size10.clo     from the LaTex base distribution
   times.sty mathptm.sty      from the PSNFSS distribution
      ot1ptm.fd ...           from fontinst generation for psnfss
   geometry.sty		      from geometry distribution
   keyval.sty		      from graphics distribution (loaded by geometry)

if any of those files are changed inplace on one installation but not on
others, then the above document will produce different output without the user
having a chance to notice as the above identication line doesn't show it. And
note, that there are several hundreds independ works that form the ULL and
that they might load each other (as geometry loads keyval).

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

 LaTeX2e <1999/12/01> patch level 1 with file remapping enabled
 !!  Check end of LaTeX run to see if portable output was 
 !!  produced!

and at the end of the run perhaps:

 !!  WARNING: This document was produced using a number of
 !!  locally modified files so it may format differently on
 !!  other installations.
 !!    Standard:		Replaced by:
 !!    article.cls		article.fcl
 !!    geometry.sty		geometry.fst


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

Reply to: