Towards a new LPPL draft

[Frank Mittelbach]

Folks,

it seems to me that by now we are turning around in cycles rehashing arguments
that are important in general (can LaTeX have security problems, yes or no?;
how does one do software development ...) but not with respect to the problem
at hand which still is (to me at least) the following two things:

 1) determine whether or not the fundamental believes of the LaTeX Mafia
comply with the those of the Debian people

 2) if so to draft a new LPPL license that reflects both believes, i.e., is
DSFG-complient (as well as being understood to be DSFG-complient) while at
the same time allowing the majority of the people in the LaTeX world to
work as they feel appropriate.

If (1) is a no-go we don't have to attempt (2) and I for my part have no
intention to. But if (1) is possible, and it seems that this is the case, then
please stop arguing on the level 

  File name requirements is something that can be circumented so remove it.

We have explained over and over again, that despite that clearly true
observation we think that it gives a good way to evolve the LaTeX language
while allowing to have other modifications (including the sidestepping)
happening outside of what LaTeX users consider conformant LaTeX.

For a last time: the argument we have is that a fork on the level of a LaTeX
package (not on the level of the LaTeX kernel) --- and that is the majority of
the "forks" that are happening --- is something that through LPPL simply
enlarges the LaTeX language and thus keeps an univerally conformant LaTeX that
then embraces the fork (if so desired by its author) making it a bigger
conformant LaTeX, while at the same time a fork at the kernel level using the
general file-name mapping feature allows a) to do anything you like (in an
easy manner, no cascading problem) while b) it is not threatening any
conformant LaTeX as it can live side by side. So for us this combines the best
of both approaches.

So to come back to (1):

 Axiom: after all discussions the LaTeX Mafia, the LaTeX users that spoke on
 this list, and the Debian users that mailed me privately, still believe that
 the requirement for renaming files LaTeX source files when doing modification
 for distribution is essential and helpful. 

What i learned from the discussion is that the license should restrict this to
what we actually need (eg not makefiles, tar balls, etc).

Starting with this axiom I get:

From: [EMAIL PROTECTED] (Thomas Bushnell, BSG)
  I think as the FSF's comments on the latex situation exemplify, the
  question ends up being a matter of "how much of a pain is it".  Since
  latex apparently has a global file-mapping feature (something not
  previously noted on the discussion on debian-legal, AFAICT) the
  problem is not actually hugely severe--and easily worked around, as
  other threads have indicated.

From: Jeff Licquia <[EMAIL PROTECTED]>
  However, as it turns out, there is a process where you can limit
  filename changes and provide "macro substitution" at runtime on
  filenames, so that (for example) "article-foo" can be called when
  "article" is referenced in a document.  This reduces the problem back
  down to the level of changing C source file names; it's an annoyance to
  have to write the redefinitions, but nothing more.  This also requires
  changing the name of the "binary", but that's OK too.

  So, it's my understanding that this is DFSG-free.


The catch that I see is from Walter's recent post:

  I just want to make sure that we don't allow a license that can only
  be applied to LaTeX.  When Thomas Bushnell writes:
   [the above]
  it seems like Thomas thinks that the LPPL is OK for LaTeX, but
  probably not for anything else.  That troubles me.

Well, if it would be OK for LaTeX or related software, like Omega, TeX,
pdftex, etc, ie for macroprocessors that have the ability to support a global
file-name mapping feature then it would be useable not only for LaTeX "core"
but for several megabytes of code written --- i don't know how big CTAN is
these days but it is distributed as compressed files on three CDs.

I can understand if Debian people would judge such a license as DFSG-complient
only if the renaming requirement is not "too painful". As LPPL is currently
drafted to be usable with any program that would mean to either

 - explicitly limit a new draft to software for macroproessors which have the
   ability needed to make the requirement file renaming painless (ie no
   cascading)

 - or to explicitly put the right kind of statement into the license that
   makes it only applicable to programs which have that feature

The latter might be difficult (finding a precise definition, not just "needs to
be painless:), I don't know. The former would bring Walter's argument back up,
but I would think that

 (a) there is nothing anywhere in DSFG that prohibits licenses to be
 applicable only to certain domains

 (b) the domain is large: it is not the latex kernel as distributed by the
 LaTeX Proje

Re: Towards a new LPPL draft

[Boris Veytsman]

> Date: Mon, 22 Jul 2002 21:31:54 +0200
> From: Frank Mittelbach <[EMAIL PROTECTED]>

> 
> To go forward I propose
> 
>  A) I would like you to come to a conclusion on (1) assuming the above Axiom
> 


The question is, who should say "yes" and "no"? Sorry for being
ignorant about the rules -- but is there a mechanism of voting or
other decision taking of the list? How it is formally initiated? 

-- 
Good luck

-Boris

Do not underestimate the power of the Force.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Towards a new LPPL draft

[Walter Landry]

Frank Mittelbach <[EMAIL PROTECTED]> wrote:
> Folks,
> 
> it seems to me that by now we are turning around in cycles rehashing arguments
> that are important in general (can LaTeX have security problems, yes or no?;
> how does one do software development ...) but not with respect to the problem
> at hand which still is (to me at least) the following two things:
> 
>  1) determine whether or not the fundamental believes of the LaTeX Mafia
> comply with the those of the Debian people

