[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Question(s) for clarifications with respect to the LPPL discussion

Scripsit Frank Mittelbach <frank.mittelbach@latex-project.org>

> Concern 1: requiring a change of filename in case of modification 
>            in case of distribution
> =================================================================
> this seems to me the major stumbling point  for most people and
> (unfortunately the most important point for us)

I think it is important to realize that what people have problems
about is not in itself that a name change is required. The problems
are about the *granularity* with which this requirement is being

Somebody has repeatedly asserted that it would be OK to do anything
with LaTeX as long as the modified LaTeX has another name than
latex. I cannot find support for it in the draft we're discussing here
- it says that if the name of each individual *file* *in* LaTeX must
be changed in the project. This means, effectively, that forking LaTeX
requires that one renames *all* the files, and then sifts through all
of the code to track cross-references between files. This is not
trivial with TeX macro code and is certainly not automateable - so it
has to be done by humans, which means that there is no way to fork
LaTeX which is at once legal and likely not to break functionality
that one wants to keep.

(That is, unless one also changes the TeX binary to do strange
nonintuitive mappings in its \input primitive, which I here assume
that one doesn't want to do. Also, some people have said something
to the effect that the word "file" in the LPPL essentially refers
to the token string given as argument to \input, so even changing
TeX wouldn't work).

> Argument 1.1: the need to fix a file because of a security problem
> Argument 1.2: the need to fix a file because of a bug
> Argument 1.3: the wish to change a file because of improvements made

These are all arguments, with varying strength, for the important
principle that the DFSG is meant to protect the Golden Rule:

    For software to be free, it must be legal to fork it.

This is supposed to hold for all software in Debian, and when the
arguments do sound rather feeble in the case of LaTeX it is because
there seems to be no really good reasons to actually fork LaTeX.
When we nevertheless hold that the legal ability to do so must be
present in the case of LaTeX, it is not for the main part because of
intrinsic reasons in LaTeX, but because the Debian project would
become a madhouse if we began waiving the Golden Rule for individual
pieces of software just because someone thinks it is not really needed
for that particular piece of software.

This perspective - that from Debian's point of wiev the necessity of
the ability to fork is an axiom and not something that needs to be
argued for each piece of software in isolation - has a tendency to be
lost in the detailed discussions on debian-legal where well-meaning
regular try to convince upstream authors that forkability is a good
thing independently of whether Debian will distribute the software
or not. It sometimes helps inexperienced upstream authors to see the light
when the general principles are spelled out in the context of their
particular brainchild - but on the other hand it creates the
impression that forkability is a negotiable requirement.

(Unfortunately my previous contribution to this discussion so far has
been in one of those confusion-spewing subthreads, for which I
apologize to all readers who care).

However, let's credit the LaTeX people with more wits than those of
"inexperiences upstream authors" and be honest about it: We want LaTeX
to be forkable because, as a matter of principle, we want all software
that Debian distributes, to be forkable. It's one of the ways that we
add value for our users: When they download something from the main
part of Debian's archive, they know that we have screened its license
terms and tried to make sure that they'll have the legal ability to
fork it if *they* somewhen, somehow, reach the conslusion that they
want to do so.

We don't say "all our software for which we can imagine a valid reason
for you to fork, is forkable". We say "all our software is forkable".

However, we don't require it to be possible to fork a project and pass
the forked off as the original. Requiring that modified version are
clearly identified as having been modified, and, where applicable
idenfifiy themselves as such in their banners or diagnostic output.

So the basic goal that the LaTeX people are trying to enforce with
their license is not intrinsically incompatible with the DFSG - but I
think that the focus on changing the names of *files* rather than the
entire program is a too rigid way of reaching that goal.

> From: Jeff Licquia <licquia@debian.org>
> http://lists.debian.org/debian-legal/2002/debian-legal-200207/msg00174.html

>  Our Social Contract states that "Our Priorities are Our Users and Free
>  Software".  User needs are as important to us as freedom, and we
>  wouldn't be serving our users if we broke LaTeX document compatibility. 

This is a relevant quote because it basically points out that the
freedoms of that the DFSG requires are not only there because the
Debian developers need them. Sometimes the DFSG requires freedoms
that the Debian project itself would never dream of using. But we
want our *users* to have them.

Henning Makholm                    "*Her* sidder jaj & har *ild* bå cigarren
                            *imens* Pelle Jönsson i Nordnorge har mavepine."

To UNSUBSCRIBE, email to debian-legal-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

Reply to: