LISTSERV mailing list manager LISTSERV 16.0

Help for LATEX-L Archives


LATEX-L Archives

LATEX-L Archives


LATEX-L@LISTSERV.UNI-HEIDELBERG.DE


View:

Message:

[

First

|

Previous

|

Next

|

Last

]

By Topic:

[

First

|

Previous

|

Next

|

Last

]

By Author:

[

First

|

Previous

|

Next

|

Last

]

Font:

Proportional Font

LISTSERV Archives

LISTSERV Archives

LATEX-L Home

LATEX-L Home

LATEX-L  July 2002

LATEX-L July 2002

Subject:

Re: Motivations; proposed alternative license (was Re: LaTeX PublicProject License, Version 1.3 (DRAFT))

From:

Frank Mittelbach <[log in to unmask]>

Reply-To:

Mailing list for the LaTeX3 project <[log in to unmask]>

Date:

Wed, 17 Jul 2002 00:00:41 +0200

Content-Type:

text/plain

Parts/Attachments:

Parts/Attachments

text/plain (314 lines)

Branden Robinson writes:
 > 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.

you asked that question in relation with a situation that I was going to
address (with respect to the content of LPPL) in a reply to Jeff's point
and still intend to. but i found the question  a bit beside the point as i
doubt that, say, anybody tried to enforce a similar "private"  violation that
could be constructed for any other license that is debian approved.

 > 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".

sorry i'm probably dumb, so please give it another try: what has "same terms
and same license" to do with allowing something to pretend to be something else?
i don't see that requiring derived work to identify itself differently is in
violation of this clause

 >      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.

ok, there is some leftover wording in the draft that contains further
restriction in particular

