Mime-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha1;
        protocol="application/pgp-signature"; boundary="H/P/fp31Su+ob3Cg"
Content-Disposition: inline
Return-path: <[log in to unmask]>
Envelope-to: [log in to unmask]
Delivery-date: Tue, 16 Jul 2002 22:40:59 +0200
Received: from pop.kundenserver.de []
        by localhost with POP3 (fetchmail-5.6.5)
        for frank@localhost (single-drop); Tue, 16 Jul 2002 22:45:11 +0200 (CEST)
Received: from [] (helo=rzdspc1.informatik.uni-hamburg.de)
        by mxng06.kundenserver.de with esmtp (Exim 3.22 #2)
        id 17UZ7w-0002Bl-00
        for [log in to unmask]; Tue, 16 Jul 2002 22:40:56 +0200
Received: from sun.dante.de ([log in to unmask] [])
        by rzdspc1.informatik.uni-hamburg.de (8.12.5/8.12.5) with ESMTP id g6GKer4Y012668
        for <[log in to unmask]>; Tue, 16 Jul 2002 22:40:53 +0200 (CEST)
Received: from rzdspc1.informatik.uni-hamburg.de ([log in to unmask] [])
        by sun.dante.de (8.12.5/8.12.5) with ESMTP id g6GKeqBn010162
        for <[log in to unmask]>; Tue, 16 Jul 2002 22:40:52 +0200 (CEST)
Received: from murphy.debian.org (murphy.debian.org [])
        by rzdspc1.informatik.uni-hamburg.de (8.12.5/8.12.5) with SMTP id g6GKed4Y012644
        for <[log in to unmask]>; Tue, 16 Jul 2002 22:40:48 +0200 (CEST)
Received: (qmail 27170 invoked by uid 38); 16 Jul 2002 20:40:27 -0000
X-Envelope-Sender: [log in to unmask]
Received: (qmail 26623 invoked from network); 16 Jul 2002 20:40:06 -0000
Received: from pcp942041pcs.cstltn01.in.comcast.net (HELO apocalypse.deadbeast.net) (
  by murphy.debian.org with SMTP; 16 Jul 2002 20:40:06 -0000
Received: by apocalypse.deadbeast.net (Postfix, from userid 1000)
        id BFA113D93; Tue, 16 Jul 2002 15:39:40 -0500 (EST)
Message-ID: <[log in to unmask]>
Mail-Followup-To: Frank Mittelbach <[log in to unmask]>,
        [log in to unmask]
References: <[log in to unmask]> <[log in to unmask]> <[log in to unmask]> <[log in to unmask]> <[log in to unmask]> <[log in to unmask]> <[log in to unmask]> <[log in to unmask]> <[log in to unmask]>
In-Reply-To: <[log in to unmask]>
User-Agent: Mutt/1.4i
X-Spam-Status: No, hits=-102.0 required=4.7 tests=IN_REP_TO,USER_IN_WHITELIST version=2.01
X-Mailing-List: <[log in to unmask]> archive/latest/8333
X-Loop: [log in to unmask]
List-Post: <mailto:[log in to unmask]>
List-Help: <mailto:[log in to unmask]>
List-Subscribe: <mailto:[log in to unmask]>
List-Unsubscribe: <mailto:[log in to unmask]>
Precedence: list
X-Virus-Scanned: by AMaViS-perl11-milter (http://amavis.org/)
X-Virus-Scanned: by AMaViS-perl11-milter (http://amavis.org/)
Resent-Date: Tue, 16 Jul 2002 22:40:39 +0200 (CEST)
Resent-Message-ID: <qwKabC.A.UoG.7SIN9@murphy>
Resent-From: [log in to unmask]
Resent-Sender: [log in to unmask]
From: Branden Robinson <[log in to unmask]>
To: Frank Mittelbach <[log in to unmask]>
Cc: [log in to unmask]
Subject: Re: Motivations; proposed alternative license (was Re: LaTeX PublicProject License, Version 1.3 (DRAFT))
Date: Tue, 16 Jul 2002 15:39:40 -0500

Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline

On Tue, Jul 16, 2002 at 09:32:13PM +0200, Frank Mittelbach wrote:

I am disappointed that you did not reply to one of my points:

        The entire raison d'etre of a copyright license is to "enforce
        things legally".  Perhaps you should contrain the LPPL's scope
        to whatever ends you want to achieve with that means.

> Branden Robinson writes:
>  > A requirement to rename *is* a restriction.
> indeed, in so far as *any* codification of a procedural requirement is
> restricting. But from that i can only conclude that you must be lobbying
> against any license (since in one way or another all of them require
> structured behaviour, for example Artistic has in clause 3 and 4 a number=
> requirement which need to be (alternatively) fulfilled---and one of which=
> rename nonstandard executables to avoid name clashes).
> The license is however not "restricting modification" other than requirin=
g a
> procedure for it and through that modification anything is achievable, so=
> modification possibilities are not restricted.
> anyway all that is beside the point in my opinion as you correctly say ...

More specifically, a requirement to rename is a restriction on the
rights Debian attempts to protect with DFSG 3:

        Derived Works

        The license must allow modifications and derived works, and must
        allow them to be distributed under the same terms as the license
        of the original software.

Note that there is no qualification on "modifications" or "derived
works".  The only exceptions to this rule that Debian recognizes in
practice are restrictions against the removal of applicable copyright
notices or license texts.  That is because the notion of copyright is
the edifice upon which free licensing is built; if there were no such
thing as copyright, we might not even need "Free Software Guidelines".

> ... indeed---let's discuss DFSG terms. that is what i would like to discu=
> where please are the guidelines violated (and if indeed they are, discuss
> how/if that can be rectified)
> and as far as the requirement to change names in certain situation is
> concerned, I don't see how that should clash with DFSG as it is covered by
> clause 4.

        Integrity of The Author's Source Code

        The license may restrict source-code from being distributed in
        modified form _only_ if the license allows the distribution of
        "patch files" with the source code for the purpose of modifying
        the program at build time. The license must explicitly permit
        distribution of software built from modified source code. The
        license may require derived works to carry a different name or
        version number from the original software. (This is a
        compromise. The Debian group encourages all authors not to
        restrict any files, source or binary, from being modified.)

There are several salient points here:

1) You are not allowed to impose further restrictions on modification
   apart from what this clause permits.
2) Note that the permitted restriction is only on redistribution of
   modified works, not modification itself.
3) If your license restricts modification, it fails DFSG 3.  DFSG 4 only
   addresses the form in which modifications are distributed.
4) In practice, Debian recognizes "a different name or version number"
   to refer *works*, not filenames.  Permission to mandate or forbid the
   renaming of files is not explicitly granted here, and would not make
   sense from a technological perspective (what to do about primitive
   filesystems with length limitations on filenames, which mandate
   version information in the filename itself, are not case-sensitive,
   or otherwise restrict us from the liberties we are accustomed to
   enjoying on modern Unix filesystems?).  Surely you'd agree that a
   work retains its identity regardless of its title or what means are
   used to identify it.  I can't digitally edit a Disney movie to
   replace the title with my own and thus ignore Disney's copyright on
   the movie.