It seems that the fundamental goal that the LaTeX project is trying to
accomplish is to make sure that any changes that are made are not
"silent".  When I run latex on my document (yes, I do use it.  I've
been using it for about 8 years, and TeX for about 12), I get the output

  This is TeX, Version 3.14159 (Web2C 7.3.7)
  (./double_neutron_saul.tex
  LaTeX2e <2001/06/01>
  ...

If you required Debian, when making a change, to have it output
something like

  This is DebTeX, a modified version of TeX
  (./double_neutron_saul.tex
  DebLaTeX2e, a modified version of LaTeX2e
  ...

then anyone running LaTeX can see that it is not a standard version of
LaTeX.  This is perfectly compatible with the DFSG, and all that the
TeX license requires.

The renaming requirement can and likely will be legally circumvented
in a way that is transparent to the user.  If Debian finds that it has
to modify article.cls, Debian will do everything that it can to make
sure that modified versions of article.cls are automatically used.
Otherwise, there will be a lot of breakage.  Certainly I would do it
on the systems I maintain.

>  Axiom: after all discussions the LaTeX Mafia, the LaTeX users that
>  spoke on this list, and the Debian users that mailed me privately,
>  still believe that the requirement for renaming files LaTeX source
>  files when doing modification for distribution is essential and
>  helpful.

If file renaming is a real axiom, then I don't think that Debian and
the LaTeX Project can come to an agreement.  DFSG #4 has never been
interpreted as allowing that kind of restriction, and I don't see why
Debian should make an exception for LaTeX.

Regards,
Walter Landry
[EMAIL PROTECTED]


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Towards a new LPPL draft

[Jeff Licquia]

On Mon, 2002-07-22 at 15:50, Walter Landry wrote:
> If file renaming is a real axiom, then I don't think that Debian and
> the LaTeX Project can come to an agreement.  DFSG #4 has never been
> interpreted as allowing that kind of restriction, and I don't see why
> Debian should make an exception for LaTeX.

I disagree.  DFSG 4 was, as I understand, drafted with explicit
reference to the situation with TeX, which is similar in many ways.

At any rate, I am satisfied that the file name issue is not a problem
with the DFSG because of the file redirect thing that is also a part of
LaTeX.  I intend to pursue getting some language into the license to
reference that specifically.

Is there anyone else who objects?  Walter, will you yield if you stand
alone on this matter?


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Towards a new LPPL draft

[Branden Robinson]

On Mon, Jul 22, 2002 at 09:31:54PM +0200, Frank Mittelbach wrote:
> So to come back to (1):
> 
>  Axiom: after all discussions the LaTeX Mafia, the LaTeX users that spoke on
>  this list, and the Debian users that mailed me privately, still believe that
>  the requirement for renaming files LaTeX source files when doing modification
>  for distribution is essential and helpful. 
> 
> What i learned from the discussion is that the license should restrict this to
> what we actually need (eg not makefiles, tar balls, etc).
[...]
>  A) I would like you to come to a conclusion on (1) assuming the above Axiom

In my opinion, this is a restriction on modification that violates DFSG
3.  DFSG 4 offers no safe harbor for this particular requirement.

To review:

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.

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.

It is apparently the desire of the LaTeX project that the LPPL "restrict
source-code from being distributed in modified form" under a
circumstance *other* than "the distribution of "patch files" with the
source code for the purpose of modifying the program at build time."

Any license with that property fails the DFSG.

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.

Note that it is the *work* for which a mandate to rename is permitted.
The "name" of a "work" is a legal construct which may or may not have
any bearing on filenames, file systems, file handles, or other details
of technical implementation.

(This is a compromise. The Debian group encourages all authors
not to restrict any files, source or binary, from being
modified.)

-- 
G. Branden Robinson|There is no housing shortage in
Debian GNU/Linux   |Lincoln today -- just a rumor that
[EMAIL PROTECTED] |is put about by people who have
http://people.debian.org/~branden/ |nowhere to live.-- G. L. Murfin


pgpsumYJu4AOU.pgp
Description: PGP signature

Re: Towards a new LPPL draft

[Walter Landry]

Jeff Licquia <[EMAIL PROTECTED]> wrote:
> On Mon, 2002-07-22 at 15:50, Walter Landry wrote:
> > If file renaming is a real axiom, then I don't think that Debian and
> > the LaTeX Project can come to an agreement.  DFSG #4 has never been
> > interpreted as allowing that kind of restriction, and I don't see why
> > Debian should make an exception for LaTeX.
> 
> I disagree.  DFSG 4 was, as I understand, drafted with explicit
> reference to the situation with TeX, which is similar in many ways.

TeX is not similar at all (Why do people keep bringing this up?).  The
only thing you have to do is not call it TeX.  You can then modify
files in place all you want.

Also, someone else claimed that DFSG 4 was written the way it was in
order to get qmail into main, not TeX.  I wouldn't know.

> At any rate, I am satisfied that the file name issue is not a problem
> with the DFSG because of the file redirect thing that is also a part of
> LaTeX.  I intend to pursue getting some language into the license to
> reference that specifically.
> 
> Is there anyone else who objects?  Walter, will you yield if you stand
> alone on this matter?

It sounds like you might have to talk to Branden and maybe Henning as
well.  I'm not sure about Mark Rafn and Glenn Maynard.  Thomas
Bushnell, Sam Hartman, and Colin Watson seem to be with you.  Those
seem to be all of the regular contributors to debian-legal.  My
apologies if I've missed someone.

Regards,
Walter Landry
[EMAIL PROTECTED]


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Towards a new LPPL draft

[Chris Lawrence]

On Jul 22, Boris Veytsman wrote:
> The question is, who should say "yes" and "no"? Sorry for being
> ignorant about the rules -- but is there a mechanism of voting or
> other decision taking of the list? How it is formally initiated? 

The only formal procedures available are:

- Action by the Debian project leader.

- Action by the technical committee - if this issue is deemed
"technical" as opposed to "non-technical".  My guess is they would
deem it non-technical and pass the buck.

- Action by the developers as a whole through the General Resolution
procedure.

Additional de facto procedures:

- Acceptance of or failure to accept an upload of a new package with
the given licen[cs]e by the Debian ftp administration team.  (Doesn't
help in this case anyway, since you're still drafting.)

- Consensus on the debian-legal list.

In practice, the de facto procedures are always followed.


Chris [no cc needed]
-- 
Chris Lawrence <[EMAIL PROTECTED]> - http://www.lordsutch.com/chris/

Instructor and Ph.D. Candidate, Political Science, Univ. of Mississippi
208 Deupree Hall - 662-915-5765


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Towards a new LPPL draft

[Glenn Maynard]

On Mon, Jul 22, 2002 at 04:27:57PM -0700, Walter Landry wrote:
> It sounds like you might have to talk to Branden and maybe Henning as
> well.  I'm not sure about Mark Rafn and Glenn Maynard.  Thomas
> Bushnell, Sam Hartman, and Colin Watson seem to be with you.  Those
> seem to be all of the regular contributors to debian-legal.  My
> apologies if I've missed someone.

I'm not a DD.  For those interested in my opinion anyway:  What if I want
to modify Latex to remove the filename mapping?  If the DFSG-freeness is
dependent on that mechanism, then I can't remove it (for the best or worst
of technical reasons) and have it remain DFSG-free.  Having freeness
dependent on a feature being present is strange.

Jeff, I don't know how you could make the renaming requirement dependent
on this; then you have to deal with the case that people might remove
the feature.  Having license conditions dependent on specific features
seems like a bad idea.  

(Of course, it might be nearly impossible to remove that mechanism without
completely breaking the entire system, but that doesn't change the point.)

-- 
Glenn Maynard


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Towards a new LPPL draft

[Mark Rafn]

> On Mon, Jul 22, 2002 at 04:27:57PM -0700, Walter Landry wrote:
>> I'm not sure about Mark Rafn and Glenn Maynard. 

On Mon, 22 Jul 2002, Glenn Maynard wrote:
> I'm not a DD.

Nor am I.  I'm just a user who shoots my mouth off, and I learn more from 
d-l than I contribute.

Put me down as "it doesn't sound free to me without a large relaxation of
the individual file requirements."
--
Mark Rafn[EMAIL PROTECTED]  



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Towards a new LPPL draft

[Mittelbach, Frank]

Branden,

can you do me the favor and try to clearify for me when in your opinion the
DSFG 4 clause is 
applicable for a license.

Question 1:

Suppose you have a program source foo.c with some license.
Suppose this license "restricts"  foo.c from being modified but allows
distribution of foo.c
plus a patch file, e.g. foo.dif and allows to patch foo.c at built time,
i.e.

patch < foo.dif
gcc foo

NOW: would it be acceptable for the license to disallow distribution of the
modified built 
and to only allow distribution of either

  foo.c  (alone)

or

  foo.c + foo (original built)

or

  foo.c + foo.dif + info how to patch (no binary)

or

  foo.c + foo (original built) + foo.dif + infor how to patch and renerate a
modified binary

but prevent the distribution of

  foo.c + foo (patched built)

and prevent distribution of

  foo.c + foo.dif + foo (patched built)

and prevent distribution of

  foo (patched built only)

is that what you think 

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.

means? I guess the answer might be no, but i would like to get a clear
picture.


Question 2:

I don't know if you use LaTeX or TeX but assuming you do to some extent, 
what exactly do you consider "source" and what "built" in case of a LaTeX 
work like varioref consisting of the files

 varioref.dtx varioref.sty (and varioref.ins to easily convert the first in
the second)

There varioref.sty is a version of varioref.dtx with some comments removed, 
but as far as TEX/LaTeX is concerned both files could be considered both
source 
as well as to some extent binary, simply because there is no translation
step.

It is like putting foo.c through a preprocessor that removes some commments
and writes
foo2.c as the result (the c-code in foo.2.c might be less easy to understand

if not all comments are around, but foo.c may not have had any comments in
the 
first place in which case foo.c and foo2.c would be identical).

In fact a lot of people do not bother with .dtx files and keep all comments
in the 
.sty file, eg make their work consist of a single file, say,

  overcite.sty

In other words, there is (normally) no "binary" in the TeX/LaTeX world but
only "source". The only 
binary is TeX the program (which has a different license and is of no
concern 
to works under LPPL) and if you like the binary image of the LaTeX kernel 
(i.e. latex.fmt) but one could essentially run all documents from the source

files only (building the format on the fly from them)

So when applying DSFG#4's patch condition: would it be okay to have a
license that forbits 
to change overcite.sty and only allows distributing derived works by
distributing

 overcite.sty + overcite.dif

leaving it to the receiver to patch the source (but then disallowing that
this 
patched sources is further distributed).


If you could answer me the above questions that would be very helpful indeed
as it might 
mean we could compromise on allowing patches as an alternative to file
renames (could I said).

regards
frank


ps (sorry for the mail format (MS exchange ...))

-Ursprungliche Nachricht-
Von: Branden Robinson [mailto:[EMAIL PROTECTED]
Gesendet: Montag, 22. Juli 2002 23:27
An: debian-legal@lists.debian.org
Betreff: Re: Towards a new LPPL draft


On Mon, Jul 22, 2002 at 09:31:54PM +0200, Frank Mittelbach wrote:
> So to come back to (1):
> 
>  Axiom: after all discussions the LaTeX Mafia, the LaTeX users that spoke
on
>  this list, and the Debian users that mailed me privately, still believe
that
>  the requirement for renaming files LaTeX source files when doing
modification
>  for distribution is essential and helpful. 
> 
> What i learned from the discussion is that the license should restrict
this to
> what we actually need (eg not makefiles, tar balls, etc).
[...]
>  A) I would like you to come to a conclusion on (1) assuming the above
Axiom

In my opinion, this is a restriction on modification that violates DFSG
3.  DFSG 4 offers no safe harbor for this particular requirement.

To review:

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.

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.

It is apparently the desire of the LaTeX project that the LPPL "restrict
source-code from being distributed in modified form" under a
cir

Re: Towards a new LPPL draft

[Brian Sniffen]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1



Frank Mittelbach <[EMAIL PROTECTED]> writes:

>  > 2) Does the draft LPPL prevent me from distributing a program called
>  >"SniffenTeX" which is a modified derivative work of LaTeX, but
>  >would be run by a user as sniffentex and carries a banner stating
>  >that it is SniffenTeX, not LaTeX?  If it doesn't prevent me, what
>  >restrictions does it place on me?
>
> as of now it would mean that for each individual work under LPPL you have to
> folow its license meaning you have to rename the work (i thought that was
> discussed on the list at some detail) --- all of these works could live side
> by side on your machine

That's the important bit, and what I wanted to make sure I'd clearly
understood from you (I think most folks on debian-legal believe
differently):  if I rename the *work*, I don't have to rename the
files I change within it. Is this correct?

- -Brian

- -- 
Brian Sniffen   [EMAIL PROTECTED]
http://www.evenmere.org/~bts/
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.0.7 (GNU/Linux)

iD8DBQE9PViH03mlJHngJfERAss5AJ9PsAGz7VemPaZUwG2BA6jYgzCKygCeLPsq
g7MamrPGEOcqYoMMeP4rPnM=
=ZI3V
-END PGP SIGNATURE-


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Towards a new LPPL draft

[Joe Moore]

Glenn Maynard wrote:
> I'm not a DD.  For those interested in my opinion anyway:  What if I
> want to modify Latex to remove the filename mapping?  If the
> DFSG-freeness is dependent on that mechanism, then I can't remove it
> (for the best or worst of technical reasons) and have it remain
> DFSG-free.  Having freeness dependent on a feature being present is
> strange.

What's wrong with the conditional statement (unproven assertion:) 
  "The LPPL-1.3 is DFSG-free, but only when applied to software which makes
the file-renaming requirement easy"

This is essentially what is said about the GFDL, "It's DFSG-free only if no
options are used in the document"

--Joe



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Towards a new LPPL draft

[Mittelbach, Frank]

sorry, I shouldn't have tried to answer your private mail in haste while
getting my coat to rush to the office.
I made a two typos ad least and one important one:

> as of now it would mean that for each individual work under LPPL you have
to
> folow its license meaning you have to rename the work (i thought that was

should have been

  follow its license meaning that you have to rename the files that you
change (i thought that was ...

as I said, sorry that was not deliberate. But for me work and file name
within the LATeX 
context is very tightly linked. I mean, if you have the single file

 overcite.sty  

under LPPL then what other is the "work" then this file, ie how do you
rename it without renaming the 
file? (yes you can put it into a tar ball, but this is not the way we think
defines "work")

If you think of LPPL applying to the whole of a LaTeX sty/cls tree of files
at once, we could, i think
live with the idea (it is even described so in modguide or cfgguide as a
possible though not encouraged 
solution (thereby actually violating the license as it is right now)), that
you produce sniffenlatex 
which has its own complete tree and in there has identical file names to the
pristine LaTeX tree so 
that both trees live side by side. 
But the problem here is that LPPL doesn'T apply to the whole thing but
individually to its many parts. 
so if you only wnat to change overcite.sty there is nothing nowhere to put
it and i don'T see how you 
describe (or even want to) that for that change you have to duplicate the
whole tree.

in contrast:  if your sniffenlatex implements the filename remapping then
all you have to do is to 
produce new versions of the (possibly few) files you actually want to
change, stick them into the 
latex tree together with the unchanged ones there and all works (ie both
your sniffenlatex as well 
as the pristine latex using the same files where applicable and different
files where needed).


cheers
frank

-Ursprungliche Nachricht-
Von: Brian Sniffen [mailto:[EMAIL PROTECTED]
Gesendet: Dienstag, 23. Juli 2002 15:22
An: Frank Mittelbach
Cc: debian-legal@lists.debian.org
Betreff: Re: Towards a new LPPL draft


-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1



Frank Mittelbach <[EMAIL PROTECTED]> writes:

>  > 2) Does the draft LPPL prevent me from distributing a program called
>  >"SniffenTeX" which is a modified derivative work of LaTeX, but
>  >would be run by a user as sniffentex and carries a banner stating
>  >that it is SniffenTeX, not LaTeX?  If it doesn't prevent me, what
>  >restrictions does it place on me?
>
> as of now it would mean that for each individual work under LPPL you have
to
> folow its license meaning you have to rename the work (i thought that was
> discussed on the list at some detail) --- all of these works could live
side
> by side on your machine

That's the important bit, and what I wanted to make sure I'd clearly
understood from you (I think most folks on debian-legal believe
differently):  if I rename the *work*, I don't have to rename the
files I change within it. Is this correct?

- -Brian

- -- 
Brian Sniffen   [EMAIL PROTECTED]
http://www.evenmere.org/~bts/
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.0.7 (GNU/Linux)

iD8DBQE9PViH03mlJHngJfERAss5AJ9PsAGz7VemPaZUwG2BA6jYgzCKygCeLPsq
g7MamrPGEOcqYoMMeP4rPnM=
=ZI3V
-END PGP SIGNATURE-


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact
[EMAIL PROTECTED]


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Towards a new LPPL draft

[Jeff Licquia]

On Tue, 2002-07-23 at 09:02, Mittelbach, Frank wrote:
> as I said, sorry that was not deliberate. But for me work and file name
> within the LATeX 
> context is very tightly linked. I mean, if you have the single file
> 
>  overcite.sty  
> 
> under LPPL then what other is the "work" then this file, ie how do you
> rename it without renaming the 
> file? (yes you can put it into a tar ball, but this is not the way we think
> defines "work")

If each piece of the work had to be downloaded separately, then this
would be a valid way of thinking.  When the LaTeX Project collects a
bunch of these separate works and combines them into "LaTeX", though,
they create a derived work, with its own licensing requirements.

The license already allows sub-works within LaTeX to have additional
modification requirements beyond the LPPL.  If you thought that some of
the sub-authors would disagree with relaxing the file naming requirement
when changing the name of the work from "LaTeX", you could allow them to
add that restriction to their file(s).

Then, it would be our problem dealing with those files.  We might, for
example, move them to tetex-nonfree.  Then, you'd need both the tetex
packages in main and tetex-nonfree for a full LaTeX installation, but
many documents would work fine without tetex-nonfree, and documents that
didn't work would fail with an error.

> If you think of LPPL applying to the whole of a LaTeX sty/cls tree of files
> at once, we could, i think
> live with the idea (it is even described so in modguide or cfgguide as a
> possible though not encouraged 
> solution (thereby actually violating the license as it is right now)), that
> you produce sniffenlatex 
> which has its own complete tree and in there has identical file names to the
> pristine LaTeX tree so 
> that both trees live side by side. 

>From the objections I have seen in trying to wrap up this thread, this
is likely to be an important point.  I would strongly advise making this
concession if you can.

> But the problem here is that LPPL doesn'T apply to the whole thing but
> individually to its many parts. 
> so if you only wnat to change overcite.sty there is nothing nowhere to put
> it and i don'T see how you 
> describe (or even want to) that for that change you have to duplicate the
> whole tree.

Would it work for you to require the following?

 - if the whole is named "LaTeX", every changed file must be renamed

 - if the whole is named something else, files may be changed without
renaming

(We would need to come up with a suitable definition for "naming", of
course.)


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Towards a new LPPL draft

[Boris Veytsman]

> From: Jeff Licquia <[EMAIL PROTECTED]>
> Date: 23 Jul 2002 10:31:57 -0500

> 
> Would it work for you to require the following?
> 
>  - if the whole is named "LaTeX", every changed file must be renamed
> 
>  - if the whole is named something else, files may be changed without
> renaming
> 


What about files that are individually released under LPPL? There are
hundreds of files contributed by individual authors (and I presume
being "works" under DFSG#4) with the "rename if you change" license.

-- 
Good luck

-Boris

An ambassador is an honest man sent abroad to lie and intrigue for the
benefit of his country.
-- Sir Henry Wotton, 1568-1639


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Towards a new LPPL draft

[Brian Sniffen]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1


> On Tue, 23 Jul 2002 15:02:40 +0100, "Mittelbach, Frank"
> <[EMAIL PROTECTED]> said:

>   follow its license meaning that you have to rename the files that
>   you change (i thought that was ...

> as I said, sorry that was not deliberate. But for me work and file
> name within the LATeX context is very tightly linked. I mean, if you
> have the single file

>  overcite.sty

> under LPPL then what other is the "work" then this file, ie how do
> you rename it without renaming the file? (yes you can put it into a
> tar ball, but this is not the way we think defines "work")

I have a file on my computer right now with the name "thesis.tex".
The title of the work is "Trust Economies in the Free Haven Project."
I gave a copy to my advisor, who renamed it to "2000/brians.tex".  He
did not change the title of the work in doing so.  I reworked it a bit
for publication, including changing the title to "A study of trust
economies" and accidentally saved it over the old thesis.tex.  The
work now has a different title but the same file name.

The name of the file and the name of the work are unrelated.  I
understand that custom causes them to frequently (barring use of the
filename mapping feature) be similar in TeX systems.

Come to think of it, the file name is actually
/home/bts/Projects/Thesis/thesis.tex.  Would you consider that I've
changed the file name if I change it to
/automount/bts/Projects/Thesis/thesis.tex?  What if I put it on a ISO
9660 CD, where the file name is "THESIS.TEX;1" ?

I would consider file name to be analogous to physical location: you
can't give me a license for a book which only allows me to keep it on
my night-stand; I can put it in any room of my house I like, on any
shelf.


> If you think of LPPL applying to the whole of a LaTeX sty/cls tree
> of files at once, we could, i think live with the idea (it is even
> described so in modguide or cfgguide as a possible though not
> encouraged solution (thereby actually violating the license as it is
> right now)), that you produce sniffenlatex which has its own
> complete tree and in there has identical file names to the pristine
> LaTeX tree so that both trees live side by side.

I think if that provision is there, it will be considered free by most
of the Debian developers.  To be specific, it would grant permission
for distribution of a fork of the *entire* program, clearly identified
as Not LaTeX, but with overlapping filenames with LaTeX.

>  But the problem
> here is that LPPL doesn'T apply to the whole thing but individually
> to its many parts.  so if you only wnat to change overcite.sty there
> is nothing nowhere to put it and i don'T see how you describe (or
> even want to) that for that change you have to duplicate the whole
> tree.

It's true, that would be (much) less convenient than just changing
overcite.sty and saving it as overcite-bts.sty, then remapping such
that my custom version is used when overcite is requested.  But it
would grant the essential freedom to modify and distribute which the
Debian project is asking you for.

Thanks again for your work here,
Brian
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.0.7 (GNU/Linux)

iD8DBQE9PXvc03mlJHngJfERAnOMAKCBpNpGVUeNXJeYGn8URIKyYo0v2QCdFebd
3emVLRxUhibSXPcS8MyCu5U=
=VLGz
-END PGP SIGNATURE-


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Towards a new LPPL draft

[Jeff Licquia]

On Tue, 2002-07-23 at 10:40, Boris Veytsman wrote:
> What about files that are individually released under LPPL? There are
> hundreds of files contributed by individual authors (and I presume
> being "works" under DFSG#4) with the "rename if you change" license.

I've seen that some people include the "LPPL 1.2 or any later version"
language into their license notice.  Those people would be fine
(although I would recommend that notice be given of this particular
license change as a gesture of goodwill to the community).

For the rest, someone should track them down and ask if they agree to
this.  I assume that the authors have placed contact information inside
their independent works, so this might not be so difficult.

It's possible that the "main part" of LaTeX could be licensed under the
LPPL 1.3 (with the new file rename relaxation), and portions could have
an additional restriction applied that re-applies the old-style filename
restriction.  This would not be ideal from Debian's point of view, but
it would end the debate regarding the freeness of "LaTeX", and move the
burden to us for dealing with those holdout files.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Towards a new LPPL draft

[Branden Robinson]

On Tue, Jul 23, 2002 at 02:19:15PM +0100, Mittelbach, Frank wrote:
> Branden,
> 
> can you do me the favor and try to clearify for me when in your
> opinion the DSFG 4 clause is applicable for a license.

Sure.  Before getting to your hypotheticals, I'll try and give you a
direct, if generalized, answer.

A license must be tested against DFSG 4 when either of the following are
true:

A) the license places restrictions on the form in which modifications to
   the Work are distributed;
B) the license places restrictions on the manner in which the Work is
   named or versioned.

Without DFSG 4, *any* license term did either of the above would violate
violate DFSG 3.

In practice, DFSG 3 is not held to apply to copyright notices or license
terms that are applicable-in-fact to the Work.  (I.e., it must be
permitted to remove copyright notices and license terms when you are
also removing all of the code that is covered by that copyright notice
and license.)  Admittedly, this nuance is not stated directly in the
DFSG, but if one thinks carefully about copyright law, it may be argued
that it follows from DFSG 9.  (In other words, the license on your Work
is not permitted to tamper with a person's rights with respect to
another Work that has no relationship -- or no longer has a relationship
-- to your Work.  Some people have, in the past, erroneously claimed
that the GNU GPL violates DFSG 9, but this is not true -- the GNU GPL
applies only to works distributed under its terms.)

> Question 1:
> 
> Suppose you have a program source foo.c with some license.  Suppose
> this license "restricts"  foo.c from being modified but allows
> distribution of foo.c plus a patch file, e.g. foo.dif and allows to
> patch foo.c at built time, i.e.
> 
> patch < foo.dif
> gcc foo
> 
> NOW: would it be acceptable for the license to disallow distribution
> of the modified built

No.  Quoting DFSG 4:

"The license must explicitly permit distribution of software built from
modified source code."

A license cannot disallow distribution of the "binary" built from
modified sources and be DFSG-free unless the license is terminated for
non-compliance.  (In other words, you don't have to permit people to
distribute binaries built from modified sources after they violate your
license, just as you don't have to permit the exercise of any other
right reserved to you under copyright law under such circumstances.
However, in and of itself, the distribution of "binaries" built from
modified sources must be permitted by the license for the license to be
DFSG-free.)

> and to only allow distribution of either
> 
>   foo.c  (alone)
> or
> 
>   foo.c + foo (original built)
> or
> 
>   foo.c + foo.dif + info how to patch (no binary)
> or
> 
>   foo.c + foo (original built) + foo.dif + infor how to patch and renerate a
> modified binary
> 
> but prevent the distribution of
> 
>   foo.c + foo (patched built)

This would fail DFSG 4: "The license must explicitly permit distribution
of software built from modified source code."

> and prevent distribution of
> 
>   foo.c + foo.dif + foo (patched built)

This would fail DFSG 4: "The license must explicitly permit distribution
of software built from modified source code."

> and prevent distribution of
> 
>   foo (patched built only)

This would fail DFSG 4: "The license must explicitly permit distribution
of software built from modified source code."

> is that what you think 
> 
> 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.
> 
> means? I guess the answer might be no, but i would like to get a clear
> picture.

You are correct.  I do not think that DFSG 4 can plausibly be read to
permit the the restrictions you posit in your hypothetical.

> Question 2:
> 
> I don't know if you use LaTeX or TeX but assuming you do to some extent, 

I have used LaTeX in the past but only at a highly rudimentary level; I
understand almost nothing of its internals.

> what exactly do you consider "source" and what "built" in case of a LaTeX 
> work

That's an excellent question and it illustrates a vagueness in the
wording of the DFSG.  The DFSG misleadingly speaks in terms of "source"
and "binary" when in many situations, as folks have noted on this list,
the distinctions are not applicable, at least not in the same way that
they are to compiled C programs.

It is my opinion that when the DFSG speaks of "source", it is referring
to that which is in a Debian "source package".  In the case of
freely-licensed software, this is an archive of files/code/data that is
the "preferred form for making modifications to the Work" (in the
language of the GNU GPL).  Some non-free Debian source packages, such as
Netscape Navigator, (used to) contain actual binaries because source
code is not available, but these are anomalies.

Lik

Re: Towards a new LPPL draft

[Frank Mittelbach]

Jeff Licquia writes:

 > If each piece of the work had to be downloaded separately, then this
 > would be a valid way of thinking.  When the LaTeX Project collects a
 > bunch of these separate works and combines them into "LaTeX", though,
 > they create a derived work, with its own licensing requirements.

well, but that is how  the situation is, isn't it?

The LaTeX Project is not collecting a bunch of seperate works and combines
them into LaTeX. It only provides 3 or 4 core parts of what is known to be
LaTeX as well as providing a license (LPPL) which helps to keep that thing
"LaTeX" uniform between different installations.

I mean I know that tetex (as a debian package) has done the downloading of
individual LaTeX-macro works of many individual authors combined it with the
scripts by Thomas Esser and with a web2c implementation of TeX and a few other
independent works.

 As a whole (the packaging etc) tetex may have its own copyright and license,
but that doesn't mean that the indivdual works it combines lose their license
just because somebody puts them together. This is why we thought it to be a
bad joke on this list when people claimed they not use TeX but tetex which is
"free and under GPL". its organisation might be under GPL, the scripts may be
under GPL, etc., but TeX the program within tetex and the 72 Computer Modern
fonts within tetex are under Knuth's license and the 500 latex packages inside
tetex are under LPPL or some other license (which is why there is the vague
reference that individual parts may have different copyrights and licenses
inside, which most people here like to ignore or overlook).

 > The license already allows sub-works within LaTeX to have additional
 > modification requirements beyond the LPPL.  If you thought that some of
 > the sub-authors would disagree with relaxing the file naming requirement
 > when changing the name of the work from "LaTeX", you could allow them to
 > add that restriction to their file(s).

What i was pointing out in my second reply to Brian is this: suppose you would
only want to modify the work overcite.sty which consists of single file, or
the work geometry which consists of geometry.sty + .dtx + a number of test
files and manual then to be able to modify that without renaming you would
need to build a "nonLaTeX" format with its own tree and place it in that
tree. Now that "nonLaTeX" format wouldn't work at all unless you also copy a
good proportion of the standard latex tree (couple of 1000 files if you
include the fonts etc) into the new tree as well. That is certainly possible
but i think it is far more painful than

providing a nonLaTeX format with filename remapping and put

 overcite.fst and geometry.fst into the main tree

thereby having LaTeX use the main tree (ignoring those two new files)
and nonLaTeX using the main tree and loading overcite.fst when overcite.sty
would by loaded by LaTeX and the same for geometry.

 > > If you think of LPPL applying to the whole of a LaTeX sty/cls tree of files
 > > at once, we could, i think
 > > live with the idea (it is even described so in modguide or cfgguide as a
 > > possible though not encouraged 
 > > solution (thereby actually violating the license as it is right now)), that
 > > you produce sniffenlatex 
 > > which has its own complete tree and in there has identical file names to 
 > > the
 > > pristine LaTeX tree so 
 > > that both trees live side by side. 
 > 
 > >From the objections I have seen in trying to wrap up this thread, this
 > is likely to be an important point.  I would strongly advise making this
 > concession if you can.

as I exlained above I don't think it is a practical solution for what you want
and far more painful than anything else (for you) unless as a result of this
you start to only distribute nonLaTeX --- and if that is the intention behind
it then all the arguments "we really don't want do this, we only want the
right to be able to do something if necessary" are simply off because then you
are essentially starting to produce a new nearly-latex distribution so that
the exchangability of documents would after a short period be in real danger
again.


 > Would it work for you to require the following?
 > 
 >  - if the whole is named "LaTeX", every changed file must be renamed
 > 
 >  - if the whole is named something else, files may be changed without
 > renaming
 > 
 > (We would need to come up with a suitable definition for "naming", of
 > course.)

if there is provision that a pristine LaTeX is distributed as well so that the
user has the choice, probably, otherwise I think not.

i'm also very interested to hear any comments on

  http://lists.debian.org/debian-legal/2002/debian-legal-200207/msg00472.html

because that may be a different way to come together.

but i really think that the best way in practical terms of the pain envolved
for people who want to do changes etc is the weak form of filerename, so I
hope that gets a bit further discussed between you.

b

Re: Towards a new LPPL draft

[William F Hammond]

More nuances of language.

Frank Mittelbach <[EMAIL PROTECTED]> writes to
debian-legal:

> that you produce sniffenlatex which has its own complete tree and in
> there has identical file names to the pristine LaTeX tree so that both
> trees live side by side.

For new LPPL language it might make sense to hold that "sniffenlatex"
is an _implemented_ _project_ which would then live parallel to the
LaTeX Project's implemented project.  Then names inside implemented
projects can be unrestricted since the objects inside them are
different objects solely by virtue of residence under the different
implemented project.

If there is an easy way for (1) a human user and (2) a formatting
robot to discern the provenance of a given implemented project, then I
see no reason in principle why there must be one implemented project
that is "legally" canonical.

Of course, however, the LaTeX Project's implemented project will be
the only sensible one for at least the next twenty years quite
independent of whatever TeX engines come along.  :-)

The license must have rules to keep the provenance thing honest.

It will be important to warn in the proximity of the LPPL for those
not trying to conduct a revolt against the LaTeX Project that their
greatest mileage for change will be with intelligent use of
\documentclass to begin a document with a class, whether custom or
not, and \usepackage to call in styles (order of call significant).

In Linux everyone needs to understand that just as non-vendor-managed
software is placed outside of vendor areas, custom items provided for
an implemented project under TDS/Kpathsea are also placed within the
implemented project outside of the project's native area (the main
texmf tree), say under texmf-local or texmf-var.

(I'm not suggesting that an implemented project be required to support
TDS/Kpathsea just as I would not suggest requiring that a filesystem
implementation support more than 8+3 monocase filenames.)

(Maybe there should be a warning near the LPPL that OS-level
TeX-related environmentals these days may not be wanted.)

\grumble{I found an otherwise excellent article through a reference in
this morning's mail by well known authors from high profile academic
institutions that began with the obsolete \documentstyle command.}

-- Bill


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Towards a new LPPL draft

[Jeff Licquia]

On Tue, 2002-07-23 at 11:46, Frank Mittelbach wrote:
> Jeff Licquia writes:
> 
>  > If each piece of the work had to be downloaded separately, then this
>  > would be a valid way of thinking.  When the LaTeX Project collects a
>  > bunch of these separate works and combines them into "LaTeX", though,
>  > they create a derived work, with its own licensing requirements.
> 
> well, but that is how  the situation is, isn't it?
> 
> The LaTeX Project is not collecting a bunch of seperate works and combines
> them into LaTeX. It only provides 3 or 4 core parts of what is known to be
> LaTeX as well as providing a license (LPPL) which helps to keep that thing
> "LaTeX" uniform between different installations.

I see.  I was under the impression that what you distribute included
lots of third-party stuff.

Debian is really only concerned here with the core license on the core
parts of LaTeX.  If others within the LaTeX community don't like what
you've done with the license, then they can add modification
restrictions, and Debian can then decide to distribute them or not, or
negotiate directly with them, or whatever.

But before we can deal with the add-ons, we need to deal with the core.

> I mean I know that tetex (as a debian package) has done the downloading of
> individual LaTeX-macro works of many individual authors combined it with the
> scripts by Thomas Esser and with a web2c implementation of TeX and a few other
> independent works.
> 
>  As a whole (the packaging etc) tetex may have its own copyright and license,
> but that doesn't mean that the indivdual works it combines lose their license
> just because somebody puts them together. This is why we thought it to be a
> bad joke on this list when people claimed they not use TeX but tetex which is
> "free and under GPL". its organisation might be under GPL, the scripts may be
> under GPL, etc., but TeX the program within tetex and the 72 Computer Modern
> fonts within tetex are under Knuth's license and the 500 latex packages inside
> tetex are under LPPL or some other license (which is why there is the vague
> reference that individual parts may have different copyrights and licenses
> inside, which most people here like to ignore or overlook).

Right.  This turned out to be an inaccuracy within the copyright file
Debian requires of all packages.  A bug has been filed to fix it.

>  > The license already allows sub-works within LaTeX to have additional
>  > modification requirements beyond the LPPL.  If you thought that some of
>  > the sub-authors would disagree with relaxing the file naming requirement
>  > when changing the name of the work from "LaTeX", you could allow them to
>  > add that restriction to their file(s).
> 
> What i was pointing out in my second reply to Brian is this: suppose you would
> only want to modify the work overcite.sty which consists of single file, or
> the work geometry which consists of geometry.sty + .dtx + a number of test
> files and manual then to be able to modify that without renaming you would
> need to build a "nonLaTeX" format with its own tree and place it in that
> tree. Now that "nonLaTeX" format wouldn't work at all unless you also copy a
> good proportion of the standard latex tree (couple of 1000 files if you
> include the fonts etc) into the new tree as well. That is certainly possible
> but i think it is far more painful than
> 
> providing a nonLaTeX format with filename remapping and put
> 
>  overcite.fst and geometry.fst into the main tree
> 
> thereby having LaTeX use the main tree (ignoring those two new files)
> and nonLaTeX using the main tree and loading overcite.fst when overcite.sty
> would by loaded by LaTeX and the same for geometry.

Please clarify something for me.  What are the .fst files?  Are they
patches?

>  > > If you think of LPPL applying to the whole of a LaTeX sty/cls tree of 
> files
>  > > at once, we could, i think
>  > > live with the idea (it is even described so in modguide or cfgguide as a
>  > > possible though not encouraged 
>  > > solution (thereby actually violating the license as it is right now)), 
> that
>  > > you produce sniffenlatex 
>  > > which has its own complete tree and in there has identical file names to 
> the
>  > > pristine LaTeX tree so 
>  > > that both trees live side by side. 
>  > 
>  > >From the objections I have seen in trying to wrap up this thread, this
>  > is likely to be an important point.  I would strongly advise making this
>  > concession if you can.
> 
> as I exlained above I don't think it is a practical solution for what you want
> and far more painful than anything else (for you) unless as a result of this
> you start to only distribute nonLaTeX --- and if that is the intention behind
> it then all the arguments "we really don't want do this, we only want the
> right to be able to do something if necessary" are simply off because then you
> are essentially starting to produce a new nearly-latex distribution so that
> the exchangab

Re: Towards a new LPPL draft

[Brian Sniffen]

> On Tue, 23 Jul 2002 18:46:18 +0200, Frank Mittelbach <[EMAIL PROTECTED]> 
> said:
>> > If you think of LPPL applying to the whole of a LaTeX sty/cls
>> > tree of files at once, we could, i think live with the idea (it
>> > is even described so in modguide or cfgguide as a possible though
>> > not encouraged solution (thereby actually violating the license
>> > as it is right now)), that you produce sniffenlatex which has its
>> > own complete tree and in there has identical file names to the
>> > pristine LaTeX tree so that both trees live side by side.
>>
>> >From the objections I have seen in trying to wrap up this thread,
>> >this
>> is likely to be an important point.  I would strongly advise making
>> this concession if you can.

> as I exlained above I don't think it is a practical solution for
> what you want and far more painful than anything else (for you)
> unless as a result of this you start to only distribute nonLaTeX ---

Yes, but it would allow a clearly DFSG-free fork, and provide all of
the freedoms (modification and distribution) that the Debian project
is asking for.  It means that you can do one (big, annoying) thing,
then patch and hack and modify as you please.  That's an important
feature. 

> and if that is the intention behind it then all the arguments "we
> really don't want do this, we only want the right to be able to do
> something if necessary" are simply off because then you are
> essentially starting to produce a new nearly-latex distribution so
> that the exchangability of documents would after a short period be
> in real danger again.

Please don't grant freedoms in your license under the expectation that
they won't be used.  I think you can have a reasonable expectation
that they won't be intentionally abused, but if the LaTeX project were
to use a license as suggested here (which required changing only the
work name, not the file name), I'd expect to see a little fork pop up
every few years and die from lack of use a few months later.

I'd also expect to see some folks here wade through the thousands of
files in LaTeX, collecting and sorting interlacing copyrights and
licenses, and produce a "DfSgTeX" package, which contained only the
DFSG-free parts of LaTeX, with the remaining parts amended so as not
to use them, or patched so as to provide DFSG-free equivalents.

>> Would it work for you to require the following?
>>
>> - if the whole is named "LaTeX", every changed file must be renamed
>>
>> - if the whole is named something else, files may be changed
>>   without
>> renaming
>>
>> (We would need to come up with a suitable definition for "naming",
>> of course.)

> if there is provision that a pristine LaTeX is distributed as well
> so that the user has the choice, probably, otherwise I think not.

If you wrote a pointer to an authoritative source into the LPPL, would
that cover the LaTeX project's requirements here?  That would
guarantee that a user not only receives notification that he didn't
just call latex when he typed "sniffentex", but also that he has a
pointer to the pristine LaTeX.

Requiring that the tarball for SniffenTeX be no smaller than the
tarball for LaTeX, since if I distribute a fork I must distribute a
pristine LaTeX *with* it, would be unacceptable.  If I'm an
English-language bigot who wishes to remove babel and all references
to it, and distribute that fork, I must have that right to be
DFSG-free.

-Brian

--
Brian Sniffen [EMAIL PROTECTED]
Security Engineer day: (617) 444-2642cel: (617) 721-0927
Akamai Technologies   eve: (781) 874-0699 pi: (314) 159-2654 


pgpkqQOYgZTAF.pgp
Description: PGP signature

Re: Towards a new LPPL draft

[Mark Rafn]

On Tue, 23 Jul 2002, Mittelbach, Frank wrote:

> can you do me the favor and try to clearify for me when in your opinion
> the DSFG 4 clause is applicable for a license.

You asked for Branden's opinion, which I hope he'll give.  I'll add mine.  
DFSG 4 has 3 sentences, the first two of which are pretty clear (and don't 
apply in the case where source=binary).  The third is durned ambiguous, 
which is at least one reason we recommend against it.

"The license may require derived works to carry a different name or 
version number from the original software."

What does it mean to "carry a name or version number". This is not 
generally applied to filenames, but to package names and output from the 
"foo -version" or whatever is used to identify the package.

> Suppose you have a program source foo.c with some license.
> Suppose this license "restricts"  foo.c from being modified but allows
> distribution of foo.c
> plus a patch file, e.g. foo.dif and allows to patch foo.c at built time,
> i.e.
> 
> patch < foo.dif
> gcc foo
> 
> NOW: would it be acceptable for the license to disallow distribution of the
> modified built 

No way.  Sentence 2 of DFSG4 explicitly requires distribution of the 
modified binary to be allowed.

> and prevent distribution of
> 
>   foo.c + foo.dif + foo (patched built)
> 
> and prevent distribution of
> 
>   foo (patched built only)

Clearly not a free license if this is prohibited.  foo.c + foo.dif +
foo(patched built)  would be the normal distribution mechanism for
modified versions.

> 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 sentence after that is even more important.  "The license must 
explicitly permit distribution of software built from modified source 
code."

> I don't know if you use LaTeX or TeX but assuming you do to some extent, 
> what exactly do you consider "source" and what "built" in case of a LaTeX 
> work like varioref consisting of the files

My opinion only - I would accept either of:

1) Source is what's in the source tree, "built" is what's executed at 
runtime, which may be a different tree.  For script files, the compiler is 
named 'cp' (or maybe 'patch').

2) Some packages have no distinction between source and binary, and can 
only meet DFSG by allowing patched source to be distributed.

> In other words, there is (normally) no "binary" in the TeX/LaTeX world but
> only "source".

> So when applying DSFG#4's patch condition: would it be okay to have a
> license that forbits to change overcite.sty and only allows distributing
> derived works by distributing
>  overcite.sty + overcite.dif

No.  The result of the patch must be distributable.  If you allow
orig-src/overcite.sty and patches/overcite.dif AND
(patched)runthis/overcite.sty to be distributed, we're looking good.

You CAN require that distributors make pristine source and patches
available in addition to the patched "binaries", but you can't disallow
distribution of the modified software.
--
Mark Rafn[EMAIL PROTECTED]  



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Towards a new LPPL draft

[Frank Mittelbach]

Jeff Licquia writes:
 > > The LaTeX Project is not collecting a bunch of seperate works and combines
 > > them into LaTeX. It only provides 3 or 4 core parts of what is known to be
 > > LaTeX as well as providing a license (LPPL) which helps to keep that thing
 > > "LaTeX" uniform between different installations.
 > 
 > I see.  I was under the impression that what you distribute included
 > lots of third-party stuff.
 > 
 > Debian is really only concerned here with the core license on the core
 > parts of LaTeX.  If others within the LaTeX community don't like what
 > you've done with the license, then they can add modification
 > restrictions, and Debian can then decide to distribute them or not, or
 > negotiate directly with them, or whatever.