< Additional Conditions on Individual Files of The Program
< --------------------------------------------------------
<
< An individual file of The Program may bear additional conditions that
< supplement and/or supersede the conditions in this license if, and only
< if, such additional conditions exclusively concern modification of the
< file or distribution of a modified version of the file.  The conditions
< on individual files of The Program therefore may differ only with
< respect to the kind and extent of modification of those files that
< is allowed, and with respect to the distribution of modified versions
< of those files.
<
<
173,176d167
<   - You may not modify any file with filename extension `.ins' since
<     these are installation files containing the legal notices that are
<     placed in the files they generate.
<


 > 2) Note that the permitted restriction is only on redistribution of
 >    modified works, not modification itself.

it is not the intention to disallow modification without redistribution. the
license has a paragraph labeled recommendation that talks about that but that
is already by its title a suggestion only

 > 3) If your license restricts modification, it fails DFSG 3.  DFSG 4 only
 >    addresses the form in which modifications are distributed.

it does not.

 > 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?).

well, for LaTeX file names are part of the language so it is not as simple as
you make it out. in other word the file name is indeed (and if you like
unfortunately, i agree with you so far) the *works* as far as a latex package
is concerned.


 >  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.

Lars (who was speaking as a user using LPPL not as somebody from the latex
borject team) already tried to explain that in his posting: we (ie the
license) are not trying to apply file name restrictions to the means of of
transporting packing ...  a WORK, we limit that explicitly to individual files
within the work because that actually is the WORK and extends/modifies the
language.

 > 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.

if DFSG would be without 4 i still have problems to see why you think we
violate 3. we offer a simple way to do anything:

 - either in a way that the language automatically understands that it is
   using something different from the default (ie by name change)

 - or by supplying a way that instead of the WORK LaTeX you use the work X
   with a change that takes you about ten minutes to implement --- i'v given
   the citation showing the necessary code in one of my replies to Jeff (you
   lose however the assurance that the system will produce predictable output
   on different implementations and that id why nobody to my knowledge
   actually every done that)

 > > 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.

How do you back up that claim? a) works that are lessin need to be predictibly
identical (both in its standard form as well as in any forks) try to do that
to some extend, eg the Artistic license

 > >  > > 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").

well, I try one more time: there is a difference in, say an emacs el file to a
geometry.sty file for LaTex. the first is something which is normally used on
a single machine and it doesn't matter for its functionality at all if you and
I (or I on different machines) have different ones. but for something like
geometry.sty it matters. if on my latop (where i use a different LATeX
distribution to the one on the machine i'm writing from now) the two geometry
files would differ i could kiss formatting my current book goodbye (which is
written half between both systems and one at CERN and one at Oxford)

now you are arguing that it is my responsibilty to ensure that in all such places i
need to ensure that i have the same files (they are part of the language
itself) and each time compare the log files and ...

and i claim you are arguing this way because you are only accustomed to
projects to which only the single machine implementation matters.

and that is in summary why indeed we think that there is someting acceptable
for LaTeX and software that has similar needs that would be unacceptable to
software thatdoes not have this need.

 > >  > 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.

sorry, can somebody help a stupid German here? I don't understand what you are
talking about or in what respect this is to something LPPL does.

 >
 > > 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.

okay, sigh, stupid German got the point (he hopes)

 > > 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.

the intention is to find out if that is thecase, yes, or if not why not and
whtehr this can be mended with satifaction of all sides. but that doesn't mean
that it is peripheral.

what i trying to make you understand is that there is beside an individual
work under LPPL (of which many indiviuals exist) there is LaTeX as a language
which defines itself as the union of such works and (as i said earlier) due
to the unfortunate situation that TeX and LATeX already are nearly 20 years
old are bound to filenames

 >
 > >  > 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 "$@"

sorry you can't because there is a constantly changing number of files that
form the LaTeX language. the point is that for a document you can have two
states

 - the subset of the latex language used by the document is being found in the
   current installation (ie all files are found)

 - some subset is not available
   in that case the receiving user may have to install more components

but there is no way to put that shell wrapper decide whether or not it is a
conformant latex. distributions add or leave out subsets of the language or
add forked version etc and all of that is fine as long as they are under a
license like LPPL because then the use still has only the above two states.

beside why make 99% conformant subsets claim they are probably not just because
there has been some change/fix/improvement.

(however, if people desire to replace the 2 level model with  one
in which the first is replaced by

 - the subset is fund, but at each side you carefully have to check that the
   results you get from the run are the same you got elsewhere

then we offer a way to do that.

so yes i think you should seriously consider reasoning that let us
believe that our software written for emacs is distributed under a license
close to your acustomed way of thinking about free software but latex is
better distributed in a way that is perhaps new to your thinking --- but that
doesn't necessarily make it unfree or not complient with somehting like DSFG

 > > 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.

sorry, probably yes --- my excuse is that sometimes email is not a good medium
for such discussions.


i will stop here (it is again after midnight which means my working day now
had 17 hours)

good night
frank

Top of Message | Previous Page | Permalink

Advanced Options


Options

Log In

Log In

Get Password

Get Password


Search Archives

Search Archives


Subscribe or Unsubscribe

Subscribe or Unsubscribe


Archives

September 2019
July 2019
April 2019
March 2019
February 2019
January 2019
December 2018
November 2018
October 2018
September 2018
August 2018
June 2018
May 2018
April 2018
February 2018
January 2018
December 2017
September 2017
August 2017
July 2017
June 2017
May 2017
April 2017
March 2017
February 2017
January 2017
December 2016
July 2016
April 2016
March 2016
February 2016
January 2016
October 2015
September 2015
August 2015
July 2015
June 2015
May 2015
April 2015
March 2015
February 2015
January 2015
December 2014
November 2014
October 2014
September 2014
August 2014
July 2014
June 2014
May 2014
April 2014
March 2014
February 2014
January 2014
December 2013
November 2013
October 2013
August 2013
July 2013
June 2013
May 2013
April 2013
March 2013
February 2013
January 2013
December 2012
November 2012
September 2012
August 2012
July 2012
June 2012
May 2012
March 2012
February 2012
January 2012
December 2011
November 2011
October 2011
September 2011
August 2011
July 2011
June 2011
May 2011
April 2011
March 2011
February 2011
January 2011
December 2010
November 2010
October 2010
September 2010
August 2010
July 2010
June 2010
May 2010
March 2010
February 2010
January 2010
December 2009
November 2009
October 2009
September 2009
August 2009
July 2009
June 2009
May 2009
April 2009
March 2009
February 2009
January 2009
December 2008
November 2008
October 2008
September 2008
May 2008
April 2008
March 2008
February 2008
January 2008
December 2007
November 2007
September 2007
August 2007
June 2007
May 2007
March 2007
December 2006
November 2006
October 2006
August 2006
July 2006
June 2006
May 2006
April 2006
March 2006
February 2006
November 2005
October 2005
September 2005
August 2005
May 2005
April 2005
March 2005
November 2004
October 2004
August 2004
July 2004
May 2004
April 2004
March 2004
February 2004
January 2004
December 2003
October 2003
August 2003
July 2003
June 2003
May 2003
April 2003
March 2003
February 2003
January 2003
December 2002
October 2002
September 2002
August 2002
July 2002
June 2002
March 2002
December 2001
October 2001
September 2001
August 2001
July 2001
June 2001
May 2001
April 2001
March 2001
February 2001
January 2001
December 2000
November 2000
October 2000
September 2000
August 2000
July 2000
May 2000
April 2000
March 2000
February 2000
January 2000
December 1999
November 1999
October 1999
September 1999
August 1999
May 1999
April 1999
March 1999
February 1999
January 1999
December 1998
November 1998
October 1998
September 1998
August 1998
July 1998
June 1998
May 1998
April 1998
March 1998
February 1998
January 1998
December 1997
November 1997
October 1997
September 1997
August 1997
July 1997
June 1997
May 1997
April 1997
March 1997
February 1997
January 1997
December 1996

ATOM RSS1 RSS2



LISTSERV.UNI-HEIDELBERG.DE

Universität Heidelberg | Impressum | Datenschutzerklärung

CataList Email List Search Powered by the LISTSERV Email List Manager