5) Exercise of DFSG 4 as a means of getting around DFSG 3's clear and
   unambiguous meaning is explicitly identified as a compromise, and
   copyright holders are explicitly asked not to use it.  It may be that
   clause 4 of the DFSG will be ommitted in a future revision of DFSG 4.

> I have tried to do that already in my posts to Jeff, please reread them. =
in a
> nutshell: LaTeX is not just the installation on a local machine it is
> the ability to communicate over a network of machines and to get identical
> results in different places.  LPPL preserves the right of the user to get
> identical output from identical input which is a major feature of TeX.

A copyright license is a poor tool to achieve that end, unless you're
not interested in circulating among the free software community.
Trademarks and certification marks are tools better suited to
controlling endorsements of conformance with a standard or set of usage

>  > > It is certainly (a bit) more work to rename a file rather than to
>  > > simply change it, but while I concur with you that for stuff which is
>  > > essentially local to my environment this is fine (and thus something
>  > > like GPL or whatever is appropriate) for the benefit of LaTeX as a
>  > > freely extensible and changeable system for exchange of information =
>  > > is not.
>  >=20
>  > I hope you'll agree with me that this statement is a subjective analys=
> subjective analysis of what? sure it is subjective (what else should it b=
e, I
> am a subject) but so is most of what i've seen so far as arguments or rat=
> comments with respect to LPPL.

That restrictions on the user's freedom which are unacceptable for other
free software projects are acceptable for LaTeX (even if LaTeX wants to
be recognized as "free software").

Debian strives not to discriminate for or against any particular project
when applying the DFSG.  We attempt to apply the DFSG as impartially and
objectively as we can.  The reputation of an author or organization does
compel us to grant them latitude with respect to their licenses and how
closely we read them vis a vis the DFSG.

Historically, an approach of doing "favors" for "good guys" in the free
software community has been tried and failed.  If I recall correctly,
the only reason clause 4 of the DFSG even exists was as a bone thrown to
Daniel J. Bernstein in the hopes he would meet Debian halfway and
license some high-quality software of his, such as qmail, in a manner we
would recongize as Free.  It didn't work.  He refused to compromise.  So
we have this escape clause designed for software that can't even
exercise it because it fails the DFSG in other respects.

>  > Asserting intellectual property right in the output of LaTeX would not
>  > be acceptable[1].  Such an assertion would be logically required if you
>  > put some indicator of modified-LaTeX status into users' output and
>  > forbade them from removing that indicator.
> ehh? who asks for that? are you saying that it is not allowed to require =
> the terminal display (when a program starts) to ensure that it identifies
> itself properly? There is no requirement whatsoever to identify itself in=
> program output, eg on the printed page or something. All the license ask =
> if it is not X it should not display claiming to be X.

No, I mean that it's not acceptable for the copyright holders of LaTeX
to assert intellectual property rights in works created using LaTeX,
such as masters' theses, conference proceedings, journal articles, or
philosophical screeds.  That's what I mean by the "output" of LaTeX.
I'm talking about the product of LaTeX that is (most) valuable to the
person using it, which is presumably a transformation of his or her

> if there is something in LPPL (not in any statements made in this list) f=
> which you wrongly got this impression, please point it out, since this is
> clearly neither wanted nor needed.

No, I'm just trying to make sure that I'm not misleading about what
sorts of things do and don't violate the DFSG.  I wouldn't want to play
some bait-and-switch game leading you to believe that if you were just
able to place an idelible stamp in, say, a .dvi file that says "THIS
be able to drop the filename-renaming restriction and everyone would be

That wouldn't be the case.  Such a stamp would not only be DFSG-unfree
but might also be an infringment on the copyright(s) of the person using
LaTeX to present his work.

> sorry, but you missed the point about what LaTeX is: it is not just a core
> distribution of the 20odd files (for those one could implement any scheme=
> keep it sane, it is a few hundred different files written by many differe=
> people and thereis no way to automatically detect a "standard" state for =
> environment by software means easily.

=46rom a software licensing perspective, LaTeX is a copyrighted work[1]; no
more, and no less.  The terms under which this copyrighted work is
licensed must satisfy the Debian Free Software Guidelines to be
part of the Debian distribution.  All other considerations are
peripheral in this context.

>  > I'm not a very sophisticated TeX user, but I'm in the habit of
>  > reading the warnings it gives me.  I've learned to ignore overfull
>  > and underfull hboxes, but maybe real TeXperts have such
>  > self-confidence that they ignore everything.  :)  In any event,
>  > it's the user's responsibility to read the output the program gives
>  > him.
> beside being nearly impossible to implement (if at all) that would be
> impractical

Why would it be impossible to implement?  I can do it in the shell:


        if [ -e /usr/share/tex/MODIFIED ]; then

        exec latex "$@"