sorry, but we are not concerned only with the core stuff. even though we don't
distribute the rest. The whole set of files put on ctan and identical (on a
pristine LaTeX installation) is what makes LaTeX useful, not  their quality as
such. So either we find a solution which keeps this intact (and we
had found something with LPPL, though we are happy to reword it, to iron out
mistakes in it that do not fit the intended meaning).

but there is no point in providing a largely useless core (identical) and
having all the rest happily return to the state of 1990 where no two site had
identical LaTeX packages and thus document exchange turned out to be largely a
matter of luck or sending whole latex package trees along with the document.

 > But before we can deal with the add-ons, we need to deal with the core.

no. sorry. if that is what only we are trying to do then I guess we have to
give up.


 > > What i was pointing out in my second reply to Brian is this: suppose you 
 > > would
 > > only want to modify the work overcite.sty which consists of single file, or
 > > the work geometry which consists of geometry.sty + .dtx + a number of test
 > > files and manual then to be able to modify that without renaming you would
 > > need to build a "nonLaTeX" format with its own tree and place it in that
 > > tree. Now that "nonLaTeX" format wouldn't work at all unless you also copy 
 > > a
 > > good proportion of the standard latex tree (couple of 1000 files if you
 > > include the fonts etc) into the new tree as well. That is certainly 
 > > possible
 > > but i think it is far more painful than
 > > 
 > > providing a nonLaTeX format with filename remapping and put
 > > 
 > >  overcite.fst and geometry.fst into the main tree
 > > 
 > > thereby having LaTeX use the main tree (ignoring those two new files)
 > > and nonLaTeX using the main tree and loading overcite.fst when overcite.sty
 > > would by loaded by LaTeX and the same for geometry.
 > 
 > Please clarify something for me.  What are the .fst files?  Are they
 > patches?

if the nonLaTeX format supports the global remapping features

 for .sty  files .fst files will be used if they exist
 for .cls  files .fcl files will be used if they exist
 and so on

then the only thing that one has to do to fix any file under LPPL is to
produce a modified version and name it .fst instead of do .sty and then
nonLaTeX will use it. No need to copy huge trees of identical software 

that was only rehashing why we think the suggested renaming together with the
global remapping feature is fully complient with DSFG and easy to use

 > The rights we demand are usually for special cases.  For example,
 > someone might want to create LaTeX Plus with some of his/her new ideas
 > for how document formatting should be done.  Or, you guys might get hit
 > by a bus, and our obligation to our users requires us to make sure that
 > LaTeX is taken care of in your absence while the Project figures out who
 > should take over.  Or maybe no one wants to take over, and we maintain
 > it as a legacy package (which we do for lots of the things we ship).

 - if somebody wants to make LATeX plus he can already and it is simple and
   can reuse all things untouched with the above method (and in fact is
   already done, eg by Lambda

 - if we get hit by a bus (which we hopefully are not) then the maintainers
   clause would allow to have people take over without the need to start a new
   fork
 - if nobody wouldwant to takeover you could become maintainer (and support it
   as a legacy package) again without the need to make a fork

so there is no problem with the rights needed by Debian for a) its users nor
for b) itself

 > >  > Would it work for you to require the following?
 > >  > 
 > >  >  - if the whole is named "LaTeX", every changed file must be renamed
 > >  > 
 > >  >  - if the whole is named something else, files may be changed without
 > >  > renaming
 > >  > 
 > >  > (We would need to come up with a suitable definition for "naming", of
 > >  > course.)
 > > 
 > > if there is provision that a pristine LaTeX is distributed as well so that 
 > > the
 > > user has the choice, probably, otherwise I think not.
 > 
 > OK.  Now I'd like to hear the Debia

Re: Towards a new LPPL draft

[Walter Landry]

Jeff Licquia <[EMAIL PROTECTED]> wrote:
> OK.  Now I'd like to hear the Debian side.  Here are the conditions for
> modification that are being proposed as I understand them:
> 
>  - you must rename all modified files, or
> 
>  - you must rename the whole of LaTeX in your modified copy AND
> distribute a pristine copy of LaTeX as well.
> 
> Comments?  Branden, Walter, Mark, and Jeremy, I'm especially interested
> in your opinions, since you three are the current objectors.

If I understand this correctly, this is basically fine with me.
Debian would distribute the pristine copy in tetex.orig.tar.gz, and
distribute a modified copy with the name DebLaTeX (or whatever) in the
.deb.  Since Debian probably won't need to modify LaTeX, or can rename
the file if it has to, it will probably just call it LaTeX.

Regards,
Walter Landry
[EMAIL PROTECTED]



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Towards a new LPPL draft

[Jeremy Hankins]

Jeff Licquia <[EMAIL PROTECTED]> writes:

> OK.  Now I'd like to hear the Debian side.  Here are the conditions for
> modification that are being proposed as I understand them:
>
>  - you must rename all modified files, or
>
>  - you must rename the whole of LaTeX in your modified copy AND
> distribute a pristine copy of LaTeX as well.
>
> Comments?  Branden, Walter, Mark, and Jeremy, I'm especially interested
> in your opinions, since you three are the current objectors.

Yikes.  I'd accept the former as free before the latter, personally.
Giving users options is one thing, but option two seems to suggest
that if Latex is forked for some reason we'll need to ferry around the
original (from the date of the fork) version of latex whenever
distributing the new version, forever.  That's a far more onerous
requirement than file renaming, imho.

Re the renaming requirement, I disagree with the statement that the
definition of file is a minor technical detail.  Do the Latex folks
really want to put this requirement on things like a readme.txt file?
And what if Latex is ported to a filesystem that doesn't have
filenames (or at least, not in the same sense)?  Is the directory
structure part of the filename?

I would be very interested in hearing someone from the Latex folks try
to say precisely what should change in order to ensure than no one
accidently use the wrong file from their document.  The way a packages
is called from a document (but that's potentially broken by the
filename remapping -- perhaps the way it's called, assuming no
remapping)?

But that said, I'm not very certain in my own mind about the file
naming issue.  I'm uncomfortable with it, but there does seem to be a
good reason for it (whether that reason is arguable is completely
separate issue).  But if we can't come up with a better way to make
the restriction, I'm not going to say we should keep it out of Debian.

-- 
Jeremy Hankins <[EMAIL PROTECTED]>
PGP fingerprint: 748F 4D16 538E 75D6 8333  9E10 D212 B5ED 37D0 0A03


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Towards a new LPPL draft

[Frank Mittelbach]

Jeremy Hankins writes:
 > Jeff Licquia <[EMAIL PROTECTED]> writes:
 > 
 > > OK.  Now I'd like to hear the Debian side.  Here are the conditions for
 > > modification that are being proposed as I understand them:
 > >
 > >  - you must rename all modified files, or
 > >
 > >  - you must rename the whole of LaTeX in your modified copy AND
 > > distribute a pristine copy of LaTeX as well.
 > >
 > > Comments?  Branden, Walter, Mark, and Jeremy, I'm especially interested
 > > in your opinions, since you three are the current objectors.
 > 
 > Yikes.  I'd accept the former as free before the latter, personally.
 > Giving users options is one thing, but option two seems to suggest
 > that if Latex is forked for some reason we'll need to ferry around the
 > original (from the date of the fork) version of latex whenever
 > distributing the new version, forever.  That's a far more onerous
 > requirement than file renaming, imho.

let me first qualify the suggestion that Jeff made above

 - the reason for it is to give the user the possibility to exchanges
   documents with other using pristine LaTeX and obtain identical output

 - it therefore quite pointless to carry around some old pristine LaTeX from
   the day of the fork; if the above suggestion has to have value to the goals
   we try to achieve with the LPPL license, then the suggestion would be to
   keep a copy of current pristine LaTeX, though I doubt that could or should
   be codified except as a suggestion.

 > Re the renaming requirement, I disagree with the statement that the
 > definition of file is a minor technical detail.  Do the Latex folks
 > really want to put this requirement on things like a readme.txt file?
 > And what if Latex is ported to a filesystem that doesn't have
 > filenames (or at least, not in the same sense)?  Is the directory
 > structure part of the filename?

the answer to the first is no and to the second "most likely no, except in
very unusual circumstances". To qualify that: I suggested at one point that
instead of requiring the filename rename it would be enough to achieve the
goals of the LaTeX community to require that from within a pristine LaTeX
kernel the original work and the derived work are distinguishable. In other
words

 in a redraft of LPPL i wuold try to limit any renaming requirement to such
 files that need to change their file names in order to make this distinction
 (or use the requirement to distinguish as the requirement rather than the
 file name and only remark that in most cases this might mean that certain
 files need new names. -> readme.txt would not need to change.

 from that it also follows that if on an OS with a different type of
 filestructure (say MVS) that revised requirement would have other effects
 (i've forgotten what the things got called on mvs, but all the classes lived a
  single datastructures with members there, and so you wouldhave to chose a
 different member name)

does this answer the question?

 > I would be very interested in hearing someone from the Latex folks try
 > to say precisely what should change in order to ensure than no one
 > accidently use the wrong file from their document.  The way a packages
 > is called from a document (but that's potentially broken by the
 > filename remapping -- perhaps the way it's called, assuming no
 > remapping)?

the answer (for me) would be

 - if a file is not used by pristine LaTeX (that is a LaTeX kernel without the
   remapping feature added) then there is no need for a renaming of any kind

 - otherwise, if it is an object used at some point in the game by the
   underlying macroprocessor (ie loaded) then the "name" used for loading
   should be different --- that is not thefile name though in most
   implementation it is a one to one mapping (which is why we suggested to use
   the filename rename as an requirement.

 > But that said, I'm not very certain in my own mind about the file
 > naming issue.  I'm uncomfortable with it, but there does seem to be a
 > good reason for it (whether that reason is arguable is completely
 > separate issue).  But if we can't come up with a better way to make
 > the restriction, I'm not going to say we should keep it out of Debian.

well thanks for saying that there seems to be a reason for it. I personally
would feel mcuh easier if that would be different in TeX and one could ensure
uniformity in a different way. but being as it is, I see no good alternative
as trademarking several hundred file names isn't (and wouldn't help Debian
either). This is why I thought and still think that a completely free hand
through the global remapping feature isactually giving everybody the best of
both worlds and is complient with DSFG

frank 


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Towards a new LPPL draft

[Walter Landry]

Jeremy Hankins <[EMAIL PROTECTED]> wrote:
> Jeff Licquia <[EMAIL PROTECTED]> writes:
> 
> > OK.  Now I'd like to hear the Debian side.  Here are the conditions for
> > modification that are being proposed as I understand them:
> >
> >  - you must rename all modified files, or
> >
> >  - you must rename the whole of LaTeX in your modified copy AND
> > distribute a pristine copy of LaTeX as well.
> >
> > Comments?  Branden, Walter, Mark, and Jeremy, I'm especially interested
> > in your opinions, since you three are the current objectors.
> 
> Yikes.  I'd accept the former as free before the latter, personally.
> Giving users options is one thing, but option two seems to suggest
> that if Latex is forked for some reason we'll need to ferry around the
> original (from the date of the fork) version of latex whenever
> distributing the new version, forever.  That's a far more onerous
> requirement than file renaming, imho.

This is specifically allowed by DFSG #4.  The Q Public License uses
this feature as well.  If you don't like it, feel free to call a
General Resolution to change it.  Until then, it is still part of the
DFSG.

Regards,
Walter Landry
[EMAIL PROTECTED]


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Towards a new LPPL draft

[Frank Mittelbach]

Glenn Maynard writes:
 > On Mon, Jul 22, 2002 at 04:27:57PM -0700, Walter Landry wrote:
 > > It sounds like you might have to talk to Branden and maybe Henning as
 > > well.  I'm not sure about Mark Rafn and Glenn Maynard.  Thomas
 > > Bushnell, Sam Hartman, and Colin Watson seem to be with you.  Those
 > > seem to be all of the regular contributors to debian-legal.  My
 > > apologies if I've missed someone.
 > 
 > I'm not a DD.  For those interested in my opinion anyway:  What if I want
 > to modify Latex to remove the filename mapping?  If the DFSG-freeness is
 > dependent on that mechanism, then I can't remove it (for the best or worst
 > of technical reasons) and have it remain DFSG-free.  Having freeness
 > dependent on a feature being present is strange.
 > 
 > Jeff, I don't know how you could make the renaming requirement dependent
 > on this; then you have to deal with the case that people might remove
 > the feature.  Having license conditions dependent on specific features
 > seems like a bad idea.  
 > 
 > (Of course, it might be nearly impossible to remove that mechanism without
 > completely breaking the entire system, but that doesn't change the point.)

but I think what changes the point is that the filename remapping feature is
something that is available in a system outside the domain of the software
LPPL applies to, eg LPPL applies to LaTex macros but the feature is in the
virtual machine running such macros, ie TeX. So there is no way to "remove it"
and anyway the license to be applicable could require it.

Again, LPPL is a license drafted to serve a particular domain, just like the
Artist license and many other do. As such it seems acceptable to me that it
puts restrictions on to what it may be applied to, and that is what Jeff was
saying: he wanted to make sure (and i would be quite happy to make sure as
well.)

frank


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Towards a new LPPL draft

[Richard Braakman]

On Tue, Jul 23, 2002 at 08:06:29AM -0600, Joe Moore wrote:
> What's wrong with the conditional statement (unproven assertion:) 
>   "The LPPL-1.3 is DFSG-free, but only when applied to software which makes
> the file-renaming requirement easy"

Well, one of the properties of free software is that you can change it :)

Consider a port of an LPPL'd program to a limited architecture, where
one of the space-optimizing changes has a side effect of making it much
harder to rename files.  (For example, suppose the standard filenames are
tokenized in some way, and the encoding for nonstandard filenames is too
bulky to be useful.)

The resulting program would not be DFSG-free, even though the license
didn't change!  This is independent of the license used for the
modifications themselves.  I think this lack of "transitive closure"
is against the spirit of DFSG 3.  It creates limits on what kinds of
derived works you can make without wandering into non-free space.

Hmm, I thought of a perhaps more practical example that also illustrates
my desire for transitive closure.  What if you take a piece of code from
an LPPL'ed work and use it in another project?  This other project might
lack any facility for remappping filenames.  Should it be required to
add a remapping facility to a project that doesn't otherwise need it,
just to satisfy an allegedly free license?

> This is essentially what is said about the GFDL, "It's DFSG-free only if no
> options are used in the document"

That's different: it's a condition on the license, not on what it covers.
A derived work can only become non-free if extra restrictions are added
(such as marking new text as an Invariant Section).

-- 
Richard Braakman
"I sense a disturbance in the force"
"As though millions of voices cried out, and ran apt-get."
  (Anthony Towns about the Debian 3.0 release)


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Towards a new LPPL draft

[Frank Mittelbach]

Richard Braakman writes:

 > Hmm, I thought of a perhaps more practical example that also illustrates
 > my desire for transitive closure.  What if you take a piece of code from
 > an LPPL'ed work and use it in another project?  This other project might
 > lack any facility for remappping filenames.  Should it be required to
 > add a remapping facility to a project that doesn't otherwise need it,
 > just to satisfy an allegedly free license?

no, but if we rework the file renaming requirement to the requirement to be
identifiable distinguiable if called from within pristine LaTeX (or more
generally from within the underlying virtual machine) then the problem would
go away, wouldn't it?

remember there is no requirement (or at least that is what the license
shouldsay in the end) whatsoever on the license for a derived work except that
it should put under a license that explicitly forbits to have the derived work
or any furth modification being renamed to the original work (or in the
new wording: make the derived work be undistinguishable from the original when
loding into pristine latex).

what i try to say is that the use of that code in a different project doesn't
make lppl apply for the derived work except with the single clause for not
putting it back into latex under its original "interface name".

so i think your transitive closure is in no danger at all

frank


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Towards a new LPPL draft

[Richard Braakman]

On Tue, Jul 23, 2002 at 01:47:46PM -0400, Brian Sniffen wrote:
> Requiring that the tarball for SniffenTeX be no smaller than the
> tarball for LaTeX, since if I distribute a fork I must distribute a
> pristine LaTeX *with* it, would be unacceptable.  If I'm an
> English-language bigot who wishes to remove babel and all references
> to it, and distribute that fork, I must have that right to be
> DFSG-free.

Unfortunately, this is exactly the kind of requirement that DFSG#4 allows.
It is, I think, the main reason why some developers (including myself)
want to get rid of that clause.

Note that this size requirement is only on the _source_ tarball, you
will always be able to build a "binary" tarball that is smaller.
This links back to the discussion of what "build time" means, but
it's pretty clear to me that creating a Debian package is "building".

-- 
Richard Braakman
"I sense a disturbance in the force"
"As though millions of voices cried out, and ran apt-get."
  (Anthony Towns about the Debian 3.0 release)


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Towards a new LPPL draft

[Brian Sniffen]

> On Tue, 23 Jul 2002 21:50:07 +0200, Frank Mittelbach <[EMAIL PROTECTED]> 
> said:

> Jeremy Hankins writes:
>> Jeff Licquia <[EMAIL PROTECTED]> writes:
>> 
>> > OK.  Now I'd like to hear the Debian side.  Here are the conditions for
>> > modification that are being proposed as I understand them:
>> >
>> >  - you must rename all modified files, or
>> >
>> >  - you must rename the whole of LaTeX in your modified copy AND
>> > distribute a pristine copy of LaTeX as well.
>> >
>> > Comments?  Branden, Walter, Mark, and Jeremy, I'm especially interested
>> > in your opinions, since you three are the current objectors.
>> 
>> Yikes.  I'd accept the former as free before the latter, personally.
>> Giving users options is one thing, but option two seems to suggest
>> that if Latex is forked for some reason we'll need to ferry around the
>> original (from the date of the fork) version of latex whenever
>> distributing the new version, forever.  That's a far more onerous
>> requirement than file renaming, imho.

> let me first qualify the suggestion that Jeff made above

>  - the reason for it is to give the user the possibility to exchanges
>documents with other using pristine LaTeX and obtain identical output

>  - it therefore quite pointless to carry around some old pristine LaTeX from
>the day of the fork; if the above suggestion has to have value to the goals
>we try to achieve with the LPPL license, then the suggestion would be to
>keep a copy of current pristine LaTeX, though I doubt that could or should
>be codified except as a suggestion.

Would a pointer to a place where a pristine copy may be obtained, as
part of the license text, be enough for you?  Say, a URL pointing to
http://www.latex-project.org/ ?

-Brian


pgp0frKzGgCDY.pgp
Description: PGP signature

Re: Towards a new LPPL draft

[Frank Mittelbach]

Branden,

thank you very much for that detailed set of comments.


 > Sure.  Before getting to your hypotheticals, I'll try and give you a
 > direct, if generalized, answer.
 > 
 > A license must be tested against DFSG 4 when either of the following are
 > true:
 > 
 > A) the license places restrictions on the form in which modifications to
 >the Work are distributed;
 > B) the license places restrictions on the manner in which the Work is
 >named or versioned.

okay. that is because DSFG 4 exists.

 > Without DFSG 4, *any* license term did either of the above would violate
 > violate DFSG 3.

stepping more and more into that type of legal thinking ... (sorry if i'm a
bore, but I really like to understand) ... I don't see that anything like the
above follows from DSFG3.

 to my (proably simple) mind DSFG3 says absolutely nothing about "how" the
 licenses must allow modification other than it must allow them to be
 distributed under the "same terms" as the original software. Eg if the
 license puts restrictions on naming or versioning (the same restrictions on
 the original as well as the modifictions) then to my understanding the "same
 terms" is not violated at all.

I can however understand that if a license make modification in principle
possible but makes modification so difficult that in practise it *is*
impossible or nearly impossible that this would violate DFSG3.

I'm therefore happily tried (and i think succeded) in removing the cascading
file renaming obstacle out of the way.

 > > Question 1:
 > > 
 > > Suppose you have a program source foo.c with some license.  Suppose
 > > this license "restricts"  foo.c from being modified but allows
 > > distribution of foo.c plus a patch file, e.g. foo.dif and allows to
 > > patch foo.c at built time, i.e.
 > > 
 > > patch < foo.dif
 > > gcc foo
 > > 
 > > NOW: would it be acceptable for the license to disallow distribution
 > > of the modified built
 > 
 > No.  Quoting DFSG 4:
 > 
 > "The license must explicitly permit distribution of software built from
 > modified source code."

question mostly withdrawn (as it anyway isn't applicable to LaTeX related
software)

 > > is that what you think 
 > > 
 > > 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.
 > > 
 > > means? I guess the answer might be no, but i would like to get a clear
 > > picture.
 > 
 > You are correct.  I do not think that DFSG 4 can plausibly be read to
 > permit the the restrictions you posit in your hypothetical.

okay, thouhg I think one can make a case for arguing that there is nothing
explicit that says you are not allowed to require the the binary has a
different name. I do however submit that the intention of clause for is to
disallow it (but since we here are so often and quite rightly into exact
wording (hallo Jeff:-) i think you might consider making this clear, but
perhaps I miss something that follows from combining other points ...)


 > > Question 2:
 > > 
 > > I don't know if you use LaTeX or TeX but assuming you do to some extent, 
 > 
 > I have used LaTeX in the past but only at a highly rudimentary level; I
 > understand almost nothing of its internals.
 > 
 > > what exactly do you consider "source" and what "built" in case of a LaTeX 
 > > work
 > 
 > That's an excellent question and it illustrates a vagueness in the
 > wording of the DFSG.  The DFSG misleadingly speaks in terms of "source"
 > and "binary" when in many situations, as folks have noted on this list,
 > the distinctions are not applicable, at least not in the same way that
 > they are to compiled C programs.

thank you. let me start by saying that i don't want to trick anybody to
submitting something that they actually do mean. I'm trying to figure out
where the common grounds are (if any)

  [definition of meaning of source and binary ommitted]

okay. sounds good to me. As I said in my post I think stuff like latex macros
really don't fit nicely into this scheme as bing both source and binary more
or less.

 > In my opinion, my interpretation of the source/binary binary dichotomy
 > is more consistent with Debian's tradition, in that we are not looking
 > for loopholes through which we will tolerate the suppression of users'
 > rights to modify the software they get from Debian, and redistribute
 > their modifications to their neighbors.

i htink both can be argued for (or even that both would need to apply) but in
any case i wasn't looking for loopholes but for a common ground and if that
part isn't the point to meet, too bad :-)


but i would liketo sumarize on what I understand (and don't) perhaps one or
the other is joining in at this point

 a) My understanding is that the outlined LPPL rewrite behind Jeff's mail
  "Concluding the debate" 
would be DSFG free as the rights w

Re: Towards a new LPPL draft

[Glenn Maynard]

On Tue, Jul 23, 2002 at 12:58:01PM -0700, Walter Landry wrote:
> > >  - you must rename the whole of LaTeX in your modified copy AND
> > > distribute a pristine copy of LaTeX as well.

> This is specifically allowed by DFSG #4.  The Q Public License uses

Branden is asserting that DFSG's patch exception doesn't apply to
non-compiled languages, though, due to its "at build time" wording.

(I tend to think that the wording of the entire paragraph is compiled-
language-centric, and that patches that are applied at installation-
time, without a "building" as such, is in the spirit of #4.  I can
sympathise with taking the statement literally, to reduce the scope of
a disliked clause, however.)

-- 
Glenn Maynard


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Towards a new LPPL draft

[Jeff Licquia]

On Tue, 2002-07-23 at 13:20, Frank Mittelbach wrote:
> Jeff Licquia writes:
>  > > The LaTeX Project is not collecting a bunch of seperate works and 
> combines
>  > > them into LaTeX. It only provides 3 or 4 core parts of what is known to 
> be
>  > > LaTeX as well as providing a license (LPPL) which helps to keep that 
> thing
>  > > "LaTeX" uniform between different installations.
>  > 
>  > I see.  I was under the impression that what you distribute included
>  > lots of third-party stuff.
>  > 
>  > Debian is really only concerned here with the core license on the core
>  > parts of LaTeX.  If others within the LaTeX community don't like what
>  > you've done with the license, then they can add modification
>  > restrictions, and Debian can then decide to distribute them or not, or
>  > negotiate directly with them, or whatever.
> 
> sorry, but we are not concerned only with the core stuff. even though we don't
> distribute the rest. The whole set of files put on ctan and identical (on a
> pristine LaTeX installation) is what makes LaTeX useful, not  their quality as
> such. So either we find a solution which keeps this intact (and we
> had found something with LPPL, though we are happy to reword it, to iron out
> mistakes in it that do not fit the intended meaning).

Well, I am confused, then.

When I talk about "LaTeX", I am talking about something with a specific
scope.  If, for example, the LPPL required that every file in /usr/bin
be renamed whenever something changes within LaTeX, that would be quite
blatantly non-free because of an overwide scope and high burden placed
on the user.

There is, I imagine, stuff that is not a part of LaTeX, but that works
with LaTeX.  That stuff may or may not be licensed under a particular
license.  That's immaterial to the question of whether LaTeX is free or
not.

If you're asking Debian to always ship absolutely everything in CTAN as
a precondition to gaining modification rights to LaTeX, then that's
something that Debian can't offer.  We don't know how that software is
licensed, and can't guarantee that it will be free or not.

> but there is no point in providing a largely useless core (identical) and
> having all the rest happily return to the state of 1990 where no two site had
> identical LaTeX packages and thus document exchange turned out to be largely a
> matter of luck or sending whole latex package trees along with the document.
> 
>  > But before we can deal with the add-ons, we need to deal with the core.
> 
> no. sorry. if that is what only we are trying to do then I guess we have to
> give up.

Then you should take over the copyright from the other contributors, or
mandate that they accept the LPPL as you deliver it, or get everyone to
accept the LPPL voluntarily, or something.

You can't have it both ways.  If you treat add-ons outside your control
as "core" to LaTeX and allow them to be licensed arbitrarily, then you
must accept the fact that people like us will be forced by the licenses
to drop portions of it.  Otherwise, as has been pointed out before, the
LPPL could be a free license but LaTeX be non-free, because one file
within it has an unacceptable modification restriction.

Put another way: If you refuse to allow us to drop a non-free file, then
the whole of LaTeX gains a new license: the LPPL plus the conditions of
the single non-free file.  If you don't give us a way around that, then
your hard work getting the LPPL compliant can be invalidated by a single
person within the LaTeX community who gets a flight of fancy that
freedom isn't all that important.

>  > Please clarify something for me.  What are the .fst files?  Are they
>  > patches?
> 
> if the nonLaTeX format supports the global remapping features
> 
>  for .sty  files .fst files will be used if they exist
>  for .cls  files .fcl files will be used if they exist
>  and so on
> 
> then the only thing that one has to do to fix any file under LPPL is to
> produce a modified version and name it .fst instead of do .sty and then
> nonLaTeX will use it. No need to copy huge trees of identical software 
> 
> that was only rehashing why we think the suggested renaming together with the
> global remapping feature is fully complient with DSFG and easy to use

I see.

>  > The rights we demand are usually for special cases.  For example,
>  > someone might want to create LaTeX Plus with some of his/her new ideas
>  > for how document formatting should be done.  Or, you guys might get hit
>  > by a bus, and our obligation to our users requires us to make sure that
>  > LaTeX is taken care of in your absence while the Project figures out who
>  > should take over.  Or maybe no one wants to take over, and we maintain
>  > it as a legacy package (which we do for lots of the things we ship).
> 
>  - if somebody wants to make LATeX plus he can already and it is simple and
>can reuse all things untouched with the above method (and in fact is
>already done, eg by Lambda
> 
>  - if we ge

Re: Towards a new LPPL draft

[Frank Mittelbach]

Jeff Licquia writes:
 > On Tue, 2002-07-23 at 13:20, Frank Mittelbach wrote:
 > > Jeff Licquia writes:
 > >  > > The LaTeX Project is not collecting a bunch of seperate works and 
 > > combines
 > >  > > them into LaTeX. It only provides 3 or 4 core parts of what is known 
 > > to be
 > >  > > LaTeX as well as providing a license (LPPL) which helps to keep that 
 > > thing
 > >  > > "LaTeX" uniform between different installations.
 > >  > 
 > >  > I see.  I was under the impression that what you distribute included
 > >  > lots of third-party stuff.
 > >  > 
 > >  > Debian is really only concerned here with the core license on the core
 > >  > parts of LaTeX.  If others within the LaTeX community don't like what
 > >  > you've done with the license, then they can add modification
 > >  > restrictions, and Debian can then decide to distribute them or not, or
 > >  > negotiate directly with them, or whatever.
 > > 
 > > sorry, but we are not concerned only with the core stuff. even though we 
 > > don't
 > > distribute the rest. The whole set of files put on ctan and identical (on a
 > > pristine LaTeX installation) is what makes LaTeX useful, not  their 
 > > quality as
 > > such. So either we find a solution which keeps this intact (and we
 > > had found something with LPPL, though we are happy to reword it, to iron 
 > > out
 > > mistakes in it that do not fit the intended meaning).
 > 
 > Well, I am confused, then.
 > 
 > When I talk about "LaTeX", I am talking about something with a specific
 > scope.  If, for example, the LPPL required that every file in /usr/bin
 > be renamed whenever something changes within LaTeX, that would be quite
 > blatantly non-free because of an overwide scope and high burden placed
 > on the user.
 > 
 > There is, I imagine, stuff that is not a part of LaTeX, but that works
 > with LaTeX.  That stuff may or may not be licensed under a particular
 > license.  That's immaterial to the question of whether LaTeX is free or
 > not.
 > 
 > If you're asking Debian to always ship absolutely everything in CTAN as
 > a precondition to gaining modification rights to LaTeX, then that's
 > something that Debian can't offer.  We don't know how that software is
 > licensed, and can't guarantee that it will be free or not.
 > 
 > > but there is no point in providing a largely useless core (identical) and
 > > having all the rest happily return to the state of 1990 where no two site 
 > > had
 > > identical LaTeX packages and thus document exchange turned out to be 
 > > largely a
 > > matter of luck or sending whole latex package trees along with the 
 > > document.
 > > 
 > >  > But before we can deal with the add-ons, we need to deal with the core.
 > > 
 > > no. sorry. if that is what only we are trying to do then I guess we have to
 > > give up.
 > 
 > Then you should take over the copyright from the other contributors, or
 > mandate that they accept the LPPL as you deliver it, or get everyone to
 > accept the LPPL voluntarily, or something.
 > 
 > You can't have it both ways.  If you treat add-ons outside your control
 > as "core" to LaTeX and allow them to be licensed arbitrarily, then you
 > must accept the fact that people like us will be forced by the licenses
 > to drop portions of it.  Otherwise, as has been pointed out before, the
 > LPPL could be a free license but LaTeX be non-free, because one file
 > within it has an unacceptable modification restriction.
 > 
 > Put another way: If you refuse to allow us to drop a non-free file, then
 > the whole of LaTeX gains a new license: the LPPL plus the conditions of
 > the single non-free file.  If you don't give us a way around that, then
 > your hard work getting the LPPL compliant can be invalidated by a single
 > person within the LaTeX community who gets a flight of fancy that
 > freedom isn't all that important.
 > 
 > >  > Please clarify something for me.  What are the .fst files?  Are they
 > >  > patches?
 > > 
 > > if the nonLaTeX format supports the global remapping features
 > > 
 > >  for .sty  files .fst files will be used if they exist
 > >  for .cls  files .fcl files will be used if they exist
 > >  and so on
 > > 
 > > then the only thing that one has to do to fix any file under LPPL is to
 > > produce a modified version and name it .fst instead of do .sty and then
 > > nonLaTeX will use it. No need to copy huge trees of identical software 
 > > 
 > > that was only rehashing why we think the suggested renaming together with 
 > > the
 > > global remapping feature is fully complient with DSFG and easy to use
 > 
 > I see.
 > 
 > >  > The rights we demand are usually for special cases.  For example,
 > >  > someone might want to create LaTeX Plus with some of his/her new ideas
 > >  > for how document formatting should be done.  Or, you guys might get hit
 > >  > by a bus, and our obligation to our users requires us to make sure that
 > >  > LaTeX is taken care of in your absence while the Project figures out who
 > > 

Re: Towards a new LPPL draft

[Jeff Licquia]

On Tue, 2002-07-23 at 12:32, Jeff Licquia wrote:
> Comments?  Branden, Walter, Mark, and Jeremy, I'm especially interested
> in your opinions, since you three are the current objectors.

Hmm.  Time to sign up for those remedial math classes, I think... :-)


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Towards a new LPPL draft

[Branden Robinson]

On Tue, Jul 23, 2002 at 11:53:26PM +0200, Frank Mittelbach wrote:
>  > Sure.  Before getting to your hypotheticals, I'll try and give you a
>  > direct, if generalized, answer.
>  > 
>  > A license must be tested against DFSG 4 when either of the following are
>  > true:
>  > 
>  > A) the license places restrictions on the form in which modifications to
>  >the Work are distributed;
>  > B) the license places restrictions on the manner in which the Work is
>  >named or versioned.
> 
> okay. that is because DSFG 4 exists.

Not exactly; see below.

>  > Without DFSG 4, *any* license term did either of the above would violate
>  > violate DFSG 3.
> 
> stepping more and more into that type of legal thinking ... (sorry if i'm a
> bore, but I really like to understand) ... I don't see that anything like the
> above follows from DSFG3.
> 
>  to my (proably simple) mind DSFG3 says absolutely nothing about "how" the
>  licenses must allow modification other than it must allow them to be
>  distributed under the "same terms" as the original software.

You're correct.  DFSG 3 says absolutely nothing about how the licenses
must allow modification, aside from the transitivity of the license.

That means that all methods of modification must be allowed (as, I have
said elsewhere, with the exception of deletion of or semantic alteration
of applicable copyright notices and license terms).

*ANY* license with restriction or condition on modification that is not
expressly permitted by the DFSG renders that license incompatible with the
DFSG.

Consider that DFSG 4 does not say:

"The license may restrict source-code from being distributed in modified
form _only_ if permission to do is always granted upon payment of US$500
or more per modification to the copyright holder."

That this sentence is not in DFSG 4 means that the copyright holder
cannot restrict source-code from being distributed in modified form to
those who pay him or her *ANY* amount of money.  It is not does
implicitly mean that a license can demand any amount of money, for
permission to distribute source-code in modified form.

You appear to be saying that it is DFSG-free for the LPPL to place
restrictions on modification -- namely a requirement to rename files --
because DFSG 4 doesn't say you cannot.  But that is backwards.  The only
DFSG-compatible restrictions on modification allowed by the DFSG are
those expressly stated in the DFSG (again, with the exception of
preservation of applicable copyright notices and license terms).

> Eg if the
>  license puts restrictions on naming or versioning (the same restrictions on
>  the original as well as the modifictions) then to my understanding the "same
>  terms" is not violated at all.

The license may require derived works to carry a different name or
^
version number from the original software.

The copyright that exists in a work is a different thing from its name
or version number.

The copyright that exists in the film _Il Postino_ is the same whether
it is released in the United States with the title _The Postman_ or _Il
Postino_.  More to the point, the copyright that exists in the film _The
Postman_ is the same regardless of whether the title is discernible when
the work is exhibited.

A filename is a technological device.  The name of a copyrighted Work is
an identifier that is used for legal purposes.  DFSG 4 does not
establish Debian as a filename registry.

> I can however understand that if a license make modification in principle
> possible but makes modification so difficult that in practise it *is*
> impossible or nearly impossible that this would violate DFSG3.

It doesn't matter whether the modification is easy or hard.  I think the
assertions of the Free Software Foundation and some of my fellow
Debian developers are misguided in this respect.  The DFSG says nothing
about how inconvenient the copyright holder is permitted to make the
acts of modification or redistribution.

I do not see any more evidence that DFSG 4 permits the imposition of the
renaming of modified files any more than it permits the requirement that
modifiers or distributors of copyrighted works pay a fee to the
copyright holder.

> I'm therefore happily tried (and i think succeded) in removing the cascading
> file renaming obstacle out of the way.

In my opinion, the only way to remove the file renaming obstacle in a
way that is DFSG-compliant is to remove the requirement to rename the
files altogether, or to provide a DFSG-free alternative to renaming
files.

>  > You are correct.  I do not think that DFSG 4 can plausibly be read to
>  > permit the the restrictions you posit in your hypothetical.
> 
> okay, thouhg I think one can make a case for arguing that there is nothing
> explicit that says you are not allowed to require the the binary has a
> different name.

Restrictions that are not permitted by the DFSG are forbidden...at least
if you want to be DFS

Re: Towards a new LPPL draft

[Mark Rafn]

On 23 Jul 2002, Jeff Licquia wrote:

> Correct.  I want to distinguish here between the rights Debian needs to
> have and the rights Debian intends to exercise.

This may be a useful distinction, in that it reminds license authors to 
keep "I hope" and "I want" out of the license and stick to "You must" and 
"you may", and include supporting documents that suggest friendlier ways 
to do things.

However, Debian tries very hard (and succeeds IMO) not to require any 
rights solely on our own behalf.  Anything Debian does is explicitly 
allowed for our users to do.

Regardless of the fact that Debian is unlikely to use some of the rights 
we require, we also guarantee those rights to our users, of whom we have 
no knowledge of their desire or intent.

> The rights we demand are usually for special cases.

I strongly disagree.  The rights we demand are guaranteed to our users, 
and they get to decide what's a special case and what's a burning need.

>>  > Would it work for you to require the following?
>>  >  - if the whole is named "LaTeX", every changed file must be renamed
>>  >  - if the whole is named something else, files may be changed without
>>  > renaming
...

>> if there is provision that a pristine LaTeX is distributed as well so
>> that the user has the choice, probably, otherwise I think not.

So far so good.  Pristine LaTeX (plus patches) is the source, modified 
unLaTeX is the executable.  The user has the choice to install the source 
if they like.

> OK.  Now I'd like to hear the Debian side.  Here are the conditions for
> modification that are being proposed as I understand them:
> 
>  - you must rename all modified files, or
>  - you must rename the whole of LaTeX in your modified copy AND
> distribute a pristine copy of LaTeX as well.

> Comments?  Branden, Walter, Mark, and Jeremy, I'm especially interested
> in your opinions, since you three are the current objectors.

This seems free to me, using the second option.  I don't know of any other 
packages that require distribution of source (instead of making source 
available seperately) and require patches seperate from original source, 
but I can live with it, unless I've missed some subtlety.

Definitions should be clear, though.  Pristine source can be distributed
with a modified version in the same way that other source is distributed
with the binaries, which is to say that users can choose not to download
or install it (though they'd then be barred from redistributing it).  It
may even be delivered on a different medium (i.e. include a source CD with
unmodified LaTeX to go with the memory-constrained PDA that has tinyLaTeX
in firmware).

>> I didn't intend to bring that up last time, but really, if you think
>> that the proposed conclusion by Jeff is violating DSFG then you have to
>> be honnest enough to through out the software by Knuth as well, eg top
>> of cmr10.mf says
>> % THIS IS THE OFFICIAL COMPUTER MODERN SOURCE FILE cmr10.mf BY D E KNUTH.
>> % IT MUST NOT BE MODIFIED IN ANY WAY UNLESS THE FILE NAME IS CHANGED!

A bug has been filed.  I hope there's a workaround available (like 
proactively renaming cmr10.mf, or finding a free replacement), but I 
haven't seen anyone address it yet.
--
Mark Rafn[EMAIL PROTECTED]  


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Towards a new LPPL draft

[Frank Mittelbach]

sorry pressed C-c C-c in the wrong window ... try again

Jeff Licquia writes:
 > > sorry, but we are not concerned only with the core stuff. even though we 
 > > don't
 > > distribute the rest. The whole set of files put on ctan and identical (on a
 > > pristine LaTeX installation) is what makes LaTeX useful, not  their 
 > > quality as
 > > such. So either we find a solution which keeps this intact (and we
 > > had found something with LPPL, though we are happy to reword it, to iron 
 > > out
 > > mistakes in it that do not fit the intended meaning).
 > 
 > Well, I am confused, then.

what i meant is that there is no point in changing LPPL that would work nicely
for a core but makes it impossible to use for individual packages as well. 

 > There is, I imagine, stuff that is not a part of LaTeX, but that works
 > with LaTeX.  That stuff may or may not be licensed under a particular
 > license.  That's immaterial to the question of whether LaTeX is free or
 > not.

well, yes but the question isn't really whether or not LaTex is free, but
rather whether some form of LPPL is DSFG-complient.

Nevertheless it is certainly correct to say that we need to define the scope
of words like "LaTeX language".

So let me try

 LaTeX Language (LL) = union of all definitions that are lodable ontop of the
  latex format regardless of their licensing or availibility

 Unique LaTeX Language (ULL) = subset of LL which is licensed under LPPL and is
  publically available, eg on CTAN

i#m too tired already to try a rigerous set of definitions (format isn't
defined ...) am prepared to do this excerise later again.

Now ULL (but not necessarily LL)has the property that if documents only use
commands from it then these documents either compile on an installation (and
giveidentical results) or stop at some point with a request for a part of the
ULL which is not installed.

That ULL is what I am concerned about. Now that is made up from many sources
with different authors and I don't except that Debian or anybody else is
necessarily distributing the whole lot.

But if Debian is distributing, say, the LaTeX package gemoetry (which is under 
LPPL and
written by somebody in Japan) then any desire to modify it and distribute the
modification (as well or only) has to ensure that the ULL stays intact. That
is what LPPL is trying to achieve and did so quite well.

so 

 > If you're asking Debian to always ship absolutely everything in CTAN as
 > a precondition to gaining modification rights to LaTeX, then that's
 > something that Debian can't offer.  We don't know how that software is
 > licensed, and can't guarantee that it will be free or not.

I don't or perhaps i should say, I haven't intended that. Not even that Debian
has to shop the whole of ULL. There is however a subset of ULL which is
considered absolutely required and one that is considered to form sensible
distribution (not defining those two tonight)


 > > but there is no point in providing a largely useless core (identical) and
 > > having all the rest happily return to the state of 1990 where no two site 
 > > had
 > > identical LaTeX packages and thus document exchange turned out to be 
 > > largely a
 > > matter of luck or sending whole latex package trees along with the 
 > > document.
 > > 
 > >  > But before we can deal with the add-ons, we need to deal with the core.
 > > 
 > > no. sorry. if that is what only we are trying to do then I guess we have to
 > > give up.
 > 
 > Then you should take over the copyright from the other contributors, or
 > mandate that they accept the LPPL as you deliver it, or get everyone to
 > accept the LPPL voluntarily, or something.

that is already the situation: a large proportation of the LL is by now in ULL 

what i was trying to say above was that it would be counterproductive from our
point of view, if we come up with a new LPPL which would result in having a
small core being in ULL and all the other packages being left out thus
returning to the state where they could be individually modified an appended
to the core distribution with the result that each two distributions from
different distributors would start being (very) different again


hope that has cleared the misunderstanding:

 > You can't have it both ways.  If you treat add-ons outside your control
 > as "core" to LaTeX and allow them to be licensed arbitrarily, then you
 > must accept the fact that people like us will be forced by the licenses
 > to drop portions of it.  Otherwise, as has been pointed out before, the
 > LPPL could be a free license but LaTeX be non-free, because one file
 > within it has an unacceptable modification restriction.

agreed. we are not talkingabout LL but ULL


 > Put another way: If you refuse to allow us to drop a non-free file, then

i do (though i try hard to getthem under LPPL and thus into ULL)

but i even would allow you to drop part of ULL

 > >  > The rights we demand are usually for special cases.  F

Re: Towards a new LPPL draft

[Jeff Licquia]

On Tue, 2002-07-23 at 16:36, Mark Rafn wrote:
> On 23 Jul 2002, Jeff Licquia wrote:
> > The rights we demand are usually for special cases.
> 
> I strongly disagree.  The rights we demand are guaranteed to our users, 
> and they get to decide what's a special case and what's a burning need.

Right.  I spoke poorly in this statement; my intent was to state
Debian's specific needs and reassure the LaTeX people that we aren't
planning on destroying LaTeX anytime soon.  User needs of course may be
different.

I think they have a legitimate concern about what we distribute versus
what users do.  What a user does may affect his machine and maybe a few
others, but what Debian does can affect thousands of machines.

> This seems free to me, using the second option.  I don't know of any other 
> packages that require distribution of source (instead of making source 
> available seperately) and require patches seperate from original source, 
> but I can live with it, unless I've missed some subtlety.
> 
> Definitions should be clear, though.  Pristine source can be distributed
> with a modified version in the same way that other source is distributed
> with the binaries, which is to say that users can choose not to download
> or install it (though they'd then be barred from redistributing it).  It
> may even be delivered on a different medium (i.e. include a source CD with
> unmodified LaTeX to go with the memory-constrained PDA that has tinyLaTeX
> in firmware).

Do you think that it is non-free for a license to require *distributors*
to always provide the option to use pristine source when running
something?  As long as they also have the choice of using the modified
version (without any other restrictions on things like the filename in
question), I don't see that as impinging on freedom.

The main thing would be whether a user would have the option of removing
the pristine files, as in the case of tinyLaTeX you mention.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Towards a new LPPL draft

[Alexander Cherepanov]

23-Jul-02 18:46 Frank Mittelbach wrote:
 >> The license already allows sub-works within LaTeX to have additional
 >> modification requirements beyond the LPPL.  If you thought that some of
 >> the sub-authors would disagree with relaxing the file naming requirement
 >> when changing the name of the work from "LaTeX", you could allow them to
 >> add that restriction to their file(s).

> What i was pointing out in my second reply to Brian is this: suppose you
> would only want to modify the work overcite.sty which consists of single file,
> or the work geometry which consists of geometry.sty + .dtx + a number of test
> files and manual then to be able to modify that without renaming you would
> need to build a "nonLaTeX" format with its own tree and place it in that
> tree. Now that "nonLaTeX" format wouldn't work at all unless you also copy
> a good proportion of the standard latex tree (couple of 1000 files if you
> include the fonts etc) into the new tree as well.

It looks a little bit strange to me. When somebody needs a new format,
say, pdflatex, he doesn't need to copy any files that he doesn't
change. He simply config paths so that pdflatex first searchs files in
his own, private subtree (say, texmf/pdftex/latex/) and then searchs
latex's subtree (texmf/tex/latex/). And standart latex doesn't see
pdflatex's subtree at all. (This is an ideal situation, in reality
it's more compicated but that is another story.)

> That is certainly
> possible but i think it is far more painful than
> providing a nonLaTeX format with filename remapping and put

>  overcite.fst and geometry.fst into the main tree

> thereby having LaTeX use the main tree (ignoring those two new files)
> and nonLaTeX using the main tree and loading overcite.fst when overcite.sty
> would by loaded by LaTeX and the same for geometry.

Sasha




-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Towards a new LPPL draft

[Richard Braakman]

On Tue, Jul 23, 2002 at 06:05:23PM -0500, Branden Robinson wrote:
> It doesn't matter whether the modification is easy or hard.  I think the
> assertions of the Free Software Foundation and some of my fellow
> Debian developers are misguided in this respect.  The DFSG says nothing
> about how inconvenient the copyright holder is permitted to make the
> acts of modification or redistribution.

Hmm... it does, by naming the GPL as an example license.  The GPL has
three conditions on modification.  Clause 2(a) does add inconvenience:

a) You must cause the modified files to carry prominent notices
stating that you changed the files and the date of any change.

Furthermore, 2(c) (too long to quote) actually restricts what kinds
of modifications you can make.

So there is some precedent for minor limitations on DFSG#3.  In practice,
we accept these limitations as still being Free.  (I'll add that they are
the reason I no longer use the GPL for my own code, however.)

> For one thing, this is statement of rationale, not a binding condition
> in any way.  The DFSG is written sloppily and consists primarily of
> normative statements, a few sentences' worth of examples, a lone
> parenthetical exhortation not to take advantage of a particular clause
> of the DFSG, and a clause that has no binding force on anyone whatsoever
> (DFSG 10).  (Maybe Bruce Perens just wanted ten clauses because it's a
> "round" number to our human, decimal minds.)

I think DFSG#10 does have binding force, by stating that those licenses
do in fact meet the Guidelines.  Any intepretations that would contradict
that are therefore incorrect.  Remember, these are Guidelines, not a
Definition.  They were never intended to be watertight.

-- 
Richard Braakman
"I sense a disturbance in the force"
"As though millions of voices cried out, and ran apt-get."
  (Anthony Towns about the Debian 3.0 release)


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Towards a new LPPL draft

[Richard Braakman]

On Tue, Jul 23, 2002 at 06:31:26PM -0500, Jeff Licquia wrote:
> I think they have a legitimate concern about what we distribute versus
> what users do.  What a user does may affect his machine and maybe a few
> others, but what Debian does can affect thousands of machines.

Consider that some of our "users" are people who create new distributions
on a Debian base.  One day, such a distribution might be more popular
than Debian itself.

Of course, this is not likely to happen unless that distribution serves
our users better than Debian itself does, which probably means it doesn't
have a broken LaTeX :-)

Richard Braakman


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Towards a new LPPL draft

[Mark Rafn]

On 23 Jul 2002, Jeff Licquia wrote:
> Do you think that it is non-free for a license to require *distributors*
> to always provide the option to use pristine source when running
> something?

