Pledge of Allegiance. Please forward

2002-07-19 Thread Ken Cutshall
Title: Target E-mailing & Creative Services





  


  

  
 Targeted
  OPT-IN E-Mail Services
   Orlando,
  FL - Atlanta, GA
  
  
Looking for cost effective emailing? 
  Are you having difficulties with your emailiing?



  
407-539-0615
  - 404-806-6124
  
  Take us for
a test drive! 

  
  

  

  

  Targeted
Opt-In Mailings
 Campaign Hosting


  

  Tailored for your
individual needs. Highly targeted E-mail Opt-In
and Postal Mail campaigns.

Included in every campaign at no
extra cost: 
  Design
of your broadcast message including Graphics,

Conversion to HTML and Hosting.

Opt-In List Generation/Management: We can help
you generate your own opt-in lists or manage your current
lists for a fraction of what you would pay a broker.
 100% List OWNERSHIP !
  Web
Site Design: Let us design your private marketing site.

  News
Letter Promotions: Promote your company through monthly
newsletters. 
  RECEIVE
THE GREATEST RETURN ON YOUR MARKETING DOLLAR
  Targeted
Messages Delivered Base Price

500,000 Messages $1,750 
1 Million Messages $3,399 
2 Million Messages $4,499 
3 Million Messages $7,799 
5 Million Messages $12,299 
10 Million Messages $16,899 
  Companies
who outsource their e-mail marketing operations actually
have a better conversion rate (6%) than companies that
do not (1.4%).
  
  

  


  

  Fresh
Email Addresses


  

  The key to a good return on your email
campaign is NEW addresses. Our automated servers harvest
new addresses around the clock. We offer lists as a direct
purchase or as a monthly service.
  250,000 e-mails $100.00
500,000 e-mails $125.00
1,000,000 e-mails $200.00
5,000,000 e-mails $400.00

  Monthly
Service 150.00*
Includes: 
4,000,000 e-mails/month
'E-Mail-IT' Cloaking Software Updates
FTP Access
URL Cloaking Software 


  *Three
months required, lists and software download from our
FTP server.

  

  


  

  Email-IT
CSC Proxy Service


  

  Send your e-mails
directly through our servers. 
  Our in house 'Email-IT' True Stealth
System is based on Unix know-how sending technology,
providing real anonymous instant delivery. 

Forget problems with ISP 's your IP address will never
be shown in our e-mail headers. 
  You send directly into OUR servers which
then send your mail out to the world, FAST! 
  FAST! FAST! FAST!
Use your CABLE or DSL connection for mind blowing SPEEDS!

  'Email-IT' Pricing is based
on number of e-mails you can send monthly. You only pay
for what you send successfully!
   

Re: User's thoughts about LPPL

2002-07-19 Thread Boris Veytsman

 Date: Thu, 18 Jul 2002 14:12:44 -0400
 From: Glenn Maynard [EMAIL PROTECTED]

 
 On Thu, Jul 18, 2002 at 12:55:43PM +0200, Javier Bezos wrote:
   but the documents created using that distribution. If I get a
   document by John Smith (somehow), how can I see if _his_
   system had a modified latex?
 
 Others (eg Boris) seem to be saying that the Latex developers don't
 mind if you rename Latex to something else and modify it such that
 \usepackage{article} in a document does something different than it
 does in the real latex.  You're contradicting this, so I'll discontinue
 this thread unless Frank or David speaks up to clarify this.
 


To say the truth, I do not see a contradiction here.

Anyway, here is a quotation from modguide, which is referred to by the
LPPL (the version currently in force):

It is possible that you need to produce a document processing
system based on standard \LaTeX{} but with functionality that
cannot be implemented by using the approved configuration files
and complying with the restriction on the code that is allowed in
them.  In other words, you may need a system which is sufficiently
distinct from Standard \LaTeX{} that it is not feasible to do this
simply by using the configuration options we provide or by
producing new classes and packages.

If you do produce such a system then, for the reasons described
above, you should ensure that your system is clearly distinguished
from Standard \LaTeX{} in every possible way, including the
following.

Then the guide lists the ways you should take to make your system
clearly distinguishable from the standard, including name change.

I read this quote as clear permission to perform any modification as
long as you do not claim your system to be LaTeX and take care it
cannot be taken for LaTeX accidentally.

-- 
Good luck

-Boris

Operator, please trace this call and tell me where I am.


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



Re: forwarded message from Jeff Licquia

2002-07-19 Thread Boris Veytsman
 Date: Thu, 18 Jul 2002 20:16:43 +0200
 From: Bernhard R. Link [EMAIL PROTECTED]

 
 I think noone wants to change the (La)TeX-Kernel, noone want do make
 .tex-file iterchange impossible. We all want the LaTeX to be the
 usefull crossplattform tool that it is.
 
 But though we do not want to do it, we want to have the right to
 choose this ourselves. We do not want to depend on anyone to be
 able to bring our computers in workable state.
 
 It's about principles. We all judge it very unlikely that the LaTeX-
 developers will go nuts or a has-to-be-fixed-fast security update
 has to be done. (As I think it is very unlikely that police would
 suspect me for anything, but am against allowing them to tortue
 suspects)
 And it is this principle to demand software to be free is one
 of the foundations of Debian and it is an important point for
 many of the people I know. (Though I doubt any would stop using
 LaTeX)
 


The problem is, the first paragraph quoted above is not true. There
are precedents when people changed important parts of TeX and LaTeX
and distributed these changed files without clearly labeling them as
such. AFAIK, there were only good intentions on the part of the
perpetrators, but the damage was real. LPPL was crafted to prevent
these things to happen again.

So, you are defending abstract principles against a very unlikely
danger. LaTeX people see a real danger in changing their way. What is
a pure abstraction for you (most of the people on debian-legal
probably never used LaTeX in their everyday work) is an important
issue for them -- and for us, end users.

-- 
Good luck

-Boris

Punning is the worst vice, and there's no vice versa.


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



Re: forwarded message from Jeff Licquia

2002-07-19 Thread Chris Lawrence
On Jul 19, Boris Veytsman wrote:
 The problem is, the first paragraph quoted above is not true. There
 are precedents when people changed important parts of TeX and LaTeX
 and distributed these changed files without clearly labeling them as
 such. AFAIK, there were only good intentions on the part of the
 perpetrators, but the damage was real. LPPL was crafted to prevent
 these things to happen again.

How does the LPPL actually prevent a distributor from FUBARing their
distribution of LaTeX?  The fact is people regularly ignore licenses,
copyrights, patents and trademarks (if this weren't the case, there'd
be almost no GIFs or MP3s in the world).

To put it another way: If you don't trust people to do the right
thing, no license will help you.

 So, you are defending abstract principles against a very unlikely
 danger. LaTeX people see a real danger in changing their way. What is
 a pure abstraction for you (most of the people on debian-legal
 probably never used LaTeX in their everyday work) is an important
 issue for them -- and for us, end users.

I *do* use LaTeX in my every day work.  I also recognize that someone
might want to make a derived work of LaTeX (say MyLaTeX) without
having to engage in unreasonable amounts of bookkeeping or bizarre
filename hacks (i.e. without recoding the parser to add my to the
beginning of every package that is \usepackage{}d since they had to
rename every single file in the distribution that they touched) and
without breaking compatibility with their own source files (i.e. so
they can run mylatex blah.tex where blah.tex is valid input to latex).

In fact, pdflatex depends on this very ability, but since the LPPL
only trusts the anointed of the LaTeX3 Project to do this in a trivial
manner, I couldn't make a tifflatex or pcllatex without going through
silly bureaucracy (renaming files, hacking macros to search for my
modified versions of .cls and .sty files with messed up names, etc.)
that Frank doesn't have to engage in.

Having said that, I'd be pissed if typing latex myfile.tex was
arbitrarily different from system to system.  But again, if you
require modified versions of LaTeX to not be called LaTeX and not be
invoked by typing latex, this surprise problem goes away.  So,
again, the IMHO reasonable thing to say is:

1. latex should always refer to unmodified LaTeX as distributed by LaTeX3

2. If you modify any part of LaTeX, you must either:
 a. call the entire derived work something other than LaTeX, and
invoke it with something other than latex, or
 b. distribute modified files within LaTeX under different names, and
include unmodified versions of those files.

Note the word or there.  If the derived work is bobslatex or
rubberfetish or whatever you want to call it, 2(b) goes away because
the derived work no longer calls itself LaTeX and is not expected to
behave like standard LaTeX.  However, if you represent your derived
work as being standard LaTeX (by calling it LaTeX), the behavior
should be consistent with standard LaTeX for all macro packages
defined in standard LaTeX.


Chris
-- 
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: LaTeX DFSG

2002-07-19 Thread Boris Veytsman
 Date: Thu, 18 Jul 2002 13:21:09 -0700 (PDT)
 From: Mark Rafn [EMAIL PROTECTED]

 
  R2. Change the appearance of all documents by (1) using instead of the
  command latex file a command modified-latex file or (2)
  passing the corresponding options to tex or (3) using my own
  version of tex with different name.
 
 This seems untrue.  The current proposal is that in addition to naming the 
 main invocation command something other than latex, there are a bunch of 
 files that cannot be changed without renaming.  I have no clue how onerous 
 this is in practice, but it definitely makes modification more difficult 
 than you state.  Perhaps difficult enough that it qualifies as non-free.


First, the documentation refereed to by the license allows you instead
of renaming files to take them away from the LaTeX search path and
change the banner (see modguide.tex). LPPL is VERY programmer-friendly
(in my opinion, too much friendly -- I'd rather take away this
permission). 

Second, did you ever try to program in TeX or hack together a LaTeX
package? If you did, you might find that renaming files is the least
of your problems. TeX is a notoriously difficult language. If you can
master it, surely you can master the art of renaming files from a
shell script.


  A1. If I issue the command latex file, the appearance of the
  resulting document will be exactly the same as intended by the
  author with discrepancy no more than tens of Angstroms.
 
 Sure if latex even exists.  The modified version latex-local may be all 
 you have.  In that case, you'll need to get the original sources and build 
 it yourself.  Which you could do anyway without the license restriction.
 
  A2. If I send my document to be latexed to my publisher, colleague,
  friend, the appearance of the document on their desks will be
  exactly same as on mine. This is true whether they use Debian
  Linux, FreeBSD, Windows, Macintosh or Palm Pilot.
 
 Sure, unless they use latex-local for all their processing.


In both cases this is a conscious decision of these users. Surely a
user might decide not to install TeX at all. I do not demand Microsoft
to make its Word to correctly process my .tex files. However, I want a
user that *decided* to use LaTeX to be able to use LaTeX and not
something that you concocted for him. 

 
  A3. The propeties A1 and A2 are going to be there whether the document
  is processed today, tomorrow or in any foreseeable future.
 
 With enough caveats that it's not much of an assurance.


This might be not much for you. It is good enough for me, my
colleagues, publishers etc.

 
 All the rights you need is a scary concept, but I'll let it go.  The 
 rights you list are sufficient to go into Debian, IFF recipients of the 
 software really have them as you state.  
 

They are. I am glad we have this understanding.

 
 If the license clearly states that we're allowed to have modified versions 
 of any file in the package as long as we don't call the package latex, the 
 discussion is done.  It's free software.  
 

OK. Here is the quotation for you:


  Ensure that it contains no file with a name the same as that of
  a file in the standard distribution but with different contents.
  (If this is not possible then you must: 
  \begin{itemize}
  \item
ensure that files from the non-\LaTeX{} system cannot be
accidentally accessed whilst using a standard \LaTeX{};
  \item ensure that each file from the non-\LaTeX{} system clearly
identifies itself as a non-\LaTeX{} file on the terminal and in the
log file.)
  \end{itemize}

 
  Thanks, but no thanks. I do not want you to have this freedom.
 
 Fair enough.  That puts you clearly in the non-free camp.  I'm sorry that


You do not think clearly, I am afraid.

The only completely free license is public domain. Any other license
takes some freedom from you. Eg GPL takes from you the freedom to take
somebody else's code, improve it and sell the result as a proprietary
software. GPL takes away this freedom to protect another freedom which
it considers more important -- the freedom of everyone to enjoy free
software. LPPL takes from you the freedom to confuse your users by
making them use non-LaTeX *unknowingly*. It does this to protect
their freedom of using LaTeX when they want to use LaTeX. It considers
this freedom more important.

A law requiring truth in labeling food products takes away the
vendor's freedom to sell saccharine while calling it sugar. It does
this to protect consumers' freedom to use sugar when they want
sugar.

Who is in the non-free camp -- the one who supports this law or the
one who opposes it?

 
 If you're looking for benign examples, imagine a constrained system (think
 embedded) that has a homegrown incomplete tinyTeX.  They want to use latex
 on it, and it just doesn't work out of the box.  Are they allowed to
 create and ship a tinylatex with modifications that make it kind of work,
 but produce vastly 

Re: User's thoughts about LPPL

2002-07-19 Thread Javier Bezos
 On Thu, Jul 18, 2002 at 12:55:43PM +0200, Javier Bezos wrote:
 but the documents created using that distribution. If I get a
 document by John Smith (somehow), how can I see if _his_
 system had a modified latex?
 
 Others (eg Boris) seem to be saying that the Latex developers don't
 mind if you rename Latex to something else and modify it such that
 \usepackage{article} in a document does something different than it
 does in the real latex.  You're contradicting this, so I'll discontinue
 this thread unless Frank or David speaks up to clarify this.

There is no real latex as opposed to unreal/modified latex.
What David is saying is that you can create a format based on latex
which is no longer latex but balhblahlatex -- a consciuos act
is necessary to typeset that document using something different
to latex and while it's true that the document (the tex file)
could look identical, it won't be latex anymore, and if it doesn't
work in your system that will be the fault of the author of the
document which is distributing a document not being latex, but
which looks like latex, without any notice. If latex can be
modified, that document could be both created and distributed
as a latex document, and that is what I'm saying.

Javier



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



Re: forwarded message from Jeff Licquia

2002-07-19 Thread Javier Bezos
 On Thu, Jul 18, 2002 at 11:59:37AM +0200, Martin Schröder wrote:
 
 This is absolutely relevant. LaTeX is just a set of macros run
 through an interpreter. The interpreter happens to be some
 implementation of TeX. The security problems will be in the
 interpreter, not in the macros. And the parts of the
 implementation concerning these possible problems are under GPL.
 
 Under the LPPL we are not allowed to fix the engine either; we have to wait
 for D. E. Knuth to do it.

1. TeX is not distributed under lppl.

2. An implementation of TeX is TeX plus a few things added, like
   the access to the filesystem.

3. The tetex specific code (including reading/writing files) is
   under GPL.

These points have been repeated over and over again.

Javier


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



Question(s) for clarifications with respect to the LPPL discussion

2002-07-19 Thread Frank Mittelbach
Jeff wrote in one of his mails he is waiting for me to return with comments
and I intend to do so, but first like to have things a bit more focused (for my
own benefit at least :-)

so what i present here is essentially a set of concerns and comments that I
gathered from the various mails that people put up as a problem with LPPL or
rather as a problem behind the ideas behind LPPL (rereading and compiling took
me roughly 7 hours last night and 4 this morning --- which makes me feel that
i'm too slow a worker these days).

I have structured it into 

 a) a number of concerns together with sub-arguments if i thought that helps
(wordings are mine)

 b) a set of mail quotes which i thought being relevant to the question of
determining whether or not LPPL (in some form, eg after further
cleanup/changes) would be DSFG-complient

 c) a set of mail quotes which i consider important for me decide whether to
carry on with this or stop (and rather get some sleep again)

 d) some other mail quotes that i thought might be worth thinking about
further.

I apologize beforehand if I have something misrepresented, or taken out of
context in a way that its meaning changed. I clearly hope not, but if so
please tell me (that's one of the purposes of this message). Similarily I
might have missed something important, again please say so in case.

I deliberately left out (finer) details of the current license text that were
discussed by Jeff and some others but which I think are more technical (eg
what is a filename) and resolvable easily; either by further discussion or
simply by clarifying or changing the license text (of course you may think
differently and point them out as something more fundamental which should be
discussed up front).  I have, however, put the most relevant mails (i hope) of
that type at the end of d).


What I now would like to ask you about these four blocks is:

  on a):  have i missed any important concerns or any important sub-argument
  within a concern?

  on b): have I missed any important aspects here? 
 do you (dis)agree with the statements made in these mail excerpts?

  on c): do you (dis)agree with the statements made in these mail excerpts?

  on d): nothing really, though you of course are invited to suggests further
remarks for which it would be helpful if we (everybody on this list,
but mostly the LaTeX Project Team) think about and perhaps comments
on.


If we could get some answers/comments with respect to this mail and the
questions posed above then i hope we can resolve these issues/concerns in one
way or another after another round of focused discussions.

compiling this stuff has helped me a lot I hope you find it useful too.

thanks
frank (taking a break)

ps I'm bcc'ing this particular message to LATEX-L (Bcc so that you don't get
rejects when you reply on debian-legal) in case people there wish to join or
listen again in at this point. As LATEX-L is a closed list (unfortunately for
this particular case) I have given up forwarding replies to it or cc'ing it
(as it was too complicated), and this will be the only message send there, so
folks if you like to see what is happening please listen at debian-legal.



-
| Block a)
| Concerns (not really ordered)
-


Concern 1: requiring a change of filename in case of modification 
   in case of distribution
=

this seems to me the major stumbling point  for most people and (unfortunately
the most important point for us)

Argument 1.1: the need to fix a file because of a security problem

Argument 1.2: the need to fix a file because of a bug

Argument 1.3: the wish to change a file because of improvements made

Argument 1.4: when keeping the name somebody else has to approve
(http://lists.debian.org/debian-legal/2002/debian-legal-200207/msg00086.html)

Argument 1.5: Changes to the LaTeX kernel to support new code (e.g klingon
  example) are made impossible this way



Concern 2: the ability to make modification without filename changes
   in case of private or closed use
=

Argument: 2.1: change article.cls to run klingon and to share it with friends
   on SuperH architecture 
(http://lists.debian.org/debian-legal/2002/debian-legal-200207/msg00086.html)




Concern 3: the uselessness of the approach taken by LPPL


Argument 3.1: write a new (unrelated/related?) package from scratch
  and give it the same name as the original one.

Argument 3.2: Trademarks and certification marks are tools better suited to
  controlling endorsements of conformance with a standard or set
  of usage practices.

Re: forwarded message from Jeff Licquia [OT]

2002-07-19 Thread Timothy Murphy
On Wed, Jul 17, 2002 at 11:32:06PM -0400, Glenn Maynard wrote:

  As far as I can see, Frank --
  who is largely responsible for the extraordinarily high quality of LaTeX 
  today --
  is sad to see a schism in the world of free software (TM RS),
  and is doing his best to bridge the gap.
 
 TM RS?

Trademark Richard Stallman

-- 
Timothy Murphy  
e-mail: [EMAIL PROTECTED]
tel: 086-233 6090
s-mail: School of Mathematics, Trinity College, Dublin 2, Ireland


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



Re: User's thoughts about LPPL

2002-07-19 Thread David Carlisle


 I think you are mistaken. You are assuming that the engine used to process
 those macros will also not be changed; it would be quite possible to change
 LaTeX in such a way that it produced identical output from all valid LaTeX
 input whilst adding other functionality, if you modified it to use
 some-modified-thing-that's-no-longer-quite-TeX under the hood.
 
 Why should this not be allowed?

it is allowed.
pdftex for example produces different output from the same input.
you could use the command latex for that as it doesn't involve any
changes in LPPL'ed code, although tetex calls the command pdflatex
as a user convenience so they can easily get access to both forms.

omega on the other hand (unicode TeX) did make a few changes to latex
(I think in only a couple of lines) to use omega features. The omega
version of latex is called lambda rather than latex. Is that really
too much to ask? So the omega developers take latex and just change it
as they see fit, they are not restricted in any way the kind of chages
they make. The end user sees lambda which is almost exactly latex but
changed a bit and using a different engine underneath. I can't see how
anyone would benefit if this version was distributed as latex.


 If you are happy for people to take the code and do anything they like with
 it (bar distributing a functionally incompatible version described as
 LaTeX), then why not keep things simple and say so -- allow all kinds of
 modification and distribution in the license, but control a LaTeX trademark
 in such a way that no-one can distribute incompatible versions.


It is just about conceivable that the latex project could consider
registering LaTeX (although certain rubber based products might make
that difficult) but LPPL isn't just used for the core LaTeX: it has
turned out to be remarkably popular (and successful in its stated aims
of keeping LaTeX both Free and stable). 100's  of contributed
packages are now distributed under LPPL.

It is not reasonable that the author of a package such as
indentfirst.sty
for example (which consists of exactly 4 TeX tokens) should be expected
to go to the trouble of trying to legally register that name.
the LPPL as it is currently drafted gives other users some assurance
that if their documents have
\usepackage{indentfirst}
then their documents will behave as they expect (indenting the first
paragraph of sections) and not invoke some other completely different
code that someone thought was an improvement.

 
 stirring
 If setting up a whole new body to perform this task is more than you are
 willing or able to undertake, then you might consider asking one of the
 existing similar bodies, such as the ASF or SPI to take on this role.
 /stirring

The latex3 project does exist as some kind of entity (has web sites and
bank accounts etc) but as I say that isn't really any help in the
general case. Most GPL'ed code is not from FSF and similarly most
LPPL'ed code is not from the LaTeX3 project.

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]



DFSG, the LaTeX Project and its works (Was: none)

2002-07-19 Thread William F Hammond
-
This was posted on July 17 to LATEX-L, but the copy for debian-legal
was misaddressed.
-

Perhaps it just comes down to nuances of language.

David Carlisle [EMAIL PROTECTED] writes to LATEX-L:

 4) In practice, Debian recognizes a different name or version number
to refer *works*, not filenames.  Permission to mandate or forbid the
 . . .
 This misses the point that in latex filenames are part of the end-user
 syntax.
 
 \usepackage{longtable}
 
 loads longtable.sty which is part of the core latex distribution.
 Under msdos this gets stored in all sorts of ways longtabl.sty lontable.sty
 longtab~1.sty, whatever,  . . .

LaTeX is a _project_.

Any of a LaTeX class, package, literate-programming wrapper, ...
is a LaTeX _work_.

With such new language in LPPL wouldn't renaming and version-numbering
restrictions be appropriate under DFSG?  Then have language in the
license to the effect that technical changes not changing the _work_
are permissible.

The new license might contain a URI pointing to the TDS standard
with some mention of its relevance.

The new license might also contain a URI pointing to a CTAN doc
with guidelines on how a distribution implementer (such as Cygwin,
Mac OS X, Redhat, Debian, SuSE, ...) can provide a distribution of
LaTeX without breaking it.

Isn't TUG's TeXLive the only free (as-in-speech) distribution we know
to be maximally reliable these days?

Ummm ... glug ... what type of object under LPPL should the URN
TDS:/$VARTEXMF/web2c/latex.fmt  be?   :-)

-- Bill


P.S.  Just because present LPPL might not conform to DFSG does not
mean that LaTeX is not free.  Assertions to the contrary represent
just one of a number of extant misappropriations of the word free,
not the least of which is that now going with free market to mean
narrow oligopoly not under the burden of governmental regulation --
a notion that would, I suspect, be quite appalling to Adam Smith.


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



Re: Question(s) for clarifications with respect to the LPPL discussion

2002-07-19 Thread Henning Makholm
Scripsit Frank Mittelbach [EMAIL PROTECTED]

 Concern 1: requiring a change of filename in case of modification 
in case of distribution
 =
 
 this seems to me the major stumbling point  for most people and
 (unfortunately the most important point for us)

I think it is important to realize that what people have problems
about is not in itself that a name change is required. The problems
are about the *granularity* with which this requirement is being
applied.

Somebody has repeatedly asserted that it would be OK to do anything
with LaTeX as long as the modified LaTeX has another name than
latex. I cannot find support for it in the draft we're discussing here
- it says that if the name of each individual *file* *in* LaTeX must
be changed in the project. This means, effectively, that forking LaTeX
requires that one renames *all* the files, and then sifts through all
of the code to track cross-references between files. This is not
trivial with TeX macro code and is certainly not automateable - so it
has to be done by humans, which means that there is no way to fork
LaTeX which is at once legal and likely not to break functionality
that one wants to keep.

(That is, unless one also changes the TeX binary to do strange
nonintuitive mappings in its \input primitive, which I here assume
that one doesn't want to do. Also, some people have said something
to the effect that the word file in the LPPL essentially refers
to the token string given as argument to \input, so even changing
TeX wouldn't work).

 Argument 1.1: the need to fix a file because of a security problem
 Argument 1.2: the need to fix a file because of a bug
 Argument 1.3: the wish to change a file because of improvements made

These are all arguments, with varying strength, for the important
principle that the DFSG is meant to protect the Golden Rule:

For software to be free, it must be legal to fork it.

This is supposed to hold for all software in Debian, and when the
arguments do sound rather feeble in the case of LaTeX it is because
there seems to be no really good reasons to actually fork LaTeX.
When we nevertheless hold that the legal ability to do so must be
present in the case of LaTeX, it is not for the main part because of
intrinsic reasons in LaTeX, but because the Debian project would
become a madhouse if we began waiving the Golden Rule for individual
pieces of software just because someone thinks it is not really needed
for that particular piece of software.

This perspective - that from Debian's point of wiev the necessity of
the ability to fork is an axiom and not something that needs to be
argued for each piece of software in isolation - has a tendency to be
lost in the detailed discussions on debian-legal where well-meaning
regular try to convince upstream authors that forkability is a good
thing independently of whether Debian will distribute the software
or not. It sometimes helps inexperienced upstream authors to see the light
when the general principles are spelled out in the context of their
particular brainchild - but on the other hand it creates the
impression that forkability is a negotiable requirement.

(Unfortunately my previous contribution to this discussion so far has
been in one of those confusion-spewing subthreads, for which I
apologize to all readers who care).

However, let's credit the LaTeX people with more wits than those of
inexperiences upstream authors and be honest about it: We want LaTeX
to be forkable because, as a matter of principle, we want all software
that Debian distributes, to be forkable. It's one of the ways that we
add value for our users: When they download something from the main
part of Debian's archive, they know that we have screened its license
terms and tried to make sure that they'll have the legal ability to
fork it if *they* somewhen, somehow, reach the conslusion that they
want to do so.

We don't say all our software for which we can imagine a valid reason
for you to fork, is forkable. We say all our software is forkable.

However, we don't require it to be possible to fork a project and pass
the forked off as the original. Requiring that modified version are
clearly identified as having been modified, and, where applicable
idenfifiy themselves as such in their banners or diagnostic output.

So the basic goal that the LaTeX people are trying to enforce with
their license is not intrinsically incompatible with the DFSG - but I
think that the focus on changing the names of *files* rather than the
entire program is a too rigid way of reaching that goal.

 From: Jeff Licquia [EMAIL PROTECTED]
 http://lists.debian.org/debian-legal/2002/debian-legal-200207/msg00174.html

  Our Social Contract states that Our Priorities are Our Users and Free
  Software.  User needs are as important to us as freedom, and we
  wouldn't be serving our users if we broke LaTeX document compatibility. 

This is a relevant quote 

Re: forwarded message from Jeff Licquia

2002-07-19 Thread Branden Robinson
On Wed, Jul 17, 2002 at 04:25:35PM -0700, Walter Landry wrote:
 The LPPL goes beyond what is allowed by DFSG #4.  If the LPPL just
 said that you can't call the resulting program latex, then it would
 be fine for Debian.

personal opinion
Actually, I dislike permitting even that, for a couple of reasons:

1) Names and titles are not copyrightable.  If you want intellectual
property protection in a name, you need a trade mark, service mark,
certification mark, or similar instrument.

2) Free Software copyright licenses should not attempt to achieve via
their license what would not ordinarily be achievable through copyright
law.  I do not know whether a court would uphold a copyright license
that attempted to enforce a poor man's trademark by conditionally
extending the license to a party contingent on that party's not using a
particular name or title in a particular way.  I do believe, however,
that it is illegitimate for a copyright license to attempt to this, and
it is especially unacceptable for a Free Software license to do this.
I feel this way for the same reason that I believe that a DFSG-free
license should not be contingent on the licensee obeying the laws of
some jurisdiction, praying to Mecca five times daily, or refraining from
kicking their dog.  A licensee may nor may not be in sympathy with any
or all of these sentiments, but the simple fact is that they are outside
the scope of copyright and should remain so.  A work that is Free
Software must be free to everyone who does not infringe its copyright by
engaging in unauthorized distribution.  A work that is Free Software
should not discriminate against those who engage in insider trading,
smoke marijuana, infringe the copyright on Microsoft Windows, infringe
the copyright on some other work of Free Software, abuse animals, eat
meat, chew tobacco, chain themselves to trees, or change lanes without
signaling.

If you want copyright protection in your work, place a copyright notice
on it and state some licensing terms.[1]

If you want protection of a word or phrase, apply for trademark, service
mark, or certification mark status.

If you want patent protection on your work, apply for a patent.

If you want trade secret protection on your work, keep it secret and
persuade those whom you share it with to sign confidentiality
agreements.
/personal opinion

[1] Under U.S. copyright law, copyright attaches to original works
automatically, but it's still a good idea to attach a notice and
license, and it's mandatory for the purposes of Free Software.

-- 
G. Branden Robinson|I'm sorry if the following sounds
Debian GNU/Linux   |combative and excessively personal,
[EMAIL PROTECTED] |but that's my general style.
http://people.debian.org/~branden/ |-- Ian Jackson


pgpk4rO0J0NvJ.pgp
Description: PGP signature


Re: forwarded message from Jeff Licquia

2002-07-19 Thread Jeff Licquia
On Fri, 2002-07-19 at 12:19, Branden Robinson wrote:
 I do not know whether a court would uphold a copyright license
 that attempted to enforce a poor man's trademark by conditionally
 extending the license to a party contingent on that party's not using a
 particular name or title in a particular way.  I do believe, however,
 that it is illegitimate for a copyright license to attempt to this, and
 it is especially unacceptable for a Free Software license to do this.

Just so I'm clear on your opinion here: do you think it's illegitimate
for a free software developer to receive a trademark, and then grant a
license to the trademark in the copyright license under certain
conditions?

I'm thinking here of the CUPS license.  This is essentially the GPL and
LGPL, but with an additional clause that states that you may not use the
(duly registered) CUPS trademark to describe derivative works except
under a certain set of circumstances - circumstances that would be
non-free if they were part of the copyright.


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



Re: forwarded message from Jeff Licquia [OT]

2002-07-19 Thread Glenn Maynard
On Fri, Jul 19, 2002 at 10:34:09AM +0100, Timothy Murphy wrote:
   is sad to see a schism in the world of free software (TM RS),
   and is doing his best to bridge the gap.
  
  TM RS?
 
 Trademark Richard Stallman

AFAIK, Free software is not trademarked.

-- 
Glenn Maynard


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



Re: Question(s) for clarifications with respect to the LPPL discussion

2002-07-19 Thread Jeff Licquia
On Fri, 2002-07-19 at 05:15, Frank Mittelbach wrote:
 so what i present here is essentially a set of concerns and comments that I
 gathered from the various mails that people put up as a problem with LPPL or
 rather as a problem behind the ideas behind LPPL (rereading and compiling took
 me roughly 7 hours last night and 4 this morning --- which makes me feel that
 i'm too slow a worker these days).

Thanks for the effort.  I generally agree with the points made, both
that they cover the issue well and that I concur with their analysis,
with the exceptions I note below.

 -
 | Block a)
 | Concerns (not really ordered)
 -
 
 
 Concern 1: requiring a change of filename in case of modification 
in case of distribution
 =
 
 this seems to me the major stumbling point  for most people and (unfortunately
 the most important point for us)
 
 Argument 1.1: the need to fix a file because of a security problem
 
 Argument 1.2: the need to fix a file because of a bug
 
 Argument 1.3: the wish to change a file because of improvements made
 
 Argument 1.4: when keeping the name somebody else has to approve
 (http://lists.debian.org/debian-legal/2002/debian-legal-200207/msg00086.html)
 
 Argument 1.5: Changes to the LaTeX kernel to support new code (e.g klingon
   example) are made impossible this way

I refer you here to the excellent reply by Henning Makholm, with which I
entirely concur.

 Concern 2: the ability to make modification without filename changes
in case of private or closed use
 =
 
 Argument: 2.1: change article.cls to run klingon and to share it with friends
on SuperH architecture 
 (http://lists.debian.org/debian-legal/2002/debian-legal-200207/msg00086.html)

I think this is a sub-question of Concern 1, above.  If Concern 1 is
addressed, then we get Concern 2 for free.

 Concern 3: the uselessness of the approach taken by LPPL
 
 
 Argument 3.1: write a new (unrelated/related?) package from scratch
   and give it the same name as the original one.
 
 Argument 3.2: Trademarks and certification marks are tools better suited to
   controlling endorsements of conformance with a standard or set
   of usage practices.
 (http://lists.debian.org/debian-legal/2002/debian-legal-200207/msg00071.html)
 
 Argument 3.3: If the core can be changed in any way without changing it
   directly, then you can break output exactly as well by this
   mechanism as you could by editing it directly.
 (http://lists.debian.org/debian-legal/2002/debian-legal-200207/msg00190.html)
 
 Argument 3.4: why have a complex license if you probably never
 legally enforce it?

These are more practical arguments that relate to Clause 1.  If a
particular license meets the DFSG, it isn't a large problem for us if
the license is complex or inconvenient, though we obviously prefer
simple and clear licenses (although note that if we can't decipher the
license, we're likely to mark it as non-free just to cover ourselves). 
However, it is important to recognize that some of your restrictions end
up serving no purpose except disqualifying your license for DFSG
compliance, which (I would think) would motivate you to alter or remove
those restrictions.

 --
 | Block b)
 | Some more comments from mails, you tell me please if they are relevant (for
 | determining LPPL to be DFSG-complient or not) and whether or not you agree
 | with them:
 --
 
 From: Mark Rafn [EMAIL PROTECTED]
 From: Jeff Licquia [EMAIL PROTECTED]
 http://lists.debian.org/debian-legal/2002/debian-legal-200207/msg00162.html
 
   It's gross, and I lose respect for the software author who put the stupid
   requirement in the license, but it doesn't stop me fixing it nor
   distributing the result, so it's free enough for Debian.
 
  I see your point, gross as it is. :-)

For reference, the gross point here is the fact that we have the power
to product independent works that change LaTeX's behavior under even the
most restrictive interpretation of the LPPL.  The only way to prevent
that would be to license LaTeX under a no modification allowed by
anyone under any circumstances license, which would be clearly
non-free.

 --
 | Block d)
 | Finally some snippets from mails or pointers to mails
 | that i thought worth thinking about or
 | commenting on (is isn't the full list probably) ...
 --
 

Re: LaTeX DFSG

2002-07-19 Thread Boris Veytsman
 From: Jeff Licquia [EMAIL PROTECTED]
 Date: 18 Jul 2002 18:30:19 -0500

 
 No, not at all.  I think that your R3 right is the point of contention;
 we do not believe that the draft of the LPPL we've seen confers that
 right.


This is exactly the reason of this discussion. 

I hope that the intention of the LPPL is clear now. As far as I can
see, some people here do not agree with this intention, while the
majority seems to be in favor on it. The question is now in the exact
wording that would express this intention in the form acceptable to
the majority of the Debian community.

 Let's take an example that will likely resonate with typesetters a bit
 more: the euro.  How did you arrange to add the euro symbol to TeX and
 LaTeX?  What would have happened if I would have needed a euro symbol
 before it was added?
 


This is a technical question, so please excuse my rather technical
answer. On the other hand this answer might be instructive in the way
(La)TeX works and why we do not want to change the kernel.

Ok, suppose you want to add a euro symbol to your document. Old
documents do not mention euro, so I can assume we have a new document.

The euro symbol is a lettershape. A collection of lettershapes is
called a font (please do not tell anybody I told you this:
typographers will crucify me for the oversimplification). Now the base
font of your document might either have euro or not. Let us consider
these possibilities.

Suppose that your document uses a font which has euro. To use a font,
LaTeX must read a bunch of text files that provide font descriptions
(.fd files) and font encodings (.def files). Since your font has euro,
then a line in one of these files tells LaTeXL: I have a strange
letter called euro symbol, which can be accessed by the command
\euro. After this LaTeX happily typesets the phrase I can buy this
CD in London for \pounds5, but in Paris it costs \euro10.

Now suppose your base font does NOT have euro. To make this case more
interesting, suppose you use Computer Moder fonts, which have no euro
by licensing reasons: Knuth does not allow anybody to change them, and
he seems to be not interested in their modification himself. Well, you
cannot add euro to CM fonts, but absolutely nothing prevents you to
use an additional font in your document. You can actually make your
own font with just one letter euro and encapsulate all font switching
in a single command. Now the command \euro will mean switch from the
current font to the 'eurofont', typeset euro symbol and switch
back. You *may* do this, but probably you would not want it because
it is already done by Ron McDonnel, the author of eurofont package. As
far as I understand, his program scans the fonts installed on your
system and picks the most proper euro symbol to include in the
documents that use euro-less fonts. So you can just add to your
document \usepackage{eurofont}, and then euro becomes magically
accessible.

You might decide that this run-time patching of CM fonts is not
convenient. It is probably not a problem for just one symbol, but it
*is* a problem when you need many patches. There are several
solutions. One was employed by the American Mathematical Society (btw,
they are the holders of the TeX trademark). When they found that
Knuthian fonts do not include many symbols that mathematicians need,
they comissioned a font designer to make a collection of these symbols
(and made them freely available to the community -- by the way, you
distribute this collection too). You add these collections by the
command \usepackage{amsfonts} (the story is even more interesting,
but I want to keep this short). Another was chosen by European users,
who needed better kerning, diacritics and additional letters. For this
purpose Jorg Knappen completely redesigned CM fonts and produced
European Computer Modern (EC) fonts, also distributed by Debian. These
fonts are used by many non-US TeX users. 

Well, as you see, this community has its own way of modifying
programs. We have traditions that predate GPL, Linux and even C. We
are quite happy with the way the things are.

-- 
Good luck

-Boris

jim Lemme make sure I'm not wasting time here... bcwhite will remove
  pkgs that havent been fixed that have outstanding bugs of severity
  important.  True or false?
JHM jim: important or higher.  True.
jim Then we're about to lose ftp.debian.org and dpkg :)
* netgod will miss dpkg -- it was occasionally useful
Joey We still have rpm
-- Seen on #Debian


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



Re: forwarded message from Jeff Licquia

2002-07-19 Thread Boris Veytsman
 Date: Fri, 19 Jul 2002 14:45:35 +1200
 From: Nick Phillips [EMAIL PROTECTED]

 
 Under the LPPL we are not allowed to fix the engine either; we have to wait
 for D. E. Knuth to do it. Which I'm sure he would do, unless he happened
 to have been run over by a bus that morning (unlikely, as he claims to be
 sitting at home working on Volume 4 of The Art of Computer Programming
 most of the time, but...). In which case we would have a nightmare time
 trying to migrate all our LaTeX users from LaTeX to not-LaTeX, which would
 be identical to LaTeX but for the fact that it used not-quite-TeX instead
 of TeX...


I think there is a misunderstanding here. You seem to think that at
the run time LaTeX makes the choice to use TeX for its engine. The
situation is exactly opposite: the engine makes the choice of using a
macro package. When the executable tex is called with argv[0] equal
to latex, it loads the file latex.fmt, which is LaTeX. The
consequence is, *any* engine that can grok latex.fmt, can use
LaTeX. Actually, there ARE non-TeX programs that use LaTeX as macro
packages. The most popular among such programs is pdftex. I use pdftex
almost as often as tex. When pdftex is called as pdflatex, it loads
latex.fmt and processes the documents almost like TeX. The only
difference is, it produces PDF output instead of DVI. The authors of
pdftex took care to make the printed output of their program in the
compatibility mode to be exactly like the output of TeX, but they
were not compelled to do this by the license.

It does not mean LaTeX is completely agnostic about the engine: the
engine can a flag (pdftex sets \pdfoutput) which can be read from
LaTeX and used to do things that are possible with pdftex but
impossible with Knuthian TeX. Nevertheless you do NOT need to change
LaTeX kernel to change the engine.



 
 If on the other hand the LaTeX license allowed us to do whatever we like,
 so long as anything that's called LaTeX produces identical output (documents)
 to unmodified LaTeX for all valid input then we could butcher LaTeX to use
 a not-quite-TeX that had the bug fixed, and still produced identical output.
 

This is impossible due to a nice rendition of Goedel
theorem. Basically it says that if your language is complex enough
(well, if you can program a Turing machine in your language), then you
cannot make a program that can in finite time automatically prove or
disprove that a pair of programs gives identical results for all valid
inputs. Since TeX the language is Turing-complete (note that TeX the
engine is not, because it has limitation for the number of registers),
you never can prove that two LaTeXs give identical output for all
valid inputs.

-- 
Good luck

-Boris

What makes us so bitter against people who outwit us is that they think
themselves cleverer than we are.


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



Re: forwarded message from Jeff Licquia

2002-07-19 Thread Boris Veytsman
 Date: Fri, 19 Jul 2002 16:38:03 -0400
 From: Boris Veytsman [EMAIL PROTECTED]

 LaTeX. Actually, there ARE non-TeX programs that use LaTeX as macro
 packages. The most popular among such programs is pdftex. I use pdftex
 almost as often as tex. When pdftex is called as pdflatex, it loads
 latex.fmt and processes the documents almost like TeX. The only


Sorry about this, but I just understood that this is not exactly
so. pdflatex loads pdflatex.fmt, which is made from latex.ltx in the
way latex.fmt is made from latex.ltx. Please read latex.ltx instead
of latex.fmt. 

Actually latex.fmt is a binary form of latex.ltx, and the format is
different for tex and pdftex.

Again, sorry for this unintentional lie.

-- 
Good luck

-Boris

The trouble with being punctual is that people think you have nothing more
important to do.


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



Re: Question(s) for clarifications with respect to the LPPL discussion

2002-07-19 Thread Frank Mittelbach
Jeff Licquia writes:

  Thanks for the effort.  I generally agree with the points made, both
  that they cover the issue well and that I concur with their analysis,
  with the exceptions I note below.

thanks for your comments  (same to Henning)

I'm not going to comment on them yet, but instead hope for further reactions
by others as well

frank


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



Re: LaTeX DFSG

2002-07-19 Thread Jeff Licquia
On Fri, 2002-07-19 at 14:34, Boris Veytsman wrote:
  From: Jeff Licquia [EMAIL PROTECTED]
  Date: 18 Jul 2002 18:30:19 -0500
  Let's take an example that will likely resonate with typesetters a bit
  more: the euro.  How did you arrange to add the euro symbol to TeX and
  LaTeX?  What would have happened if I would have needed a euro symbol
  before it was added?
 
 This is a technical question, so please excuse my rather technical
 answer. On the other hand this answer might be instructive in the way
 (La)TeX works and why we do not want to change the kernel.

[discussion of process to add euro, math symbols, etc. removed]

 Well, as you see, this community has its own way of modifying
 programs. We have traditions that predate GPL, Linux and even C. We
 are quite happy with the way the things are.

I think this is the main issue.  You have a tradition for allowing
modification that is different from what we're used to.  The question is
whether this tradition meets the qualifications of DFSG 3 and 4.

Rather than make reference to patch files and other things that may
mean different things to different people, it may be good to talk about
what constitutes a modifiable program.  Here's one description:

 - A program is modifiable if a user has the legal right to change the
program's behavior in an arbitrary way without excessive inconvenience
or requirements.

Now, the sticky word here is excessive.  In one respect, LD_PRELOAD
can be used to change any program's behavior no matter the license, but
I think we'd agree that this would be an excessive requirement.

Taken at a stupid level, your requirement for filename changes also
seems excessive.  At face value, the cascading change requirements
(change references in this other file, which is also a change requiring
rename, which means more references to the new file have to be changed,
etc.) would make it nearly impossible to practically make changes to
LaTeX.  Further, it's not clear whether further modifications beyond the
first set require yet more name changes, for reasons I've discussed
elsewhere.

The data point that we were missing is that you consider it OK to get
around the absolute requirement to change filenames if the result isn't
called LaTeX, and that you even have a documented procedure for doing
this.  This significantly lowers the modification barrier to the point
where, it seems, most Debian people don't consider the requirement to be
excessive.

So, the issue at hand seems to be to get the above data point propagated
into the license in a clear and unambiguous way.


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



Re: forwarded message from Jeff Licquia

2002-07-19 Thread Jeff Licquia
On Fri, 2002-07-19 at 15:38, Boris Veytsman wrote:
  Date: Fri, 19 Jul 2002 14:45:35 +1200
  From: Nick Phillips [EMAIL PROTECTED]
 
  If on the other hand the LaTeX license allowed us to do whatever we like,
  so long as anything that's called LaTeX produces identical output 
  (documents)
  to unmodified LaTeX for all valid input then we could butcher LaTeX to use
  a not-quite-TeX that had the bug fixed, and still produced identical output.
 
 This is impossible due to a nice rendition of Goedel
 theorem. Basically it says that if your language is complex enough
 (well, if you can program a Turing machine in your language), then you
 cannot make a program that can in finite time automatically prove or
 disprove that a pair of programs gives identical results for all valid
 inputs. Since TeX the language is Turing-complete (note that TeX the
 engine is not, because it has limitation for the number of registers),
 you never can prove that two LaTeXs give identical output for all
 valid inputs.

From a licensing perspective, this isn't a problem.  We can, for
example, reference a test suite in the license (doesn't TeX do this?),
or perhaps require that any demonstrated inconsistency must be fixed. 
This transfers the onus onto the person claiming a license violation;
that person must provide definitive proof of an inconsistency not
allowed by the license.

You do have to be careful about your wording, however, so that the
intent is carefully spelled out.  For example, you might want to allow
bug fixes without renaming; in that case, you'd want to define bug fix
so the inconsistency of a fix isn't used as evidence of a license
violation.


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



Re: LaTeX DFSG

2002-07-19 Thread Frank Mittelbach
Jeff Licquia writes:
   Well, as you see, this community has its own way of modifying
   programs. We have traditions that predate GPL, Linux and even C. We
   are quite happy with the way the things are.
  
  I think this is the main issue.  You have a tradition for allowing
  modification that is different from what we're used to.  The question is
  whether this tradition meets the qualifications of DFSG 3 and 4.

nicely put, that is the core issue.

  Rather than make reference to patch files and other things that may
  mean different things to different people, it may be good to talk about
  what constitutes a modifiable program.  Here's one description:
  
   - A program is modifiable if a user has the legal right to change the
  program's behavior in an arbitrary way without excessive inconvenience
  or requirements.

hope this is a description everybody can agree with (including that it
hopefully meets DSFG 3+4)

  Now, the sticky word here is excessive.  In one respect, LD_PRELOAD
  can be used to change any program's behavior no matter the license, but
  I think we'd agree that this would be an excessive requirement.
  
  Taken at a stupid level, your requirement for filename changes also
  seems excessive.  At face value, the cascading change requirements
  (change references in this other file, which is also a change requiring
  rename, which means more references to the new file have to be changed,
  etc.) would make it nearly impossible to practically make changes to
  LaTeX.  Further, it's not clear whether further modifications beyond the
  first set require yet more name changes, for reasons I've discussed
  elsewhere.

I hope that i will be able to proof that successfully to you. I think we now
also all understand that the current LPPL license has a number of deficienies
which makes it difficult to understand if you are coming from a background not
rooted in the tradition of TeX/LaTeX.

by a) explaining this tradition better to you and b) (with your help) drafting
a different wording of LPPL I think we should be able to resolve this.

again I would urge everybody to have a look at my clarification questions in

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

and answer my questions concerning the four blocks in there (perhaps adding
the above definition to block b)

thanks
frank


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



Re: forwarded message from Jeff Licquia

2002-07-19 Thread Boris Veytsman
 Date: Fri, 19 Jul 2002 01:24:24 -0500
 From: Chris Lawrence [EMAIL PROTECTED]

 
 How does the LPPL actually prevent a distributor from FUBARing their
 distribution of LaTeX?  The fact is people regularly ignore licenses,
 copyrights, patents and trademarks (if this weren't the case, there'd
 be almost no GIFs or MP3s in the world).
 
 To put it another way: If you don't trust people to do the right
 thing, no license will help you.


This argument is too sweeping to be taken seriously: if licenses are
useless, then you must forget not only about LPPL, but also about GPL,
LGPL, Artistic license, etc. trash DFSG, close this list and urge its
subscribers to do something useful with their lives instead. While
this decision might have merits, I suspect it is too strong.


 I *do* use LaTeX in my every day work.  I also recognize that someone
 might want to make a derived work of LaTeX (say MyLaTeX) without
 having to engage in unreasonable amounts of bookkeeping or bizarre
 filename hacks (i.e. without recoding the parser to add my to the
 beginning of every package that is \usepackage{}d since they had to
 rename every single file in the distribution that they touched) and
 without breaking compatibility with their own source files (i.e. so
 they can run mylatex blah.tex where blah.tex is valid input to latex).
 
 In fact, pdflatex depends on this very ability, but since the LPPL
 only trusts the anointed of the LaTeX3 Project to do this in a trivial
 manner, I couldn't make a tifflatex or pcllatex without going through
 silly bureaucracy (renaming files, hacking macros to search for my
 modified versions of .cls and .sty files with messed up names, etc.)
 that Frank doesn't have to engage in.



This is completely wrong. Pdflatex does NOT depend on this
ability. The authors of pdftex (Han The Thanh, Petr Sojka, and Jiri
Zlatuska) are not members of LaTeX3 projects and have no special
rights or privileges. No members of LaTeX3 team I know participated in
pdftex project. Pdflatex does not change any single file in the LaTeX
tree. 

As far as I know there are two files in the common LaTeX distribution
that provide additional functionality for pdftex: pdf drivers in
graphics package and hyperref package. They were added by the authors
of these packages; under LPPL anybody can *add* a new file to provide
additional functionality to the system

There is absolutely no need for you to change LaTeX kernel to make a
tifflatex -- in the same way Han The Thanh did not need to change it
to make pdflatex.

If you *knew* how LaTeX works, you might give another example instead,
when there was need to change many LaTeX files: the hyperref
package. Hyperref provides additional functionality for LaTeX, but it
needed to rewrite a lot of things to do so. Nevertheless it does not
touch any files: it dynamically patches the kernel at run-time. 

-- 
Good luck

-Boris

I don't know who my grandfather was; I am much more concerned to know
what his grandson will be.
-- Abraham Lincoln


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



Re: forwarded message from Jeff Licquia

2002-07-19 Thread Richard Braakman
On Fri, Jul 19, 2002 at 04:38:03PM -0400, Boris Veytsman wrote:
 This is impossible due to a nice rendition of Goedel
 theorem. Basically it says that if your language is complex enough
 (well, if you can program a Turing machine in your language), then you
 cannot make a program that can in finite time automatically prove or
 disprove that a pair of programs gives identical results for all valid
 inputs. Since TeX the language is Turing-complete (note that TeX the
 engine is not, because it has limitation for the number of registers),
 you never can prove that two LaTeXs give identical output for all
 valid inputs.

Yes you can :)  You can't write a program that can prove this in the
general case, but if you're creating a new LaTeX then you're not dealing
with the general case.  It's quite easy to design the changes in such a
way that you can prove that the output will be identical.

Richard Braakman


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



Re: forwarded message from Jeff Licquia

2002-07-19 Thread Boris Veytsman
 Date: Fri, 19 Jul 2002 12:19:07 -0500
 From: Branden Robinson [EMAIL PROTECTED]

 
 1) Names and titles are not copyrightable.  If you want intellectual
 property protection in a name, you need a trade mark, service mark,
 certification mark, or similar instrument.
 

I afraid this is not -- so at least for some jurisdictions. I am not a
lawyer, but it happened that I have been closely watching a lawsuit in
Russia, where the plaintiff alleged that title is an important part of
a copyrighted work. In other word, the theory was that if I make a
movie Moby Dick completely unrelated to the famous novel, I am
probably fine, but if I publish a *novel* Moby Dick, I might violate
copyright, especially if my novel has important parallels.


 2) Free Software copyright licenses should not attempt to achieve via
 their license what would not ordinarily be achievable through copyright


I can only quote GPL here:

  5. You are not required to accept this License, since you have
not signed it.  However, nothing else grants you permission to
modify or distribute the Program or its derivative works.  These
actions are prohibited by law if you do not accept this License.
Therefore, by modifying or distributing the Program (or any work
based on the Program), you indicate your acceptance of this
License to do so, and all its terms and conditions for copying,
distributing or modifying the Program or works based on it.

Modification and redistribution is expressly forbidden by the
copyright law unless specifically granted. If the license grants this
right under certain conditions, these conditions apply. 



 law.  I do not know whether a court would uphold a copyright license
 that attempted to enforce a poor man's trademark by conditionally
 extending the license to a party contingent on that party's not using a
 particular name or title in a particular way.  I do believe, however,
 that it is illegitimate for a copyright license to attempt to this, and
 it is especially unacceptable for a Free Software license to do this.
 I feel this way for the same reason that I believe that a DFSG-free
 license should not be contingent on the licensee obeying the laws of
 some jurisdiction, praying to Mecca five times daily, or refraining from
 kicking their dog.  A licensee may nor may not be in sympathy with any
 or all of these sentiments, but the simple fact is that they are outside
 the scope of copyright and should remain so.  A work that is Free
 Software must be free to everyone who does not infringe its copyright by
 engaging in unauthorized distribution.  A work that is Free Software
 should not discriminate against those who engage in insider trading,
 smoke marijuana, infringe the copyright on Microsoft Windows, infringe
 the copyright on some other work of Free Software, abuse animals, eat
 meat, chew tobacco, chain themselves to trees, or change lanes without
 signaling.
 


GPL discriminates agains those, who want to take somebody else's
programs from the free software world. Some people think this is
illegitimate and cannot be achieved through copyright laws. I along
with Stallman think this reasoning is wrong. From the legal standpoint
an author can put virtually any conditions on redistribution. If some
work can be redistributed only by Christian Scientists, it will be
so. 

A moral standpoint is different. Certain restrictions, while legally
permissible, might be inconsistent with the understanding of the word
free -- we are speaking on free licenses here. Well, your
understanding of this word is different from mine. This is fine.

-- 
Good luck

-Boris

A good marriage would be between a blind wife and deaf husband.
-- Michel de Montaigne


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



Re: LaTeX DFSG

2002-07-19 Thread Frank Mittelbach
Mark Rafn writes:
Let's take an example that will likely resonate with typesetters a bit
more: the euro.  How did you arrange to add the euro symbol to TeX and
LaTeX?  What would have happened if I would have needed a euro symbol
before it was added?
  
  On Fri, 19 Jul 2002, Boris Veytsman wrote:
  
   This is a technical question, so please excuse my rather technical
   answer. On the other hand this answer might be instructive in the way
   (La)TeX works and why we do not want to change the kernel.
  
  It was indeed instructive to me.  But it was based on a premise that I 
  didn't read in Jeff's message.  
  
   Ok, suppose you want to add a euro symbol to your document. Old
   documents do not mention euro, so I can assume we have a new document.

I think that this premise was a resonable assumption. 

  I don't mean to waste your time, but I think it would be equally 
  instructive if you didn't make this assumption.  What is required for me 
  to distribute a ltx-eurodollar such that any document that prints 
  dollar signs (in CM) in latex instead prints euro signs when the user 
  runs ltx-euroinsteadofdollar?

that is an interesting question as well, but i think it has nothing to do with
Jeff's. it is in fact something we probably shouldn't answer as it sounds very 
much
like we should tell you how to do something illegal :-)



having waited a while for someone to answer, here is my solution:

 Apply the LPPL rules (what else? :-):

technically what you want (i think) is that \$ (that prints a dollar sign as
long as you process with LaTeX (and haven't loaded a package to change LaTeX's
behaviour in a LPPL-complient way) is now printing a euro sign, right?

so somehow you would need to have

\usepackage{eurofont}  % or something else to get \euro (sign)
\renewcommand\${\euro}

but you don't want to add this to your document, instead you want this
automatically done by your processor called ltx-euroinsteadofdollar.

so ltx-euroinsteadofdollar is (for example) a modified latex kernel (and no
longer latex).  In other words what you would want is to get that into
latex.ltx instead of the \$ definition there (kernel definitions would look a
little different---but i'm not here to teach you LaTeX., definitely not at 1:45
in the morning :-).

Thus we come to the LPPL-draft section

 CONDITIONS ON DISTRIBUTION AND MODIFICATION
 ===

as we assume that you are not the Maintainer of The Program (since that is me
and David, et al at the moment) that section gives you seven conditions to
meet 
[hmmm 8 i think in the draft that went to this list ... so let's use that one]

1) -- is gone (thanks to Walter) as well as the section it refers to

2) -- that doesn't apply to latex.ltx (and by now that section does nothing
  other than taking away any renaming restrictions for .cfg and .fd files)

3) -- okay so let's call the new kernel file
euroinsteadofdollar.ltx

4) -- okay, so please add some comments on top as necessary

5) -- that's a little tricky with that file as it is a boot-trapping TeX file
  in essentially every other tex/latex file the identification stuff is on
  top but when a kernel is made Tex starts out stupid and doesn't even
  know which chars mean what, so you have to teach it like a baby.
  As result the indentification strings are a little scattered around.
  (guess we should put some comment on top how to find them)
  to be really correct the right thing is probably to search the file for
  references of the string LaTeX and replace them as needed.

6) -- This is mostly likely already done since we updated the comments in 4)

7) -- Assuming the understanding we have of this section (granted that the
  wording is wrong or at least difficult to understand) you now have to
  choose a license for your new file. No idea what you would want here (i
  would again use LPPL but choose one, say, GPL, and add the clause

   This file is distributed under GPL with the restriction that you are
   not allowed to distribute it or modified versions of it under its
   original name latex.ltx.

  [now don't shoot me if GPL doesn't allow adding clauses to it, if so
  spell GPL out, or use a different license, you may even use a completely
  unfree one for your work]

8) -- Not being stupid: if you distribute euroinsteadofdollar.ltx you choose
  option (B) ie tell people where to get latex.ltx from (or more exactly
  the whole of core latex as that is The Program in that case).

s. that's the legal side (a few minutes, especially in the kernel case if
you never did it before, but most definitely less than what i spend writing
this message up to here)

now what is left is actually changing the file in earnst, ie go near the end
and add

\RequirePackage{eurofont}
\renewcommand\${\euro}

or whatever you have chosen to use for the euro.

Having done that you finally have to 

Re: LaTeX DFSG

2002-07-19 Thread Boris Veytsman

 Date: Sat, 20 Jul 2002 02:07:05 +0200
 From: Frank Mittelbach [EMAIL PROTECTED]

 
 5) -- that's a little tricky with that file as it is a boot-trapping TeX file
   in essentially every other tex/latex file the identification stuff is on
   top but when a kernel is made Tex starts out stupid and doesn't even
   know which chars mean what, so you have to teach it like a baby.
   As result the indentification strings are a little scattered around.
   (guess we should put some comment on top how to find them)
   to be really correct the right thing is probably to search the file for
   references of the string LaTeX and replace them as needed.


I just tested this on my machine. The simplest way to change the
banner is to change the lines


-
\everyjob{\typeout{\fmtname
 \space\fmtversion}}
\immediate\write16{\fmtname
 \space\fmtversion}

-

to the lines

-
\def\realfmtname{euroinsteadofdollar}
\everyjob{\typeout{\realfmtname
 \space\fmtversion}}
\immediate\write16{\realfmtname
 \space\fmtversion}
--

You see, you cannot just change \fmtname to euroinsteadofdollar,
because many LaTeX packages ask the format name and refuse to work
under wrong formats (this is not inteneded to prevent modification,
but rather to prevent the packages to be used with the wrong version
of LaTeX). So you need \fmtname to fool these programs and
\realfmtname to be honest with people (LPPL does not forbid you to
fool the computer programs, does it?)

So here is the diff file between latex.ltx and euroinsteadofdollar.ltx


508c508
 \edef\fmtversion{2002/07/19}
---
 \edef\fmtversion{2000/06/01}
533,534c533
 \def\realfmtname{Euroinsteadofdollar}
 \everyjob{\typeout{\realfmtname
---
 \everyjob{\typeout{\fmtname
536c535
 \immediate\write16{\realfmtname
---
 \immediate\write16{\fmtname
7916,7917d7914
 \input{eurofont.sty}
 \def\${\euro}
---

I needed also new ltpatch.ltx with the lines

-
[EMAIL PROTECTED]/07/19} % This patch will not work with
% any other release.

[EMAIL PROTECTED]


--

Then the new format indeed changed all dollars to euros. 

Here is the log file which proves I am not in violation of LPPL:

-

This is TeX, Version 3.14159 (Web2C 7.3.7) (format=euroinsteadofdollar 2002.7.19
)  19 JUL 2002 20:32
**tmp
(./tmp.tex
Euroinsteadofdollar 2002/07/19
Babel v3.7h and hyphenation patterns for american, french, german, ngerman, r
ussian, nohyphenation, loaded.
(/usr/local/share/texmf/tex/latex/base/article.cls
Document Class: article 2000/05/19 v1.4b Standard LaTeX document class
(/usr/local/share/texmf/tex/latex/base/size10.clo
File: size10.clo 2000/05/19 v1.4b Standard LaTeX file (size option)
)
---

Note that article.cls here is standard, and announces itself as such. 

-- 
Good luck

-Boris

Visit beautiful Wisconsin Dells.


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