> And to be honnest what "seems to grate on me more than anything else" (to=
> Jeff's words) are statements like your last sentence, ie the progammers v=
> of the type
>   free software is to serve my private whims -- f*** the others

This sounds more like an inflammatory straw man than an argument.

While, as I said elsewhere, the Debian Project has not sworn ideological
fealty to the Free Software Foundation, their definition of Free
Software is of extremely high utility to Debian, and informed our
process of drafting the DFSG:

Free software is a matter of the users' freedom to run, copy,
distribute, study, change and improve the software. More precisely, it
refers to four kinds of freedom, for the users of the software:

    * The freedom to run the program, for any purpose (freedom 0).
    * The freedom to study how the program works, and adapt it to
      your needs (freedom 1). Access to the source code is a
      precondition for this.
    * The freedom to redistribute copies so you can help your
      neighbor (freedom 2).
    * The freedom to improve the program, and release your
      improvements to the public, so that the whole community
      benefits. (freedom 3). Access to the source code is a
      precondition for this.

Maybe it's just me, but I perceive no denotational difference between
"freedom to adapt [software] to your needs" and "freedom to adapt
software to serve your private whims".

Of course, phrasing it in the latter manner is hostile and belittling,
which is why we try not to speak to each other that way.

> I hope i'm mistaken because otherwise there is no point in having any such
> discussion.

It seems to me like either there is some miscommunication here, or that
you are not interested in the LPPL being a free software license.

> Why should the user if she asks for
>   \usepackage{caption}=20
> as part of her document have to check each time she moves the file from o=
> installation to another that it is still the "caption" she thinks it is? =
> she prefers the forged version she can use ccaption or caption2 package w=
> the advantage that all can coexist (and do) and also do so on the other s=
> of the ocean or whereever.

The user doesn't have to.  In my opinion, users should be even more
vigilant about checking the programs they run on their machine for
security holes that would enable the theft of their identity, theft of
their intellectual property, violation of their privacy, and so forth.

That is why software distributors have come up with the concept of the
"trusted source".  You can trust Debian to identify our modifications to
LaTeX, if any, because we try to responsible distributors, and take into
account the needs of both our users and the upstream authors.  Sometimes
Debian may ship modifications that an upstream author would not choose.
Ethically, we should report such modifications to our users.  But it is
important that we have that freedom.  Even if upstream is so amazingly
cool and on-the-ball that we never need to exercise it.

> Again, please get back to the original goal of finding out if, and if so =
> LPPL would conflict with DFSG (and how to fix that if it is indeed the ca=
> and not argue on the level of statements of the type
>   It appears that Debian's consensus is that forbidding the renaming of
>   files is too large a stick to achieve your goal of notification of
>   deviation from a standard.
> which is (i hope you agree) nothing other than a subjective feeling not b=
> out of any DFSG terms.

See above.  The above statement is also less subjective than you claim.
So far, not a single Debian developer has spoken up in this conversation
to assert that the LPPL 1.3 draft is DFSG-free.

If you cannot find a single person within Debian who can plausible argue
that the LPPL 1.3 draft is DFSG-free, I'd call that a pretty objective

> So far I have seen the comments by Jeff (who goes in a lot of detail thro=
> the license, for which i would like to thank him, and to which i intend t=
o get
> back) but other than that, all I heard so far and repeatedly heard is "we
> don't like that you use clause 4 and therefore it is a license  acceptabl=
e by
> us" (though in more elaborate words).

You are failing even to exercise DFSG 4 properly, as I noted above.  My
best advice to you is to design your license as if DFSG 4 doesn't exist,
even if you can comply with its letter and spirit; the subject of
eliminating clause 4 from our guidelines has been raised before, and may
come to a vote sometime this year.  Presumably, you will want the LPPL
to be a DFSG-free license regardless of the outcome of such a vote.

Also, I think the fact that the very language of DFSG 4 itself
discourages its use should register with you more strongly than the
repeated requests from Debian developers, which you appear to be

[1] It may actually contain independent works copyrighted by many
people; that isn't really important for the purposes of this discussion.
We're assuming that all of the copyright and licensing within the LaTeX
distribution is internally consistent.

G. Branden Robinson                |     You could wire up a dead rat to a
Debian GNU/Linux                   |     DIMM socket and the PC BIOS memory
[log in to unmask]                 |     test would pass it just fine.
http://people.debian.org/~branden/ |     -- Ethan Benson

Content-Type: application/pgp-signature
Content-Disposition: inline

Version: GnuPG v1.0.7 (GNU/Linux)



To UNSUBSCRIBE, email to [log in to unmask]
with a subject of "unsubscribe". Trouble? Contact [log in to unmask]