LATEX-L Archives

Mailing list for the LaTeX3 project

LATEX-L@LISTSERV.UNI-HEIDELBERG.DE

Options: Use Classic View

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

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

Print Reply
Frank Mittelbach <[log in to unmask]>
Wed, 10 Jul 2002 22:14:30 +0200
text/plain (94 lines)
C.M. Connelly writes:
 > "MS" == Martin Schroeder <[log in to unmask]>
 > "LD" == Loic Dachary  <[log in to unmask]>
 >
 >     LD> I think the LPPL is trying to define and enforce a
 >     LD> distribution policy within the license.  This is a strange
 >     LD> idea. Imagine what mess it would be if the Linux kernel
 >     LD> imposed the same restrictions on system calls ?-) Instead
 >     LD> a specification was issued
 >     LD> (http://www.opengroup.org/onlinepubs/007908799/) to
 >     LD> encourage the necessary standardization and
 >     LD> uniformity. Defining a standard interface and behaviour is
 >     LD> a complex matter that can hardly be implemented by a
 >     LD> license.
 >
 >     MS> "The Single UNIX® Specification, Version 2" -- which I
 >     MS> find irrelevant here.
 >
 > Yes, the specification is irrelevant, but Loic's point was that a
 > license cannot force standardization; that job has to be left to a
 > group of interested parties who draft a standards document that
 > define what bits make up a complete system, how they interact,
 > their interface, what sort of output they produce, and so on.

but he doesn't give a reason for it other than

         > Defining a standard interface and behaviour is
 >     LD> a complex matter that can hardly be implemented by a
 >     LD> license.

and there he is just voicing an opinion. fact is that latex software can, has
successfully done so (via LPPL) and through this process has resolved a very
difficult situation with a lot of incompatibilities within the language
definition.

that this model my not be appropriate in other situation is certainly true but
what does this prove or point out?

 > In other words, he wasn't suggesting you look at the document
 > because it would tell you anything about LaTeX, he was suggesting
 > that the process that produced the document is worth looking at.
 > (And perhaps that the document itself might serve as a model for a
 > LaTeX standard.)

certainly worth looking at it. and this was exactly after looking at this
approach as an option (i.e. to put LaTeX under GPL) that we came to the
conclusion that it is not the right approach for software of a type like
LaTeX.


 > The basic idea here is that if you want to keep LaTeX pure, you
 > can take one of two approaches:
 >
 >    1. Impose a restrictive, non-free license that prevents
 >       modification of key components

Claire, stop right here please!!!!

where does that "non-free" comes from? I repeat:

a) all that is in LPPL is not in conflict with the OSI or Debian guideline
(unless proven otherwise)

b) especially the question about requesting a name change as part of a
modification is _part_ of Debian + OSI (as one possible approach)
so the fact that Loic Dachary and others don't like it is not something from
which "non-free"

 >    2. Develop an open standard that defines the behavior of the
 >       system in a testable way

as sensible approach in the right context and the right environment ---
impractial and not resulting in the desired results for the users (who also
have rights!) with something like LaTeX. For the LaTeX kernel itself it could
have been the model together with a suitable test set, but LaTeX is the
combination of a large environment which is in that form untestable (in
reality) but  kept sane because of LPPL --- while being free for change
andaddition.


but again, that is not the question really, the question is is LaTeX free
software by some standards and that wasn't touched by this argument in my
opinin.

frank

ps the only real argument that I saw so far was the problem of the license
allowing additions which may make something under LPPL due to further
restrictions in individual files unfree --- that is a fair argument and it is
precisely the argument that I was removing by proposing to remove/change that
part. which by the way is why I found Martin's attempt to start a discussion
on LPPL 1.2 not really helpful (especially not if it is not backed up by
arguing the case)

ATOM RSS1 RSS2