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 of
> requirement which need to be (alternatively) fulfilled---and one of which is
> rename nonstandard executables to avoid name clashes).
>
> The license is however not "restricting modification" other than requiring a
> procedure for it and through that modification anything is achievable, so your
> 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 discuss,
> 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
practices.
> > > 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 it
> > > is not.
> >
> > I hope you'll agree with me that this statement is a subjective analysis.
>
> subjective analysis of what? sure it is subjective (what else should it be, I
> am a subject) but so is most of what i've seen so far as arguments or rather
> 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 on
> the terminal display (when a program starts) to ensure that it identifies
> itself properly? There is no requirement whatsoever to identify itself in its
> program output, eg on the printed page or something. All the license ask that
> 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
input.
> if there is something in LPPL (not in any statements made in this list) from
> 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
FILE PRODUCED WITH PRISTINE, UNMODIFIED LATEX" (or the converse), you'd
be able to drop the filename-renaming restriction and everyone would be
happy.
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 to
> keep it sane, it is a few hundred different files written by many different
> people and thereis no way to automatically detect a "standard" state for that
> environment by software means easily.
From 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:
#!/bin/sh
if [ -e /usr/share/tex/MODIFIED ]; then
echo >&2 "WARNING: MODIFIED VERSION OF TEX DETECTED! OUTPUT MAY NOT BE STANDARDS-CONFORMANT!"
fi
exec latex "$@"
> And to be honnest what "seems to grate on me more than anything else" (to use
> Jeff's words) are statements like your last sentence, ie the progammers view
> 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}
>
> as part of her document have to check each time she moves the file from one
> installation to another that it is still the "caption" she thinks it is? if
> she prefers the forged version she can use ccaption or caption2 package with
> the advantage that all can coexist (and do) and also do so on the other side
> 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 how,
> LPPL would conflict with DFSG (and how to fix that if it is indeed the case)
> 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 borne
> 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
failure.
> So far I have seen the comments by Jeff (who goes in a lot of detail through
> the license, for which i would like to thank him, and to which i intend to 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 acceptable 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
dismissing.
[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
branden@debian.org | test would pass it just fine.
http://people.debian.org/~branden/ | -- Ethan Benson
Attachment:
pgpKWzEIBIkut.pgp
Description: PGP signature