Definitely non-free.  Distributors may be required to provide pristine
source and patches, but must be allowed to have the actual installed
runnables be the modified version.

"required to distribute source". Ok.

"required to distribute unchanged source". Ok, I think.  (there may 
be subtleties I hadn't thought of, and I don't see the benefit of this 
over just publishing a URL).

"prevented from distributing runnables based on modified source".  No way.

"required to distribute binaries (runnables) built from pristine source". 
No way.

> The main thing would be whether a user would have the option of removing
> the pristine files, as in the case of tinyLaTeX you mention.

That was my reason for the clarification.  As long as PDA tinyLaTeX can be
distributed with pristine source on another medium (like a CD), it's ok
(IMO).  The fact that the pristine source can't be used on the PDA is
irrelevant - it was distributed with it, as required.
--
Mark Rafn[EMAIL PROTECTED]  


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Towards a new LPPL draft

[Alexander Cherepanov]

23-Jul-02 15:02 Mittelbach, Frank wrote:
> If you think of LPPL applying to the whole of a LaTeX sty/cls tree of
> files at once, we could, i think
> live with the idea (it is even described so in modguide or cfgguide as a
> possible though not encouraged
> solution (thereby actually violating the license as it is right now)),
> that you produce sniffenlatex
> which has its own complete tree and in there has identical file names to
> the pristine LaTeX tree so that both trees live side by side.
> But the problem here is that LPPL doesn'T apply to the whole thing but
> individually to its many parts.
> so if you only wnat to change overcite.sty there is nothing nowhere to put
> it and i don'T see how you
> describe (or even want to) that for that change you have to duplicate the
> whole tree.

The question here is how to guarantee that a changed overcite.sty
(without renaming) will not be used with pristine LaTeX, right? If so,
LPPL in case of modification without renaming could, for example,
require to change an argument of \NeedsTeXFormat macro, i.e. to
replace

  \NeedsTeXFormat{LaTeX2e}

in overcite.sty by something like

  \NeedsTeXFormat{sniffenlatex}

(or to add such a macro if it was not there).
After that, pristine LaTeX will not process this file.

And in sniffenlatex one should redefine \NeedsTeXFormat (say,
following an example in future cfgguide) so that it will accept
`LaTeX2e' and `sniffenlatex' as an argument. Then sniffenlatex will be
able to process both files intended for pristine LaTeX and files
intended solely for sniffenlatex.

Sasha




-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Towards a new LPPL draft

[Branden Robinson]

On Wed, Jul 24, 2002 at 03:41:29AM +0300, Richard Braakman wrote:
> Hmm... it does, by naming the GPL as an example license.  The GPL has
> three conditions on modification.  Clause 2(a) does add inconvenience:
> 
> a) You must cause the modified files to carry prominent notices
> stating that you changed the files and the date of any change.
> 
> Furthermore, 2(c) (too long to quote) actually restricts what kinds
> of modifications you can make.
> 
> So there is some precedent for minor limitations on DFSG#3.  In practice,
> we accept these limitations as still being Free.  (I'll add that they are
> the reason I no longer use the GPL for my own code, however.)

Both true.  However, I see no reason to loosen our standards still
further in the instant case.

> I think DFSG#10 does have binding force, by stating that those licenses
> do in fact meet the Guidelines.  Any intepretations that would contradict
> that are therefore incorrect.  Remember, these are Guidelines, not a
> Definition.  They were never intended to be watertight.

I stand corrected.  However, I still think DFSG 10 is too vague.  It
doesn't mention which versions (or variants) of the BSD, Artistic, and
GPL licenses we regard as free.  I think a future revision of the DFSG
should instead have an adjunct document that contains actual license
texts that meet the DFSG.  Given the non-free license on the text of the
GNU GPL itself, maybe we shouldn't list it.  :)

-- 
G. Branden Robinson| If you have the slightest bit of
Debian GNU/Linux   | intellectual integrity you cannot
[EMAIL PROTECTED] | support the government.
http://people.debian.org/~branden/ | -- anonymous


pgpJw5kOwHp4p.pgp
Description: PGP signature

Re: Towards a new LPPL draft

[Jeremy Hankins]

Walter Landry <[EMAIL PROTECTED]> writes:
> Jeremy Hankins <[EMAIL PROTECTED]> wrote:

>> Yikes.  I'd accept the former as free before the latter, personally.
>> Giving users options is one thing, but option two seems to suggest
>> that if Latex is forked for some reason we'll need to ferry around the
>> original (from the date of the fork) version of latex whenever
>> distributing the new version, forever.  That's a far more onerous
>> requirement than file renaming, imho.
>
> This is specifically allowed by DFSG #4.  The Q Public License uses
> this feature as well.  If you don't like it, feel free to call a
> General Resolution to change it.  Until then, it is still part of the
> DFSG.

It's quite similar, yes, but I can distribute a patch without the file
it patches.  If, for example, I have to include an entire pristine
Latex installation with any fork, that's a significant burden indeed.
Not that the LPPL could necessarily legally require such a thing, but
if that's the intent of the Latex developers, I find it too onerous.

In fact, as a rather off-topic question, if you have a license to
distribute but not modify a package with three files (foo, bar & baz),
and you have a patch for foo that makes it a useful program in its own
right, can you distribute foo + patch, omitting bar & baz?  But I
imagine that if this is possible at all it falls into some murky
category of fair use.

-- 
Jeremy Hankins <[EMAIL PROTECTED]>
PGP fingerprint: 748F 4D16 538E 75D6 8333  9E10 D212 B5ED 37D0 0A03


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Towards a new LPPL draft

[Jeremy Hankins]

Frank Mittelbach <[EMAIL PROTECTED]> writes:

> let me first qualify the suggestion that Jeff made above
>
>  - the reason for it is to give the user the possibility to exchanges
>documents with other using pristine LaTeX and obtain identical output
>
>  - it therefore quite pointless to carry around some old pristine LaTeX from
>the day of the fork; if the above suggestion has to have value to the goals
>we try to achieve with the LPPL license, then the suggestion would be to
>keep a copy of current pristine LaTeX, though I doubt that could or should
>be codified except as a suggestion.

I certainly have no problem with a suggestion.  I also don't really
have a problem with the requirement of a pointer to a place to find a
pristine latex (with the caveat, of course, that if no such place
exists to the best knowledge of the distributor that requirement is
void).

>  in a redraft of LPPL i wuold try to limit any renaming requirement to such
>  files that need to change their file names in order to make this distinction
>  (or use the requirement to distinguish as the requirement rather than the
>  file name and only remark that in most cases this might mean that certain
>  files need new names. -> readme.txt would not need to change.

I like the idea of making the requirement to distinguish the
requirement.  That provides flexibility in the odd (and unlikely)
edge-cases that might need it.  It also maintains your intentions
better in those situations, I suspect.

>  from that it also follows that if on an OS with a different type of
>  filestructure (say MVS) that revised requirement would have other effects
>  (i've forgotten what the things got called on mvs, but all the classes lived 
> a
>   single datastructures with members there, and so you wouldhave to chose a
>  different member name)
>
> does this answer the question?

Yes.  Thank you.

>  - if a file is not used by pristine LaTeX (that is a LaTeX kernel without the
>remapping feature added) then there is no need for a renaming of any kind
>
>  - otherwise, if it is an object used at some point in the game by the
>underlying macroprocessor (ie loaded) then the "name" used for loading
>should be different --- that is not thefile name though in most
>implementation it is a one to one mapping (which is why we suggested to use
>the filename rename as an requirement.

If this is codified into the license, I see no issue with its
DFSG-freeness.  This states your intention (that a reference to 'foo'
always reference the same thing) but creates an explicit (in the
license) loophole in form of the filename remapping facility.

-- 
Jeremy Hankins <[EMAIL PROTECTED]>
PGP fingerprint: 748F 4D16 538E 75D6 8333  9E10 D212 B5ED 37D0 0A03


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Towards a new LPPL draft

[Walter Landry]

Jeremy Hankins <[EMAIL PROTECTED]> wrote:
> Walter Landry <[EMAIL PROTECTED]> writes:
> > Jeremy Hankins <[EMAIL PROTECTED]> wrote:
> 
> >> Yikes.  I'd accept the former as free before the latter, personally.
> >> Giving users options is one thing, but option two seems to suggest
> >> that if Latex is forked for some reason we'll need to ferry around the
> >> original (from the date of the fork) version of latex whenever
> >> distributing the new version, forever.  That's a far more onerous
> >> requirement than file renaming, imho.
> >
> > This is specifically allowed by DFSG #4.  The Q Public License uses
> > this feature as well.  If you don't like it, feel free to call a
> > General Resolution to change it.  Until then, it is still part of the
> > DFSG.
> 
> It's quite similar, yes, but I can distribute a patch without the file
> it patches.  If, for example, I have to include an entire pristine
> Latex installation with any fork, that's a significant burden indeed.
> Not that the LPPL could necessarily legally require such a thing, but
> if that's the intent of the Latex developers, I find it too onerous.

Actually, you can always distribute patches (at least in the US, and
only up to a point).  You can even distribute patches to Oracle or
Photoshop.  You just can't distribute the originals or a patched
binary without permission.

In any case, DFSG #4 specifically allows a requirement that source be
distributed as pristine + patches.  Requiring source to accompany the
"binary" is an uncontroversial requirement under the DFSG.

Regards,
Walter Landry
[EMAIL PROTECTED]


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Towards a new LPPL draft

[Nick Phillips]

On Tue, Jul 23, 2002 at 09:50:07PM +0200, Frank Mittelbach wrote:

> uniformity in a different way. but being as it is, I see no good alternative
> as trademarking several hundred file names isn't (and wouldn't help Debian
> either).

I'm probably missing something obvious, but if the name "LaTeX" were
trademarked and could only be used by systems that are created so as
not to conflict with any package that could be obtained from CTAN, would
that not actually provide better protection than is currently available?

You'd need to allow for the case where someone is distributing something
OK, then a new package is added to CPAN and it's no longer OK (e.g. allow
"someone" to continue to distribute their already-available version but
not any subsequent version with the conflicting name), but this potential
for future conflicts might also encourage people to work more closely with
you and CTAN when making modifications, lest you later decide to do it
"right" and in doing so force them to rename their extensions.

Anybody who didn't want to play could distribute things their own way, but
could not use the name LaTeX do describe their work, either in documentation
or within the work itself. I think this would probably be a good balance.

It would after all prevent the introduction of incompatible extra packages
that are not derived works of any LPPL-licensed work. It wouldn't protect
anything not (yet) in CTAN, but there's no current protection from namespace
conflicts between unrelated non-CTAN works anyway.

All the third-party modules author has to do to in order to be able to 
guarantee that their users will not be fooled by an incompatible package
is then to get their package in to CTAN, and they can use any license they
like (so long as it's acceptable to CTAN).

Note that this also automatically protects users of non-LPPL packages that
are part of CTAN from incompatibilities, which I guess is not the case at
present.


What would be the problem with this scenario?



Cheers,


Nick

-- 
Nick Phillips -- [EMAIL PROTECTED]
Accent on helpful side of your nature.  Drain the moat.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Towards a new LPPL draft

[David Carlisle]

> TeX is not similar at all (Why do people keep bringing this up?).  The
> only thing you have to do is not call it TeX.  You can then modify
> files in place all you want.

As has been shown before the situation with TeX isn't as clear cut as
you make out, and the situation with the cm fonts is almost identical to
latex. They all have explicit requirements on not changing the file.

See earlier messages in these threads.

as a reminder, cmr10.mf says

% THIS IS THE OFFICIAL COMPUTER MODERN SOURCE FILE cmr10.mf BY D E KNUTH.
% IT MUST NOT BE MODIFIED IN ANY WAY UNLESS THE FILE NAME IS CHANGED!


If you make a program that isn't called tex, are you saying you can edit
plain.tex and call the modified file plain.tex without being in
contravention of the comment at the top of plain.tex which says

% And don't modify the file under any circumstances.

David

_
This message has been checked for all known viruses by Star Internet
delivered through the MessageLabs Virus Scanning Service. For further
information visit http://www.star.net.uk/stats.asp or alternatively call
Star Internet for details on the Virus Scanning Service.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Towards a new LPPL draft

[David Carlisle]

Jeff

> I've seen that some people include the "LPPL 1.2 or any later version"
> language into their license notice.  Those people would be fine
> (although I would recommend that notice be given of this particular
> license change as a gesture of goodwill to the community).

No. I don't think the situation here is "fine".

The situation you describe is probably the most common and most
important case. The sample boilerplate we offer for people to use is of
that form.

Despite all the legal mumbo jumbo in the licence, the _intent_ of LPPL
1.2 (and 1.0 and 1.1) is I think clear to everyone.

  If you make any changes, change the name. If you change the name, make
  whatever changes you like.

Now people who put a reference to LPPL in the form you quote are
basically saying that they trust us not to abuse our power to make
arbitrary changes to the licence that would allow their software to be
misused.

We have to be careful not to abuse that trust.

And tracking down the authors of an unknown number of pieces of software
distributed from an unknown number of sites (ctan isn't the only sourc)
is not really an option.

I think it is clear that (unless we give up on Debian altogether, which
I'd rather not do) LPPL 1.3 is going to have to relax the "rename rule"
somehow.
It is in fact much easier to think of ways of doing that for the core
latex, as you can talk about command names (suitably defined) default
tex input paths etc, as a way of keeping a modified and unmodified
versions distinct, without requiring rules at the level of filenames.

But in all the posts I haven't really seen yet a good plan for what to
do about the main case: third party files distributed under LPPL.
Take geometry.sty for example

That is written by  Hideo Umeki (who I don't know) and has a notice of
the form you quote. It is distributed separately by him, with no
connection to the latex3 project. (It's also quite good, but that's not
the point here:-)

The intention of LPPL 1.2 is that users of latex who go
\usepackage{geometry}
have some assurance that Hideo's code is going to get loaded.

whether or not LPPL succeeds in giving this assurance, or remains free
in doing so isn't the point here. The point I want to make is that
we have to be very careful while redrafting LPPL to maintain
some semblance of the "main idea". As we owe it to the 100's of people
who have chosen to use LPPL (no pressure is applied to third party
authors to use LPPL they could use GPL or public domain or any otehr
licence) An alternative would be to freeze
LPPL at 1.2 and have LPPLNEW 1.0 which was used for latex and any
authors who could be contacted and agreed to change. I'd really like to
avoid this if possible though.

Speaking personally I could live with a solution that changed

  If you make any changes, change the name. If you change the name, make
  whatever changes you like.

to

  If you make any changes, change the name, or make sure this file will
  not be loaded by a standard version of . If you do either of those things 
  whatever changes you like.


so in the geometry case the meaning would be
if the file is used with latex, change the name if you make changes.
If the file is used with non-latex make arbitrary changes.

The problem is I see no way to word such a restriction given that
geometry isn't distributed with latex, it's just a file stuck on an
archive.  Also I'd want the restriction to apply to say pdflatex or
elatex, which are formats made with unmodified latex code using non-texs
(pdftex and etex respectively) so it isn't really the "user command"
that is relevant.

By the time someone like Debian is making a "ready-to-run" distribution
you can make sense of keeping modified files distincteven if they have
the same filename by setting TEXINPUTS appropriately, but I don't see
what licence text on the geometry distribution could realistically
enforce that.

Sorry this message is rather negative,
despite possible appearance to the contrary, it is trying to be
helpful:-)

David

_
This message has been checked for all known viruses by Star Internet
delivered through the MessageLabs Virus Scanning Service. For further
information visit http://www.star.net.uk/stats.asp or alternatively call
Star Internet for details on the Virus Scanning Service.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Towards a new LPPL draft

[Boris Veytsman]

> Date: Fri, 26 Jul 2002 19:07:06 +0100
> From: David Carlisle <[EMAIL PROTECTED]>

> 
> If you make a program that isn't called tex, are you saying you can edit
> plain.tex and call the modified file plain.tex without being in
> contravention of the comment at the top of plain.tex which says
> 
> % And don't modify the file under any circumstances.
> 


David, but what if I have my own file plain.tex outside iniTeX search
path? I might even not know about this file and write my own paper
about plain yogurt...

-- 
Good luck

-Boris

Things equal to nothing else are equal to each other.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Towards a new LPPL draft

[Jeff Licquia]

On Fri, 2002-07-26 at 15:24, David Carlisle wrote:
> 
> Jeff
> 
> > I've seen that some people include the "LPPL 1.2 or any later version"
> > language into their license notice.  Those people would be fine
> > (although I would recommend that notice be given of this particular
> > license change as a gesture of goodwill to the community).
> 
> No. I don't think the situation here is "fine".
> 
> The situation you describe is probably the most common and most
> important case. The sample boilerplate we offer for people to use is of
> that form.
> 
> Despite all the legal mumbo jumbo in the licence, the _intent_ of LPPL
> 1.2 (and 1.0 and 1.1) is I think clear to everyone.
> 
>   If you make any changes, change the name. If you change the name, make
>   whatever changes you like.
> 
> Now people who put a reference to LPPL in the form you quote are
> basically saying that they trust us not to abuse our power to make
> arbitrary changes to the licence that would allow their software to be
> misused.
> 
> We have to be careful not to abuse that trust.

Right; that was why I made the comment about "goodwill".

The "fine-ness" I was referring to was that, for works that add the
"LPPL 1.2 or any later version" language to the license, we aren't
required by law to hunt them down.  Whether you want to hunt them down
or not is up to you.

> Speaking personally I could live with a solution that changed
> 
>   If you make any changes, change the name. If you change the name, make
>   whatever changes you like.
> 
> to
> 
>   If you make any changes, change the name, or make sure this file will
>   not be loaded by a standard version ofrun the unmodified version>. If you do either of those things 
>   whatever changes you like.

This sounds very close to what I posted in the "try 2" thread.  If you
don't like what's there, then I'd be very interested in what you don't
like, as the delta in intent between what you wrote and what I wrote
seems very small.

> so in the geometry case the meaning would be
> if the file is used with latex, change the name if you make changes.
> If the file is used with non-latex make arbitrary changes.
> 
> The problem is I see no way to word such a restriction given that
> geometry isn't distributed with latex, it's just a file stuck on an
> archive.  Also I'd want the restriction to apply to say pdflatex or
> elatex, which are formats made with unmodified latex code using non-texs
> (pdftex and etex respectively) so it isn't really the "user command"
> that is relevant.

I don't know if you've delved down to the API call suggestions yet, but
that's one way to provide that.

Essentially, third-party LaTeX extensions can hitch their chariot to
"Standard LaTeX" by making a macro call in their code and by licensing
under the "new" LPPL.  Personally, I think the protections are stronger,
as you're using code to enforce the distinction instead of just a
license.

> Sorry this message is rather negative,
> despite possible appearance to the contrary, it is trying to be
> helpful:-)

Not a problem.  It's better to get these things out in the air
beforehand.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Towards a new LPPL draft

[David Carlisle]

> The "fine-ness" I was referring to was that, for works that add the
> "LPPL 1.2 or any later version" language to the license, we aren't
> required by law to hunt them down.

Law's the law but I just wanted to stress that this is one of (perhaps the
main) constraint that Frank and I have. Knowing that legally we can
change the licence any way we want doesn't really help.
Would you be pleased if you'd licenced your code under GPL version 1 or
any later version and then FSF released a GPL v 1001 that was LPPL
(or the licence from Microsoft word)? I suspect not. By agreeing to
licence under "any later version" terms an author is showing a certain
amount of faith in the distributor of the licence. Faith's more
important than the law here...

> This sounds very close to what I posted in the "try 2" thread.  If you
> don't like what's there, then I'd be very interested in what you don't
> like, as the delta in intent between what you wrote and what I wrote
> seems very small.

Yes just catching up (day job, you know:-), I may respond to that
thread later, (or I may go to bed, we'll see..)


> I don't know if you've delved down to the API call suggestions yet, but
> that's one way to provide that.

I've read the messages, implications haven't sunk in yet, so I want to
wait a bit before commenting on the details.



David

_
This message has been checked for all known viruses by Star Internet
delivered through the MessageLabs Virus Scanning Service. For further
information visit http://www.star.net.uk/stats.asp or alternatively call
Star Internet for details on the Virus Scanning Service.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Towards a new LPPL draft

[David Carlisle]

> I'm probably missing something obvious, but if the name "LaTeX" were
> trademarked and could only be used by systems that are created so as
> not to conflict with any package that could be obtained from CTAN, would
> that not actually provide better protection than is currently available?

we've been over this already. That (might be) fine for latex but it
offers no help at all to the vast majority of LPPL'ed software that isn't
called latex.


> All the third-party modules author has to do to in order to be able to 
> guarantee that their users will not be fooled by an incompatible package
> is then to get their package in to CTAN, and they can use any license
> they like (so long as it's acceptable to CTAN).

There is nothing in LPPL that requires ctan distrib. In particular your
solution would allow Debian to make arbitrary changes to every
third-party latex package with no licence constraints at all, so long as
they distributed the changes themselves rather than resubmit them to
ctan, perhaps that's your intention?

David



_
This message has been checked for all known viruses by Star Internet
delivered through the MessageLabs Virus Scanning Service. For further
information visit http://www.star.net.uk/stats.asp or alternatively call
Star Internet for details on the Virus Scanning Service.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Towards a new LPPL draft

[David Carlisle]

> 
> > Date: Fri, 26 Jul 2002 19:07:06 +0100
> > From: David Carlisle <[EMAIL PROTECTED]>
> 
> > 
> > If you make a program that isn't called tex, are you saying you can
> > edit
> > plain.tex and call the modified file plain.tex without being in
> > contravention of the comment at the top of plain.tex which says
> > 
> > % And don't modify the file under any circumstances.
> > 
> 
> 
> David, but what if I have my own file plain.tex outside iniTeX search
> path? I might even not know about this file and write my own paper
> about plain yogurt...
> 
> 
> 
> 
> 

then it isn't a derived work and nothing in the TeX licence applies.
So be it Of course it would be virtually impossible to  have a plain.tex
that worked anything like Knuth's plain that was not a derived work as
the information of what's needed in the file isn't really anywhere else.

The same is even more true (unfortuanely) of latex classes.
If someone has a file article.cls on their system that is totally
independent of latex, then this can happen and there is nothing wrong
with that. The chance that they have such a file that actually works as
a latex class but is not derived from article is almost nill, as the
documentation about what has to be in a latex class is almost all in the
LPPL'ed source of article.cls (classes.dtx).

But the situation with TeX is confused as the files in Knuth's
distribution do have distribution conditions but elsewhere he says its
public domain which is probably inconsistant with some of the
conditions. But it is clear what the intent is. If you modify
te-the-program or plain.tex you should rename them.

David

_
This message has been checked for all known viruses by Star Internet
delivered through the MessageLabs Virus Scanning Service. For further
information visit http://www.star.net.uk/stats.asp or alternatively call
Star Internet for details on the Virus Scanning Service.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Towards a new LPPL draft

[Nick Phillips]

On Sat, Jul 27, 2002 at 12:10:11AM +0100, David Carlisle wrote:

> > I'm probably missing something obvious, but if the name "LaTeX" were
> > trademarked and could only be used by systems that are created so as
> > not to conflict with any package that could be obtained from CTAN, would
> > that not actually provide better protection than is currently available?
> 
> we've been over this already. That (might be) fine for latex but it
> offers no help at all to the vast majority of LPPL'ed software that isn't
> called latex.

> > All the third-party modules author has to do to in order to be able to 
> > guarantee that their users will not be fooled by an incompatible package
> > is then to get their package in to CTAN, and they can use any license
> > they like (so long as it's acceptable to CTAN).
> 
> There is nothing in LPPL that requires ctan distrib. In particular your
> solution would allow Debian to make arbitrary changes to every
> third-party latex package with no licence constraints at all, so long as
> they distributed the changes themselves rather than resubmit them to
> ctan, perhaps that's your intention?

I was thinking rather that distributors would not be able to make incompatible
changes (i.e. any which affect the output) to any CTAN module if they still
wanted to call the system it works in 'LaTeX'.

As I said, I would think that the system I was suggesting would actually
provide better protection than currently, as it would protect users of
CTAN modules even if the author was disinclined or unable to use the LPPL.

But if it's important to you that modules not part of CTAN should be
protected (although as I said, I don't believe that protection is
particularly strong), and there is no other (at least that anyone can think of)
way of defining the modules which a user should be able to expect to
function identically across all systems, then I guess you can't do it
that way.

Which is a shame, IMHO, but 'to each his own'.



Cheers,


Nick

-- 
Nick Phillips -- [EMAIL PROTECTED]
Afternoon very favorable for romance.  Try a single person for a change.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Concluding the debate (was Re: Towards a new LPPL draft)

[Jeff Licquia]

On Mon, 2002-07-22 at 14:31, Frank Mittelbach wrote:
> it seems to me that by now we are turning around in cycles rehashing arguments
> that are important in general (can LaTeX have security problems, yes or no?;
> how does one do software development ...) but not with respect to the problem
> at hand which still is (to me at least) the following two things:
> 
>  1) determine whether or not the fundamental believes of the LaTeX Mafia
> comply with the those of the Debian people
> 
>  2) if so to draft a new LPPL license that reflects both believes, i.e., is
> DSFG-complient (as well as being understood to be DSFG-complient) while at
> the same time allowing the majority of the people in the LaTeX world to
> work as they feel appropriate.
> 
> If (1) is a no-go we don't have to attempt (2) and I for my part have no
> intention to. But if (1) is possible, and it seems that this is the case, then
> please stop arguing on the level 

[...]

> So to sumarize:
> 
> To go forward I propose
> 
>  A) I would like you to come to a conclusion on (1) assuming the above Axiom
> 
>  B) if you do and the outcome is not a flat no, but at least a grunted yes (or
>  if you like "its stupid and pointless but within the limits"), then I'm happy
>  to get back to the early posts by Jeff and take together with him and anybody
>  else interested the license completely apart to make its wording and
>  statements reflect what is intended without needing long explanations of
>  intend for the reader (as it is currently the case) and remove or rephrase
>  those parts that are completely wrong or unnecessary.
> 
>  C) if the conclusion on (1) is a flat no, then I fear I have to suggest to
>  you to remove LaTeX from Debian, which I think many (me included) would think
>  would be a pitty.

It seems that the filename restriction problem is the main sticking
point; the rest are either the result of misunderstandings or are
details the Project has already committed to fixing ("what is a
file?").  So, I'm going to post a definitive statement:

-
The requirement for modifications to LaTeX to be in files with different
names from the original files, when combined with the ability for LaTeX
to do filename mapping for file references, does not constitute a
violation of the Debian Free Software Guidelines.
-

Now, I want to hear objections to that statement.  If there are none,
then I will assert: 

-
Condition (1) above is satisfied; Debian and LaTeX should set about the
business of drafting changes to the LPPL.
-

Now is the time to object, or to be silent.  I agree with Frank that we
either need to move forward or break off the discussion; there are no
new points being presented.

After that, Frank has asked me to act as a representative for Debian so
we can iron out the main points without fomenting debate on every
subpoint.  Once this is done, we can present the new license and ask for
comments.  Does anyone object to this?  I do not mind being replaced if
another volunteer is considered to be a better representative for
Debian.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Concluding the debate (was Re: Towards a new LPPL draft)

[Branden Robinson]

On Mon, Jul 22, 2002 at 04:04:25PM -0500, Jeff Licquia wrote:
> -
> The requirement for modifications to LaTeX to be in files with different
> names from the original files, when combined with the ability for LaTeX
> to do filename mapping for file references, does not constitute a
> violation of the Debian Free Software Guidelines.
> -
> 
> Now, I want to hear objections to that statement.

Hate to do this to you Jeff, but I cannot agree with you in clear
conscience.

Message-ID: <[EMAIL PROTECTED]>

-- 
G. Branden Robinson| What influenced me to atheism was
Debian GNU/Linux   | reading the Bible cover to cover.
[EMAIL PROTECTED] | Twice.
http://people.debian.org/~branden/ | -- J. Michael Straczynski


pgpzUQ28jEOVR.pgp
Description: PGP signature

Re: Concluding the debate (was Re: Towards a new LPPL draft)

[Jeremy Hankins]

Jeff Licquia <[EMAIL PROTECTED]> writes:

> -
> The requirement for modifications to LaTeX to be in files with different
> names from the original files, when combined with the ability for LaTeX
> to do filename mapping for file references, does not constitute a
> violation of the Debian Free Software Guidelines.
> -
>
> Now, I want to hear objections to that statement.  If there are none,
> then I will assert: 

Whether there is an objection may depend on the wording.  Someone
(Frank?) espoused a desire to make this restriction as weak as
possible while still safeguarding the goals of the Latex folks.  I'd
like to see what that results in.  Only package names?  (e.g., 'Any
occurrence of "Foo" in filenames in package Foo must be replaced with
something other than "Foo", but which may include "Foo", such as
"NotFoo"'.)  Only files intended to be called directly from a user
document?  Only files listed in 'importantfiles.txt'?  There are
several ways of approaching this requirement, and I'm curious which
one the Latex folks intend to use.  For example, I'd personally be
more favorably inclined to the license if there's a requirement that
there be a list of files who's names must be changed.

But, of course, IANAL, and IANADD (Debian Developer).

-- 
Jeremy Hankins <[EMAIL PROTECTED]>
PGP fingerprint: 748F 4D16 538E 75D6 8333  9E10 D212 B5ED 37D0 0A03


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Encoding the name in the file contents (was Re: Towards a new LPPL draft)

[Jeff Licquia]

On Tue, 2002-07-23 at 21:17, Alexander Cherepanov wrote:
> The question here is how to guarantee that a changed overcite.sty
> (without renaming) will not be used with pristine LaTeX, right? If so,
> LPPL in case of modification without renaming could, for example,
> require to change an argument of \NeedsTeXFormat macro, i.e. to
> replace
> 
>   \NeedsTeXFormat{LaTeX2e}
> 
> in overcite.sty by something like
> 
>   \NeedsTeXFormat{sniffenlatex}
> 
> (or to add such a macro if it was not there).
> After that, pristine LaTeX will not process this file.
> 
> And in sniffenlatex one should redefine \NeedsTeXFormat (say,
> following an example in future cfgguide) so that it will accept
> `LaTeX2e' and `sniffenlatex' as an argument. Then sniffenlatex will be
> able to process both files intended for pristine LaTeX and files
> intended solely for sniffenlatex.

This is an intriguing idea.  It appears to satisfy the need for LaTeX to
ensure that a hacked file doesn't get run with pristine LaTeX while not
running afoul of the DFSG.

It would be good if unmodified files were not required to define the
macro; thus, anyone modifying a file would define the macro as the first
modification (and not as "LaTeX", of course).

What does everyone think?


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Encoding the name in the file contents (was Re: Towards a new LPPL draft)

[Mark Rafn]

On 23 Jul 2002, Jeff Licquia wrote:

> On Tue, 2002-07-23 at 21:17, Alexander Cherepanov wrote:
> > The question here is how to guarantee that a changed overcite.sty
> > (without renaming) will not be used with pristine LaTeX, right?

This is insanity.  If this is the goal, just choose a nice simple license
"this can be used and distributed verbatim at no charge, but you may not
modify it without permission from the current maintainer".

> > LPPL in case of modification without renaming could, for example,
> > require to change an argument of \NeedsTeXFormat macro, i.e. to
> > replace
> > 
> >   \NeedsTeXFormat{LaTeX2e}
> > 
> > in overcite.sty by something like
> > 
> >   \NeedsTeXFormat{sniffenlatex}

Requiring filename changes is objectionable at least partly because it's
hard to distinguish filename from the use of the program.  A license that
mandates API changes doesn't even pass the sniff test.

> This is an intriguing idea.  It appears to satisfy the need for LaTeX to
> ensure that a hacked file doesn't get run with pristine LaTeX while not
> running afoul of the DFSG.

How does this not run afoul of the DFSG?  It places even worse limits on 
modification than the previous attempts?
--
Mark Rafn[EMAIL PROTECTED]  


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Encoding the name in the file contents (was Re: Towards a new LPPL draft)

[Jeff Licquia]

On Tue, 2002-07-23 at 22:31, Mark Rafn wrote:
> On 23 Jul 2002, Jeff Licquia wrote:
> 
> > On Tue, 2002-07-23 at 21:17, Alexander Cherepanov wrote:
> > > LPPL in case of modification without renaming could, for example,
> > > require to change an argument of \NeedsTeXFormat macro, i.e. to
> > > replace
> > > 
> > >   \NeedsTeXFormat{LaTeX2e}
> > > 
> > > in overcite.sty by something like
> > > 
> > >   \NeedsTeXFormat{sniffenlatex}
> 
> Requiring filename changes is objectionable at least partly because it's
> hard to distinguish filename from the use of the program.  A license that
> mandates API changes doesn't even pass the sniff test.

How is it an API change to register the name of the work you belong to?

(I understand that the macro itself is an API change, but there is no
reason why the API itself would need to change for each derived work.)

Remember that derived works would be allowed to accept macros from any
other "source", so debTeX could allow "LaTeX" and "debTeX" as
arguments.  Thus, backward compatibility would be preserved.  For
forward compatibility, the LaTeX team could decide to accept "debTeX"
macros as well (assuming the debTeX team wasn't willing to contribute
the changes upstream).

> > This is an intriguing idea.  It appears to satisfy the need for LaTeX to
> > ensure that a hacked file doesn't get run with pristine LaTeX while not
> > running afoul of the DFSG.
> 
> How does this not run afoul of the DFSG?  It places even worse limits on 
> modification than the previous attempts?

We already allow for the concept that programs may not be allowed to
"lie" about their origin in that they may be required to have a
different name.  For some time now, we have been telling the LaTeX
people that we allow them to require renaming "latex" to "footex".

So now we add a facility for files to identify themselves as a part of a
greater work and require them to be "truthful" about that name (for a
given definition of "truthful").  I see no necessary violation here.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Encoding the name in the file contents (was Re: Towards a new LPPL draft)

[Boris Veytsman]

> Date: Tue, 23 Jul 2002 20:31:13 -0700 (PDT)
> From: Mark Rafn <[EMAIL PROTECTED]>


> > On Tue, 2002-07-23 at 21:17, Alexander Cherepanov wrote:
> > > The question here is how to guarantee that a changed overcite.sty
> > > (without renaming) will not be used with pristine LaTeX, right?
> 
> This is insanity.  If this is the goal, just choose a nice simple license
> "this can be used and distributed verbatim at no charge, but you may not
> modify it without permission from the current maintainer".
> 


Perhaps because LaTeX people want to give other people (basically
themselves) a couple of other rights, namely:

1. The right to use fragments, ideas or algorithms of their code in
   any way whatsoever without any limitations

2. The right to *extend* the API by adding new features, based on the
   old code.

Again, I think there is a philosophical difference between the
interpretation of the word "modification" in our communities. For you
the right to modify means "I can take the published function foo and
make it do bar if I want". For us it means "I can write a function bar
OR I can write a function baz such as after it is invoked all
functions foo in the following code actually do bar". I am afraid that
it would be difficult to achieve consensus until we understand the
truth behind each others's approach.

-- 
Good luck

-Boris

For years a secret shame destroyed my peace--
I'd not read Eliot, Auden or MacNiece.
But now I think a thought that brings me hope:
Neither had Chaucer, Shakespeare, Milton, Pope.
-- Justin Richardson.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Encoding the name in the file contents (was Re: Towards a new LPPL draft)

[Mark Rafn]

> > > On Tue, 2002-07-23 at 21:17, Alexander Cherepanov wrote:
> > > > LPPL in case of modification without renaming could, for example,
> > > > require to change an argument of \NeedsTeXFormat macro, i.e. to
> > > > replace
> > > > 
> > > >   \NeedsTeXFormat{LaTeX2e}
> > > > 
> > > > in overcite.sty by something like
> > > > 
> > > >   \NeedsTeXFormat{sniffenlatex}

> On Tue, 2002-07-23 at 22:31, Mark Rafn wrote:
> > Requiring filename changes is objectionable at least partly because it's
> > hard to distinguish filename from the use of the program.  A license that
> > mandates API changes doesn't even pass the sniff test.

On 24 Jul 2002, Jeff Licquia wrote:
> How is it an API change to register the name of the work you belong to?

Perhaps I misunderstood, but it sounded like it would be required for a
modified work to identify itself as modified, so that documents can
determine if they're running on "real" latex.  This disallows preserving
the API exactly while changing the execution.

> We already allow for the concept that programs may not be allowed to
> "lie" about their origin in that they may be required to have a
> different name.

A different name to humans.  A different package name, sure.  In some
cases, a different executable name (This would be problematic if it
were broad enough).  A different name in it's API?  I don't think that
follows.

> So now we add a facility for files to identify themselves as a part of a
> greater work and require them to be "truthful" about that name (for a
> given definition of "truthful").  I see no necessary violation here.

Adding the facility is no worry.  Requiring derived works to use that 
facility is non-free IMO.
--
Mark Rafn[EMAIL PROTECTED]  


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Encoding the name in the file contents (was Re: Towards a new LPPL draft)

[Jeff Licquia]

On Wed, 2002-07-24 at 10:22, Mark Rafn wrote:
> On 24 Jul 2002, Jeff Licquia wrote:
> > How is it an API change to register the name of the work you belong to?
> 
> Perhaps I misunderstood, but it sounded like it would be required for a
> modified work to identify itself as modified, so that documents can
> determine if they're running on "real" latex.  This disallows preserving
> the API exactly while changing the execution.

No, no.  The *kernel* would do the recognition, not the documents.  It
would have a list of "acceptable" values for that macro.

Thus, "latex" would refuse to use any modules that didn't identify
themselves as Standard LaTeX, while "debtex" would accept modules that
identified themselves as "debTeX" or Standard LaTeX.

A particular API may or may not work at any time due to other factors,
but there's no reason why debTeX couldn't process any Standard LaTeX
document, or why LaTeX couldn't process debTeX documents.

> > We already allow for the concept that programs may not be allowed to
> > "lie" about their origin in that they may be required to have a
> > different name.
> 
> A different name to humans.  A different package name, sure.  In some
> cases, a different executable name (This would be problematic if it
> were broad enough).  A different name in it's API?  I don't think that
> follows.

Why not?  Why does embedding the name in a registration call offend you?

> > So now we add a facility for files to identify themselves as a part of a
> > greater work and require them to be "truthful" about that name (for a
> > given definition of "truthful").  I see no necessary violation here.
> 
> Adding the facility is no worry.  Requiring derived works to use that 
> facility is non-free IMO.

Give me some reasons.  "I don't like it" is really hard to argue with,
address, or even evaluate.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Encoding the name in the file contents (was Re: Towards a new LPPL draft)

[Frank Mittelbach]

Mark and others,

 > > We already allow for the concept that programs may not be allowed to
 > > "lie" about their origin in that they may be required to have a
 > > different name.
 > 
 > A different name to humans.  A different package name, sure.  In some
 > cases, a different executable name (This would be problematic if it
 > were broad enough).  A different name in it's API?  I don't think that
 > follows.

who is the human here? the Debian developer or the (typical?) user who uses
ready packed/installed/whatever systems.

Our point is that that a user of LaTeX is (normally) in either of two 
situations:

 - she starts "LaTeX" on a installed unix or windows system where the
   installation of the system was not installed by her or was installed by her
   but using the default packings of the supplier (which might be debian suse
   whatever)

 - she has installed LaTeX by herself and is aware that she added packages
   that on their human names identify themselves as not belonging to the ULL
   (unique latex language) as i defined it sometime last night.

there might be a third category, which is users that run SniffenLaTeX instead
of LaTeX (those i put into category 2 for this argument)

[ as a recall from last night:

 LaTeX Language (LL) = union of all definitions that are lodable ontop of the
  latex format regardless of their licensing or availibility

 Unique LaTeX Language (ULL) = subset of LL which is licensed under LPPL and is
  publically available, eg on CTAN

 Now ULL (but not necessarily LL)has the property that if documents only use
 commands from it then these documents either compile on an installation (and
 giveidentical results) or stop at some point with a request for a part of the
 ULL which is not installed.
]

Now people in the second situation know that their documents even if written
in ULL may not be processed elsewhere  in the same way and they do not expect
it.

But people that are in the first situation expect that documents written
using only ULL will behave identical on different installations or more
exactly behave as explained in brackets above.

 But if the installing process that was used to put "LaTeX" on that system,
combined LPPL works with works derived from LPPL works (properly humanly
identified in its package name but disguising itself inside LaTeX) then this
is not at all any longer visible for her as she will never see those (Debian)
package names but only their unpacked runtime files in the texmf file tree
(which show up identically to the orginal as far as LaTex is concerned)

as a result if her document contains, say

 \usepackage{geometry} 

she expects the geometry from Hideo (which its features and misfeatures) but
not that something else is happening still identifying itself as "geometry"
from LaTeX's point of view.

Thus the fact that you intend to provide identification only in the name for
the packaging method (which isn't any longer visible in most situations) means
that as far is this user is concerned, you are misguiding her (willingly or
unwillingly).

In other words, I challenge you that in this case you don't live up to your
social contract in particular to #4 of it.  I.e. you are not guided be the
needs of your user _and_ the free-software community but guided only by one
singular interpretation of what is free-software (a view that is sensible in
many cases, but not necessarily in all).

Now I couldn't argue much about the singular interpretation of what free
software is, if it would the the interpretation of DSFG. But DSFG is not a
singular interpretation but for good reasons leaves leeway in several
directions, ie embraces very different licenses as free software.

Our claim is that the intentions behind LPPL (which have been stated, restated
and discussed here) do satisfy DSFG #3 already alone as well as being in
agreement with DSFG #4 or at least not in disagreement. And satisfy all other
clauses.


Branden very authoritatively explained to me why we would be in conflict with
DSFG 3:

> That means that all methods of modification must be allowed (as, I have
> said elsewhere, with the exception of deletion of or semantic alteration
> of applicable copyright notices and license terms).

which he made sound (to me at least) as if that would be the standard
interpretation needed to be fulfilled by every license you check --- which
turned out not to be true, not only for GPL but also for Artistic, both of
which are listed as DSFG-complient (and i would guess for many others as well
in one form or the other).

Branden later said:

> However, I see no reason to loosen our standards still
> further in the instant case.

I repeat my challenge: you are loosen your standards on #4 of the Social
Contract in order to prevent a simple modification restriction that

 - allows everything to achieve (easily) by the provided means.

In fact we tried to offer several other alternatives, like the one that was
suggested as par

Re: Encoding the name in the file contents (was Re: Towards a new LPPL draft)

[Henning Makholm]

Scripsit Frank Mittelbach <[EMAIL PROTECTED]>

> Our point is that that a user of LaTeX is (normally) in either of
> two situations:

>  - she starts "LaTeX" on a installed unix or windows system where the
>installation of the system was not installed by her or was
>installed by her but using the default packings of the supplier
>(which might be debian suse whatever)
> 
>  - she has installed LaTeX by herself and is aware that she added packages
>that on their human names identify themselves as not belonging to the ULL
>(unique latex language) as i defined it sometime last night.
> 
> there might be a third category, which is users that run SniffenLaTeX instead
> of LaTeX (those i put into category 2 for this argument)

[...]

> In other words, I challenge you that in this case you don't live up to your
> social contract in particular to #4 of it.  I.e. you are not guided be the
> needs of your user _and_ the free-software community but guided only by one
> singular interpretation of what is free-software (a view that is sensible in
> many cases, but not necessarily in all).

This paragraph, and the rest of the article, is looking disturbingly
like an attempt to start a flamefest.


Really, all that's going on is that we try to make sure that users of
the second kind can get their work done without meeting any excessive
legal or technical barriers on the way. We believe that it is possible
to protect the needs of users of the first kind using the free
software community's normal social mechanisms, combined with a few
natural requirements that users of the second kind do not misrepresent
what they are doing. We don't think that using courts to force the
second group to put the first group's needs before their own will
actually improve the situation of the first group enough to justify
the disadvantage that the second group will suffer.

The discussion at the moment is focused on determining

 a) How much disadvantage for group 2 your legal measures are in
practise.

 b) How much disadvantage we can let group 2 suffer and still have
good conscience about telling them that we think they will be
able to get their work done.

 c) Whether there are alternative (legal or technical) measures that
will provide the first group with the protection you desire yet
yield a larger probablity that we can make (a) and (b) meet.

These things (plus some more, and various fallout from things we have
covered, and editorial questions about understanding what your
proposed legal solution is at all) are going on in parallel. That can
be confusing, especially because (b) is basically an internal Debian
debate where there is yet no unanimous consensus and no authoritative
test that can easily resolve the matter. However, that's the way
things have to be, given the social structures in which they unfold.

> From my perspective (which is undoubtely biased) this looks this
> looks as if some people are very hard trying to ensure, that the
> above type of user has no way at all to detect that, she is not
> getting what she things she is getting.

This is simply false. No people at all have been arguing against
requiring modified versions to have all applicable identification
strings and comments changed or amended with clear statements about
the changes made. (Indeed, in several jurisdiction an author cannot
even legally waive his right to have derived works clearly labeled
as derivates).

Your perspective looks as if you're claiming that any way of
inspecting the software that is based on anything but looking at its
filename and only its filename, is "no way at all".

-- 
Henning Makholm   "`Update' isn't a bad word; in the right setting it is
 useful. In the wrong setting, though, it is destructive..."


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Encoding the name in the file contents (was Re: Towards a new LPPL draft)

[Mark Rafn]

> > > On Tue, 2002-07-23 at 21:17, Alexander Cherepanov wrote:
> > > > The question here is how to guarantee that a changed overcite.sty
> > > > (without renaming) will not be used with pristine LaTeX, right?

> Mark Rafn wrote:
> > This is insanity.  If this is the goal, just choose a nice simple license
> > "this can be used and distributed verbatim at no charge, but you may not
> > modify it without permission from the current maintainer".

On Wed, 24 Jul 2002, Boris Veytsman wrote:
> Perhaps because LaTeX people want to give other people (basically
> themselves) a couple of other rights, namely:

> 1. The right to use fragments, ideas or algorithms of their code in
>any way whatsoever without any limitations

Cool.  This right is incompatible with your interoperability guarantee,
and with some other license terms for at least some uses of some
fragments, but I like the sentiment a lot.

Ideas and algorithms aren't really covered by copyright, so this right is
covered (though stating it in the license is nice).  Code fragments are
not clear unless your license specifies them.  I'd strongly recommend you
declare under what circumstances a code fragment may be distributed under
a more liberal license than other derived works.

> 2. The right to *extend* the API by adding new features, based on the
>old code.

Which is included in #1.  From what I've understood, there is one very
large limitation, which is "as long as it's done in an approved way" or
perhaps "as long as you don't change the way existing code behaves".

> Again, I think there is a philosophical difference between the
> interpretation of the word "modification" in our communities. For you
> the right to modify means "I can take the published function foo and
> make it do bar if I want". For us it means "I can write a function bar
> OR I can write a function baz such as after it is invoked all
> functions foo in the following code actually do bar".

This sums it up well.  You would like people to be able to create add-on
software but not modify the base.  We would like people to be able to
modify the software itself.

> I am afraid that it would be difficult to achieve consensus until we
> understand the truth behind each others's approach.

[ the following is rambling and probably unhelpful.  I should probably hit 
cancel rather than send, but I'm bad at that kind of judgement.]

I think I see the truth behind your approach.  It is intended to maintain
beneficial control over how the software evolves and is used, motivated at
least in part by some bad experiences with people distributing unlabelled
modifications.  This is a fine and good goal, but it's not free.  There
are lots of other proprietary no-charge software examples with similar
goals.

I'd characterize this as a beneficial dictator.  It's nearly ideal as long 
as the dictator is beneficial (in latex, he is) and one doesn't mind that 
a few malcontents aren't allowed to do things they otherwise could.

My approach is to allow users to make any changes they want, and accept
the risk that they'll break things.  I'm happy to encourage them not to,
and to make it as easy as possible for them not to, and for their users to
recover if it happens, but I just don't know enough about them to be
willing to limit their freedom to do stupid things.

I think of this as anarchy-without-force.  Nobody can force anyone to use 
software they don't like, and anyone can offer any software they choose.  

Can a consensus be found between the two?  Probably not on a philosophical
level.  Possibly on a practical one, if the dictator is secure enough to
accept some risk of incompatibility (which I think latex is) and the
anarchists are willing to accept some limits (which I think we are).

--
Mark Rafn[EMAIL PROTECTED]  



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Encoding the name in the file contents (was Re: Towards a new LPPL draft)

[Mark Rafn]

> On Wed, 2002-07-24 at 10:22, Mark Rafn wrote:
> > Perhaps I misunderstood, but it sounded like it would be required for a
> > modified work to identify itself as modified, so that documents can
> > determine if they're running on "real" latex.  This disallows preserving
> > the API exactly while changing the execution.

On 24 Jul 2002, Jeff Licquia wrote:
> No, no.  The *kernel* would do the recognition, not the documents.  It
> would have a list of "acceptable" values for that macro.
> 
> Thus, "latex" would refuse to use any modules that didn't identify
> themselves as Standard LaTeX, while "debtex" would accept modules that
> identified themselves as "debTeX" or Standard LaTeX.

Still don't get it.  You're either requiring modified work to follow a
specific API, which is IMO non-free, or you don't get the desired
protection against impostors, as a modified work could simply return the 
latex identifier.

> > A different name to humans.  A different package name, sure.  In some
> > cases, a different executable name (This would be problematic if it
> > were broad enough).  A different name in it's API?  I don't think that
> > follows.
> 
> Why not?  Why does embedding the name in a registration call offend you?

For the same reason that limiting the API of any program would be 
non-free.  I also wouldn't accept a C library that disallowed calling a 
modified function "printf".

> > Adding the facility is no worry.  Requiring derived works to use that 
> > facility is non-free IMO.
> 
> Give me some reasons.  "I don't like it" is really hard to argue with,
> address, or even evaluate.

Because freedom to change (or not change) the API is part of the freedom 
that I believe Debian guarantees to it's users.
--
Mark Rafn[EMAIL PROTECTED]  


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Encoding the name in the file contents (was Re: Towards a new LPPL draft)

[Frank Mittelbach]

Henning,

 > > In other words, I challenge you that in this case you don't live up to your
 > > social contract in particular to #4 of it.  I.e. you are not guided be the
 > > needs of your user _and_ the free-software community but guided only by one
 > > singular interpretation of what is free-software (a view that is sensible 
 > > in
 > > many cases, but not necessarily in all).
 > 
 > This paragraph, and the rest of the article, is looking disturbingly
 > like an attempt to start a flamefest.

sorry, and applogised. email is not always an easy medium.

My intention is and was to point out that while it was several times expressed
that the user is on your mind as well as the developer my impression is that
it is heavily weighted towards the latter and in this particular case (in my
opinion) partly sacrifying the former. My intention in that mal was therefore
to rethink your position with respect to these goals (which may of course
result in -- wrong impression, because)

that way acceptable?


 > Really, all that's going on is that we try to make sure that users of
 > the second kind can get their work done without meeting any excessive
 > legal or technical barriers on the way. 

ok. understood and never questioned (asa goal)

 > We believe that it is possible
 > to protect the needs of users of the first kind using the free
 > software community's normal social mechanisms, combined with a few
 > natural requirements that users of the second kind do not misrepresent
 > what they are doing. 

And this is where our believes differ (for LaTeX type software because too
many people believe small changes are not changes) don't want to rehash the
arguments here.

 > We don't think that using courts to force the
 > second group to put the first group's needs before their own will
 > actually improve the situation of the first group enough to justify
 > the disadvantage that the second group will suffer.

i don't really think it is the courts. but be honnest. how many people do you
think within Debian or some commercial TeX provider or ... would happly
replace article.cls by something better (as it has its "bugs") and stick it
into the texmf tree as a replacement if we only had some guideline document
saying please don't do that. On the other hand how many people would do it if
the license says you are not allowed to? and instead provide debarticle.cls
(under LPPL (making it ULL) or under som other license.

or alternatively providing article.fcl   remember i offered to have LaTeX
come already with a second format that contains the remapping feature.

our experience is they do (without going to court) while they didn't earlier
on, when Leslie Lamport only expressed this in separate statements.

the problem is (and that is my experience from by now 15 years of working in
that community) that there are a few people (but enough) not realizing that
inplace modification is breaking the ULL into pieces unless there is a way to
determine (automatically) that the resulting file is not part of ULL.


 > The discussion at the moment is focused on determining
 > 
 >  a) How much disadvantage for group 2 your legal measures are in
 > practise.
 > 
 >  b) How much disadvantage we can let group 2 suffer and still have
 > good conscience about telling them that we think they will be
 > able to get their work done.
 > 
 >  c) Whether there are alternative (legal or technical) measures that
 > will provide the first group with the protection you desire yet
 > yield a larger probablity that we can make (a) and (b) meet.
 > 
 > These things (plus some more, and various fallout from things we have
 > covered, and editorial questions about understanding what your
 > proposed legal solution is at all) are going on in parallel. That can
 > be confusing, especially because (b) is basically an internal Debian
 > debate where there is yet no unanimous consensus and no authoritative
 > test that can easily resolve the matter. However, that's the way
 > things have to be, given the social structures in which they unfold.

i agree with that


 > > From my perspective (which is undoubtely biased) this looks this
 > > looks as if some people are very hard trying to ensure, that the
 > > above type of user has no way at all to detect that, she is not
 > > getting what she things she is getting.
 > 
 > This is simply false. No people at all have been arguing against
 > requiring modified versions to have all applicable identification
 > strings and comments changed or amended with clear statements about
 > the changes made. (Indeed, in several jurisdiction an author cannot
 > even legally waive his right to have derived works clearly labeled
 > as derivates).

but people strongly trying to push that onto the level of Debian packaging
(basically). I can understand that from the developers point of view but it
doesn't haelp users from group 1  at all if the work is allowed to falsely
identify itself as the original work 

Re: Encoding the name in the file contents (was Re: Towards a new LPPL draft)

[Boris Veytsman]

> Date: Wed, 24 Jul 2002 13:20:52 -0700 (PDT)
> From: Mark Rafn <[EMAIL PROTECTED]>

> 
> On Wed, 24 Jul 2002, Boris Veytsman wrote:
> > Perhaps because LaTeX people want to give other people (basically
> > themselves) a couple of other rights, namely:
> 
> > 1. The right to use fragments, ideas or algorithms of their code in
> >any way whatsoever without any limitations
> 
> Cool.  This right is incompatible with your interoperability guarantee,

Why? I took snippets of code from David Carlisle's enumerate.sty and
used it in my envlab.sty. This action is not going to break the
interoperability guarantee. 


> and with some other license terms for at least some uses of some
> fragments, but I like the sentiment a lot.
> 

I meant only the code released under LPPL.


> Ideas and algorithms aren't really covered by copyright, so this right is
> covered (though stating it in the license is nice).  Code fragments are
> not clear unless your license specifies them.  I'd strongly recommend you
> declare under what circumstances a code fragment may be distributed under
> a more liberal license than other derived works.
> 

