Re: forwarded message from Jeff Licquia
> Now, I realize that you don't say this in so many words. But all of the
> restrictions on filenames and the business about Current Maintainers
> make very little sense otherwise. Certainly those clauses in the
> license don't give people a sense of cooperation and trust.
>
> It might be instructive to see if that's really the feeling among people
> associated with LaTeX. If not, then perhaps you could be a little less
> paranoid about changes to LaTeX that are well-documented.
If you are really interested in the views of LaTeX users,
why not ask on comp.text.tex ?
I'm quite certain you will find that 99% of LaTeX users support Frank 100%,
and do NOT want Debian or anyone else distributing "improved" versions of
article.cls ,
even if they correct what their authors consider to be "bugs".
On a technical point, I would have thought
that any conceivable change to article.cls
could be encompassed in a package (.sty file),
and you could simply tell people that you think article class
is greatly improved if you usepackage{debianmods} or whatever.
I've used TeX and Linux since they each came out,
and I have no sense that one is "free-er" than the other.
I don't even see the distinction you make regarding Current Maintainers.
Could I distribute a modified version of Linux without Torvald's permission?
I hope not.
--
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: forwarded message from Jeff Licquia
On Tue, Jul 16, 2002 at 09:48:29AM +0100, Timothy Murphy wrote: > Could I distribute a modified version of Linux without Torvald's permission? Yes.[1] > I hope not. Thanks for this insight into the LaTeX community's notion of "freedom"; I was honestly unaware of this perspective. [1] Alternatively, "no, but you already have it, because it's licensed under the GNU GPL, version 2." Also note that there are many contributors to the Linux kernel aside from Linus Torvalds, so if permission to distribute modified copies were not already granted by the GNU GPL, a person would need to ask permission from a great many people before doing so. -- G. Branden Robinson| Q: How does a Unix guru have sex? Debian GNU/Linux | A: unzip;strip;touch;finger;mount; [EMAIL PROTECTED] |fsck;more;yes;fsck;fsck;fsck; http://people.debian.org/~branden/ |umount;sleep pgp6Skbi94aXA.pgp Description: PGP signature
Re: forwarded message from Jeff Licquia
Timothy Murphy <[EMAIL PROTECTED]> wrote: > I've used TeX and Linux since they each came out, > and I have no sense that one is "free-er" than the other. > I don't even see the distinction you make regarding Current Maintainers. > Could I distribute a modified version of Linux without Torvald's permission? > I hope not. Absolutely. Debian distributes modified kernels, and I know that we didn't ask for permission from Linus or the thousands of other copyright holders. In fact, some of the modifications were made against the express wish of some of the copyright holders. Regards, Walter Landry [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: forwarded message from Jeff Licquia
On Tuesday 16 Jul 2002 9:48 am, Timothy Murphy wrote:
> On a technical point, I would have thought
> that any conceivable change to article.cls
> could be encompassed in a package (.sty file),
> and you could simply tell people that you think article class
> is greatly improved if you usepackage{debianmods} or whatever.
The fact that something is a bad idea for technical reasons is no reason for
it to be made legally impossible. (Insert any number of Microsoft jokes here)
Yes, any *reasonable* person would find this license acceptable in most
cases, but please spare a thought for those that are perhaps less reasonable
- for example if someone wanted to rewrite LaTeX to typeset Klingon (it may
already be done) and this required such a modification - my point being that
there are surely circumstances where one might wish to alter this file,
however outlandish or "unlikely" they may sound.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: forwarded message from Jeff Licquia
On Tuesday 16 Jul 2002 9:48 am, Timothy Murphy wrote:
> On a technical point, I would have thought
> that any conceivable change to article.cls
> could be encompassed in a package (.sty file),
> and you could simply tell people that you think article class
> is greatly improved if you usepackage{debianmods} or whatever.
The fact that something is a bad idea for technical reasons is no reason for
it to be made legally impossible. (Insert any number of Microsoft jokes here)
Yes, any *reasonable* person would find this license acceptable in most
cases, but please spare a thought for those that are perhaps less reasonable
- for example if someone wanted to rewrite LaTeX to typeset Klingon (it may
already be done) and this required such a modification - my point being that
there are surely circumstances where one might wish to alter this file,
however outlandish or "unlikely" they may sound.
One of the features of bad technical ideas is that they usually don't stay
around very long. (Insert further MS jokes)
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: forwarded message from Jeff Licquia
On Tue, Jul 16, 2002 at 01:51:05PM -0700, Walter Landry wrote: > Absolutely. Debian distributes modified kernels, and I know that we > didn't ask for permission from Linus or the thousands of other > copyright holders. In fact, some of the modifications were made > against the express wish of some of the copyright holders. I hasten to add that our modifications are legally permitted under the terms of the copyright license, which is the GNU GPL. Again, we see a distinction between "that which the copyright holder permits" and "that which the copyright holder thinks is a good idea". -- G. Branden Robinson| Debian GNU/Linux | If encryption is outlawed, only [EMAIL PROTECTED] | outlaws will @goH7Ok=http://people.debian.org/~branden/ | pgpAep4l9puEV.pgp Description: PGP signature
Re: forwarded message from Jeff Licquia
On Tue, Jul 16, 2002 at 03:45:23PM -0500, Branden Robinson wrote: > Thanks for this insight into the LaTeX community's notion of "freedom"; > I was honestly unaware of this perspective. I am not "the LaTeX community". I am just a LaTeX user. Incidentally, the only thing I said about freedom was that from my perspective TeX seems just as "free" as Linux. That doesn't seem an earth-shaking pronouncement to me. > Also note that there are many > contributors to the Linux kernel aside from Linus Torvalds But they are all vetted by Torvalds. There are also several contributors to the LaTeX "kernel" -- not so many, certainly, but that is because LaTeX is a much narrower project. (It doesn't have to have a new module every time some tinpot company brings out a new USB device.) -- 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: forwarded message from Jeff Licquia
On Tue, Jul 16, 2002 at 01:51:05PM -0700, Walter Landry wrote: > > Could I distribute a modified version of Linux without Torvald's permission? > > I hope not. > Absolutely. Debian distributes modified kernels, and I know that we > didn't ask for permission from Linus or the thousands of other > copyright holders. In fact, some of the modifications were made > against the express wish of some of the copyright holders. That seems to me a very good reason for not using Debian kernels. In any case, does it matter what "modified kernels" Debian distributes? Surely anyone with a serious interest in Linux will get the latest kernel from www.kernel.org and compile that. I do much the same with LaTeX. When I get a new Linux distribution, I look at the TeX system, and if it seems odd in any way I get the official teTeX sources from one of the CTANs and compile those. Life is too short to waste time on "personal versions" of software. We went through that with LaTeX-2.09, of which there were a dozen different versions (probably one of them was Debian's) which just caused a lot of pain. Incidentally, I am not "the LaTeX community". I am just a LaTeX user. -- 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: forwarded message from Jeff Licquia
On Wed, Jul 17, 2002 at 02:24:16AM +0100, Timothy Murphy wrote: > On Tue, Jul 16, 2002 at 01:51:05PM -0700, Walter Landry wrote: > > > Could I distribute a modified version of Linux without Torvald's > > > permission? > > > I hope not. > > Absolutely. Debian distributes modified kernels, and I know that we > > didn't ask for permission from Linus or the thousands of other > > copyright holders. In fact, some of the modifications were made > > against the express wish of some of the copyright holders. > That seems to me a very good reason for not using Debian kernels. > In any case, does it matter what "modified kernels" Debian distributes? > Surely anyone with a serious interest in Linux > will get the latest kernel from www.kernel.org and compile that. > Life is too short to waste time > on "personal versions" of software. Sadly, you seem to have missed the point of Free Software altogether, which can be stated simply as: preventing anyone from having exclusive control of the software so that everyone can benefit. If you don't value the freedom that permits Debian to ship changed versions of software, that's your prerogative; but that happens to be the one thing you'll get all Debian developers to agree on. The freedom to create these "personal versions" of software is the only protection that our thousands or millions of users worldwide have against software authors who are unresponsive, missing, or antagonistic. It is our insurance policy that we will be free to continue to do what we believe is in the best interest of our users, even when upstream disagrees. If the Latex developers don't believe this is important enough that they will choose a license that complies with the Debian Free Software Guidelines, that's once again their right as copyright holders, but it definitely makes it incompatible with Debian's stated goals. Steve Langasek postmodern programmer pgp5BYujL7Xlr.pgp Description: PGP signature
Re: forwarded message from Jeff Licquia
On Wed, Jul 17, 2002 at 02:24:16AM +0100, Timothy Murphy wrote: > On Tue, Jul 16, 2002 at 01:51:05PM -0700, Walter Landry wrote: > > > Could I distribute a modified version of Linux without Torvald's > > > permission? I hope not. > > > Absolutely. Debian distributes modified kernels, and I know that we > > didn't ask for permission from Linus or the thousands of other > > copyright holders. In fact, some of the modifications were made > > against the express wish of some of the copyright holders. > > That seems to me a very good reason for not using Debian kernels. In > any case, does it matter what "modified kernels" Debian distributes? > Surely anyone with a serious interest in Linux will get the latest > kernel from www.kernel.org and compile that. It seems to me that being able to distribute modified kernels is an amazing reason for using Debian kernels. If you track the linux-kernel mailing list; you will see an apalling disregard for non-i386 architectures; which causes Linus's kernel to FAIL TO WORK. Which is one of the reasons the non-i386 kernel maintainers have their own trees; and why the Debian Project has its own modifications. Now, I do not say that the LaTeX project has such a blatant disregard for your users. In fact, it seems to me that the LaTeX project's desire for conformity across all LaTeX installations is solely based on consideration for users' needs. However, the Debian community recognises that not all people are perfect, and that modifications may have to be made. Since the Debian Project also treats its users as one of our highest priorities, the Project would consider it a grave decision (not to be done lightly) to break output compatibility and interfaces with most other LaTeX installations in the world. You must understand, though, for the benefit of our users, that Debian must be able to reserve the right to change base files. If there were a security exploit in LaTeX, we would consider it more important to fix that problem; then to remain compatible with all other LaTeX installations. Of course, a malicious document that could take over a system through LaTeX when typeset would not work identically with the Debian version, even though it would work for "official" installations; but most users would see this as a feature, and not a bug. Simon -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: forwarded message from Jeff Licquia
On Wed, Jul 17, 2002 at 02:35:48AM +0100, Timothy Murphy wrote: > But they are all vetted by Torvalds. Actually, no. There are at least four versions of the Linux kernel in active development: Linus's, Alan Cox's, David Jones's, and Marcelo Tosatti's. This doesn't even count the versions of the kernel maintained by various Linux distributors. You seem at least as ignorant of Linux kernel development as you accuse Debian developers of being with respect to TeX. Here are some useful resources: http://kt.zork.net/kernel-traffic/kt20020715_175_print.html http://lwn.net/Articles/4154/ -- G. Branden Robinson|The basic test of freedom is Debian GNU/Linux |perhaps less in what we are free to [EMAIL PROTECTED] |do than in what we are free not to http://people.debian.org/~branden/ |do. -- Eric Hoffer pgp23rxlHzOUw.pgp Description: PGP signature
Re: forwarded message from Jeff Licquia
> Date: Tue, 16 Jul 2002 22:46:53 -0500 > From: Branden Robinson <[EMAIL PROTECTED]> > You seem at least as ignorant of Linux kernel development as you accuse > Debian developers of being with respect to TeX. > I am afraid the ignorance is truly mutual. I was amused by the suggestion that a LaTeX macro might cause a security problem and thus need a fix by Debian team. This is about as possible as a security problem from the Bible text in bible-kjv-text. By the way I hope Debian developers do NOT reserve the right to change King James Version? -- Good luck -Boris /* * Please skip to the bottom of this file if you ate lunch recently * -- Alan */ -- from Linux kernel pre-2.1.91-1 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: forwarded message from Jeff Licquia
On Tue, Jul 16, 2002 at 11:51:35PM -0400, Boris Veytsman wrote: > I am afraid the ignorance is truly mutual. > > I was amused by the suggestion that a LaTeX macro might cause a > security problem and thus need a fix by Debian team. I'm not the person who made such an assertion; in any event, it is wholly irrelevant to the licensing analysis. > This is about as possible as a security problem from the Bible text in > bible-kjv-text. If the reader used to view the text allocated static buffers, and failed to take into the account the single longest verse in the Bible... But, as I said, this is irrelevant. > By the way I hope Debian developers do NOT reserve the right to change > King James Version? We don't have to. At least in the United States, anyone is free to quote, copy, and modify the text of the King James Bible however they wish. -- G. Branden Robinson|I have a truly elegant proof of the Debian GNU/Linux |above, but it is too long to fit [EMAIL PROTECTED] |into this .signature file. http://people.debian.org/~branden/ | pgprK7bVnOh5W.pgp Description: PGP signature
Re: forwarded message from Jeff Licquia
On Tue, Jul 16, 2002 at 11:51:35PM -0400, Boris Veytsman wrote: > I am afraid the ignorance is truly mutual. > > I was amused by the suggestion that a LaTeX macro might cause a > security problem and thus need a fix by Debian team. This is about as > possible as a security problem from the Bible text in bible-kjv-text. I'm not amused by this suggestion. I'm dead serious. I see that ctan.tug.org, the US mirror where you recommend people get their LaTeX packages is running WU-FTPD. 220 alan.smcvt.edu FTP server (Version wu-2.6.1-0.6x.21) ready. This FTP daemon is known in the security industry as being less than secure.[1] See: http://www.cert.org/advisories/CA-2001-33.html If you recall the latest configure script hijacking of fragroute, dsniff, and fragrouter, you will note that malicious attackers can seize a server and replace the "official" files with modified ones (that don't respect the LPPL.) I can imagine latex.ltx containing a couple extra \openin15=.ssh/identity , \openin15=.gnupg/secring.gpg and \openout15=.shrc commands[2] as put there by someone who has cracked an FTP server. Please don't laugh or scoff at this "remote possibility," just because you guys haven't seen this happen before, doesn't mean it can't happen. Simon [1] Please note that I have no intention of doing any penetration testing on this machine to see if it vulnerable to any attacks. Caveat sysadmin. [2] Warning, I am not a true TeXnician, so my syntax may be rusty/completely wrong. But I know that TeX (and therefore LaTeX) has filesystem access. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: forwarded message from Jeff Licquia
On 2002-07-17 00:44:21 -0400, Simon Law wrote:
> I can imagine latex.ltx containing a couple extra
> \openin15=.ssh/identity , \openin15=.gnupg/secring.gpg and
> \openout15=.shrc commands[2] as put there by someone who has cracked an
This is not possible on a default TeX installation.
http://www.tug.org/web2c/manual/web2c_4.html";>
TeX can write output files, via the \openout primitive; this
opens a security hole vulnerable to Trojan horse attack: an
unwitting user could run a TeX program that overwrites, say,
`~/.rhosts'. (MetaPost has a write primitive with similar
implication). To alleviate this, there is a configuration
variable `openout_any'; by default, this is set to `0', which
disallows writing to any filename beginning with `.' except
`.tex' (for the sake of the LaTeX distribution). If set to `1',
any file can be written. In any case, all \openout filenames are
recorded in the log file, except those opened on the first line
of input, which is processed when the log file has not yet been
opened. (If you as a TeX administrator wish to implement more
stringent rules on \openout, modifying the function openoutnameok
in `web2c/lib/texmfmp.c' is intended to suffice.)
...
`-shell-escape'
Enable the `\write18{shell-command}' feature. This is also
enabled if the environment variable or config file value
`shell_escape' is set to anything non-null that does not start
with `n' or `0'. It is disabled by default to avoid security
problems. When enabled, the shell-command string (which first
undergoes the usual TeX expansions, just as in `\special') is
passed to the command shell (via the C library function
`system'). The output of shell-command is not diverted anywhere,
so it will not appear in the log file. The system call either
happens at `\output' time or right away, according to the absence
or presence of the `\immediate' prefix, as usual for \write. (If
you as a TeX administrator wish to implement more stringent rules
on what can be executed, you will need to modify `tex.ch'.)
Best regards
Martin
--
Martin Schröder, [EMAIL PROTECTED]
ArtCom GmbH, Grazer Straße 8, D-28359 Bremen
Voice +49 421 20419-44 / Fax +49 421 20419-10
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: forwarded message from Jeff Licquia
On 2002-07-16 21:35:23 -0500, Steve Langasek wrote: > control of the software so that everyone can benefit. If you don't > value the freedom that permits Debian to ship changed versions of > software, that's your prerogative; but that happens to be the one thing > you'll get all Debian developers to agree on. The freedom to create > these "personal versions" of software is the only protection that our > thousands or millions of users worldwide have against software authors > who are unresponsive, missing, or antagonistic. It is our insurance > policy that we will be free to continue to do what we believe is in the > best interest of our users, even when upstream disagrees. If the Latex > developers don't believe this is important enough that they will choose > a license that complies with the Debian Free Software Guidelines, that's > once again their right as copyright holders, but it definitely makes it > incompatible with Debian's stated goals. The (La)TeX community has lived nearly 25 years very happily without that freedom; indeed we all remember the one time someone tried to exercise that freedom (he distributed modified versions of the cm fonts). So yes, we value the interchangebilty of our documents higher than the freedom to modify the components which are used by these documents. Best regards Martin -- Martin Schröder, [EMAIL PROTECTED] ArtCom GmbH, Grazer Straße 8, D-28359 Bremen Voice +49 421 20419-44 / Fax +49 421 20419-10 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: forwarded message from Jeff Licquia
On Wed, Jul 17, 2002 at 11:35:02AM +0200, Martin Schröder wrote: > On 2002-07-17 00:44:21 -0400, Simon Law wrote: > > I can imagine latex.ltx containing a couple extra > > \openin15=.ssh/identity , \openin15=.gnupg/secring.gpg and > > \openout15=.shrc commands[2] as put there by someone who has cracked an > > This is not possible on a default TeX installation. Hmm, so dot-files are protected, but other files are not. That still leaves potential security holes. I wouldn't want to have my ~/Mail/debian-devel folder overwritten just because I process a document I receive, for example. Also, there is the possibility of *reading* files that it shouldn't, and embedding them in the output somehow. This might cause me to unknowingly publish a document that has my secret keys hidden in it. Richard Braakman -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: forwarded message from Jeff Licquia
On Tue, Jul 16, 2002 at 11:51:35PM -0400, Boris Veytsman wrote: > By the way I hope Debian developers do NOT reserve the right to change > King James Version? How do you think the world got the Revised Standard Version? The importance of the ability to copy and modify works was present long before the invention of the digital computer. -- John Goerzen <[EMAIL PROTECTED]>GPG: 0x8A1D9A1Fwww.complete.org -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: forwarded message from Jeff Licquia
> Date: Wed, 17 Jul 2002 07:42:23 -0500 > From: John Goerzen <[EMAIL PROTECTED]> > > > By the way I hope Debian developers do NOT reserve the right to change > > King James Version? > > How do you think the world got the Revised Standard Version? The importance > of the ability to copy and modify works was present long before the > invention of the digital computer. > Note that the Revised Standard Version *changed* the name -- it added the word "Revised" to the version identification. This is exactly what the LaTeX community wants. -- Good luck -Boris If there was any justice in the world, "trust" would be a four-letter word. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: forwarded message from Jeff Licquia
The freedom to create these "personal versions" of software is the only protection that our thousands or millions of users worldwide have against software authors who are unresponsive, missing, or antagonistic. It is our insurance policy that we will be free to continue to do what we believe is in the best interest of our users, even when upstream disagrees. If the Latex developers don't believe this is important enough that they will choose a license that complies with the Debian Free Software Guidelines, that's once again their right as copyright holders, but it definitely makes it incompatible with Debian's stated goals. Speaking as a LaTeX developer, and as one of the authors of the LPPL I agree with those aims and would say that LPPL is perfectly compatible with them. I agree that anyone should be free to modify latex in any way and distribute that modification. I just don't agree that they should leave my email address at the top as the place where people should report bugs, and I don't agree that they should call the software by the same name, so as to deliberately trick users who believe they are using one piece of software into using a different piece of software. As a matter of fact we did read the DFSG while drafting the original version 1 of the LPPL. I believed then and still believe now that it is compatible. Nothing in any of the multitude of threads has shown any real bar on LPPL being DFSG compatible. Some minor wording issues that Frank has been addressing, but nothing in principle. What has been clear is that some people at Debian don't like clause 4 and are trying to force licences that do not require that clause. If Debian want to do that that is their right of course, but it is not the current published guidelines. If Debian does change its guidelines and drop clause 4 then clearly LPPL would not meet the new criteria. Neither would the TeX or Computer Modern licences. If Debian wish to distribute its core free Debian distribution witout tex (and presumably without texinfo) again that is their right and there is nothing we in the LaTeX project can do about that as we don't control the Licence on TeX. David _ This message has been checked for all known viruses by Star Internet delivered through the MessageLabs Virus Scanning Service. For further information visit http://www.star.net.uk/stats.asp or alternatively call Star Internet for details on the Virus Scanning Service. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: forwarded message from Jeff Licquia
On Wed, 2002-07-17 at 04:35, Martin Schröder wrote: > On 2002-07-17 00:44:21 -0400, Simon Law wrote: > > I can imagine latex.ltx containing a couple extra > > \openin15=.ssh/identity , \openin15=.gnupg/secring.gpg and > > \openout15=.shrc commands[2] as put there by someone who has cracked an > > This is not possible on a default TeX installation. [quotes about security protections removed] So you agree that LaTeX can be the source of a security hole. Having agreed to that, you can also appreciate our need to fix such holes immediately once discovered - in some cases, without asking permission beforehand. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: forwarded message from Jeff Licquia
On Wed, Jul 17, 2002 at 02:44:19PM +0100, David Carlisle wrote: > Speaking as a LaTeX developer, and as one of the authors of the LPPL I > agree with those aims and would say that LPPL is perfectly compatible > with them. > I agree that anyone should be free to modify latex in any way and > distribute that modification. I just don't agree that they should leave > my email address at the top as the place where people should report > bugs, and I don't agree that they should call the software by the same > name, so as to deliberately trick users who believe they are using one > piece of software into using a different piece of software. > As a matter of fact we did read the DFSG while drafting the original > version 1 of the LPPL. I believed then and still believe now that it is > compatible. Nothing in any of the multitude of threads has shown > any real bar on LPPL being DFSG compatible. Some minor wording issues > that Frank has been addressing, but nothing in principle. > What has been clear is that some people at Debian don't like clause 4 > and are trying to force licences that do not require that clause. > If Debian want to do that that is their right of course, but it is not > the current published guidelines. If Debian does change its guidelines > and drop clause 4 then clearly LPPL would not meet the new criteria. > Neither would the TeX or Computer Modern licences. If Debian wish to > distribute its core free Debian distribution witout tex (and presumably > without texinfo) again that is their right and there is nothing we in > the LaTeX project can do about that as we don't control the Licence on > TeX. Speaking in the abstract, and in light of the fact that TeX macros *as installed on the system* can be considered source code, I believe that the desire to prevent people from using the same name for modified versions of macro files is compatible with the DFSG, possibly even without the benefit of DFSG 4. However, I also don't think that copyright law gives you the protection you're really looking for, because unless you have the legal budget of the Scientologists, a name cannot be protected under copyright law; and therefore, your license has no power over anyone who chooses to implement a macro from scratch and give it the same name as a macro file in your software. The best protection, IMHO (and IANAL) comes from trademarks on the names rather than copyright licenses on your existing macros. On the copyright license front, DFSG 4 reads: Integrity of The Author's Source Code The license may restrict source-code from being distributed in modified form _only_ if the license allows the distribution of "patch files" with the source code for the purpose of modifying the program at build time. The license must explicitly permit distribution of software built from modified source code. The license may require derived works to carry a different name or version number from the original software. (This is a compromise. The Debian group encourages all authors not to restrict any files, source or binary, from being modified.) So, to be DFSG free, the license must permit us to distribute software built from modified source code, and this freedom must even apply to TeX macro files; but the license may require us to use different names for derived works. A modified version of a TeX macro is a derived work, so your license can impose this restriction and still be DFSG-free. Your goals (which seem to differ markedly from the opinions of at least some members of the LaTeX community, judging by this thread) seem consistent with the DFSG. The devil, of course, is in the details of the license text. One would conclude that if your goals are consistent with the DFSG, and the license text is not, that the license doesn't truly reflect your actual goals and would need to be revised for our mutual benefit. Steve Langasek postmodern programmer pgppEOeul0zwh.pgp Description: PGP signature
Re: forwarded message from Jeff Licquia
On 2002-07-17 10:23:56 -0500, Jeff Licquia wrote: > On Wed, 2002-07-17 at 04:35, Martin Schröder wrote: > > On 2002-07-17 00:44:21 -0400, Simon Law wrote: > > > I can imagine latex.ltx containing a couple extra > > > \openin15=.ssh/identity , \openin15=.gnupg/secring.gpg and > > > \openout15=.shrc commands[2] as put there by someone who has cracked an > > > > This is not possible on a default TeX installation. > > [quotes about security protections removed] > > So you agree that LaTeX can be the source of a security hole. Having No. The default installation of teTeX makes it extremly difficult (if not impossible) to open any security holes. If you are really concerned about security in TeX, you could and should enhance the web2c TeX distribution, not LaTeX. Best regards Martin P.S.: Your fear of security holes in LaTeX borders on either ludicrious or paranoid (seen from 25 years of TeX history); it is at best very hypothecial. P.P.S.: The same potential "security problems" are relevant to plain.tex, which everyone except Donald Knuth is forbidden to change. Are you going to stop distributing that? -- Martin Schröder, [EMAIL PROTECTED] ArtCom GmbH, Grazer Straße 8, D-28359 Bremen Voice +49 421 20419-44 / Fax +49 421 20419-10 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: forwarded message from Jeff Licquia
> I also don't think that > copyright law gives you the protection you're really looking for, > because unless you have the legal budget of the Scientologists, a name > cannot be protected under copyright law; and therefore, your license has > no power over anyone who chooses to implement a macro from scratch and > give it the same name as a macro file in your software. True we can't protect against everything but we can protect against some things. In practice preventing people who've modified article.cls calling it article.cls is protection enough. A modified version of a TeX macro is a derived work, so your license can impose this restriction and still be DFSG-free. so what's the problem with the LPPL? ie not "could it be better" that I am sure it could be better. the question is "why does anyone think it is not DFSG compliant". Your goals (which seem to differ markedly from the opinions of at least some members of the LaTeX community, There isn't a latex community in the sense of any organised network. Several latex users have contributed to these threads. However of the people who have posted to this list only Frank Mittelbach and myself are part of the latex project that maintains latex. I wouldn't find it surprising if end users and core developers/maintainers have a slightly different slant on the issues. One would conclude that if your goals are consistent with the DFSG, and the license text is not, that the license doesn't truly reflect your actual goals and would need to be revised for our mutual benefit. __Exactly__ and that is why Frank stated 1001 messages ago that _any_ part of the text of the LPPL in the current revision could be changed if only someone would say where it contravenes DFSG. But the threads haven't in the main been doing that, but rather discussing the virtues (or otherwise) of the desire to force renaming of changed files. If we can all accept the principle that the latex licence will require modified files get renamed, then we can more usefully look at the details of the wordiing. David _ This message has been checked for all known viruses by Star Internet delivered through the MessageLabs Virus Scanning Service. For further information visit http://www.star.net.uk/stats.asp or alternatively call Star Internet for details on the Virus Scanning Service. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: forwarded message from Jeff Licquia
On Wed, 2002-07-17 at 10:34, Martin Schröder wrote: > On 2002-07-17 10:23:56 -0500, Jeff Licquia wrote: > > On Wed, 2002-07-17 at 04:35, Martin Schröder wrote: > > > On 2002-07-17 00:44:21 -0400, Simon Law wrote: > > > > I can imagine latex.ltx containing a couple extra > > > > \openin15=.ssh/identity , \openin15=.gnupg/secring.gpg and > > > > \openout15=.shrc commands[2] as put there by someone who has cracked an > > > > > > This is not possible on a default TeX installation. > > > > [quotes about security protections removed] > > > > So you agree that LaTeX can be the source of a security hole. Having > > No. Then the protections you quoted are not necessary? I'm confused. Why were they added if they weren't needed? > The default installation of teTeX makes it extremly difficult (if > not impossible) to open any security holes. If you are really > concerned about security in TeX, you could and should enhance the > web2c TeX distribution, not LaTeX. Lots of people have made claims that their software is impregnable, and cannot be exploited. Lots of people have been wrong. Several people in this thread have already quoted several possibilities where LaTeX could be the vector of a security problem. If you're going to claim impossibility, then I'm afraid I'm going to have to ask for proof. And if it's not impossible (even if it's just "extremely difficult"), then our concerns for patching any potential holes that come up are valid. > P.S.: Your fear of security holes in LaTeX borders on either > ludicrious or paranoid (seen from 25 years of TeX history); > it is at best very hypothecial. In 1995, security holes in Microsoft operating systems were also hypothetical, even after over 10 years of use. That didn't make the holes any less real when they were found. Microsoft even made some claims way back then that sound awfully similar to the claims you're making now. I feel duty-bound to point out that I don't think TeX or LaTeX are any worse than anything else in this regard; for all I know, they may be better. It's just my contention that they fall under the category of "software produced by humans", and that everything that falls into that category may potentially be a security problem. That's all. > P.P.S.: The same potential "security problems" are relevant to > plain.tex, which everyone except Donald Knuth is > forbidden to change. Are you going to stop distributing > that? That would be a problem, in my opinion. Unfortunately, I'm having trouble verifying the TeX licensing situation, so I can't comment on the status of TeX in Debian. I'll check that file out if I can find it. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: forwarded message from Jeff Licquia
On Wed, Jul 17, 2002 at 10:54:54AM -0500, Jeff Licquia wrote: > That would be a problem, in my opinion. Unfortunately, I'm having > trouble verifying the TeX licensing situation, so I can't comment on the > status of TeX in Debian. I'll check that file out if I can find it. It's in the source of tetex-bin (texk/web2c/tex.web). I've already filed bug#153257 to ask about it. Note that there is a big difference between having to rename a source file, and having to rename a file that is visible to the user and where the filename is part of the interface. However, I don't know if that applies here. I'll wait for some response to the bugreport. Richard Braakman -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: forwarded message from Jeff Licquia
On Wed, 2002-07-17 at 10:32, Steve Langasek wrote:
> On Wed, Jul 17, 2002 at 02:44:19PM +0100, David Carlisle wrote:
>
> > I agree that anyone should be free to modify latex in any way and
> > distribute that modification. I just don't agree that they should leave
> > my email address at the top as the place where people should report
> > bugs, and I don't agree that they should call the software by the same
> > name, so as to deliberately trick users who believe they are using one
> > piece of software into using a different piece of software.
That's totally fine.
I believe it was Frank who pointed out that there is a process for
forking LaTeX that involves pulling the name of the LaTeX Project and
LaTeX out of various places in the code. If that process were described
in the license, or explicitly named as an acceptable procedure to get
around the file naming problem, I think Debian's complaints about the
license would evaporate.
> > As a matter of fact we did read the DFSG while drafting the original
> > version 1 of the LPPL. I believed then and still believe now that it is
> > compatible. Nothing in any of the multitude of threads has shown
> > any real bar on LPPL being DFSG compatible. Some minor wording issues
> > that Frank has been addressing, but nothing in principle.
>
> > What has been clear is that some people at Debian don't like clause 4
> > and are trying to force licences that do not require that clause.
As an aside: I'm not sure that this is important. Whatever happens in
the future, DFSG 4 is there now, and we can't fault people for using
it. The status of LaTeX concerning DFSG 4 will be a data point if/when
the proposal comes up to remove it, and may affect enough developer
votes to cause the proposal to fail. Or, it may not.
> Speaking in the abstract, and in light of the fact that TeX macros *as
> installed on the system* can be considered source code, I believe that
> the desire to prevent people from using the same name for modified
> versions of macro files is compatible with the DFSG, possibly even
> without the benefit of DFSG 4.
I'm not sure I agree.
Let's take a look at it from a different perspective. What happens when
someone does something like this in their LaTeX document?
\usepackage{article}
(Sorry if I screwed that up; I'm not a regular LaTeX user.)
If the license prevents us from modifying the behavior of LaTeX *under
any circumstances* when a document does that, then it seems to me that
the license is not free.
Another example: Suppose the Python module "foo" has a similar
restriction. Is it really free to claim that "foo" is free when I
cannot fix a bug in "foo" and have that bug fix work in all the programs
on my system that "import foo"?
Yet another example: Would we consider it acceptable to rename "ls" to
"lsf" (for "ls fixed") as a legal requirement for fixing a bug in it?
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: forwarded message from Jeff Licquia
> Several people in this thread have already quoted several possibilities > where LaTeX could be the vector of a security problem. If you're going > to claim impossibility, then I'm afraid I'm going to have to ask for > proof. Actually in the case of latex itself the proof is trivial to provide. LaTeX is a set of macros. It doesn't actually have any capabilities to do anything. Any effect of running latex on a document is a result of the macro expansion engine or the execution of the primitive commands into which latex constructs expand. The expansion engine and the execution engine are both tex-the-program. So any security issues in latex are not in latex itself (or LPPL'ed code) but must be due to issues in the underlying tex engine. As a compiled program with write access to the filesystem, that is of course subject to the usual raft of issues, but it isn't under LPPL, most of it is under a "don't change it if you are not Don Knuth" licence, although the part that access the filesystem is GPL'ed as it happens. (TeX's file handling is just a stub into which system dependant code needs to be added, debian uses web2c based tetex and all the web2c file handling code is GPL) Of course, for other programs that might be placed under LPPL this specific line of reasoning would not apply. But in general I'd say that if you wanted to change a program because of security issues, changing the name of the program at the same time isn't so bad. It lets people know whether they have a good or bad version. So I don't see an LPPL licence as a threat to security. David _ This message has been checked for all known viruses by Star Internet delivered through the MessageLabs Virus Scanning Service. For further information visit http://www.star.net.uk/stats.asp or alternatively call Star Internet for details on the Virus Scanning Service. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: forwarded message from Jeff Licquia
> Let's take a look at it from a different perspective. What happens when
> someone does something like this in their LaTeX document?
> \usepackage{article}
> (Sorry if I screwed that up; I'm not a regular LaTeX user.)
(yes you did, but you're forgiven:-)
> If the license prevents us from modifying the behavior of LaTeX *under
> any circumstances* when a document does that, then it seems to me that
> the license is not free.
Unfortunately "seems to me" is almost the only kind of comment that we get,
it would be more helpful if anyone could give a more objective criterion
that shows how LPPL breaks some clause of the DFSG, however not this
example.
If the command the latex uses isn't called latex then basically all bets
are off and it can produce anything at all.
You may find that you have a command "pslatex" in Debian (it's in
texlive; I think it's also in tetex)
pslatex is a wrapper around latex that modifies things, changing default
fonts mainly, although it could do anything else. It does not contravene
the LPPL on latex (and it is itself LPPL'ed) I wrote it, but even if
someone else had done that I would still say that it clearly does not
contravene the latex licence and
pslatex document.tex
can produce whatever the author of pslatex wants it to produce, it
certainly will not normally produce the same printed document as
latex document
on the same source.
David
_
This message has been checked for all known viruses by Star Internet
delivered through the MessageLabs Virus Scanning Service. For further
information visit http://www.star.net.uk/stats.asp or alternatively call
Star Internet for details on the Virus Scanning Service.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: forwarded message from Jeff Licquia
>> The default installation of teTeX makes it extremly difficult (if >> not impossible) to open any security holes. If you are really >> concerned about security in TeX, you could and should enhance the >> web2c TeX distribution, not LaTeX. > > Lots of people have made claims that their software is impregnable, and > cannot be exploited. Lots of people have been wrong. > > Several people in this thread have already quoted several possibilities > where LaTeX Stop! Please, read again and slooowly :-) what Martin said (not the first sentence, but the second one): >>you could and should enhance the >>web2c TeX distribution, not LaTeX. Let's put it in other words. TeX leaves to the distribution the decision about how files are read/written. tetex decides how files are read/written and it's under GPL. Thus, you can change it if you want. Nothing to do with LaTeX ot LPPL. After that, explaining the problem of holes in our dangerous time can be interesting but it's certainly irrelevant. Regards Javier -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: forwarded message from Jeff Licquia
On Wed, 2002-07-17 at 12:19, David Carlisle wrote: > If the command the latex uses isn't called latex then basically all bets > are off and it can produce anything at all. This is, I think, the most crucial part of this whole discussion. I did not see any statement to this effect in the LPPL draft that was posted here: http://lists.debian.org/debian-legal/2002/debian-legal-200207/msg7.html I would love to hear that I had completely missed it, or that you've changed the draft to include such a statement. It's my belief that if a statement to this effect were added to the license, then there would be no question as to the license's compliance with the DFSG, either as it is or with DFSG 4 removed. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: forwarded message from Jeff Licquia
On Wed, 2002-07-17 at 12:23, Javier Bezos wrote: > Let's put it in other words. TeX leaves to the distribution > the decision about how files are read/written. tetex > decides how files are read/written and it's under GPL. Thus, you > can change it if you want. Nothing to do with LaTeX ot LPPL. > After that, explaining the problem of holes in our dangerous > time can be interesting but it's certainly irrelevant. This is irrelevant to my position as stated: 'It's just my contention that they fall under the category of "software produced by humans", and that everything that falls into that category may potentially be a security problem.' Thus, your way forward in convincing me that LaTeX cannot cause security problems involves one of the following: - proving that LaTeX is not software, - proving that LaTeX is not written by humans, - proving that it is possible for software written by humans to not contain security flaws, and that LaTeX meets the criteria for inclusion in that group. This is different from proving that it's *unlikely* that LaTeX could contains a security flaw; that may be true, for all I know. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: forwarded message from Jeff Licquia
On Wed, Jul 17, 2002 at 06:19:38PM +0100, David Carlisle wrote: > Unfortunately "seems to me" is almost the only kind of comment that we get, > it would be more helpful if anyone could give a more objective criterion > that shows how LPPL breaks some clause of the DFSG, however not this > example. http://lists.debian.org/debian-legal/2002/debian-legal-200207/msg00035.html http://lists.debian.org/debian-legal/2002/debian-legal-200207/msg00036.html http://lists.debian.org/debian-legal/2002/debian-legal-200207/msg00071.html -- G. Branden Robinson| Software engineering: that part of Debian GNU/Linux | computer science which is too [EMAIL PROTECTED] | difficult for the computer http://people.debian.org/~branden/ | scientist. pgpEojoHkZb3G.pgp Description: PGP signature
Re: forwarded message from Jeff Licquia
On Tue, Jul 16, 2002 at 09:35:23PM -0500, Steve Langasek wrote: > Sadly, you seem to have missed the point of Free Software altogether, > which can be stated simply as: preventing anyone from having exclusive > control of the software so that everyone can benefit. (1) The intersection of those interested in LaTeX and those seriously interested in Debian is almost empty, I imagine. I would have said it was empty, except that Frank Mittelbach seems to belong to both sets. (2) You (or someone else on the Debian "side") asked for the "LaTeX community" to comment on the discussion. I'm an ordinary LaTeX user, but I'm pretty sure that I speak for 95% (if not 100%) of LaTeX users when I say that satisfying the Debian licence comes very low indeed in my order of priorities. (3) Debian does not have a monopoly of the word "free". I suggest that if you do not want to be offensive you should say "Debian-free" or "free in the Debian sense". (4) There is no need for Debian or anyone else to modify the LaTeX kernel, since you can make any changes you want in a package (.sty file). So the whole discussion seems to me entirely theological. (5) You speak a lot about Linux, but your approach seems to me far from that promoted by Linus Torvalds. In fact Torvalds and Knuth seem to me very similar in their viewpoints, as perhaps one might expect. > If the Latex > developers don't believe this is important enough that they will choose > a license that complies with the Debian Free Software Guidelines, that's > once again their right as copyright holders, but it definitely makes it > incompatible with Debian's stated goals. I guess we'll just have to do our best to survive from day to day. -- 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: forwarded message from Jeff Licquia
Branden Robinson writes: > On Wed, Jul 17, 2002 at 06:19:38PM +0100, David Carlisle wrote: > > Unfortunately "seems to me" is almost the only kind of comment that we get, > > it would be more helpful if anyone could give a more objective criterion > > that shows how LPPL breaks some clause of the DFSG, however not this > > example. > > http://lists.debian.org/debian-legal/2002/debian-legal-200207/msg00035.html already answered that it was an oversight to leave that in the draft > http://lists.debian.org/debian-legal/2002/debian-legal-200207/msg00036.html already responded to half of it (in one or two cases asking for clarification if i remember) > http://lists.debian.org/debian-legal/2002/debian-legal-200207/msg00071.html that's one of yours right? it does discuss general stuff and not explicit points about the license draft or where there is explicit an explicit problem. ie it is another one of those examples of general type. and as far as the general stuff about freedom for ... etc goes it was answered very explicitly by David, wasn't it? so in other words the above are either no explicit criterion (for which David asked) or they have been answered or mended. anyway a) I think i have identified a number of concerns as well as other problems which I would like to address with a proposal and/or comments b) I'm dead tired tonight so i'm not going to do that ... perhaps giving some thinking space might now be that wrong anyway frank -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: forwarded message from Jeff Licquia
On Wed, Jul 17, 2002 at 09:55:42PM +0100, Timothy Murphy wrote: > On Tue, Jul 16, 2002 at 09:35:23PM -0500, Steve Langasek wrote: > > Sadly, you seem to have missed the point of Free Software altogether, > > which can be stated simply as: preventing anyone from having exclusive > > control of the software so that everyone can benefit. > (3) Debian does not have a monopoly of the word "free". > I suggest that if you do not want to be offensive > you should say "Debian-free" or "free in the Debian sense". Given that the term Free Software was coined by Richard Stallman, you can use his definition if you like: http://www.gnu.org/philosophy/free-sw.html Or you can use the DFSG, if that better meets your needs. I never claimed to have a monopoly on the word "free". I used the term "Free Software", which is much more specific and has a specific meaning to the community in which the term originated. To claim that my viewpoint is Debian-specific would be facile. > (4) There is no need for Debian or anyone else to modify the LaTeX kernel, > since you can make any changes you want in a package (.sty file). > So the whole discussion seems to me entirely theological. Consider it theological if you will; the fact remains that eligibility for inclusion in Debian is determined by a set of principles that are embodied in the DFSG. That this discussion is being entertained at all surely indicates that at least someone with a say in the matter believes freeness -- or at least widespread distribution -- is important to LaTeX. > (5) You speak a lot about Linux, > but your approach seems to me far from that promoted by Linus Torvalds. > In fact Torvalds and Knuth seem to me very similar in their viewpoints, > as perhaps one might expect. Linux is licensed under the GPL, which alone speaks volumes; and, as has already been pointed out, Linus is not the only one who has a say in the fate of that kernel: he's not even the only one who releases kernels. Steve Langasek postmodern programmer pgpwSKfxYZIEM.pgp Description: PGP signature
Re: forwarded message from Jeff Licquia
> Date: Wed, 17 Jul 2002 21:55:42 +0100 > From: Timothy Murphy <[EMAIL PROTECTED]> > > (1) The intersection of those interested in LaTeX > and those seriously interested in Debian is almost empty, I imagine. > I would have said it was empty, > except that Frank Mittelbach seems to belong to both sets. > > (2) You (or someone else on the Debian "side") > asked for the "LaTeX community" to comment on the discussion. > I'm an ordinary LaTeX user, > but I'm pretty sure that I speak for 95% (if not 100%) of LaTeX users > when I say that satisfying the Debian licence > comes very low indeed in my order of priorities. > I completely disagree with these points. 1. I know many LaTeX users. Debian is a distribution of choice for many of them. 2. The state of TeX/LaTeX in Debian is high on the priority list for many LaTeX users I know, and very high for many system admins that support LaTeX on their machines. I have several machines with LaTeX and Debian that I support. LaTeX there is used for everyday work, automatic production of reports from databases and other tasks. It is an important part of the system -- for some machine it is the reason of their employment. The fact that I can easily maintain the systems by simple apt-get update/apt-get upgrade is important for me. I remember too well the bad old times where I ought to update the texmf tree manually. This ease of maintaining made me migrate from TeXLive TeX to Debian standard packages. I do not want to lose it. If Debian will declare TeX suite (and this is not just about LaTeX -- this is about the core Knuthian system) non-DFSG and decrease or drop support for it, it would make the life much harder for me. Having said this, I need to note that the integrity of my (La)TeX distribution on the production systems is higher in my priority list than ease of maintaining. If Debian starts to change the standard, I will probably migrate to TeXLive again -- with all the problems this migration would cause. -- Good luck -Boris I am returning this otherwise good typing paper to you because someone has printed gibberish all over it and put your name at the top. -- Professor Lowd, English, Ohio University -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: forwarded message from Jeff Licquia
On Wed, 2002-07-17 at 16:24, Boris Veytsman wrote: > I completely disagree with these points. [lots of nice things about Debian snipped - thanks, by the way] > Having said this, I need to note that the integrity of my (La)TeX > distribution on the production systems is higher in my priority list > than ease of maintaining. If Debian starts to change the standard, I > will probably migrate to TeXLive again -- with all the problems this > migration would cause. Well, let me say for my part that I hope it's clear that we aren't hell-bent on gratuitously changing LaTeX. If we decide to start breaking things, please complain loudly. 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. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: forwarded message from Jeff Licquia
David Carlisle <[EMAIL PROTECTED]> wrote: > I agree that anyone should be free to modify latex in any way and > distribute that modification. I just don't agree that they should leave > my email address at the top as the place where people should report > bugs, and I don't agree that they should call the software by the same > name, so as to deliberately trick users who believe they are using one > piece of software into using a different piece of software. If these were the only restrictions (change contact info and change the name of the *program*, not the individual files), then we wouldn't be having this argument. Regards, Walter Landry [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: forwarded message from Jeff Licquia
Frank Mittelbach <[EMAIL PROTECTED]> wrote: > Branden Robinson writes: > > On Wed, Jul 17, 2002 at 06:19:38PM +0100, David Carlisle wrote: > > > Unfortunately "seems to me" is almost the only kind of comment that we > get, > > > it would be more helpful if anyone could give a more objective criterion > > > that shows how LPPL breaks some clause of the DFSG, however not this > > > example. > > http://lists.debian.org/debian-legal/2002/debian-legal-200207/msg00071.html > > that's one of yours right? > > it does discuss general stuff and not explicit points about the license draft > or where there is explicit an explicit problem. ie it is another one of those > examples of general type. and as far as the general stuff about freedom for > ... etc goes it was answered very explicitly by David, wasn't it? Please reread it. The first and fourth points especially 1) You are not allowed to impose further restrictions on modification apart from what this clause permits. 4) In practice, Debian recognizes "a different name or version number" to refer *works*, not filenames. This is the current argument. There was an argument about the ".ins" files, but you said that is no longer an issue. 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. Regards, Walter Landry [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: forwarded message from Jeff Licquia
> Date: Wed, 17 Jul 2002 16:25:26 -0700 (PDT) > From: Walter Landry <[EMAIL PROTECTED]> > > If these were the only restrictions (change contact info and change > the name of the *program*, not the individual files), then we wouldn't > be having this argument. I am afraid you do not understand the way LaTeX works. If you change any file in the texmf tree, and keep its name, the results of latex run would be completely different. Consider these files to be analogs of dynamicaly loaded libraries. Note that you do not need to this if you want to change latex behavior. Continuing the analogy, you do have an analog of LD_PRELOAD variable, so you do not need to hack libc.so to achieve anything. -- Good luck -Boris You must include all income you receive in the form of money, property and services if it is not specifically exempt. Report property (goods) and services at their fair market values. Examples include income from bartering or swapping transactions, side commissions, kickbacks, rent paid in services, illegal activities (such as stealing, drugs, etc.), cash skimming by proprietors and tradesmen, "moonlighting" services, gambling, prizes and awards. Not reporting such income can lead to prosecution for perjury and fraud. -- Excerpt from Taxachussetts income tax forms -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: forwarded message from Jeff Licquia
On Wed, 17 Jul 2002, Boris Veytsman wrote: > Note that you do not need to this if you want to change latex > behavior. Continuing the analogy, you do have an analog of LD_PRELOAD > variable, so you do not need to hack libc.so to achieve anything. But if there was a bug in libc I could fix it and still name it libc and I wouldn't need to rebuild all my dynamically linked programs to take advantage of my fix, would I? yours, peter -- PGP signed and encrypted | .''`. ** Debian GNU/Linux ** messages preferred.| : :' : The universal | `. `' Operating System http://www.palfrader.org/ | `-http://www.debian.org/ pgpSGj9U2XLle.pgp Description: PGP signature
Re: forwarded message from Jeff Licquia
On Wed, Jul 17, 2002 at 04:23:58PM -0500, Steve Langasek wrote: > I never claimed to have a monopoly on the word "free". I used the term > "Free Software", which is much more specific and has a specific meaning > to the community in which the term originated. ... > That this discussion is being entertained at all > surely indicates that at least someone with a say in the matter believes > freeness -- or at least widespread distribution -- is important to > LaTeX. There you are -- you _do_ consider you have been granted the True Meaning of "freeness". Can't you understand that all LaTeX users I've ever met -- and I've met many -- consider that LaTeX IS (already) FREE. You seem to believe that Frank Mittelbach is looking for some kind of papal blessing from Debian. 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. In my opinion he is rather innocent; he has about as much chance of reaching agreement with Debian as I have of reaching an understanding with the Orange Order. -- 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: forwarded message from Jeff Licquia
> Date: Thu, 18 Jul 2002 03:33:57 +0200 > From: Peter Palfrader <[EMAIL PROTECTED]> > On Wed, 17 Jul 2002, Boris Veytsman wrote: > > > Note that you do not need to this if you want to change latex > > behavior. Continuing the analogy, you do have an analog of LD_PRELOAD > > variable, so you do not need to hack libc.so to achieve anything.=20 > > But if there was a bug in libc I could fix it and still name it libc and > I wouldn't need to rebuild all my dynamically linked programs to take > advantage of my fix, would I? > This is because libc on Linux is LGPL'ed. Now suppose that you work on a system where you cannot rename libc -- either because of license or because you are not a superuser. Still you can say something like export LD_PRELOAD=my.cool.libc-substitute.so and all your dynamically linked programs will use your substitute. In LaTeX you can make your own format latex-palfrader.fmt, which will work exactly like latex, with only one difference: instead of klingon.sty it will load klingon-improved.sty. If you then use latex-palfrader myfile.tex for yor TeX files, it will give you exactly the results you want *without renaming* klingon.sty. -- Good luck -Boris There is no such thing as an ugly woman -- there are only the ones who do not know how to make themselves attractive. -- Christian Dior -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: forwarded message from Jeff Licquia
> I did not see any statement to this effect in the LPPL draft that was
> posted here:
>
> http://lists.debian.org/debian-legal/2002/debian-legal-200207/msg7.html
>
> I would love to hear that I had completely missed it, or that you've
> changed the draft to include such a statement.
My understanding is that no such statement is necessary (but there is
one anyway:-)
(Also it's difficult for latex to talk of command names, even more than
files, latex is used on systems with no command line, so you have to
interpret "command name" as "menu option or icony thing or anything else
that can be reasonably construed as starting the program from a user
action", which propbably isn't legally watertight...)
To take that specific example.
pslatex does not modify any of the latex source or run time files
so is clearly not in breach of the LPPL. It does have a pile of extra
tex macros that redefine chunks of latex, but LPPL explictly does not
forbid redefintions it just says such redefinitions should not be in a
file of the same name as the original.
Then wrapping it all up it has a new shell script which called "pslatex"
which calls standard latex on the user's document while inserting the
redefinitions in a suitably cunning way. This shell script again is not
a modification of any part of latex and doesn't share any name with any
part of latex so clearly is not in breach of LPPL.
This is spelled out more fully in the latex modification guide
modguide.tex which is referenced in the preamble of the LPPL draft you
quoted.
modguide.tex is in the base latex distribution, or ready formatted here:
ftp://ftp.tex.ac.uk/tex-archive/macros/latex/doc/modguide.pdf
the relevant bit of modguide.tex source says
\section{Modification conditions}
\label{sec:modcon}
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.
\begin{enumerate}
\item
Give your system a distinguished name, such as \nstex, which clearly
distinguishes it from \LaTeX{}.
\item
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}
\item
Ensure that the method used to run your system is clearly
\label{mcon:command}
distinct from that used to run Standard \LaTeX; e.g.~by using a
command name or menu entry that is clearly not \texttt{latex}
(or \texttt{LaTeX} etc).
\item
Ensure that, when a file is being processed by your system, the
use of non-standard \LaTeX{} is clearly proclaimed to the user by
whatever means is appropriate.
\item Ensure that what is written at the beginning of the log file
clearly shows that your system has been used, and that it is
not Standard \LaTeX{}.
See the file \texttt{cfgguide.tex} for how to achieve this.
\item
Clearly explain to users that bug reports concerning your
system should not be sent to the maintainers of Standard
\LaTeX{}.
\end{enumerate}
_
This message has been checked for all known viruses by Star Internet
delivered through the MessageLabs Virus Scanning Service. For further
information visit http://www.star.net.uk/stats.asp or alternatively call
Star Internet for details on the Virus Scanning Service.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: forwarded message from Jeff Licquia
> If these were the only restrictions (change contact info and change
> the name of the *program*, not the individual files), then we wouldn't
> be having this argument.
The filenames are part of the syntax of the language.
\documentclass{article}
does not mean "whatever article means on your system" it means the latex
article class. Without the filename restriction there would be no
standardisation of latex at all.
However if the program isn't called latex (even if it is derived from
latex) the code can be redefined so that
\documentclass{article}
does not load article.cls but loads article.debian-improved-class
instead, and that can do anything you like.
But this is basically just an unhelpful side issue of the form "I
personally don't like file name restrictions" as you are not I take it
claiming that anything in DFSG makes this distinction.
David
_
This message has been checked for all known viruses by Star Internet
delivered through the MessageLabs Virus Scanning Service. For further
information visit http://www.star.net.uk/stats.asp or alternatively call
Star Internet for details on the Virus Scanning Service.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: forwarded message from Jeff Licquia
On 2002-07-17 14:24:15 -0500, Jeff Licquia wrote: > On Wed, 2002-07-17 at 12:23, Javier Bezos wrote: > > Let's put it in other words. TeX leaves to the distribution > > the decision about how files are read/written. tetex > > decides how files are read/written and it's under GPL. Thus, you > > can change it if you want. Nothing to do with LaTeX ot LPPL. > > After that, explaining the problem of holes in our dangerous > > time can be interesting but it's certainly irrelevant. > > This is irrelevant to my position as stated: 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. The same applies to PostScript: One fixes security holes in the interpreter (e.g. GhostScript) and doesn't worry about the PostScript files. Best regards Martin -- Martin Schröder, [EMAIL PROTECTED] ArtCom GmbH, Grazer Straße 8, D-28359 Bremen Voice +49 421 20419-44 / Fax +49 421 20419-10 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: forwarded message from Jeff Licquia
On Wed, Jul 17, 2002 at 09:52:05PM -0400, Boris Veytsman wrote: > This is because libc on Linux is LGPL'ed. Now suppose that you work on > a system where you cannot rename libc -- either because of license or > because you are not a superuser. Still you can say something like > > export LD_PRELOAD=my.cool.libc-substitute.so > > and all your dynamically linked programs will use your substitute. I think this is a bad example in the context of this discussion. We would not consider it acceptable if we couldn't modify the libc and the libc copyright holders said "LD_PRELOAD is available, so use that instead". -- Colin Watson [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: forwarded message from Jeff Licquia
A short two cents from a user... Boris Veytsman <[EMAIL PROTECTED]> wrote: > Timothy Murphy <[EMAIL PROTECTED]> wrote: > > > (1) The intersection of those interested in LaTeX and those > > seriously interested in Debian is almost empty, I imagine. I'm a LaTeX user and Debian developer. > > (2) You (or someone else on the Debian "side") asked for the "LaTeX > > community" to comment on the discussion. I'm an ordinary LaTeX > > user, but I'm pretty sure that I speak for 95% (if not 100%) of > > LaTeX users when I say that satisfying the Debian licence comes very > > low indeed in my order of priorities. > I completely disagree with these points. > > 1. I know many LaTeX users. Debian is a distribution of choice for >many of them. > > 2. The state of TeX/LaTeX in Debian is high on the priority list for >many LaTeX users I know, and very high for many system admins that >support LaTeX on their machines. Right. As a LaTeX user, I'd be sad to see it go from Debian. > Having said this, I need to note that the integrity of my (La)TeX > distribution on the production systems is higher in my priority list > than ease of maintaining. If Debian starts to change the standard, I > will probably migrate to TeXLive again -- with all the problems this > migration would cause. I think you can have both. I don't think a DFSG-compliant license will mean a fork of LaTeX by the Debian maintainer of that package. I have always appreciated the fact that you could run latex on 10 year-old sources and get the same output, but I have also come to appreciate the rights granted by DFSG-compliant software. Peter -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: forwarded message from Jeff Licquia
Scripsit David Carlisle <[EMAIL PROTECTED]> > LaTeX is a set of macros. It doesn't actually have any capabilities to > do anything. telnetd is a set of machine-language instructions. It doesn't actually have any capabilities to do anything. > Any effect of running latex on a document is a result of the macro > expansion engine or the execution of the primitive commands > into which latex constructs expand. Any effect of running telnetd on a server is a result of a processor's data path, or the execution of system calls embedded in telnetd. > So any security issues in latex are not in latex itself (or LPPL'ed > code) but must be due to issues in the underlying tex engine. So any security issues in telnetd are not in telnetd itself, but must be due to issues in the underlying machine language. > As a compiled program with write access to the filesystem, that is > of course subject to the usual raft of issues, but it isn't under > LPPL, most of it is under a "don't change it if you are not Don > Knuth" licence, As a piece of silicon with an interface to the harddisk, that is of cource subject to the usual raft of issues, but it is not under a free license, most of it is under a "don't change this unless you are Intel" licence. Does this mean we should not be concerned about the ability to distribute security fixes for telnetd if a security issue was discovered? -- Henning Makholm "Hele toget raslede imens Sjælland fór forbi." -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: forwarded message from Jeff Licquia
> telnetd is a set of machine-language instructions. It doesn't actually > have any capabilities to do anything. This misses the point entirely so I'll try stating it another way. latex essentially runs in a virtual machine provided by tex the program. If you set the security options for tex-the-program correctly then the access of any tex document to read and/or write to your filesystem or to run external programs can be controlled suitably (and turned off by default in the case of running external programs.) Assuming TeX is bug free and correctly installed, then there is _nothing_ you can do in latex that gets round that. If you manage to find some latex construct that does get round it it is a bug in TeX. so it needs to be fixed there. In that case the fix will not be in LPPL code (most likely it is in GPL'ed code, as all TeX's file and system call handling is GPL in the version of TeX on Debian). telnetd is not at all similar as those machine instructions are running in an environment that does have access to secure information, so it is the responsibility of the program not to do the wrong thing. More similar would be a java program running in the secure environment in a browser. If you find an applet that manages to escape from the browser and trash your filesystem, then fixing the applet isn't really the right thing to do, you should fix the security lapse in the browser's JVM. David _ This message has been checked for all known viruses by Star Internet delivered through the MessageLabs Virus Scanning Service. For further information visit http://www.star.net.uk/stats.asp or alternatively call Star Internet for details on the Virus Scanning Service. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: forwarded message from Jeff Licquia
On 2002-07-18 17:18:23 +0200, Henning Makholm wrote: > Scripsit David Carlisle <[EMAIL PROTECTED]> > > LaTeX is a set of macros. It doesn't actually have any capabilities to > > do anything. > > telnetd is a set of machine-language instructions. It doesn't actually > have any capabilities to do anything. http://lists.debian.org/debian-legal/2002/debian-legal-200207/msg00199.html http://lists.debian.org/debian-legal/2002/debian-legal-200207/msg00140.html Sorry, but are you trying to start a flame war? Best regards Martin -- Martin Schröder, [EMAIL PROTECTED] ArtCom GmbH, Grazer Straße 8, D-28359 Bremen Voice +49 421 20419-44 / Fax +49 421 20419-10 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: forwarded message from Jeff Licquia
Scripsit David Carlisle <[EMAIL PROTECTED]> > > telnetd is a set of machine-language instructions. It doesn't actually > > have any capabilities to do anything. > This misses the point entirely so I'll try stating it another way. > latex essentially runs in a virtual machine provided by tex the program. My point is that there is no meaningful difference between "virtual" and "non-virtual" machines in this respect. -- Henning Makholm"It's kind of scary. Win a revolution and a bunch of lawyers pop out of the woodwork." -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: forwarded message from Jeff Licquia
> My point is that .. I give up. I don't think your point makes any sense, and as you only assert it without giving any reasons I don't see what else there is to say on the issue. There is in any case no point continuing the thread as this is really a general discussion about the merits of LPPL. The particular case of latex's execution strategy might be relevant in a specific decision about latex, but LPPL is drafted to be able to be applied to any program if the author of the program chooses that licence. Clearly it could be the case that an LPPL'ed program was found to have a security problem, and it is reasonable for the Debian maintainers to consider what they could do if they found themseleves distributing such a thing. I am sure that LPPL as drafted or with minor changes that anyone cares to suggest gives enough freedom to the debian maintainers to stop distributing the dangerous code and instead distribute a fixed code. The only thing LPPL does is makes sure that the end user notices that a fix has been applied. Which is probably a good thing as otherwise code may move by accident from Debian (where it runs safely) to some other system (where it does not). David _ This message has been checked for all known viruses by Star Internet delivered through the MessageLabs Virus Scanning Service. For further information visit http://www.star.net.uk/stats.asp or alternatively call Star Internet for details on the Virus Scanning Service. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: forwarded message from Jeff Licquia
On 2002-07-18 17:54:31 +0200, Henning Makholm wrote: > My point is that there is no meaningful difference between "virtual" > and "non-virtual" machines in this respect. There is: You can not change the "real" machine (the cpu in your example) while it's possible and legal to change the "virtual" machine (tex in our case). Best regards Martin -- Martin Schröder, [EMAIL PROTECTED] ArtCom GmbH, Grazer Straße 8, D-28359 Bremen Voice +49 421 20419-44 / Fax +49 421 20419-10 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: forwarded message from Jeff Licquia
Henning Makholm <[EMAIL PROTECTED]>: > > > telnetd is a set of machine-language instructions. It doesn't actually > > > have any capabilities to do anything. > > > This misses the point entirely so I'll try stating it another way. > > latex essentially runs in a virtual machine provided by tex the program. > > My point is that there is no meaningful difference between "virtual" > and "non-virtual" machines in this respect. However, there is a relevant difference between a virtual machine such as TeX or a browser's JVM that is intended to be secure, and a (virtual or non-virtual) machine such as IA32 or the Linux ABI that is not intended to be secure and supposed to be able to run a shell, trash things, etc (at least if you have supervisor status or root, respectively). Edmund -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: forwarded message from Jeff Licquia
On Thu, 2002-07-18 at 03:59, David Carlisle wrote: > > I did not see any statement to this effect in the LPPL draft that was > > posted here: > > > > http://lists.debian.org/debian-legal/2002/debian-legal-200207/msg7.html > > > > I would love to hear that I had completely missed it, or that you've > > changed the draft to include such a statement. > > My understanding is that no such statement is necessary (but there is > one anyway:-) That's good to hear. At some point, it might be fruitful to post the latest draft, so we don't argue over things that are already resolved. I don't know what the status of the draft is, though, or whether there are some more changes needed, so I'll leave that to you to decide. In licensing, you have to assume that nothing is allowed unless permission is explicitly granted. Explanatory text that lays out how you're able to exercise freedoms granted to the licensee (such as being able to create "mylatex" and how to override the default classes and such) is also good to avoid problems. > (Also it's difficult for latex to talk of command names, even more than > files, latex is used on systems with no command line, so you have to > interpret "command name" as "menu option or icony thing or anything else > that can be reasonably construed as starting the program from a user > action", which propbably isn't legally watertight...) Right. Definitions are key; something like this might be closer: "For the purposes of this license, a 'command name' constitutes any method of starting the Program, including but not limited to commands typed at command shells and clickable icons in a graphical environment." You could then reference that definition in your restrictions. Of course, IANAL; if you have access to one, they might be able to write you a better definition. > pslatex does not modify any of the latex source or run time files > so is clearly not in breach of the LPPL. It does have a pile of extra > tex macros that redefine chunks of latex, but LPPL explictly does not > forbid redefintions it just says such redefinitions should not be in a > file of the same name as the original. > > Then wrapping it all up it has a new shell script which called "pslatex" > which calls standard latex on the user's document while inserting the > redefinitions in a suitably cunning way. This shell script again is not > a modification of any part of latex and doesn't share any name with any > part of latex so clearly is not in breach of LPPL. I see. So the process of modifying LaTeX involves a "runtime patch system" of sorts, where a LaTeX document's calling of the "article" class gets redirected to the file "article-hacked". The original "article" must remain, then, but never gets used in the LaTeX-alike system, although it will continue to be used in standard LaTeX when that is called. That's the part that has been confusing me the most, I think. No, I don't see that as unreasonable, or non-free. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: forwarded message from Jeff Licquia
On Thu, 2002-07-18 at 04:59, Martin Schröder wrote:
> On 2002-07-17 14:24:15 -0500, Jeff Licquia wrote:
> > On Wed, 2002-07-17 at 12:23, Javier Bezos wrote:
> > > Let's put it in other words. TeX leaves to the distribution
> > > the decision about how files are read/written. tetex
> > > decides how files are read/written and it's under GPL. Thus, you
> > > can change it if you want. Nothing to do with LaTeX ot LPPL.
> > > After that, explaining the problem of holes in our dangerous
> > > time can be interesting but it's certainly irrelevant.
> >
> > This is irrelevant to my position as stated:
>
> This is absolutely relevant. LaTeX is just a set of macros run
> through an interpreter.
So interpreted languages cannot be insecure?
-
#!/usr/bin/python
import os
os.unlink("/etc/passwd")
-
I take it that you would think the proper solution to this problem is to
remove the os.unlink() function from Python?
> The same applies to PostScript: One fixes security holes in the
> interpreter (e.g. GhostScript) and doesn't worry about the
> PostScript files.
This is not true. There are lots of things that you can do in
PostScript by design that can delete files, consume available memory,
etc. That is not the fault of PostScript, but the particular PostScript
files you run.
You seem to be confusing bugs in the interpreter with bugs in
interpreted programs. It is possible for an interpreter to be bug-free,
but programs written in that interpreted language to have bugs.
You also seem to have a lot of faith in sandboxing. Sandboxes work *if
the sandbox model is correct* and the implementation has no bugs. Ask
the Java people about how sandbox models can be incorrect.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: forwarded message from Jeff Licquia
On Thu, 2002-07-18 at 04:59, Martin Schröder wrote: > The same applies to PostScript: One fixes security holes in the > interpreter (e.g. GhostScript) and doesn't worry about the > PostScript files. Actually, afair, postscript is 'feature complete' on some platforms and has the ability to muck with filesystems. Having a postscript file nuke your homedirectory would suck, wouldn't it? I think ghostscript uses a 'safe' mode by default, however. In any case, lets say one of the scripts decided to use /tmp in a stupid way... I don't know whats possible in TeX, however. In any case, I agree with others in this group. Non-free is non-free. -- Scott Dier <[EMAIL PROTECTED]> http://www.ringworld.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: forwarded message from Jeff Licquia
* Timothy Murphy <[EMAIL PROTECTED]> [020717 23:00]: > (1) The intersection of those interested in LaTeX > and those seriously interested in Debian is almost empty, I imagine. > I would have said it was empty, > except that Frank Mittelbach seems to belong to both sets. It may be nearly empty for the developers, but the userbase has an large intersection in my eyes. People judging effiency more than WYSWYG and inital ease of use tend to use Debian and LaTeX. > (2) You (or someone else on the Debian "side") > asked for the "LaTeX community" to comment on the discussion. > I'm an ordinary LaTeX user, > but I'm pretty sure that I speak for 95% (if not 100%) of LaTeX users > when I say that satisfying the Debian licence > comes very low indeed in my order of priorities. Those persons I know, that use LaTeX for more then their diploma- thesises and the like, do also note freedom of their software very high. > (3) Debian does not have a monopoly of the word "free". > I suggest that if you do not want to be offensive > you should say "Debian-free" or "free in the Debian sense". Sorry. But any word has a context. Microsoft Word is "free", too. You can get it without paying when buying computers in some shops. And Linux is "non-free", as you do not have the right to reduce the freedom. This in mind the term "Free Software" nowadays has in large areas a meaning that fit very well with the meaning in Debian. > (4) There is no need for Debian or anyone else to modify the LaTeX kernel, > since you can make any changes you want in a package (.sty file). > So the whole discussion seems to me entirely theological. This discussion is theological, because the sibject is. 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) As I have not looked into the licenses, I do not yet have made up an opinion for myself wheater they are non-free, as I can not think of any licence that would effectfuly allow what you want to be allowed and forbid what you want to forbid. Escpeccially preventing local changes (that are not distributed) by copyright law seems to be quite hard for me. (It might be a little bit difficult to make such changes legally, if the rights of the users are inadequatly restricted, but not impossible, as extreme examples like patches for games have shown) Hochachtungsvoll, Bernhard R. Link -- sagen wir mal...ich hab alle sourcen in /lost+found/waimea gEistiO: [...] Warum lost+found? wo haette ich es denn sonst hingeben solln? -- 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. 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... 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. For example. Cheers, Nick -- Nick Phillips -- [EMAIL PROTECTED] Is this really happening? -- 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: 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]
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. 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. [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
> 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: 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: 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: forwarded message from Jeff Licquia
* Boris Veytsman <[EMAIL PROTECTED]> [020719 12:48]: > > 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. > > 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. Sorry. I think some context was lost. I talked about most people in Debian. And as said before, if it is only clearly labeling that should be no problem for most people. It think the problem is more > So, you are defending abstract principles against a very unlikely > danger. It's not an abstract danger, it is the state of the world with almost anything. And most people in and around Debian see freedom of software as a very important thing due to their experiences, where it is lacking. Giving up this principle here would be like demanding the right to travel out the country but allowing a restriction to forbid travels to Australia as one would not intend to go there personally. > 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. It think it is quite an big problem in this discusion, that many people shouting loud, that had never to do with the other side. And I can assure you, that I and any LaTeX-user I can think of in and around Debian sees a standard for LaTeX and interoparable installations everywhere as a very worthy goal. But we can not tolerate means to reach this goal, that are against our principles, against our ethics. And as some means (at least) *sound* like extremly bad stuff, some people are shouting very loud. (And even some people without experience in LaTeX, which makes the discusion tending to complete confusion everywhere). I think the whole problem would disappear immidiatly, if the licence would allow and state this clear even to people not used to any form of TeX, that - *within* restrictions to have a changed version be clearly recognizeable for the user - anyone can change it in an arbitrary way without crude hacks (Preload, modifing the loaded image in memory,...), without having to change the files to be processed( i.e. without having to change the .tex-Files to work with). One way might be an restriction on the name of the called entry-point binary (though this is a very strange thing, it is already accepted for apache) or an duty to print pages of notifications to the output. Hochachtungsvoll, Bernhard R. Link -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: forwarded message from Jeff Licquia
* Jeff Licquia <[EMAIL PROTECTED]> [020719 20:22]: > > 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 not the person asked, but in my opinion this would be illegitimate. (Though a special licence for the trademark with conditions may be fine and quoted near the copyright licence, as long as this are two licences) > 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. I think http://www.cups.org/new-license.html is acceptable, as it clearly states, that it is GPL/LGPL than talked about additional things beeing allowed(with additional restrictions when these things are allowed) and then talks about the Trademark. (Though they could have put the paragraph trademarks after the paragraph Binary Distributions rights, as these are copyright- thingies again) Hochachtungsvoll, Bernhard R. Link -- 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 01:28:53AM -0400, Boris Veytsman wrote: > So, you are defending abstract principles against a very unlikely It sounds like you're dismissing Debian's strict free software principles because they're "abstract". Don't forget, however, that they're abstract principles that have proven to be extremely successful for all involved. People defend them with good reason. -- Glenn Maynard -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: forwarded message from Jeff Licquia
Glenn Maynard writes: > On Fri, Jul 19, 2002 at 01:28:53AM -0400, Boris Veytsman wrote: > > So, you are defending abstract principles against a very unlikely > > It sounds like you're dismissing Debian's strict free software principles > because they're "abstract". I for my part am not dissmissing Debian's software principles because they are abstract, on the contrary (and in fact i don't think that Boris does either, though he can speak up for himself). But at the same time it would be nice if we don't have to rehash the same arguments over and over again. To repeat a quote from Jeff's recent mail: > 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. > - 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. the question is: is LPPL-x (x for a carified version) conformant with DSFG 3+4 (and the others) yes or no. In other words, do our "abstract" principles conflict with yours. > Don't forget, however, that they're abstract principles that have > proven to be extremely successful for all involved. People defend them > with good reason. right, but that goes for both sides and i think statements like the one in Boris' mail result from the fact, that we get your "abstract" principles repeated over and over again without ever coming to the point that anyone acknowledges that our abstract principles also have some merrit so that we can (together) tackle the question: can they coexist and if so how? I see in some posts people actually trying to work on the latter question (which i find encouraging), but on the other hand there are a good number of posts that always return to the argument chain - we have "good" valid abstract prinicples % which is fine; i for my part % agree with them - we are used to see them implemented as % i know, doing it myself too follows ...% when the circumstances are % right - so get rid of your nonsense and% this is where I stop to follow suit% follow often followed by - if the LaTeX people do not value free software then ... the DSFG describe features a license has to have to be complient with free software in the debian sense. To fcome to a common understanding about that (in case of LPPL) I tried to sumarize the concerns posted and the arguments given. I still wait for further comments on that summary to see if that covers your concerns and thinking about LPPL (as of now). If we get those further comments I think we should be able to have a focused discussion of whether LPPL is complient or can be made complient. There are a number of myths it seems concerning what is allowed or not and how LPPL must or can be applied. Now that might be born out of the fact that the text of LPPL is badly written, or might be born out of the fact that people simply have incorrect information (like they not use TeX but a free tetex :-) here are some of them: - to fork you have to rename every package under LPPL - to get support from the kernel for a new package you have to fork the kernel - when modifying all future names pile up as being unchangeable all of them wrong (and explained over and over again by now) there have been detailed questions (intended to show that LPPL produces "excessive inconvenience" when doing modifications (for whatever reason)) --- I think the answers have shown that this is not the case. so let us come back to the question whether the intentions behind LPPL (eg our abstract principles) are in conflict with DSFG and if not try to help us reformulating it so that everything gets clearer. so let me repeat: I still wait for further comments on that summary http://lists.debian.org/debian-legal/2002/debian-legal-200207/msg00250.html to see if that covers your concerns and thinking about LPPL (as of now). And please give David and me (as two of the authors of LPPL) the credit that we have indeed looked at DSFG already when version 1.0 of LPPL came out and are convinced that it was written to be complient with DSFG. frank -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: forwarded message from Jeff Licquia
Scripsit Frank Mittelbach <[EMAIL PROTECTED]> > There are a number of myths it seems concerning what is allowed or > not and how LPPL must or can be applied. > here are some of them: > - to fork you have to rename every package under LPPL > all of them wrong (and explained over and over again by now) It has been *asserted* over and over again that this is wrong, but that assertation does not seem to be consistent with the actual license text we're discussing. It says that each *file* must be renamed if it is changed, and since each package is a file that has the package name as its file name, it logically follows that one would have to rename all packages. Have I overlooked something in the license? > so let us come back to the question whether the intentions behind LPPL (eg > our abstract principles) are in conflict with DSFG and if not try to help us > reformulating it so that everything gets clearer. I'm confused about what you mean here. Since it already has been established that the ideal goals seem to be compatible, why do you insist that we "come back" to that question instead of moving on to "reformulating it so that everything gets clearer"? -- Henning Makholm "Slip den panserraket og læg dig på jorden med ansigtet nedad!" -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: forwarded message from Jeff Licquia
Henning Makholm writes: > Scripsit Frank Mittelbach <[EMAIL PROTECTED]> > > > There are a number of myths it seems concerning what is allowed or > > not and how LPPL must or can be applied. > > > here are some of them: > > > - to fork you have to rename every package under LPPL > > > all of them wrong (and explained over and over again by now) > > It has been *asserted* over and over again that this is wrong, but > that assertation does not seem to be consistent with the actual > license text we're discussing. It says that each *file* must be > renamed if it is changed, and since each package is a file that has > the package name as its file name, it logically follows that one would > have to rename all packages. > > Have I overlooked something in the license? no. *each* file that you change must be renamed, but where is the problem here? I think it has also been demonstrated that is neither excessive nor in conflict with DSFG 3+4 You would only have to rename all files if you change all files. It does not follow that if you change only some, that you also have to change those that you do not intend to fork. Note that there are many individual works (each consisting typically of a small number of files) that are licensed these days under LPPL. So if you like to fork, say, the varioref package (a package for generating extended reference to sections and the like) you give varioref.sty a new name and that's it. You don't have to rename anything else though you may want to document your changes by using the .dtx method in which case you probably end up with a new work consisting of varioref2.dtx varioref2.sty varioref2.ins but this is neither a requirement nor something that follows from the license. same if true if you fork the kernel (i gave an example for the dolloar->euro question). > > so let us come back to the question whether the intentions behind LPPL (eg > > our abstract principles) are in conflict with DSFG and if not try to help > > us > > reformulating it so that everything gets clearer. > > I'm confused about what you mean here. Since it already has been > established that the ideal goals seem to be compatible, why do you > insist that we "come back" to that question instead of moving on to > "reformulating it so that everything gets clearer"? is it established? if so fine, I wasn't so sure seeing arguments like But we can not tolerate means to reach this goal, that are against our principles, against our ethics. (http://lists.debian.org/debian-legal/2002/debian-legal-200207/msg00274.html) frank -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: forwarded message from Jeff Licquia
Frank Mittelbach <[EMAIL PROTECTED]> writes: > no. *each* file that you change must be renamed, but where is the > problem here? I think it has also been demonstrated that is neither > excessive nor in conflict with DSFG 3+4 Why is renaming important to you at all? Why not simply require a notice in the file indicating that it has been changed? (Which is what the GPL requires.) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: forwarded message from Jeff Licquia
On Sat, Jul 20, 2002 at 09:49:15PM +0200, Frank Mittelbach wrote: > > > - to fork you have to rename every package under LPPL > > > > > all of them wrong (and explained over and over again by now) > > > > It has been *asserted* over and over again that this is wrong, but > > that assertation does not seem to be consistent with the actual > > license text we're discussing. It says that each *file* must be > > renamed if it is changed, and since each package is a file that has > > the package name as its file name, it logically follows that one would > > have to rename all packages. > > > > Have I overlooked something in the license? > > no. *each* file that you change must be renamed, but where is the problem > here? I think it has also been demonstrated that is neither excessive nor in > conflict with DSFG 3+4 As long as you offer DFSG-free options, you can offer as many other options as you want. You can say: "you can distribute modified files if 1: you rename the program to something other than 'Latex', 2: you rename all modified files, *or* 3: you swear loyalty to Frank Mittelbach." #1 is DFSG-free. #2 (and presumably #3) is not, but we don't have to choose them. David Carlisle has said that, with some exceptions, option #1 is okay with him [1], and I'm assuming you two are in agreement. That one's DFSG-free. (I can't say if the exceptions, regarding the latex search path, are.) However, option #1 isn't in the license. This is what Henning was asking about. [1] Message-Id: <[EMAIL PROTECTED]> -- Glenn Maynard -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: forwarded message from Jeff Licquia
Thomas Bushnell, BSG writes: > Frank Mittelbach <[EMAIL PROTECTED]> writes: > > > no. *each* file that you change must be renamed, but where is the > > problem here? I think it has also been demonstrated that is neither > > excessive nor in conflict with DSFG 3+4 > > Why is renaming important to you at all? > > Why not simply require a notice in the file indicating that it has > been changed? (Which is what the GPL requires.) because ... please start reading the message http://lists.debian.org/debian-legal/2002/debian-legal-200207/msg00055.html a good thread is also: http://lists.debian.org/debian-legal/2002/debian-legal-200207/msg00227.html you can also read modguide.tex in the latex distribution which gives some reasons. http://www.latex-project.org/guides/modguide/modguide.html cheers frank -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: forwarded message from Jeff Licquia
Glenn Maynard writes: > As long as you offer DFSG-free options, you can offer as many other > options as you want. You can say: "you can distribute modified files if > 1: you rename the program to something other than 'Latex', 2: you rename > all modified files, *or* 3: you swear loyalty to Frank Mittelbach." > #1 is DFSG-free. #2 (and presumably #3) is not, but we don't have to > choose them. i don't want an explanation for #3 :-) but I would like to see an argument for #2 not being DSFG-complient. frank -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: forwarded message from Jeff Licquia
Scripsit Frank Mittelbach <[EMAIL PROTECTED]>
> no. *each* file that you change must be renamed, but where is the problem
> here? I think it has also been demonstrated that is neither excessive nor in
> conflict with DSFG 3+4
I still think it can be viewed as excessive. Let me explain.
Imagine that I want to create a typesetting system that behaves just
like LaTeX on all input files, except that input files that say
something like
\documentclass[12pt]{article}
will actually be typeset with a 13-point font (and similarly for the
other standard classes). Note that I have deliberately selected an
extremely silly task, because I already conceded that I can think of
no non-silly reasons to want to fork LaTeX although I do care for the
theoretical ability to fork nevertheless.
Now, the technically sane way to achieve my goal would be to make
some small modifications to size12.clo, or whereever in classes.dtx
the lines in size12.clo come from. To do this, I'd have to change the
name of size12.clo - I suppose the intention of the LPPL is that it
will not be enough for me to rename classes.dtx and have the renamed
.dtx file generate a size12.clo with nonstandard contents.
However, when I modify the name of size12.clo I need to make sure that
article.cls can find my modified file. For example, article.cls
contains something like
[EMAIL PROTECTED]
...
[EMAIL PROTECTED]
so I need to modify that logic; otherwise things will not work.
Similarly for report.cls and letter.cls. OK, so I have to rename
the standard classes.
But since I want source compatibility (of a sort...) with LaTeX, a
document that says
\documentclass[12pt]{article}
must be able to find my changed and renamed article.cls. And what's
more, my boundary conditions for the fork are that if the user has
written his own class file that says
\LoadClass{article}
that one, too, must inherit the different behavior of the 12pt option
from the standard class.
That sends me messing with the class-loading code in the kernel. I do
not protest about having to call my kernel something else than
latex.ltx even if I didn't change its functional contents, and nothing
references the kernel by name anyway, so the renaming cascade stops
here - unless I've overlooked some other filename interaction.
However, look at the net effect of the cascade. What I initially
wanted to do was a simple change of a few decimal numbers in the
.clo file. Now, as the result of the renaming rule and only the
renaming rule, I find myself recoding some deep magic in the kernel
which will probably require that I'm able to keep a dozen double-bend
paragraphs from The TeXbook afloat in my head at once - in addition
to knowing which double-bend paragraphs to load into my head in the
first place.
Personally I am megalomanic enough to believe I have memoized
sufficiently large parts of The TeXbook to be able to make an attempt,
and perhaps even have it work after a few days of debugging. But I
certainly don't believe that everyone capable of changing a few
numbers in the .clo file will be able to do it. So the morale I'm
aiming at is that the renaming rule will prevent some people from
doing modifications that they would otherwise be technically competent
to do.
> Note that there are many individual works (each consisting typically
> of a small number of files) that are licensed these days under LPPL.
Point taken. So I agree that all packages do not have to be renamed.
BTW, is there an easy way to figure out which collections of files
constitute a work? In the teTeX installation I do my daily work with,
texmf/tex/latex/base contains 123 files - are they all one work, or
are they divided somehow?
> > I'm confused about what you mean here. Since it already has been
> > established that the ideal goals seem to be compatible, why do you
> > insist that we "come back" to that question instead of moving on to
> > "reformulating it so that everything gets clearer"?
> is it established? if so fine, I wasn't so sure seeing arguments like
> But we can not tolerate means to reach this goal, that are
> against our principles, against our ethics.
On Debian lists there'll always be random fallout from earlier phases
of the discussion - I'm guilty of this myself sometimes. However, I
think the guy that you quote here was merely stating an intention to
work on finding alternative means to reach your goal that does not
clash with our pinciples. (Here I'm deliberately overlooking the
possible interpretation that he was flaming, which is best overlooked
even if it should happen to be true).
Some disclaimers: Yes, I am aware that the points I make here apply
equally well to the current licence of LaTeX. No, that doesn't mean
that I'm arguing that LaTeX should be dropped from Debian immediately
until such time that we can persuade the LaTeX project to change its
licence. Although some of the more zealous (and influental?) regulars
on debian-legal might well hold that opinion. I
Re: forwarded message from Jeff Licquia
On Sat, Jul 20, 2002 at 11:04:42PM +0200, Frank Mittelbach wrote: > > As long as you offer DFSG-free options, you can offer as many other > > options as you want. You can say: "you can distribute modified files if > > 1: you rename the program to something other than 'Latex', 2: you rename > > all modified files, *or* 3: you swear loyalty to Frank Mittelbach." > > #1 is DFSG-free. #2 (and presumably #3) is not, but we don't have to > > choose them. > > i don't want an explanation for #3 :-) but I would like to see an argument for > #2 not being DSFG-complient. "4. Integrity of The Author's Source Code The license may restrict source-code from being distributed in modified form _only_ if the license allows the distribution of "patch files" ... The license may require derived works to carry a different name or version number from the original software." There are other things that are allowed in practice, such as requiring modifications to be documented. Filename changing isn't one of them, since that's far more cumbersome, especially where filenames have a direct impact on the language, as they do here. (Even where they don't, it has other practical problems. For example, if you do use patch files for your changes, they won't work well, since "diff" doesn't know you renamed the file. Similar problems with "cvs diff" and "cvs rdiff", which makes it difficult or impossible to use CVS to merge a tree with a new upstream version.) -- Glenn Maynard -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: forwarded message from Jeff Licquia
Henning Makholm writes:
> Scripsit Frank Mittelbach <[EMAIL PROTECTED]>
>
> > no. *each* file that you change must be renamed, but where is the problem
> > here? I think it has also been demonstrated that is neither excessive nor
> > in
> > conflict with DSFG 3+4
>
> I still think it can be viewed as excessive. Let me explain.
>
> Imagine that I want to create a typesetting system that behaves just
> like LaTeX on all input files, except that input files that say
> something like
>
> \documentclass[12pt]{article}
>
> will actually be typeset with a 13-point font (and similarly for the
> other standard classes). Note that I have deliberately selected an
> extremely silly task, because I already conceded that I can think of
> no non-silly reasons to want to fork LaTeX although I do care for the
> theoretical ability to fork nevertheless.
[example of the complex way removed]
Do you know about the suggested way of forking given in cfgguide.tex? That
wouldn't fully cover you example as it was written in 1995 or so, but LaTeX
only knows about a very small number of file types that are "loadable via
interfaces and by rewriting that example to cover the three missing ones (only
deals with .sty and .cls there) you have a simple way to fork which consists of
making a new kernel by adding 20+ lines of code
modify any loadable file as you wish (after giving it a new name constructed
from the old) and still have it found by your new kernel as if it had its
original name, eg in your example instead of art12.clo you name your file
art12.fcl and it will be found whenever the unmodified kernel would try to
load art12.clo.
after that kernel change (which makes it a "nonLaTeX") no hacking unrelated
files, no checking for them, ..., would be required.
of course that isn't the only way to fork it is one suggested way not a
requirement or anything.
> numbers in the .clo file will be able to do it. So the morale I'm
> aiming at is that the renaming rule will prevent some people from
> doing modifications that they would otherwise be technically competent
> to do.
but with the above approach (which is documented and even referred to in the
license)
We, the LaTeX3 Project, believe that the conditions below give you
the freedom to make and distribute modified versions of The Program
that conform with whatever technical specifications you wish while
maintaining the availability, integrity, and reliability of
The Program. If you do not see how to achieve your goal while
meeting these conditions, then read the document `cfgguide.tex'
in the base LaTeX distribution for suggestions.
it boils down to a simple change of a few numbers in the right file
> BTW, is there an easy way to figure out which collections of files
> constitute a work? In the teTeX installation I do my daily work with,
> texmf/tex/latex/base contains 123 files - are they all one work, or
> are they divided somehow?
it is suggested in the license to specify that in a sensible way, most works
do that by saying in every file something like:
%% The list of all files belonging to the LaTeX base distribution is
%% given in the file `manifest.txt'.
if the list is longer or else simply enumerate the files forming a work.
frank
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: forwarded message from Jeff Licquia
Glenn Maynard writes:
> > i don't want an explanation for #3 :-) but I would like to see an argument
> > for
> > #2 not being DSFG-complient.
>
> "4. Integrity of The Author's Source Code
>
> The license may restrict source-code from being distributed in modified
> form _only_ if the license allows the distribution of "patch files" ...
> The license may require derived works to carry a different name or version
> number from the original software."
>
> There are other things that are allowed in practice, such as requiring
> modifications to be documented. Filename changing isn't one of them,
> since that's far more cumbersome, especially where filenames have a
> direct impact on the language, as they do here.
i have heard that statement before, but to me it doesn't follow from DSFG 4
and others (regulars on this list I presume) have in my understanding also
expressed that. Not everybody --- the camp is clearly divided.
this is one of the reasons why i asked to review my compiled summary, some
such statements are contained therein, eg
http://lists.debian.org/debian-legal/2002/debian-legal-200207/msg00139.html
http://lists.debian.org/debian-legal/2002/debian-legal-200207/msg00147.html
---
but to try it from a different direction: suppose i have the work "varioref"
consisting of "varioref.sty" and varioref.dtx, say. Now I'm allowed to require
a "name" change according to DSFG 4, correct?
now varioref.sty contains the line
\ProvidesPackage{varioref}
so you agree with me that as part of DSFG 4 it is valid to request that this
line is changed to contain the new name of the work, correct?
problem then is that this line is tied to the external file name directly, ie
in case of a package LaTeX wil bark if you keep varioref.sty but change that
line to \ProvidesPackage{foo}. so to use that modified file with LaTeX you
have rename it to foo.sty as well.
-
or what about this:
Bernd Link said in
http://lists.debian.org/debian-legal/2002/debian-legal-200207/msg00274.html
I think the whole problem would disappear immidiatly, if the licence
would allow and state this clear even to people not used to any form
of TeX, that - *within* restrictions to have a changed version be clearly
recognizeable for the user - anyone can change it in an arbitrary way
without crude hacks (Preload, modifing the loaded image in memory,...),
without having to change the files to be processed( i.e. without having
to change the .tex-Files to work with).
One way might be an restriction on the name of the called entry-point
binary (though this is a very strange thing, it is already accepted for
apache) or an duty to print pages of notifications to the output.
I have no idea if this is only his opinion though his reference to apache
indicates differently. Assuming the latter then i would propose to think
about the formula that
the derived work has to change its name such that when loaded into LaTeX it
will not be confused (by LaTeX) with the original unmodified work, eg if
\usepackage{varioref}
was the loading interface for the varioref work then the modified work has to
identify itself differently to LaTeX --- which again, sorry boils down to a
change in filename, by the way the loading process works.
--
as we find it important that within the LaTeX contexts different variants of
some work are automatically distinguishable (not repeat reasons here) we
started drafting the license in a way that where honnest to what needs to be
done (while as we thought and still think being complient with DSFG-4)
anyway, as i said before I still don't see how you conclude or derive from
DFSG 4 that a change of name for a work, can't mean for certain types of work
a file name change. I understand that for many types of software it would mean
an unnecessary restriction, but that doesn't mean it is universally true, nor
does it mean that it can be concluded from DSFG.
I can accept the argument: that you want it excluded and intend to change the
clause in this way, but this is a different argument then (and I don't think
that this is actually the consensus within Debian right now).
frank
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: forwarded message from Jeff Licquia
On Sun, Jul 21, 2002 at 01:15:42AM +0200, Frank Mittelbach wrote: > i have heard that statement before, but to me it doesn't follow from DSFG 4 > and others (regulars on this list I presume) have in my understanding also > expressed that. Not everybody --- the camp is clearly divided. I havn't seen dissention on this issue. Some people have said that they don't like it (many DD's don't like #4; that's why it's a a compromise), and others (eg. Thomas and Branden) have pointed out that renaming may not necessarily accomplish what you want. The rest of this seems, to me, like you're trying to use #4 in ways it wasn't intended to be used. I'll leave replies to people more experienced with Latex and the DFSG than myself. > I can accept the argument: that you want it excluded and intend to change the > clause in this way, but this is a different argument then (and I don't think > that this is actually the consensus within Debian right now). The DFSG is a set of guidelines, not a legal document; it has room for interpretation. Debian doesn't change the DFSG to indicate the details of every debian-legal decision that required interpretation. Yes, this means there's some ambiguity if all a person has for reference is the DFSG text. (That's one reason these things are discussed publically.) -- Glenn Maynard -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: forwarded message from Jeff Licquia
Glenn Maynard writes: > On Sun, Jul 21, 2002 at 01:15:42AM +0200, Frank Mittelbach wrote: > > i have heard that statement before, but to me it doesn't follow from DSFG 4 > > and others (regulars on this list I presume) have in my understanding also > > expressed that. Not everybody --- the camp is clearly divided. > > I havn't seen dissention on this issue. Some people have said that they what about the posts i cited? I wan't indicating that people where thinking about filename changes being a "name or version" change before, i was indicating that some people were following the argumentation. > don't like it (many DD's don't like #4; that's why it's a a compromise), > and others (eg. Thomas and Branden) have pointed out that renaming may > not necessarily accomplish what you want. but renaming does accomplish it, as pointed out in replies. and we know no other way to accomplish it. on the other hand, no (usable) suggestions so far were put up on how to solve that exchangibility feature of LaTeX (not the nonLaTeX startinf from a kernel fork) otherwise. Branden tried but he thought of LaTeX being a monolith which would allow to test for "standard" conformance --- but as it isn't (remember any derived work under a new name might extend "LaTeX" as seen by the users), this approach is unworkable. > The rest of this seems, to me, like you're trying to use #4 in ways it > wasn't intended to be used. I'll leave replies to people more experienced > with Latex and the DFSG than myself. i'm certainly aware that we interpret #4 in a way which is at least uncommon, though that doesn't necessarily makes it wrong. I would certainly be glad to hear other opinions on the interpretation that i put forward in the previous mail frank -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: forwarded message from Jeff Licquia
On Sun, Jul 21, 2002 at 02:09:46AM +0200, Frank Mittelbach wrote: > on the other hand, no (usable) suggestions so far were put up on how to solve > that exchangibility feature of LaTeX (not the nonLaTeX startinf from a kernel > fork) otherwise. Branden tried but he thought of LaTeX being a monolith which > would allow to test for "standard" conformance --- but as it isn't (remember > any derived work under a new name might extend "LaTeX" as seen by the users), > this approach is unworkable. Part of their point, I believe, is that you're trying to use copyrights to accomplish something that you need to use a trademark for. (IANAL, either.) Even if trademarks don't work for you here, copyrights remain inappropriate for this. Even if you have some code that tries to prevent symlink tricks, as you seem to have suggested in your "stolen flag" message, I can remove that code (just another modification), or sidestep it with something it doesn't know about, like a menu item label. (Again, we're not suggesting that we actually want to do this; just that the renaming requirements *can* be sidestepped, making them useless.) > i'm certainly aware that we interpret #4 in a way which is at least uncommon, > though that doesn't necessarily makes it wrong. Other interpretations may be interesting, but it's ultimately Debian's interpretation that determines whether it's DFSG-free, not yours (or mine). > I would certainly be glad to hear other opinions on the interpretation that i > put forward in the previous mail I'm interested in yours. If renaming requirements are clearly unenforcable, why keep them around? -- Glenn Maynard -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: forwarded message from Jeff Licquia
Frank Mittelbach <[EMAIL PROTECTED]> wrote: > - to get support from the kernel for a new package you have to fork the >kernel > - when modifying all future names pile up as being unchangeable > > all of them wrong (and explained over and over again by now) I must be thick headed. How can you say that the kernel will never need to be modified for a new package? I accept that in most cases, this is true, but saying that it is always true is absurd. Also, why don't future names pile up as unchangeable? The LaTeX project release file FOO. Bob modifies and renames it to BAR and puts it under the LPPL. Alice modifies that, renames it to BAZ, and puts that under the LPPL. Eve modifies it again and doesn't know what to name it, since we've run out of silly computer science names. Regards, Walter Landry [EMAIL PROTECTED] -- 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 07:27:49PM -0400, Boris Veytsman wrote: > 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. *shrug* This sounds like something that has to be handled on a case-by-case basis. Song titles and movie titles in North America and Western Europe have been reused freely. > > 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: [snip] > 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. Your point? Free Software copyright licenses should not attempt to achieve via their terms what would not ordinarily be achievable through copyright law. The terms and conditions of the GNU GPL are entirely within the scope of copyright law. > 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. The above screed is completely irrelevant to my statements. My message was not about the GNU GPL. If you want to gripe about the GNU GPL, or misrepresent my remarks in an effort to rhetoric me into some corner regarding the GNU GPL, please do so in a different thread. Until and unless the LaTeX Project considers applying the GNU GPL to their works, the GNU GPL is almost totally irrelevant to the present discussion. Maybe you're just playing devil's advocate; in any event, I am not in the mood to argue about the GNU GPL at present. There, I've said it three times, maybe you'll get it... -- G. Branden Robinson| "There is no gravity in space." Debian GNU/Linux | "Then how could astronauts walk [EMAIL PROTECTED] | around on the Moon?" http://people.debian.org/~branden/ | "Because they wore heavy boots." pgp5SboIkqSJo.pgp Description: PGP signature
Re: forwarded message from Jeff Licquia
Walter Landry writes: > Frank Mittelbach <[EMAIL PROTECTED]> wrote: > > - to get support from the kernel for a new package you have to fork the > >kernel > > - when modifying all future names pile up as being unchangeable > > > > all of them wrong (and explained over and over again by now) > > I must be thick headed. How can you say that the kernel will never > need to be modified for a new package? I accept that in most cases, > this is true, but saying that it is always true is absurd. no its not. perhaps you mistake "kernel" with "virtual machine". LaTeX as most macro languages is three layered: 1 a virtual machine (TeX program) 2 a kernel (the way LaTeX starts out by default) 3 packages loaded within a document ( document = latex program) Each package can modify absolutely any aspect of layer 2. What it can't do is to change 1. That is: TeX, for example, can't execute OS commands. Then there is no way to make that possible from (3) or (2). So to get such an extension you need to modify (1) (which has been done) but TeX is under a different license. But comeing back to my statement. The kernel of LaTeX is nothing other than a huge list of TeX instructions executed and the state of TeX then dumped as an image for high spead loading at this point. > Also, why don't future names pile up as unchangeable? The LaTeX > project release file FOO. Bob modifies and renames it to BAR and puts > it under the LPPL. Alice modifies that, renames it to BAZ, and puts > that under the LPPL. Eve modifies it again and doesn't know what to > name it, since we've run out of silly computer science names. true, by extending the LaTeX language (through putting BAR under LPPL) Bob has added to the language and in this way to the pile of names within the language and so does Alice. This is like extensions in a computer language from one version to the next might increase the number of keywords in that language. And yes number of useful keywords is finite. what i meant, however, (and sorry for not expressing that good enough) is that LPPL doesn't pile up names by default, ie simply through forking. That is there is no requirement for Alice to put BAZ under LPPL just because FOO or BAR was. frank -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: forwarded message from Jeff Licquia
Scripsit Frank Mittelbach <[EMAIL PROTECTED]>
> Henning Makholm writes:
> > Imagine that I want to create a typesetting system that behaves just
> > like LaTeX on all input files, except that input files that say
> > something like
> > \documentclass[12pt]{article}
> > will actually be typeset with a 13-point font (and similarly for the
> > other standard classes). Note that I have deliberately selected an
> > extremely silly task, because I already conceded that I can think of
> > no non-silly reasons to want to fork LaTeX although I do care for the
> > theoretical ability to fork nevertheless.
> [example of the complex way removed]
I thought I argued in quite a level of detail why it is the *only* way
that is allowed by the renaming rule. If you think my arguments are
wrong, could you please explain why in more detail than just
dismissing them as "the complex way"?
> Do you know about the suggested way of forking given in cfgguide.tex?
No.
There is a texmf/doc/latex/base/cfgguide.dvi on my local machine. It
contains a document with the title "Configuration options for LaTeX2e"
dated 17 October 1998.
As the last section of that file there is a very brief example of
how the last step of the "complex way" I described in my previous
posting - namely how to get the renamed article.cls loaded while
still allowing the user to define his own .cls files - could be
carried out.
> LaTeX only knows about a very small number of file types that are
> "loadable via interfaces and by rewriting that example to cover the
> three missing ones (only deals with .sty and .cls there) you have a
> simple way to fork which consists of making a new kernel by adding
> 20+ lines of code
It's not simply a matter of rewriting the *example*. There is no
[EMAIL PROTECTED] hook to use, at least not in article.cls 1999/09/10
v1.4a - the entire construction of the .clo file's name is hardcoded
in the class file, so I'd still have to change the mechanism there,
which cascades my name-change requirements up as I described in my
previous posting.
That is, unless I do something really gross like
[EMAIL PROTECTED]@iinput
[EMAIL PROTECTED]@[EMAIL PROTECTED]
[EMAIL PROTECTED]@b
[EMAIL PROTECTED]
\fi
[EMAIL PROTECTED]@a}}
which I still think is beyond the capabilities of the hypothetical
forker who knows what he want to change in size12.clo.
> of course that isn't the only way to fork it is one suggested way not a
> requirement or anything.
If there was a *general* way to do this kind of replacements, and
not one that worked only for .cls and .sty files, I'd be inclined to
be statisfied with that as a forking device.
As you've pointed out, there are other and normally more desirable
ways ways to achive modified behavior in "small" cases, but as long as
the possibility to do an all-out fork is present, the rest is just
extra bonus.
> (which is documented and even referred to in the license)
It seems that I'm referring to a wrong licence. I thought we were
talking about the draft that C.M. Connelly posted in
http://lists.debian.org/debian-legal/2002/debian-legal-200207/msg7.html
The character combination "cfgguide" does not appear in his posting.
Do you have an URL reference to the license you're talking about?
> it boils down to a simple change of a few numbers in the right file
Yes, ideally. But as I've explained, the need to then change the name
of that file cascades up the file-invocation chain until one reached
the kernel.
--
Henning Makholm "Man vælger jo selv sine forbilleder."
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: forwarded message from Jeff Licquia
> From: Henning Makholm <[EMAIL PROTECTED]>
> Date: 20 Jul 2002 20:15:30 +0200
>
> > - to fork you have to rename every package under LPPL
>
> > all of them wrong (and explained over and over again by now)
>
> It has been *asserted* over and over again that this is wrong, but
> that assertation does not seem to be consistent with the actual
> license text we're discussing. It says that each *file* must be
> renamed if it is changed, and since each package is a file that has
> the package name as its file name, it logically follows that one would
> have to rename all packages.
>
I thought about your question, and now I think I understood what you
mean.
Suppose I changed file foo.sty in LaTeX. I need to rename it when I
change -- it is not a difficult task. However, it happens that another
file bar.sty uses foo.sty, so I need to change bar.sty AND rename
it. Then I need to change baz.sty that references bar.sty etc. Is this
what you mean?
If so, there is another, easy way to do this change, completely in the
spirit of LPPL. Since we are changing foo.sty, we are changing the way
LaTeX kernel works. Therefore we need to change and rename latex.ltx
anyway. Now the loading of files in LaTeX is done by the commands
\RequirePackage and \usepackage. Right now \RequirePackage{foo} loads
the file foo.sty. It is easy to change the definition of this command
in the kernel to the following: if the file foo.hck exists, load it,
otherwise load foo.sty. Then you need to rename ONLY the files you
modified (from foo.sty to foo.hck) which is not too difficult.
I repeat: you can do ANYTHING you want by redefining LaTeX
macros. Admitted, sometime it requires a certain level of
knowledge. However, I do not think that the freedom of modification
must be interpreted as the ease of modification by the people who do
not understand the language. If you want this, then somebody might
require the ease of modification by the point and click methods.
--
Good luck
-Boris
Virginia law forbids bathtubs in the house; tubs must be kept in the yard.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: forwarded message from Jeff Licquia
> From: Henning Makholm <[EMAIL PROTECTED]>
> Date: 20 Jul 2002 23:32:48 +0200
>
> I still think it can be viewed as excessive. Let me explain.
>
> Imagine that I want to create a typesetting system that behaves just
> like LaTeX on all input files, except that input files that say
> something like
>
> \documentclass[12pt]{article}
>
> will actually be typeset with a 13-point font (and similarly for the
> other standard classes). Note that I have deliberately selected an
[the long saga is omitted]
> That sends me messing with the class-loading code in the kernel. I do
> not protest about having to call my kernel something else than
> latex.ltx even if I didn't change its functional contents, and nothing
> references the kernel by name anyway, so the renaming cascade stops
> here - unless I've overlooked some other filename interaction.
>
You do not need to this. A simple solution is to change in your
changed kernel the lines:
[EMAIL PROTECTED]
\expandafter\let\csname [EMAIL PROTECTED]
\csname [EMAIL PROTECTED]@[EMAIL PROTECTED]
#2{#3}}
to the lines
[EMAIL PROTECTED]
\expandafter\let\csname [EMAIL PROTECTED]
\csname [EMAIL PROTECTED]@[EMAIL PROTECTED]
#2{#3}%
[EMAIL PROTECTED]
and create 13pt.clo with the appropriate contents.
>
> Personally I am megalomanic enough to believe I have memoized
> sufficiently large parts of The TeXbook to be able to make an attempt,
> and perhaps even have it work after a few days of debugging. But I
> certainly don't believe that everyone capable of changing a few
> numbers in the .clo file will be able to do it. So the morale I'm
> aiming at is that the renaming rule will prevent some people from
> doing modifications that they would otherwise be technically competent
> to do.
I do not think that "freedom of modification" should mean "ease of
modification by people with superficial knowledge of the
language". The task of creating non-quite-LaTeX *is* difficult in any
real situation. The requirement that it must be easily done by people
who do not know TeX seems excessive to me.
--
Good luck
-Boris
"Imitation is the sincerest form of television."
-- The New Mighty Mouse
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: forwarded message from Jeff Licquia
Henning Makholm writes: > > [example of the complex way removed] > > I thought I argued in quite a level of detail why it is the *only* way > that is allowed by the renaming rule. If you think my arguments are > wrong, could you please explain why in more detail than just > dismissing them as "the complex way"? sorry, i thought that I made this clear later on. > > > Do you know about the suggested way of forking given in cfgguide.tex? > > No. > > There is a texmf/doc/latex/base/cfgguide.dvi on my local machine. It > contains a document with the title "Configuration options for LaTeX2e" > dated 17 October 1998. yes, that one. > As the last section of that file there is a very brief example of > how the last step of the "complex way" I described in my previous > posting - namely how to get the renamed article.cls loaded while > still allowing the user to define his own .cls files - could be > carried out. yes it explains a scenario for two of the five or so file types of LaTeX. > > LaTeX only knows about a very small number of file types that are > > "loadable via interfaces and by rewriting that example to cover the > > three missing ones (only deals with .sty and .cls there) you have a > > simple way to fork which consists of making a new kernel by adding > > 20+ lines of code > > It's not simply a matter of rewriting the *example*. There is no > [EMAIL PROTECTED] hook to use, at least not in article.cls 1999/09/10 > v1.4a - the entire construction of the .clo file's name is hardcoded > in the class file, so I'd still have to change the mechanism there, > which cascades my name-change requirements up as I described in my > previous posting. well it is a matter of rewriting the example, though not trivially to cover all possible case. The best solution is either to provide something like [EMAIL PROTECTED] inside the kernel, or to rewrite the LaTeX file parser to not only recognise area path base and extension of a file name but to do something about them. Now i wans't suggesting that this should be left to somebody who wants to fork, I was suggesting that this example (being written in 1995) is not general enough and would need to be updated by us to be completely general. > That is, unless I do something really gross like > >[EMAIL PROTECTED]@iinput >[EMAIL PROTECTED]@[EMAIL PROTECTED] > [EMAIL PROTECTED]@b > [EMAIL PROTECTED] > \fi > [EMAIL PROTECTED]@a}} > > which I still think is beyond the capabilities of the hypothetical > forker who knows what he want to change in size12.clo. well, not this way :-) but there is no disagreement ... for the discussion assume that the example given there is general so all you have to do when you want to fork is to copy it from the file apply it and make your own non-latex format > > of course that isn't the only way to fork it is one suggested way not a > > requirement or anything. > > If there was a *general* way to do this kind of replacements, and > not one that worked only for .cls and .sty files, I'd be inclined to > be statisfied with that as a forking device. that would be fine and that is what i was trying to say --- basically your example made me understood that your description and code for it was incomplete > As you've pointed out, there are other and normally more desirable > ways ways to achive modified behavior in "small" cases, but as long as > the possibility to do an all-out fork is present, the rest is just > extra bonus. > > > (which is documented and even referred to in the license) > > It seems that I'm referring to a wrong licence. I thought we were > talking about the draft that C.M. Connelly posted in > http://lists.debian.org/debian-legal/2002/debian-legal-200207/msg7.html > The character combination "cfgguide" does not appear in his posting. > Do you have an URL reference to the license you're talking about? sorry ... LPPL 1.2 contained cfgguide in place of modguide in the paragraph starting "We, the LaTeX3 Project, believe that the conditions below give you the freedom to make and distribute modified versions of The Program ... when discussing 1.3-draft on LATEX-L somebody suggested that we most certainly meant modguide at this point (and me not thinking straight) just changed it without further reflection. but modguide is only giving some rationale not explaining how to do things (and is referred to in cfgguide) so i simply made the wrong decision then. so the 1.3-draft you seen indeed doesn't have it but it is already changed back (and i remarked on that at some point in the whole discussion. not that i really expect you to have noticed that. > > it boils down to a simple change of a few numbers in the right file > > Yes, ideally. But as I've explained, the need to then change the name > of that file cascades up the file-invocation chain until one reached > the ke
Re: forwarded message from Jeff Licquia
On Sat, 2002-07-20 at 18:41, Glenn Maynard wrote: > On Sun, Jul 21, 2002 at 01:15:42AM +0200, Frank Mittelbach wrote: > > i have heard that statement before, but to me it doesn't follow from DSFG 4 > > and others (regulars on this list I presume) have in my understanding also > > expressed that. Not everybody --- the camp is clearly divided. > > I havn't seen dissention on this issue. Some people have said that they > don't like it (many DD's don't like #4; that's why it's a a compromise), > and others (eg. Thomas and Branden) have pointed out that renaming may > not necessarily accomplish what you want. > > The rest of this seems, to me, like you're trying to use #4 in ways it > wasn't intended to be used. I'll leave replies to people more experienced > with Latex and the DFSG than myself. To an extent, we've covered this already. Here's my current thinking on the situation. First of all, requiring a source file rename is, I think, obviously OK; renaming "foo.c" to "bar.c" doesn't really affect your rights, and is mostly an annoyance (tracking down Makefile references and so on). Requiring a binary file rename is also OK; I think we might even do this now. A C include file is more of a problem, because there are references to the original source file in other programs. You now need to patch all other C programs that use the include file to include your modified version. This may cross the bounds of what you're allowed to require under DFSG 3 (but I'm not going to say definitely one way or the other). Since LaTeX is essentially a macro collection, we have lots of interconnected filename references. On the face of it, requiring filename changes for each individual file is too restrictive, as it can require large amounts of overhead due to cascading filename changes, and it forbids modified versions from processing standard documents (as in: you can't change what "article" does, you can only add "article-hacked"). However, as it turns out, there is a process where you can limit filename changes and provide "macro substitution" at runtime on filenames, so that (for example) "article-foo" can be called when "article" is referenced in a document. This reduces the problem back down to the level of changing C source file names; it's an annoyance to have to write the redefinitions, but nothing more. This also requires changing the name of the "binary", but that's OK too. So, it's my understanding that this is DFSG-free. > > I can accept the argument: that you want it excluded and intend to change > > the > > clause in this way, but this is a different argument then (and I don't think > > that this is actually the consensus within Debian right now). > > The DFSG is a set of guidelines, not a legal document; it has room for > interpretation. Debian doesn't change the DFSG to indicate the details > of every debian-legal decision that required interpretation. Yes, this > means there's some ambiguity if all a person has for reference is the > DFSG text. (That's one reason these things are discussed publically.) Strictly speaking, not even debian-legal is "authoritative". A maintainer may do what (s)he wants with a package no matter what debian-legal says. However, it's likely that a maintainer who went against clear consensus on d-legal would find lots of people invoking the Technical Committee and/or filing General Resolutions to override them, so it generally doesn't happen. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: forwarded message from Jeff Licquia
On Sun, Jul 21, 2002 at 05:11:07PM -0500, Jeff Licquia wrote: > Requiring a binary file rename is also OK; I think we might even do this > now. Is it? Would you consider fileutils free under such a license? (You can change "ls" all you want as long as you rename the binary) Richard Braakman -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: forwarded message from Jeff Licquia
On Mon, Jul 22, 2002 at 01:25:42AM +0300, Richard Braakman wrote: > > Requiring a binary file rename is also OK; I think we might even do this > > now. > > Is it? Would you consider fileutils free under such a license? > (You can change "ls" all you want as long as you rename the binary) It seems to boil down to "forcing renames is free if it doesn't matter". Forced renaming ls doesn't matter, since you can symlink it, and so on. It'd just be really obnoxious. That also seems to boil down to "if it doesn't actually work, why keep it in the license?" If you can remap the filenames, why force us to rename them at all? And if you can't remap the filenames in *all* cases, such your changed version is used by default in a distribution, then the restriction does matter--and then seems non-free. I've stopped trying to follow all of the technical discussion on whether the facilities are "good enough" or not, since it seems like this can be figured out at a much higher level. If it lets you do anything and everything you could do without the restriction, it's free but pointless (since it lets you do whatever you're trying to prevent); otherwise it's not free. (IMO.) -- Glenn Maynard -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: forwarded message from Jeff Licquia
On Sun, 2002-07-21 at 17:25, Richard Braakman wrote: > On Sun, Jul 21, 2002 at 05:11:07PM -0500, Jeff Licquia wrote: > > Requiring a binary file rename is also OK; I think we might even do this > > now. > > Is it? Would you consider fileutils free under such a license? > (You can change "ls" all you want as long as you rename the binary) Sure, why not? I used this very example, and thought that Mark Rafn's rebuttal was persuasive; see http://lists.debian.org/debian-legal/2002/debian-legal-200207/msg00153.html and the responses for details. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
