Re: forwarded message from Jeff Licquia
Scripsit Frank Mittelbach <frank.mittelbach@latex-project.org>
> no. *each* file that you change must be renamed, but where is the problem
> here? I think it has also been demonstrated that is neither excessive nor in
> conflict with DSFG 3+4
I still think it can be viewed as excessive. Let me explain.
Imagine that I want to create a typesetting system that behaves just
like LaTeX on all input files, except that input files that say
something like
\documentclass[12pt]{article}
will actually be typeset with a 13-point font (and similarly for the
other standard classes). Note that I have deliberately selected an
extremely silly task, because I already conceded that I can think of
no non-silly reasons to want to fork LaTeX although I do care for the
theoretical ability to fork nevertheless.
Now, the technically sane way to achieve my goal would be to make
some small modifications to size12.clo, or whereever in classes.dtx
the lines in size12.clo come from. To do this, I'd have to change the
name of size12.clo - I suppose the intention of the LPPL is that it
will not be enough for me to rename classes.dtx and have the renamed
.dtx file generate a size12.clo with nonstandard contents.
However, when I modify the name of size12.clo I need to make sure that
article.cls can find my modified file. For example, article.cls
contains something like
\DeclareOption{12pt}{\renewcommand\@ptsize{2}}
...
\input{size1\@ptsize.clo}
so I need to modify that logic; otherwise things will not work.
Similarly for report.cls and letter.cls. OK, so I have to rename
the standard classes.
But since I want source compatibility (of a sort...) with LaTeX, a
document that says
\documentclass[12pt]{article}
must be able to find my changed and renamed article.cls. And what's
more, my boundary conditions for the fork are that if the user has
written his own class file that says
\LoadClass{article}
that one, too, must inherit the different behavior of the 12pt option
from the standard class.
That sends me messing with the class-loading code in the kernel. I do
not protest about having to call my kernel something else than
latex.ltx even if I didn't change its functional contents, and nothing
references the kernel by name anyway, so the renaming cascade stops
here - unless I've overlooked some other filename interaction.
However, look at the net effect of the cascade. What I initially
wanted to do was a simple change of a few decimal numbers in the
.clo file. Now, as the result of the renaming rule and only the
renaming rule, I find myself recoding some deep magic in the kernel
which will probably require that I'm able to keep a dozen double-bend
paragraphs from The TeXbook afloat in my head at once - in addition
to knowing which double-bend paragraphs to load into my head in the
first place.
Personally I am megalomanic enough to believe I have memoized
sufficiently large parts of The TeXbook to be able to make an attempt,
and perhaps even have it work after a few days of debugging. But I
certainly don't believe that everyone capable of changing a few
numbers in the .clo file will be able to do it. So the morale I'm
aiming at is that the renaming rule will prevent some people from
doing modifications that they would otherwise be technically competent
to do.
> Note that there are many individual works (each consisting typically
> of a small number of files) that are licensed these days under LPPL.
Point taken. So I agree that all packages do not have to be renamed.
BTW, is there an easy way to figure out which collections of files
constitute a work? In the teTeX installation I do my daily work with,
texmf/tex/latex/base contains 123 files - are they all one work, or
are they divided somehow?
> > I'm confused about what you mean here. Since it already has been
> > established that the ideal goals seem to be compatible, why do you
> > insist that we "come back" to that question instead of moving on to
> > "reformulating it so that everything gets clearer"?
> is it established? if so fine, I wasn't so sure seeing arguments like
> But we can not tolerate means to reach this goal, that are
> against our principles, against our ethics.
On Debian lists there'll always be random fallout from earlier phases
of the discussion - I'm guilty of this myself sometimes. However, I
think the guy that you quote here was merely stating an intention to
work on finding alternative means to reach your goal that does not
clash with our pinciples. (Here I'm deliberately overlooking the
possible interpretation that he was flaming, which is best overlooked
even if it should happen to be true).
Some disclaimers: Yes, I am aware that the points I make here apply
equally well to the current licence of LaTeX. No, that doesn't mean
that I'm arguing that LaTeX should be dropped from Debian immediately
until such time that we can persuade the LaTeX project to change its
licence. Although some of the more zealous (and influental?) regulars
on debian-legal might well hold that opinion. I usually argue the idea
that a few select pieces of software, including (La)TeX and Emacs, are
so universally desired that realpolitik forces us to be slightly
lenient with the aspects of their licenses that we wouldn't like if
they were attached to less essential programs. However it would be
silly to maintain that position while the upstream author in question
is acutally listening and trying to be cooperative.
--
Henning Makholm "Detta, sade de, vore rena sanningen;
ty de kunde tala sanning lika väl som någon
annan, när de bara visste vad det tjänade til."
--
To UNSUBSCRIBE, email to debian-legal-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Reply to: