Pledge of Allegiance. Please forward
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
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
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
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
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
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
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
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]
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
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)
-
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
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
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
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]
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
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
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
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
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
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
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
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
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
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
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
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
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
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]