I think it might be spelled out, but my (and seems to be other
developers') understanding is exactly this: a code fragment per se is
in public domain under LPPL. This is *much* more free than, say GPL,
where I cannot take a substantial part of gcc code and put it into my
new cool compiler without putting it under GPL.

Of course not mentioning in the comments the people whose code you
used will not make you many friends...

> > 2. The right to *extend* the API by adding new features, based on the
> >old code.
> 
> Which is included in #1.  From what I've understood, there is one very
> large limitation, which is "as long as it's done in an approved way" or
> perhaps "as long as you don't change the way existing code behaves".
> 

The latter phrase nicely summarizes it.

> > Again, I think there is a philosophical difference between the
> > interpretation of the word "modification" in our communities. For you
> > the right to modify means "I can take the published function foo and
> > make it do bar if I want". For us it means "I can write a function bar
> > OR I can write a function baz such as after it is invoked all
> > functions foo in the following code actually do bar".
> 
> This sums it up well.  You would like people to be able to create add-on
> software but not modify the base.  We would like people to be able to
> modify the software itself.


Exactly. Note that you are limited by your programming language
(mostly C): we can modify the base by add-ons in the ways which would
be difficult or impossible for you. That is why we do not feel the
need to modify the base *directly*.


> 
> I think I see the truth behind your approach.  It is intended to
> maintain beneficial control over how the software evolves and is
> used, motivated at least in part by some bad experiences with people
> distributing unlabelled modifications.  This is a fine and good
> goal, but it's not free.  There are lots of other proprietary
> no-charge software examples with similar goals.
> 

I think you are thinking in "C-ish" terms again. This is not C. This
is a macro language. Freezing the common base does not change the way
the language evolves or used. On the other way, since it is infinitely
flexible, not freezing the base makes the divergence and balkanization
almost unevitable. Look at the history of Lisp, for example.

Again, you come to this with preconcieved notions: here is source,
here is binary, here is data. Here the is freedom of distribution of
sources, here is the freedom of compilation, here is the freedom of
data copying. The problem is, our documents, classes, styles, font
description files, kernel etc. are not exactly program sources or
compiled binaries or data. They are in some sense all three and in
some other sense none of these.

Imagine that you have a set of laws about marriages and divorces.  It
works fine, and you are assigned a task of drafting similar laws for
Martians. You find out that instead of two sexes these Martians have
six. Or, even better, they have none, but can choose any during
certain times (see the nice novel by Ursula Le Guin). It does not make
your task impossible (albeit it will be hard), but you must analyze
you preconcieved notions and be willing to adapt them for this
situation. The basic principles of fairness and justice still apply,
but you implementation of them might be completely revised.

I have the impression Debian people on this list do not exactly
realize the difference between their common practice and our situation
-- and between the goals of free software and the means to achieve
these goals.  Yes, we use different ways to modify our programs. I
hope you could understand that it does not mean that we do not have
the freedom to modify them. We just do it in our way.

> I'd characterize this as a beneficial dictator.  It's nearly ideal
> as 

Re: Encoding the name in the file contents (was Re: Towards a new LPPL draft)

[Jeff Licquia]

On Wed, 2002-07-24 at 16:03, Mark Rafn wrote:
> Still don't get it.  You're either requiring modified work to follow a
> specific API, which is IMO non-free, or you don't get the desired
> protection against impostors, as a modified work could simply return the 
> latex identifier.

I still don't see how the API is restricted.

> > > A different name to humans.  A different package name, sure.  In some
> > > cases, a different executable name (This would be problematic if it
> > > were broad enough).  A different name in it's API?  I don't think that
> > > follows.
> > 
> > Why not?  Why does embedding the name in a registration call offend you?
> 
> For the same reason that limiting the API of any program would be 
> non-free.  I also wouldn't accept a C library that disallowed calling a 
> modified function "printf".

OK.  But:

printf("This is Standard LaTeX\n");

is not allowed, and the restriction is allowed by the DFSG.

What is the difference between that and the following?

register_std("LaTeX");

(Which, as I understand it, is a C equivalent to the \NeedsTeXFormat
thing.)

Remember that the only condition imposed on modifying the file would be
that you have to pick some other string to pass to register_std().


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Encoding the name in the file contents (was Re: Towards a new LPPL draft)

[Mark Rafn]

>  > A different name to humans.  A different package name, sure.  In some
>  > cases, a different executable name (This would be problematic if it
>  > were broad enough).  A different name in it's API?  I don't think that
>  > follows.
> 
On Wed, 24 Jul 2002, Frank Mittelbach wrote:
> who is the human here? the Debian developer or the (typical?) user who uses
> ready packed/installed/whatever systems.

I'd start with GPL 2c for this definition.

when started running for such interactive use in the most ordinary way ...
with the exception that this cannot be required if the original program 
does not have such output.

It can be required to identify itself to any user who bothers to look.  It 
should not be required (though I welcome it to be encouraged) to identify 
itself to programs as part of a standard API.  Yes, there is a gray line.

>  - she starts "LaTeX" on a installed unix or windows system where the
>installation of the system was not installed by her or was installed by her
>but using the default packings of the supplier (which might be debian suse
>whatever)

If 'latex -v' or 'latex document' normally identifies itself by name and
version (in human-readable form not intended to technically prevent
modifications), it's fair game to require modified versions to say so on
this output.

It's fair game to require it to be stated in the comments in a modified
file, if such a file has comments about origin to start with.

>  - she has installed LaTeX by herself and is aware that she added packages
>that on their human names identify themselves as not belonging to the ULL
>(unique latex language) as i defined it sometime last night.

Same as above.

> But people that are in the first situation expect that documents written
> using only ULL will behave identical on different installations or more
> exactly behave as explained in brackets above.

I expect that as well, as long as those installations are running standard
latex.  If not, she'll have to 1) find this out and 2) install it or
complain to her sysadmin.  I welcome the addition of a "latex -v" command
to make it easy for her to determine what version of latex she has and
whether it's been modified.

I even welcome making this available in the API, but only as a strong 
suggestion, not a requirement for distribution.  One similar example might 
be the User-Agent header sent by browsers.  It's strongly recommended that 
this be changed when modifying a browser, but it would be non-free to 
require it, as it's intended to be read by a machine rather than a user.

>  But if the installing process that was used to put "LaTeX" on that system,
> combined LPPL works with works derived from LPPL works (properly humanly
> identified in its package name but disguising itself inside LaTeX) then this
> is not at all any longer visible for her as she will never see those (Debian)
> package names but only their unpacked runtime files in the texmf file tree
> (which show up identically to the orginal as far as LaTex is concerned)

Yes.  This seems to be a flaw in LaTeX - it doesn't interactively identify
itself when run.

> Thus the fact that you intend to provide identification only in the name for
> the packaging method (which isn't any longer visible in most situations) means
> that as far is this user is concerned, you are misguiding her (willingly or
> unwillingly).

She can do whatever users normally do to determine the version and type of 
software she has.  I always start with "foo -v" or "foo -h", but other 
packages have Help...About or some other method.  How does she currently 
tell which version she has?

> In other words, I challenge you that in this case you don't live up to your
> social contract in particular to #4 of it.  I.e. you are not guided be the
> needs of your user _and_ the free-software community but guided only by one
> singular interpretation of what is free-software (a view that is sensible in
> many cases, but not necessarily in all).

I think this challenge will fail.  The Debian users I personally 
talk to have two main reasons to prefer Debian over other Linuces.  I 
can't tell which order these come in, but the top two are:
 - Apt rocks.
 - I know it's free.
Thrown in there is completeness, architecture support, and various
preferences as to specific packages, but my point is that the freedom
guarantee is vital to at least one set of our users.

> would it worry you less if packages belonging to the ULL would have to contain
> a line
> 
> \ULLcomplientPackage{foo}
> 
> and we require that this is removed?

Same thing.  Freedom to fork a package means the freedom to make an 
incompatible change that normal programs won't notice.  Humans can be 
required to be able to find out by reading something.

>> From my perspective (which is undoubtely biased) this looks this looks
>> as if some people are very hard trying to ensure, that the above type
>> of user has no way at all to detect that, she is not getti

Re: Encoding the name in the file contents (was Re: Towards a new LPPL draft)

[Mark Rafn]

On Wed, 24 Jul 2002, Boris Veytsman wrote:

> > > 1. The right to use fragments, ideas or algorithms of their code in
> > >any way whatsoever without any limitations
> > 
> > Cool.  This right is incompatible with your interoperability guarantee,
> > and with some other license terms for at least some uses of some
> > fragments, but I like the sentiment a lot.
> 
> Why? I took snippets of code from David Carlisle's enumerate.sty and
> used it in my envlab.sty. This action is not going to break the
> interoperability guarantee. 

"for some uses of some fragments".  The fragment "all of latex except for 
one one file" is clearly not in bounds for use in any way whatsoever 
without any limitations.

> I meant only the code released under LPPL.

Sure, I just didn't see this in the current or draft version, so while it 
may be common practice to use snippets, it's not allowed.

> I think it might be spelled out, but my (and seems to be other
> developers') understanding is exactly this: a code fragment per se is
> in public domain under LPPL. This is *much* more free than, say GPL,
> where I cannot take a substantial part of gcc code and put it into my
> new cool compiler without putting it under GPL.

Completely agree that it's more free, and I laud you for including it.  I 
just didn't notice it in the license, but it's been awhile since I read 
it and I wasn't looking for parts that are free.  If it's there to your 
satisfaction, excellent.

> Of course not mentioning in the comments the people whose code you
> used will not make you many friends...

Sure.  There's lots of things licenses must allow to be free that I don't 
recommend actually be done.

> Exactly. Note that you are limited by your programming language
> (mostly C): we can modify the base by add-ons in the ways which would
> be difficult or impossible for you. That is why we do not feel the
> need to modify the base *directly*.

No, it's true of C as well.  We wouldn't accept a Perl, for instance, that 
forbade incompatible changes to the API, even if it allowed addition of 
keywords.  It really is the case that we want to preserve the right to 
make machine-indistinguishable subtly-incompatible changes.  We recommend 
against it, but if someone can't do it, it's not free.

> I think you are thinking in "C-ish" terms again. This is not C. This
> is a macro language. Freezing the common base does not change the way
> the language evolves or used.

Sure it does.  It prevents a certain kind of evolution - that of 
incompatible forks.  This really isn't a C vs Script issue, although what 
is tolerable is more clearly defined for compiled programs. 

> The thing is, there is no dictator. Or, if you wish, the LaTeX
> community in toto is such dictator. The LaTeX3 project is responsible
> for the kernel, but LaTeX is not the kernel or even kernel+packages
> from the required directory. LaTeX is the union of the code presently
> in the latex directory on CTAN, and mind you, CTAN managers are just
> registrars: they do not make decisions about the code itself.

Ok, "beneficial dictatorial committee" then.  The point remains that there
are certain types of modifications you oppose on principle (that which
could concievably be missed by a user who does not examine the software
she runs).  I agree that such changes are undesirable, but I'm unwilling
to take away the right to make them.

--
Mark Rafn[EMAIL PROTECTED]  


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Encoding the name in the file contents (was Re: Towards a new LPPL draft)

[Mark Rafn]

On 24 Jul 2002, Jeff Licquia wrote:

> printf("This is Standard LaTeX\n");
> 
> is not allowed, and the restriction is allowed by the DFSG.

Maybe. If it's part of an API (like an HTTP header), or it's a common
practice for programs to switch on this string, I'd probably argue that
this restriction makes it non-free.

The ability to make modifications and still have programs that depend on 
it still work is the fundamental freedom I'm arguing for.

> What is the difference between that and the following?
> register_std("LaTeX");
> (Which, as I understand it, is a C equivalent to the \NeedsTeXFormat
> thing.)

The difference is that the printf is intended to identify to the human
running the program what version she has, and the registration is intended
to prevent compatible derivative works.
--
Mark Rafn[EMAIL PROTECTED]  


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Encoding the name in the file contents (was Re: Towards a new LPPL draft)

[Boris Veytsman]

> Date: Wed, 24 Jul 2002 16:42:34 -0700 (PDT)
> From: Mark Rafn <[EMAIL PROTECTED]>

> 
> No, it's true of C as well.  We wouldn't accept a Perl, for instance, that 
> forbade incompatible changes to the API, even if it allowed addition of 
> keywords.  It really is the case that we want to preserve the right to 
> make machine-indistinguishable subtly-incompatible changes.  We recommend 
> against it, but if someone can't do it, it's not free.
> 


I think here is the difference between our goals.

Our community has the following model of evolution. Any change in the
language or API are allowed as long as the full backward compatibility
is preserved. By the full backward compatibility I mean the following:

Any legacy document will always either produce 
exactly same output on all systems or trigger an
error message requesting installation  (P)
of additional components (and will compile after
these components are installed) OR the system is not
called LaTeX.

In our language this requirement is NOT as big burden as in other
languages because of the properties of the language.

You say that the property (P) makes the system non-free.  If this is
the opinion of debian-legal, I really do not see any benefit in the
discussion: LaTeX people will invent more and more subtle ways to
achieve (P) while Debian people will prove them to be non-free.  I
personally cannot spend my time in such amusing activity and hope
David and Frank would not waste theirs. As a LaTeX user I prefer them
to work on LaTeX3 to doing something patently fruitless.

We cannot let go of (P); this is our obligation to the community. If
you cannot accept it, we cannot do anything.

Jeff, is there any way to establish whether debian-legal *can* accept
a system with the property (P) before we invest any more effort into
this discussion?

-- 
Good luck

-Boris

The secret of success is sincerity.  Once you can fake that, you've got
it made.
-- Jean Giraudoux


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Encoding the name in the file contents (was Re: Towards a new LPPL draft)

[Jeff Licquia]

On Wed, 2002-07-24 at 18:56, Mark Rafn wrote:
> On 24 Jul 2002, Jeff Licquia wrote:
> > What is the difference between that and the following?
> > register_std("LaTeX");
> > (Which, as I understand it, is a C equivalent to the \NeedsTeXFormat
> > thing.)
> 
> The difference is that the printf is intended to identify to the human
> running the program what version she has, and the registration is intended
> to prevent compatible derivative works.

I'm confused.  How are they incompatible?



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Encoding the name in the file contents (was Re: Towards a new LPPL draft)

[Boris Veytsman]

> Date: Wed, 24 Jul 2002 16:42:34 -0700 (PDT)
> From: Mark Rafn <[EMAIL PROTECTED]>

> 
> No, it's true of C as well.  We wouldn't accept a Perl, for instance, that 
> forbade incompatible changes to the API, even if it allowed addition of 
> keywords.  It really is the case that we want to preserve the right to 
> make machine-indistinguishable subtly-incompatible changes.  We recommend 
> against it, but if someone can't do it, it's not free.
> 


Another thought in this thread. I already mention the biggest
difference between the Perl programs and our documents. You can afford
throw out a Perl program in a decade; our documents are supposed to be
stored forever.

If you insist on the freedom of introduction of
"machine-indistinguishable subtly-incompatible changes", you are
losing not just TeX or LaTeX. You are losing any sensible document
storage and interchange format. 

This discussion is not caused by some special obstinacy of LaTeX
community or our peculiar distaste for freedom. This discussion is
caused by certain needs of our community. If these needs are
incompatible with your understanding of freedom, we are forced to
remain non-free in your eyes. Sorry, but nothing can be done by our
goodwill or effort.

-- 
Good luck

-Boris

"Nuclear war can ruin your whole compile."
-- Karl Lehenbauer


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Encoding the name in the file contents (was Re: Towards a new LPPL draft)

[Thomas Bushnell, BSG]

Boris Veytsman <[EMAIL PROTECTED]> writes:

> I think here is the difference between our goals.
> 
> Our community has the following model of evolution. Any change in the
> language or API are allowed as long as the full backward compatibility
> is preserved. By the full backward compatibility I mean the following:
> 
> Any legacy document will always either produce 
> exactly same output on all systems or trigger an
> error message requesting installation  (P)
> of additional components (and will compile after
> these components are installed) OR the system is not
> called LaTeX.
> 
> In our language this requirement is NOT as big burden as in other
> languages because of the properties of the language.

See, we have a different model of evolution--one much much much longer
term.

Our model is one that should not rely on any assumption that
*anything* will be static, because of a desire to think *long* term.  

Consider if every package did what you say.  Then in a few centuries,
all the names are taken.  Do we want that?


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Encoding the name in the file contents (was Re: Towards a new LPPL draft)

[Boris Veytsman]

> From: [EMAIL PROTECTED] (Thomas Bushnell, BSG)
> Date: 24 Jul 2002 22:44:16 -0700

> 
> See, we have a different model of evolution--one much much much longer
> term.
> 
> Our model is one that should not rely on any assumption that
> *anything* will be static, because of a desire to think *long* term.  
> 
> Consider if every package did what you say.  Then in a few centuries,
> all the names are taken.  Do we want that?
> 

\begin{rant}
  I would like to remind you that our model is realy old. LPPL is
  based on Knuth's ideas. TeX exists for about a quarter of century,
  and its license is based on the traditions existing in scientific
  community for several thousand years. We knew the value of
  freedom at the times when RMS did not even think about GPL.
\end{rant}

Your question is similar to the question "If you want to store
everything in libraries, what are you going to do when the projected
library space exceeds than the combined volume of all Earth
buildings?" The answer is, the available space (namespace for packages
in our case) is more than we need for several hundred thousand years
(just try elementary combinatorics to check). This is more than the
total time of existence of our culture; we can safely assume that
human beings so much in the future would be vastly different from
us. I doubt that our copyright laws and licenses survive this
long. Also, with all my respect to Knuth, I doubt that TeX survives
this long.

-- 
Good luck

-Boris

When it's dark enough you can see the stars.
-- Ralph Waldo Emerson,


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Encoding the name in the file contents (was Re: Towards a new LPPL draft)

[Mark Rafn]

> > On 24 Jul 2002, Jeff Licquia wrote:
> > > What is the difference between that and the following?
> > > register_std("LaTeX");
> > > (Which, as I understand it, is a C equivalent to the \NeedsTeXFormat
> > > thing.)

> On Wed, 2002-07-24 at 18:56, Mark Rafn wrote:
> > The difference is that the printf is intended to identify to the human
> > running the program what version she has, and the registration is intended
> > to prevent compatible derivative works.

On 24 Jul 2002, Jeff Licquia wrote:
> I'm confused.  How are they incompatible?

They're incompatible because the intent is to write programs that check
this string and behave differently if it does not give the
forbidden-in-changed-works answer.

--
Mark Rafn[EMAIL PROTECTED]  


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Encoding the name in the file contents (was Re: Towards a new LPPL draft)

[Jeff Licquia]

On Thu, 2002-07-25 at 10:27, Mark Rafn wrote:
> > On Wed, 2002-07-24 at 18:56, Mark Rafn wrote:
> > > The difference is that the printf is intended to identify to the human
> > > running the program what version she has, and the registration is intended
> > > to prevent compatible derivative works.
> 
> On 24 Jul 2002, Jeff Licquia wrote:
> > I'm confused.  How are they incompatible?
> 
> They're incompatible because the intent is to write programs that check
> this string and behave differently if it does not give the
> forbidden-in-changed-works answer.

Maybe I'm just dense, but I still don't see the incompatibility.  Can
anyone else see it?

It would be extremely helpful if you could describe your objection in
detail.  I suspect that one of us is misunderstanding the proposal in
some subtle way.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Encoding the name in the file contents (was Re: Towards a new LPPL draft)

[Brian Sniffen]

> On 25 Jul 2002 12:39:35 -0500, Jeff Licquia <[EMAIL PROTECTED]> said:

> On Thu, 2002-07-25 at 10:27, Mark Rafn wrote:
>> > On Wed, 2002-07-24 at 18:56, Mark Rafn wrote:
>> > > The difference is that the printf is intended to identify to the human
>> > > running the program what version she has, and the registration is 
>> > > intended
>> > > to prevent compatible derivative works.
>> 
>> On 24 Jul 2002, Jeff Licquia wrote:
>> > I'm confused.  How are they incompatible?
>> 
>> They're incompatible because the intent is to write programs that check
>> this string and behave differently if it does not give the
>> forbidden-in-changed-works answer.

> Maybe I'm just dense, but I still don't see the incompatibility.  Can
> anyone else see it?

Yes.  Look at Microsoft's Trusted Computing plans: programs will
identify themselves as "Good".  It'll be illegal to distribute a
modified program which claims to be "Good."  And while they're doing
this with the best of intentions, it certainly won't produce Free
Software.

In order for me to truly have freedom to modify a program, I must be
able to change functionality and still have the program work.  In this
case, if I change something in article.cls, the license compels me to
change the \NeedsTeXFormat{} argument.  latex.fmt will now no longer load
my altered article.cls file.  I can go and change latex.fmt, but its
license compels me to change the filename.

Now I can either go much with the (GPL'd part of) the tex executable,
or resign myself to calling sniffentex instead of latex every time I
compile a LaTeX file with my altered article.cls.  More than that, in
order for me to usefully distribute my changed article.cls, I need to
distribute my custom format and such with it.  

Given all that, I *do* think that this is a free license, because it
is permissible for the Debian project to create a deblatex.fmt which
provides LaTeX and DebLaTeX, and preemptively switch all the files to
NeedsTeXFormat{DebLaTeX}.  Then modifications may be freely made and
exchanged among users of DebLaTeX, and the LaTeX project has their
goal of interoperability as well.

-Brian


pgpW5aVUG0uO2.pgp
Description: PGP signature

Re: Encoding the name in the file contents (was Re: Towards a new LPPL draft)

[Jeff Licquia]

On Thu, 2002-07-25 at 13:08, Brian Sniffen wrote:
> > On 25 Jul 2002 12:39:35 -0500, Jeff Licquia <[EMAIL PROTECTED]> said:
> > Maybe I'm just dense, but I still don't see the incompatibility.  Can
> > anyone else see it?
> 
> Yes.  Look at Microsoft's Trusted Computing plans: programs will
> identify themselves as "Good".  It'll be illegal to distribute a
> modified program which claims to be "Good."  And while they're doing
> this with the best of intentions, it certainly won't produce Free
> Software.
> 
> In order for me to truly have freedom to modify a program, I must be
> able to change functionality and still have the program work.  In this
> case, if I change something in article.cls, the license compels me to
> change the \NeedsTeXFormat{} argument.  latex.fmt will now no longer load
> my altered article.cls file.  I can go and change latex.fmt, but its
> license compels me to change the filename.
> 
> Now I can either go much with the (GPL'd part of) the tex executable,
> or resign myself to calling sniffentex instead of latex every time I
> compile a LaTeX file with my altered article.cls.  More than that, in
> order for me to usefully distribute my changed article.cls, I need to
> distribute my custom format and such with it.  
> 
> Given all that, I *do* think that this is a free license, because it
> is permissible for the Debian project to create a deblatex.fmt which
> provides LaTeX and DebLaTeX, and preemptively switch all the files to
> NeedsTeXFormat{DebLaTeX}.  Then modifications may be freely made and
> exchanged among users of DebLaTeX, and the LaTeX project has their
> goal of interoperability as well.

I think I see now.  Yes, we do need the ability to hack or remove the
\NeedsTeXFormat stuff entirely if we so desire.

I've posted a new summary with a more comprehensive description of how I
expect this system to work, which will hopefully make things more clear.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Encoding the name in the file contents (was Re: Towards a new LPPL draft)

[Henning Makholm]

Scripsit Mark Rafn <[EMAIL PROTECTED]>

> Yes.  This seems to be a flaw in LaTeX - it doesn't interactively identify
> itself when run.

Huh? The LaTeX I run identifies itself quite plainly in the third line
of the output:

pc-043:~/foo$ latex radio.tex
This is TeX, Version 3.14159 (Web2C 7.3.1)
(radio.tex
LaTeX2e <1999/12/01> patch level 1
Babel  and hyphenation patterns for american, british, danish, nohyphena
tion, loaded.
(/usr/local/stow/share/texmf/tex/latex/base/article.cls
Document Class: article 1999/09/10 v1.4a Standard LaTeX document class
(/usr/local/stow/share/texmf/tex/latex/base/size12.clo))
(/usr/local/stow/share/texmf/tex/latex/psnfss/avantgar.sty) (radio.aux)
(/usr/local/stow/share/texmf/tex/latex/psnfss/ot1pag.fd) [1] (radio.aux) )
Output written on radio.dvi (1 page, 1152 bytes).
Transcript written on radio.log.
pc-043:~/foo$ 

If there is any problem it would be that TeX has a tendency to write
so much routine stuff to stdout that most users - novices and experts
alike - don't bother to read *any* of it unless the run happens to
stop with an error. (I understand that this is precisely why the LaTeX
people are not happy with relying on human-readable diagnostics output
to prevent hacked files from erroneourly ending up in places where
pristine files are expected, without anybody noticing).

However, the verbosity certainly isn't a fault that LaTeX can be
blamed for. Only four of the lines above are ones that LaTeX (in a
broad sense, but excluding the TeX engine) could, technically, have
chosen not to emit.

-- 
Henning Makholm "However, the fact that the utterance by
   Epimenides of that false sentence could imply the
   existence of some Cretan who is not a liar is rather unsettling."


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Encoding the name in the file contents (was Re: Towards a new LPPL draft)

[Henning Makholm]

Scripsit Frank Mittelbach <[EMAIL PROTECTED]>
> Henning,

> My intention is and was to point out that while it was several times
> expressed that the user is on your mind as well as the developer my
> impression is that it is heavily weighted towards the latter and in
> this particular case (in my opinion) partly sacrifying the former.

The fact is that we're most emphatically not out to sacrifice the
user. As the discussion clearly shows, we don't agree that the
advantage $A_{ou}$ that the ordinary user gets from certain of the
ways you attempt to protect him is significant enough to justify the
corresponding disadvantage $D_{\overline{ou}}$ so the non-ordinary
user [1]. But the core of the disagreement is about the size of
$A_{ou}$, not about how to weight the comparison between $A_{ou}$ and 
$D_{\overline{ou}}$.

I don't think we'll manage to agree on the size of $A_{ou}$ by
beating that matter any further, and in any case it ought to be
possible to reach a workable compromise about the actual licensing
without agreeing on that size. So couldn't we just agree to disagree
about that matter and not make false inferences about  the other
party's morals based on the flawed assumption that we do agree about
$A_{ou}$?

[1] yes, a political choice of words: What you call a developer is to
us just a user with very unusual needs. The developers who
develops for development's sake (i.e. with the intention of
producing something that other people find useful) are undoubtedly
mostly happy with the renaming requirement.

>  > We don't think that using courts to force the
>  > second group to put the first group's needs before their own will
>  > actually improve the situation of the first group enough to justify
>  > the disadvantage that the second group will suffer.

> i don't really think it is the courts.

I think this has been in the thread before, but: From debian-legal's
point of view, licence texts are all about courts. When you write in a
licence that so-and-so is forbidden, the message is that you intend to
sue anybody who does it (to the extent that you learn of it at all).
If you just want to call them names, or alert the entire community to
the fact that These People Are Bad Guys, a legal document like a
copyright license is not the right place to do it.

> but be honnest. how many people do you think within Debian or some
> commercial TeX provider or ... would happly replace article.cls by
> something better (as it has its "bugs") and stick it into the texmf
> tree as a replacement if we only had some guideline document 
> saying please don't do that. On the other hand how many people would do it if
> the license says you are not allowed to?

This is the discussion I've just claimed I won't, go into, but just
for the record:

I think the number would be extremely small in both cases - assuming
that in the first case your license does legally prevent people who
"fix bugs" from claiming that what they're distributing is LaTeX. You
guys are doing quite an effective job of propagandizing for the
intrinsic value of stability - so even users who never read licenses
will generally be wary of downloading and using something that is
advertized as "not quite LaTeX". If somebody had little enough of a
clue to nevertheless put together such a not-quite-LaTeX distribution,
then (even if we stipulate the improbable fact that they succeeded
in putting together something that anyone would want to use rather
than a distribution built by people with clues) they would get such
large amounts of bad press that only the most determined of their
users could remain ignorant of the problems for long.

> or alternatively providing article.fcl   remember i offered to have LaTeX
> come already with a second format that contains the remapping feature.

Personally I have already declared myself happy with that.

I would be more happy if the remapping could be part of the source for
the standard format (but not enabled there, of course), such that we
wouldn't have to distribute a 'latex-free' for the diehards who want
absolute freedom of everything they use, and a 'tetex' in non-free
that contains the pristine LaTeX that sane people wants to use.

[This is somewhat academic, however - it assumes that the eventual
consensus on the list is that exactly a kernel-level remapping feature
is the minimal requirement for DFSG-freedom. While that is certainly
a possible outcome - e.g. it is the reasoning that matches the FSF's
stance on the matter - I do not think it is very likely. Either we
will eventually find that the ability to put a softlink or a trivial
redirection file is enough, or the faction that will not tolerate any
kind of name changes will win].

> but people strongly trying to push that onto the level of Debian packaging
> (basically). I can understand that from the developers point of view but it
> doesn't haelp users from group 1  at all

Strangely enough, my impression was that it is the other way aroun

Re: Encoding the name in the file contents (was Re: Towards a new LPPL draft)

[Thomas Bushnell, BSG]

Henning Makholm <[EMAIL PROTECTED]> writes:

> (I understand that this is precisely why the LaTeX people are not
> happy with relying on human-readable diagnostics output to prevent
> hacked files from erroneourly ending up in places where pristine
> files are expected, without anybody noticing).

The LaTeX people are not able to know whether "pristine files are
expected", because they don't know all the circumstances under which
their product is used.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Encoding the name in the file contents (was Re: Towards a new LPPL draft)

[Mark Rafn]

> Scripsit Mark Rafn <[EMAIL PROTECTED]>
> > Yes.  This seems to be a flaw in LaTeX - it doesn't interactively identify
> > itself when run.

On 25 Jul 2002, Henning Makholm wrote:
> Huh? The LaTeX I run identifies itself quite plainly in the third line
> of the output:

Excellent, you're right (I stupidly didn't run an actual file through it, 
I just typed "latex" and didn't see anything but the TeX idintifier, 
because it was waiting for my input).

> pc-043:~/foo$ latex radio.tex
> This is TeX, Version 3.14159 (Web2C 7.3.1)
> (radio.tex
> LaTeX2e <1999/12/01> patch level 1

Cool.  Is it possible to simply add a requirement "the identification 
string when used must state that it has been modified".  You'd then get
  LaTex2e <1999/12/01> patch level 1 modified by markr 
or whatever.  Users who wanted an unmodified version would then know to go 
get one.  
--
Mark Rafn[EMAIL PROTECTED]  


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Encoding the name in the file contents (was Re: Towards a new LPPL draft)

[Henning Makholm]

Scripsit [EMAIL PROTECTED] (Thomas Bushnell, BSG)
> Henning Makholm <[EMAIL PROTECTED]> writes:

> > (I understand that this is precisely why the LaTeX people are not
> > happy with relying on human-readable diagnostics output to prevent
> > hacked files from erroneourly ending up in places where pristine
> > files are expected, without anybody noticing).

> The LaTeX people are not able to know whether "pristine files are
> expected", because they don't know all the circumstances under which
> their product is used.

You're missing the point. The LaTeX people certainly do know that
there are *some* places where pristine files are expected. It's not
necessary for them to be able to identify each of those places
individually.

-- 
Henning Makholm   "Man vælger jo selv sine forbilleder."


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Encoding the name in the file contents (was Re: Towards a new LPPL draft)

[Henning Makholm]

Scripsit Mark Rafn <[EMAIL PROTECTED]>
> On 25 Jul 2002, Henning Makholm wrote:

> > pc-043:~/foo$ latex radio.tex
> > This is TeX, Version 3.14159 (Web2C 7.3.1)
> > (radio.tex
> > LaTeX2e <1999/12/01> patch level 1

> Cool.  Is it possible to simply add a requirement "the identification 
> string when used must state that it has been modified".  You'd then get
>   LaTex2e <1999/12/01> patch level 1 modified by markr 
> or whatever.  Users who wanted an unmodified version would then know to go 
> get one.

This is already required, but the LaTeX community does not trust this
mechanism enough to really provide users with knowledge. As I said
(and as you demonstrated in practise) hardly anybody ever looks at the
spew of boot-up messages that scrolls by after one starts latex.

-- 
Henning Makholm  "Jeg kunne ikke undgå at bemærke at han gik på hænder."


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Encoding the name in the file contents (was Re: Towards a new LPPL draft)

[Thomas Bushnell, BSG]

Henning Makholm <[EMAIL PROTECTED]> writes:

> > The LaTeX people are not able to know whether "pristine files are
> > expected", because they don't know all the circumstances under which
> > their product is used.
> 
> You're missing the point. The LaTeX people certainly do know that
> there are *some* places where pristine files are expected. It's not
> necessary for them to be able to identify each of those places
> individually.

No, you're missing the point.

They have no information whatsoever about the user of the package.
They *cannot* assume, for example, that the package is being used to
translate LaTeX source into PDF files or the like.  

They have no idea what the user expects, because they have no idea who
the user *is*.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Encoding the name in the file contents (was Re: Towards a new LPPL draft)

[Henning Makholm]

Scripsit [EMAIL PROTECTED] (Thomas Bushnell, BSG)
> Henning Makholm <[EMAIL PROTECTED]> writes:

> > You're missing the point. The LaTeX people certainly do know that
> > there are *some* places where pristine files are expected. It's not
> > necessary for them to be able to identify each of those places
> > individually.

> They have no information whatsoever about the user of the package.

They don't speak about *all* users. Their points consider the fact
that there are *some* users who have this property.

-- 
Henning Makholm   "Oh, hvilken kok detilig!"


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Encoding the name in the file contents (was Re: Towards a new LPPL draft)

[Frank Mittelbach]

I'm just got back online and found 100 messages or so. I will come to the
thread "Concluding the LPPL debate, try 2" at some point, but some of the
mails I read contain some misunderstanding that I think needs clearing up as
well (as they might help to come to a conclusion on the above thread) ... 

Henning Makholm writes:
 > Scripsit Mark Rafn <[EMAIL PROTECTED]>
 > > On 25 Jul 2002, Henning Makholm wrote:
 > 
 > > > pc-043:~/foo$ latex radio.tex
 > > > This is TeX, Version 3.14159 (Web2C 7.3.1)
 > > > (radio.tex
 > > > LaTeX2e <1999/12/01> patch level 1
 > 
 > > Cool.  Is it possible to simply add a requirement "the identification 
 > > string when used must state that it has been modified".  You'd then get
 > >   LaTex2e <1999/12/01> patch level 1 modified by markr 
 > > or whatever.  Users who wanted an unmodified version would then know to go 
 > > get one.
 > 
 > This is already required, but the LaTeX community does not trust this
 > mechanism enough to really provide users with knowledge. As I said
 > (and as you demonstrated in practise) hardly anybody ever looks at the
 > spew of boot-up messages that scrolls by after one starts latex.

If

   LaTex2e <1999/12/01> patch level 1

would identify that the system you are using is ULL, then Mark has an argument
that (after some education) it should be enough to have people check for
that particular line. The counter argument is that there are many TeX front
ends these days that hide all of that stuff, so it isn't that easy.

However, the point that both of you miss in this discussion (as well as in
earlier posts about it by Thomas and Henning) is the following:

 This line only identifies the LaTeX kernel

But that is identifying the starting point, a small fraction of what comprises
the ULL (Unique LaTeX Language). So that line doesn't tell anything about
whether or not a package written by some author and distributed under LPPL (ie
thereby being part of (ULL).

Thus if you fork the kernel, then this line is supposed to be telling that
this is not LaTeX but if the kernel stays unchanged then this line is
unchanged too. 

Thus, if you modify times.sty or mathptm.sty or whatever, then this line
will not change, even though these are individual works under LPPL and forming
part of the ULL. Eg this small document (which typesets a word and a formula
in Times Roman and Adobe symbol and changes the default LaTeX article page
layout to have different margins):

 \documentclass{article}
 \usepackage[tmargin=1.2in]{geometry}
 \usepackage{times,mathptm}
 \begin{document}
   Test $a=b$
 \end{document}

 - first emits that kernel idenfication line

 - and then loads files from 4 (!) independ works (all under LPPL and thus all
 belonging to the ULL)

   article.cls size10.clo from the LaTex base distribution
   times.sty mathptm.sty  from the PSNFSS distribution
  ot1ptm.fd ...   from fontinst generation for psnfss
   geometry.sty   from geometry distribution
   keyval.sty from graphics distribution (loaded by geometry)

if any of those files are changed inplace on one installation but not on
others, then the above document will produce different output without the user
having a chance to notice as the above identication line doesn't show it. And
note, that there are several hundreds independ works that form the ULL and
that they might load each other (as geometry loads keyval).

As I said earlier, I guess we could be persuaded  to provide two kernels within 
LaTeX
distribution, one as it is now, and one with the remapping feature already
available. If that kernel would be used then you would perhaps get


 LaTeX2e <1999/12/01> patch level 1 with file remapping enabled
 !!
 !! 
 !!  Check end of LaTeX run to see if portable output was 
 !!  produced!
 !! 
 !!

and at the end of the run perhaps:

 !!
 !!
 !!  WARNING: This document was produced using a number of
 !!  locally modified files so it may format differently on
 !!  other installations.
 !!
 !!Standard:Replaced by:
 !!
 !!article.cls  article.fcl
 !!geometry.sty geometry.fst
 !!
 !!



frank


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Encoding the name in the file contents (was Re: Towards a new LPPL draft)

[Thomas Bushnell, BSG]

Henning Makholm <[EMAIL PROTECTED]> writes:

> Scripsit [EMAIL PROTECTED] (Thomas Bushnell, BSG)
> > Henning Makholm <[EMAIL PROTECTED]> writes:
> 
> > > You're missing the point. The LaTeX people certainly do know that
> > > there are *some* places where pristine files are expected. It's not
> > > necessary for them to be able to identify each of those places
> > > individually.
> 
> > They have no information whatsoever about the user of the package.
> 
> They don't speak about *all* users. Their points consider the fact
> that there are *some* users who have this property.

But this is the problem!  They take away the freedom of all users in
order to give a subset of the users a benefit.  


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Encoding the name in the file contents (was Re: Towards a new LPPL draft)

[Frank Mittelbach]

Thomas Bushnell, BSG writes:
 > Henning Makholm <[EMAIL PROTECTED]> writes:
 > 
 > > Scripsit [EMAIL PROTECTED] (Thomas Bushnell, BSG)
 > > > Henning Makholm <[EMAIL PROTECTED]> writes:
 > > 
 > > > > You're missing the point. The LaTeX people certainly do know that
 > > > > there are *some* places where pristine files are expected. It's not
 > > > > necessary for them to be able to identify each of those places
 > > > > individually.
 > > 
 > > > They have no information whatsoever about the user of the package.
 > > 
 > > They don't speak about *all* users. Their points consider the fact
 > > that there are *some* users who have this property.
 > 
 > But this is the problem!  They take away the freedom of all users in
 > order to give a subset of the users a benefit.  

Thomas,

I must confess that i havea bit of a problem to understand the exchange
between you and Henning, but could you please be more precise about

 - which freedom is taken away from all users, and
 - which freedom is given to a subset

frank
 > 
 > 
 > -- 
 > To UNSUBSCRIBE, email to [EMAIL PROTECTED]
 > with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Encoding the name in the file contents (was Re: Towards a new LPPL draft)

[Frank Mittelbach]

Henning Makholm writes:
 > Scripsit Frank Mittelbach <[EMAIL PROTECTED]>
 > > Henning,
 > 
 > > My intention is and was to point out that while it was several times
 > > expressed that the user is on your mind as well as the developer my
 > > impression is that it is heavily weighted towards the latter and in
 > > this particular case (in my opinion) partly sacrifying the former.
 > 
 > The fact is that we're most emphatically not out to sacrifice the
 > user. 

sorry, I believe that (from everbody I've heard so far speak). Again I
expressed myself badly i guess. 

 > As the discussion clearly shows, we don't agree that the
 > advantage $A_{ou}$ that the ordinary user gets from certain of the
 > ways you attempt to protect him is significant enough to justify the
 > corresponding disadvantage $D_{\overline{ou}}$ so the non-ordinary
 > user [1]. But the core of the disagreement is about the size of
 > $A_{ou}$, not about how to weight the comparison between $A_{ou}$ and 
 > $D_{\overline{ou}}$.

The disgreement is also about the size of $D_{\overline{ou}}$ to which I still
think there aren't many real arguments on the table (most are of the type: "i
think this is not free"). And what I was trying to point out is that, as you
normally do not have to make a distinction between group 1 and 2 because most
of your software if not all is relevent only to a single machine and may
differ between different machines so there is no need interest in
cross-machine equality. So if was asking you to reflect upon the question
whether a certain fixed type interpretation what is free or not is not
actually (in that particular case --- not in others) a problem for the
majority of your users.

 > I don't think we'll manage to agree on the size of $A_{ou}$ by
 > beating that matter any further, and in any case it ought to be
 > possible to reach a workable compromise about the actual licensing
 > without agreeing on that size. So couldn't we just agree to disagree
 > about that matter and not make false inferences about  the other
 > party's morals based on the flawed assumption that we do agree about
 > $A_{ou}$?

again I didn't ant to make moral statements and again apologize for probably
having sounded like that. I wanted to make you think about further on the
size of the disadvantages of $D_{\overline{ou}}$ and compare both in the light
of the situation for a cross platform exchangibility.

 > > i don't really think it is the courts.
 > 
 > I think this has been in the thread before, but: From debian-legal's
 > point of view, licence texts are all about courts. When you write in a
 > licence that so-and-so is forbidden, the message is that you intend to
 > sue anybody who does it (to the extent that you learn of it at all).

sorry, I didn't mean that. the legal threat is not unimportant and in case of
a very crippled LaTeX distribution by a commercial supplier I sort of made it
once (and it helped).

I just meant that things normally don't end up in court.

 > > or alternatively providing article.fcl   remember i offered to have 
 > > LaTeX
 > > come already with a second format that contains the remapping feature.
 > 
 > Personally I have already declared myself happy with that.

which I find encouraging. I understand that LPPL is an edgy case, but I think
it is a case which is relevant to more than just LaTeX (or other
macro languages on top of TeX or a a variant) it is relevant to the case of
languages those domain is not a single computer but basically an open set of
nodes on the internet. At thesame time I sure would like to see it limit to
the domain it belongs to and not further and this could be properly encoded.


 > I would be more happy if the remapping could be part of the source for
 > the standard format (but not enabled there, of course), such that we
 > wouldn't have to distribute a 'latex-free' for the diehards who want
 > absolute freedom of everything they use, and a 'tetex' in non-free
 > that contains the pristine LaTeX that sane people wants to use.

I already offered that though, the question is what is "not enabled".

 - it is trivially possible to provide a package that opens that up

 - it is equally trivially possible to provide a second format that has it
   enabled.

As long as both formats are distributed side by side I would see no problems
to provide both solutions.

I personally prefer them over the "register" solution, though I guess with
suitable care that one could be added to the list of choices as well.

 > > but people strongly trying to push that onto the level of Debian packaging
 > > (basically). I can understand that from the developers point of view but it
 > > doesn't haelp users from group 1  at all
 > 
 > Strangely enough, my impression was that it is the other way around. I
 > see the "ULL as a whole" viewpoint as one that concerns mostly the end
 > user (who has no reason to concern himself with the division of labor
 > among the people who wrote the software), whereas "l