Re: Motivations; proposed alternative license
Frank Mittelbach <frank.mittelbach@latex-project.org> wrote:
> Walter Landry writes:
> > Well, there were my comments that preventing the modification or
> > removal of .ins files goes beyond what clause 4 allows. I even gave
> > an example where it might be completely appropriate to do such a
> > thing. The message should be in the debian-legal archive.
>
> sorry, yes there are such comments and i try to pay attention to them (that
> particular concern should be gone in the draft of two days ago (it was a
> leftover)
Great! I look forward to the new draft.
> concerning patches and klingons
>
> a) LaTeX has support for klingons (i have never tried it but it is somewhere,
> i've seen it) ... :-)
>
> b) latex or rather tex is a macro language in other words yu can modify
> anything of it at any time during the process not just data but program.
>
> c) that means you are not restricted into only one way of patching stuff
> eg the package hyperref redefines a good deal of the kernel and a large
> number of commands from other packages (so everybody now knows that this
> packages is best loaded last:-)
Now you seem to be saying that there are so many ways to modify Latex
that I would never need to change article.cls. What if article.cls is
itself broken? Why can't I fix it and distribute that fix?
> yes. we do as well about 90% of the latex software around has
> nothing to do with the latex project team from which the license
> comes. it is neither certified or directly integrated nor
> anything. it improves on the kernel or addes new features to the
> language (including klingon or whatever) therby probably breaking a
> lot of things within the language if used together but all that is
> fine and okay under the license. the license only ensures that
>
> \usepackage{klingon}
> \usepackage{babel}
>
> will break in the same way here as well at your desk so that if i send you
>
> \usepackage{klingon}
> \usepackage{babel}
> \renewcommand\klingonblabla....
>
> it will work for you (for the current document) because it worked here.
What if the "official" version of the Klingon package erases my hard
drive, because I'm using a MIPS machine, and the person who wrote the
Klingon package uses a SuperH machine? Under the LPPL, I can't even
send a copy of the fixed file (along with other improvements) back to
the original author unless I change the filename. Even my friends who
are using SuperH will have to change their files from
\usepackage{klingon}
to
\usepackage{klingon-fixed}
to get the other improvements until the original maintainer (who might
be dead or otherwise not incommunicado) releases an updated version.
And he might never, because he works for Hitachi and doesn't talk to
MIPS people.
What I am trying to impress upon you here is that free software must
be allowed to evolve in ways that the original author had never dreamt
of and may not approve of. Clause 4 of the DFSG is a compromise that
allows certain restrictions, but the LPPL goes far beyond that.
Debian must be able to change article.cls and still call it
article.cls. Clause 4 allows you to require source code changes to be
distributed as a patch, and you can require the final product to be
called something else (e.g. DebTex). But you must allow the final
installation to be different from what you envision.
Regards,
Walter Landry
wlandry@ucsd.edu
--
To UNSUBSCRIBE, email to debian-legal-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Reply to: