X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil] ["7494" "Fri" "14" "July" "1995" "15:28:32" "-0300" "David Carlisle" "carlisle@CS.MAN.AC.UK" nil "155" "Re: 4 small packages of basic 2e code made available" "^Date:" nil nil "7" nil nil nil nil] nil) Received: from MZDMZA.ZDV.UNI-MAINZ.DE (vzdmzi.zdv.Uni-Mainz.DE [134.93.8.15]) by trudi.zdv.Uni-Mainz.DE (8.6.12/8.6.12) with ESMTP id QAA19937 for ; Fri, 14 Jul 1995 16:30:26 +0200 Received: from DIRECTORY-DAEMON by MZDMZA.ZDV.UNI-MAINZ.DE (PMDF V4.3-12 #4432) id <01HSV7V1QGQO9D4DJ7@MZDMZA.ZDV.UNI-MAINZ.DE>; Fri, 14 Jul 1995 16:30:10 +0100 Received: from listserv.gmd.de by MZDMZA.ZDV.UNI-MAINZ.DE (PMDF V4.3-12 #4432) id <01HSV7UVM7NK8WW5T5@MZDMZA.ZDV.UNI-MAINZ.DE>; Fri, 14 Jul 1995 16:30:05 +0100 Received: from listserv.gmd.de by listserv.gmd.de (LSMTP for OpenVMS v0.1a) with SMTP id 89CC14D0 ; Fri, 14 Jul 1995 16:30:04 +0200 Received: from VM.URZ.UNI-HEIDELBERG.DE by VM.URZ.UNI-HEIDELBERG.DE (LISTSERV release 1.8b) with NJE id 0798 for LATEX-L@VM.URZ.UNI-HEIDELBERG.DE; Fri, 14 Jul 1995 16:29:39 +0000 Received: from DHDURZ1 (NJE origin SMTP@DHDURZ1) by VM.URZ.UNI-HEIDELBERG.DE (LMail V1.2a/1.8a) with BSMTP id 1658; Fri, 14 Jul 1995 16:28:43 +0000 Received: from m1.cs.man.ac.uk by vm.urz.Uni-Heidelberg.de (IBM VM SMTP V2R2) with TCP; Fri, 14 Jul 95 16:28:42 CET Received: from r8h.cs.man.ac.uk by m1.cs.man.ac.uk (4.1/SMI-4.1:AL5l) id AA08226; Fri, 14 Jul 95 15:28:34 BST Reply-to: Mailing list for the LaTeX3 project Message-id: <9507141428.AA07374@r8h.cs.man.ac.uk> X-Envelope-to: schoepf@goofy.zdv.uni-mainz.de MIME-version: 1.0 Content-type: TEXT/PLAIN; CHARSET=US-ASCII Content-transfer-encoding: 7BIT Date: Fri, 14 Jul 1995 15:28:32 -0300 (BST) From: David Carlisle Sender: Mailing list for the LaTeX3 project To: Multiple recipients of list LATEX-L Subject: Re: 4 small packages of basic 2e code made available Status: R X-Status: X-Keywords: X-UID: 1691 [Matt sent the following reply to Frank's message. As he said we could forward it to this list, and Frank is (or is about to be) away, I thought I would quote it in full then make some comments at the end David] > > > > Following is a description of the files in this directory. These bits > > are, a nd > the future package will be, protected by the Gnu Public License, > > unless some o ne > wants to convince me otherwise. > > > I would like to convince him otherwise. > > OK, I'm going to re-consider. I have saved some of the recent discussion of > the modguide, and I will read the modguide itself more closely. > > > Under GPL it would be possible to produce a system which claims to be LaTeX > > but violates this basic right. > > I do not yet understand why this is true. I suspect it is true > because the GPL makes no mention of disk file names. That is, makes > no restriction on them. Disk file names are a pain in the neck! In > the paper I will present at TUG'95, > I discuss ways to bury disk file names in a layer of abstraction; one would > \usepackage{} and \requirepackage{} a feature name which would be > mapped to a disk file, a part of a disk file, or a number of parts. > > I sent an email suggesting this solution to the list a couple of > weeks ago, but I'm not sure it ever was distributed, because I don't > think I received a copy.... I reiterate below. > > Disk file names can continue to uniquely identify segments of code; this is > all I think that is necessary to preserve the "standard LaTeX" as strictly as > you wish -- I agree with this priorty. At the site level, however, > it will be easy to make extensions and modifications of the standard > LaTeX -- much easier than is possible with the present system. > > Let's consider for simplicity a replacement for article.cls. Do you > think that a LaTeX source document which has the line > "\documentclass{article}" should ideally compile to an identical dvi > file on every LaTeX site? I don't think so, I think a site should > be free to make changes without having to write, say, "xarticle". > 1) it is very desirable for every user to be easily able to get an > identical dvi file from this document. 2) it is very desirable for an > individual user or site to be able to easily get a different dvi > file from the same document. The present system is not so good on > 2; using the GPL will compromise 1. If you agree with both 1 and 2, > then the only solution I see is the separation of disk file names > from feature names. Also, I think the GPL will be no problem then > (but I will try to understand your point better before saying I'm > sure of this). > > Maybe you disagree with the value of 2, thinking it represents a > danger to the achievement of 1. I don't think it needs to be a > danger, but this would be a point for further discussion. > > A hierarchical path-searching engine like kpathsea would be sufficient for 2, > but not everyone has this kind of search engine, and this solution requires > different files to share the same name, which does in fact > compromise 1. If as I suggest files load features not disk files, > then a hierarchical search-engine is a good way of achieving 2: the > local person makes a deliberate choice to put certain directories > before the standard directory in > the search path. Since enot every platform has such a system, > another solution must also be devised for them. > I haven't thought too hard, but a table of > (local) exceptions to the standard feature-to-diskfile mapping seems > a perfectly decent and simple way. > There are a lot of combinations of ways to arrive at something > satisfactory; I hope to think more of them through soon. > > Feel free to quote this letter if you wish to make a reply to the > LATEX-L list; maybe I am just repeating myself: as I say I'm not > sure whether my previous message made it out to everyone. > > Sincerely, > > Matt > I do not think that it is really just filenames that are the issue. If a document contains \usepackage{array}[1994/10/16] Then anyone running that document who gets past that stage without a warning is running a recent version of array.sty and so will not fall over a primitive TeX `undefined command' error if the document uses the command \firsthline. If however an `alternative' array package had been developed and its development path had diverged before this date, then a recent copy of this alternative might not have the new feature and so there would be no traps to prevent primitive TeX errors occuring. Note that the file name is not the important thing here, it is the user syntax. If the alternative version was in a file alt-array.foo which got mapped to \usepackage{array} by some local mapping file, the same problem would occur. Thus for users using a command `latex' (or whatever the standard calling sequence/menu option/... is), standard package and class names names should map down to the standard *code*. Note that this does not prevent locally modified versions with different behaviour. One could take the latex source code and chage the names of some files (to allow modification) and then generate a format swift-latex.fmt that was identical to standard LaTeX except for the \everyjob banner and the fact that \@pkgextension was defined as \def\@pkgextension{foo} rather than \def\@pkgextension{sty} This would have the effect that \usepackage{array} loaded array.foo and array.foo could do whatever you wanted. The important thing is that on any `site' or `distributed' installation the users have access to `standard LaTeX' (ie customised up to the limits in cfgguide). If they also have access to a `non-standard' latex then that is fine. It is then clear to everybody that the behaviour of that version should not be relied apon at another site. In fact it is not always necessary to build a new customised format. Locally we have a `pslatex' command that is just a shell script that issues a banner on the terminal and then `drops' something like \usepackage{times,mathptm} into the file as seen by TeX. thus users can use latex to get cm fonts or pslatex to get adobe times without editing the document. As regards the GPL consider one important difference between laTeX and, say, gcc. Under GPL one can take the gcc code and make yourself a better C compiler, however there are limits on what one can call a C compiler as C has a definition apart from its gcc implementation. It would not make sense to call a fortran compiler `gcc' just because you thought the syntax of fortran an improvement of that of C. We get all kinds of `enhancement' requests for LaTeX. While many of them make sense individually it is quite likely that they are mutually incompatible. If it were allowed for individual distributions to make these `enhancements' and still call the resulting language LaTeX then chaos would result, and LaTeX would no longer be able to be used as a means of transporting documents. It is this requirement to try to maintain control over the language LaTeX, that we need rather different control than that provided by GPL. (It is not an ideal situation that LaTeX is defined by its implementation, but that is the current situation, and one that is not easy to change starting from the current position.) Also LaTeX is currently used in some commercial products in ways that may conflict with GPL. So we could not incorporate GPL'ed code as that may force the whole of LaTeX under GPL. David