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 [212.227.126.141] by localhost with POP3 (fetchmail-5.6.5) for frank@localhost (single-drop); Tue, 16 Jul 2002 22:45:11 +0200 (CEST) Received: from [134.100.9.61] (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] [134.100.9.52]) 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] [134.100.9.61]) 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 [65.125.64.134]) 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) (68.57.244.226) 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: List-Help: List-Subscribe: List-Unsubscribe: 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: Resent-From: [log in to unmask] Resent-Sender: [log in to unmask] Resent-Bcc: 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 --H/P/fp31Su+ob3Cg CONTENT-TRANSFER-ENCODING: quoted-printable 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. >=20 > 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). >=20 > The license is however not "restricting modification" other than requirin= g a > procedure for it and through that modification anything is achievable, so= your > modification possibilities are not restricted. >=20 > 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= ss, > where please are the guidelines violated (and if indeed they are, discuss > how/if that can be rectified) >=20 > 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. > >=20 > > I hope you'll agree with me that this statement is a subjective analys= is. >=20 > 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= her > 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. >=20 > 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) f= rom > 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 differe= nt > people and thereis no way to automatically detect a "standard" state for = that > 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. >=20 > 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 v= iew > of the type >=20 > 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 >=20 > \usepackage{caption}=20 >=20 > as part of her document have to check each time she moves the file from o= ne > 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 w= ith > the advantage that all can coexist (and do) and also do so on the other s= ide > 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 ca= se) > and not argue on the level of statements of the type >=20 > 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. >=20 > which is (i hope you agree) nothing other than a subjective feeling not b= orne > 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 thro= ugh > 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 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. --=20 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 --H/P/fp31Su+ob3Cg Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.7 (GNU/Linux) iEYEARECAAYFAj00hIwACgkQ6kxmHytGonzi6wCfVzdiPpsQbgNA45oxeACyiP6n +osAn1DU0f0tXrp5UWDFC8Bs69sNFhzR =3by2 -----END PGP SIGNATURE----- --H/P/fp31Su+ob3Cg-- -- To UNSUBSCRIBE, email to [log in to unmask] with a subject of "unsubscribe". Trouble? Contact [log in to unmask]