LATEX-L Archives

Mailing list for the LaTeX3 project


Options: Use Forum View

Use Monospaced Font
Show Text Part by Default
Show All Mail Headers

Message: [<< First] [< Prev] [Next >] [Last >>]
Topic: [<< First] [< Prev] [Next >] [Last >>]
Author: [<< First] [< Prev] [Next >] [Last >>]

Print Reply
Frank Mittelbach <[log in to unmask]>
Reply To:
Mailing list for the LaTeX3 project <[log in to unmask]>
Mon, 1 Jul 2002 20:30:17 +0200
text/plain (95 lines)

I think you are very mistaken about the purpose and reasoning behind LPPL.

 > I don't think that the license has to assume that anyone making
 > changes is up to no good and restrict people's ability to make
 > those changes or to make those changes available in some form.

LPPL does not try to prevent people from making changes or from benefitting
from progress. It offers a clear route for supporting change at any time (you
only have to change the name). Its fundamental goal, however is to preserve
the main feature of LaTeX: its universal exchangability of documents. Package
and class files are, if you will, part of the language of latex and therefore
at a given point in time should "ideally" be identical at all sites.

In this respect it is like a programming language: the programming language
may change from language version to language version (features may get added
or changed) but within one language release you can (again ideally) expect
that a source program written in that language will compile at any site that
uses this release of the language.

Same with latex, except that the changes (and more often the additions) to the
language are larger in numbers than with something like FORTRAN. What the
license tries to ensure is that something is not called FORTRAN77 but
FORTRAN2002 if its spec is changed.

 > At
 > the moment, the LPPL doesn't prevent an original author from
 > making significant changes to their package that break backwards
 > compatibility or even completely change its functionality.

There is no reason for LPPL to prevent that, just as it doesn't intend to
prevent development or improvement. It is true that if a package changes
significantly different releases of LaTeX may not compile documents in the
same way. But the most siginifcant part that LPPL tries to capture is still
valid: identical releases will give identical results and due to LPPL there
can only be one "current" release for a package with the name xxx.

A completely different situation would arise if packages would be distributed
under,say, GPL. Then it would be perfectly permissible to locally enhance
files for one or the other reason (with good or without good reason is
irrelevant here) and thus resulting in documents behaving differently on
different sites even if both sites started from the same files --- and in many
cases without the author of a document having a chance (other than using her
own implementation on her own pc).

[ Just assume that a maintainer of a university site would change the number
of lines in the article class a number of times because he or she is reading
different books on typography (with different suggestions) and she gradually
learns that the defaults in that class are really bad (which they are to some
extend but that history).  --- this may sound like a strange scenario, but it
isn't really. At the end of LaTeX209 half the sites in Europe couldn't
exchanges files between each other because all had their local "corrections"
without labeling them as such. ]

Again: LPPL does not prevent such changes, corrections, enhancements! It only
channels them by requesting a change in name to ensure the above.

It is true that we (the project team) keep the LaTeX kernel very closely
garded with respect to backward and forward compatibility (meaning adding new
features in the kernel, which is too a sort of incompatibility as it means
that using this feature results in failure on older releases) --- this is done
to keep the core stable and help portability through different releases of
LaTeX. However, this does not follow from applying LPPL at all, and we think
that anything outside the core does not and should not necessarily follow this
principle (even if it makes life for organisations like the AMS slightly more

Now coming back to the earlier question:

 > Do we really need to have a time limit built into the license?
 > If what we're concerned about here is someone ``hijacking'' a
 > particular package, then it might make more sense to define some
 > restrictions on uploading to CTAN and leaving the license such
 > that anyone can modify the package and make it available somewhere
 > else.

all my attempts where not done to prevent hijacking but rather to give an
agreed way to take a package further when the original author is no longer
able/interested in developing/maintaining it. Otherwise a package under LPPL
has indeed the danger that one has to unnecessarily start from a new name just
to comply to the license.

But in fact in most situations this isn't what the authors of packages would
like to have. they would like to have the package live on after they stopped
using latex or being able to maintain it. by defining a suitable process for
this case and allowing the authors to agree to this process beforehand (by
using the license) the situation improved (imho) without losing the major goal
for LPPL out of sight.