Re: TeX Licenses teTeX (Was: Re: forwarded message from Jeff Licquia)
On Mon, 5 Aug 2002 21:22:24 +0200, Frank Mittelbach [EMAIL PROTECTED] wrote: no i'm saying that my understanding of his [Donald E. Knuth's] intentions is that he wants to ensure that within a TeX system (ie program plus surroundings) \font\foo=cmr10 refers to his CMR10 and \input plain to his plain.tex I believe that the following quote from fontname.texi (author Karl Berry, de-TeXInfo-ified by me) makes the interpretation that he reserves the right to enforce this legally rather unlikely. A fontname mapping file === At the moment, most implementations of TeX look up a TFM file (as part of the \font command), by searching for a file with the name given by the user (possibly in any of series of directories). But if we also looked TFM names up in *another* file (or set of files), which specifies the actual filename, the fontname given in the TeX source file could be almost anything at all, of any length. In version 5.851d of Web2c, I implemented this mapping file. Each file texfonts.map in a search path is read for abbreviations. The file has a straightforward format: each line specifies the filename and the TeX name for one font, separated by whitespace. Extra information on the line is ignored; then more information could be specified for the benefit of DVI-reading programs in the same file. Comments start with % and continue to the end of the line. Besides allowing long names, this sort of mapping file has other benefits. TeX source or DVI files can be more easily transported, because the font names in a particular file can be made work on every system. Also, when combined with a consistent naming scheme, macros could be written to access any of a number of fonts. Right now, each font family has to have specialized macros written to deal with it. (Background info for the Debianites: What Karl describes above could be useful with the font selection scheme set up by plain.tex, but I don't think it is used much these days. Instead the de facto standard is to use the New Font Selection Scheme, which is integrated with LaTeX2e but also exists in a version for use with PlainTeX.) Incidentally, Professor Knuth has approved this as a legitimate ``system-dependent'' extension; a TeX with such a feature can still be called ``TeX''. Hence if anyone was to add the line ptmr7t cmr10 to texfonts.map in a Web2C system (such as teTeX) then \font\foo=cmr10 would no longer load Knuth's cmr10. Apparently this does not contradict the trademark license on TeX (provided we can trust Karl Berry on this matter, but I think we can). Lars Hellström
Re: TeX Licenses teTeX (Was: Re: forwarded message from Jeff Licquia)
At 08.38 +0200 2002-08-11, Thomas Bushnell, BSG wrote: Lars Hellström [EMAIL PROTECTED] writes: However concerning the CM fonts I think you're wrong, since the conditions for these are indeed very similar to those of the LPPL; it's just the case that the LPPL relaxes these conditions in some cases. If you think a rename file before modification rule is clearly DFSG-free then I'm glad, but there are others that need to be convinced of that too. A key difference is that the CM fonts source need not be installed (tetex automatically runs METAFONT in some cases, but it could easily be pointed at different source names). Users use *.tfm files when running TeX, and the restrictions on *.mf names are not restrictions on *.tfm names. That's a key fact. However, the LPPL restricts the actual filename the user normally uses, rather than a name that really appears only in the source. You've got TeX mixed up with METAFONT in this argument. The *.mf files are METAFONT programs, and their names are indeed what the METAFONT user normally uses. When LPPL is applied to *.sty, *.cls, etc. files then it is applied to TeX programs, and their names are what the TeX user normally uses. It is true that one doesn't need cmr10.mf, but rather cmr10.tfm, to run TeX, but one similarly does not need any part of LaTeX or PlainTeX to dvips mpman.dvi, even though one probably would need that to TeX mpman.tex. Lars Hellström
Re: TeX Licenses teTeX (Was: Re: forwarded message from Jeff Licquia)
be built into METAFONT and all the other programs in a TeX system. Are there then any catches in this? There are at least two: It is essential that .sty etc. files generated by docstrip are not considered to be built software in the sense of DFSG4 sentence 2, since that would render the necessary protection of file names useless. Hopefully the fact that these files _can_ be patched by the standard patch program is sufficient for not making them built software. It is also perfectly possible that the license for the Computer Modern fonts, if a clear and authorized statement of such could be found, would disallow such runtime patching of the Computer Modern METAFONT sources. In that case the CM fonts might well turn out to be non-DFSG-free, but that needs not be a critical problem, as all the TFMs could be included in main anyway and there are free Type 1 fonts that can be used instead of the MF-generated bitmaps. Lars Hellström
Re: Font license recommendation
On 08 Aug 2002 15:37:29 -0700, [EMAIL PROTECTED] (Thomas Bushnell, BSG) wrote: Lars Hellström [EMAIL PROTECTED] writes: In a broad sense of intent perhaps, but I got clear impression Thomas had something much more concrete and close in mind. The GPL applies to anything that counts as a derivative work, with some explicit exceptions (mere aggregation, for example). The copyright law itself (as nearly every law) considers intent to be of cardinal importance when considering cases of contributory infringment, and since the GPL reaches just as far as copyright, intent therefore matters in deciding where the GPL's conditions attach. OK, this makes sense. It was something more concrete, but working at a different level. Whereas this in principle could affect the inclusion-of-font-in-PS matter, I doubt that it will in practice. It does however seem to me that this aspect has a direct application to another matter, namely that of tarballs. Jeff claimed in our discussion regarding the LPPL that, as I understood it a general principle, tarballs automatically become derived works of whatever is stored in them and that any license conditions for derived works would automatically attach themselves to the tarball. (In particular: if some file in the tarball has a rename before modify condition then that would apply to the tarball as a whole and thus, I suspect, the tarball would have to be renamed whenever anything was added to or removed from it.) The above principle of intent seems, at least to me, to void that argument. As long as there is no intent to use the tarball in any but the normal ways then the conditions concerning derived works do not attach to it. Instead the conditions attached to the tarball (at least this is what I would expect as default conditions, if nothing else is said) should be that whatever is produced by extracting the contents of the tarball in the most common way satisfies the conditions for the files that have been put into the tarball. Lars Hellström
Re: Bug#153257: TeX Licenses teTeX (Was: Re: forwarded message from Jeff Licquia)
On Mon, 5 Aug 2002 11:10:12 -0500, Branden Robinson [EMAIL PROTECTED] wrote:
On Mon, Aug 05, 2002 at 09:53:20AM -0600, Julian Gilbey wrote:
On Mon, Aug 05, 2002 at 09:33:37AM -0500, Branden Robinson wrote:
I repeat: the file renaming requirement is not DFSG-free, and you
wanting it to be so will not make it so. DFSG 4 does not permit it.
4. Integrity of The Author's Source Code
The license may restrict source-code from being distributed in
modified form _only if the license allows the distribution of
patch files with the source code for the purpose of modifying
the program at build time. 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 to
not restrict any files, source or binary, from being modified.)
Note the ***...*** section.
The license may require derived *** works *** to carry a different name
or version number from the original software.
Note the ***...*** section.
A filename is not the name of a work any more than an MD5 checksum is.
Your whole argument rests on this interpretation of name in the third
sentence of DFSG:4 as meaning name used to legally identify, correct? And
the only tangible support you have for this interpretation is the presence
in that sentence of the word work, which is (amongst many other things) a
legal term. All the rest is, despite its verbosity, merely an expression
for you[1] wanting it to be so.
I suggest that this interpretation of name here is at best an implausible
one. For one thing the word name has a number of interpretations, as it
is a very general term. If your legalistic interpretation really was all
that the author(s) of the DFSG had in mind there then wouldn't title had
been a much more natural choice? I strongly suspect that title _is_ the
proper legal term.
My main objection to your interpretation is however that name is used in
parallel to version number, which is a much more precise term. version
number is not a legal term -- the legal term would probably rather be
edition -- but something very practical and technical in nature. It is
furthermore the case that version numbers often have a functional purpose.
Programs regularly inspect and interpret the version numbers of other
programs, and they may behave quite differently depending on what version
numbers they find. Admittedly this may be uncommon in the world of C
programs, where communication between different programs is quite an
endeavour, but it is common practice for packages that get loaded into an
interpreter and the LaTeX way of reacting to version numbers is definitely
not the most restrictive in this area.
Thus for any restriction you want to impose on what DFSG-free licenses may
require in the area of renaming, consistency requires you to impose the
same restriction with respect to version numbers. Take the example that a
work
% Copyright 2002 M. Y. Name
% The foobar package ... license ...
\ProvidesPackage{foobar}[2002/06/01 v1.00]
...
is licensed so that modified versions must be renamed, e.g.
% Copyright 2002 M. Y. Name, A. N. Other
% The newfoobar package ... license ...
\ProvidesPackage{newfoobar}[2002/07/02 v1.00]
...
If you think such a license is non-free because the newfoobar in the first
argument of \ProvidesPackage is functional then it would be inconsistent
to not declare as non-free also a license that only requires a version
number change, e.g.
% Copyright 2002 M. Y. Name, A. N. Other
% The newfoobar package ... license ...
\ProvidesPackage{foobar}[2002/07/02 v2.00]
since this new version number would still be functional. If you restrict
renaming to instances where the name cannot be reliably checked by computer
then you must put a similar restriction on version numbers. However I don't
believe that appearing in a comment somewhere in the source, while being
contradicted in the code is the normal interpretation of carrying a
version number in the community that has to interpret the DFSG.
Lars Hellström
[1] On a completely off-topic matter, shouldn't that rather be your
wanting it to be so, with a possesive pronoun and the -ing form of the
verb? Perhaps someone natively English-speaking can clarify this; I suspect
it could be a matter on the lines of who vs. whom.
Re: Font license recommendation
On 04 Aug 2002 20:22:11 -0500, Jeff Licquia [EMAIL PROTECTED] wrote: On Sun, 2002-08-04 at 17:53, Lars Hellström wrote: At 00.53 +0200 2002-08-03, Thomas Bushnell, BSG wrote: Since things like intention matter--and not just technical mechanism--this is just FUD. FUD ? On what do you base your opinion that intent has any significance for whether the GPL allows an action? Well, there's this: The source code for a work means the preferred form of the work for making modifications to it. (section 3) Preferred is an intent, last time I checked. Intent. A purpose or aim; meaning; import. Syn.: Design, purpose, intention, drift, significance, view, aim. Prefer. To regard or esteem more than something else; to place in a higher rank or position; to give priority to; to seek recompense. In a broad sense of intent perhaps, but I got clear impression Thomas had something much more concrete and close in mind. It's used against people who use obfuscators on their source before distribution, for example, because no one in their right mind would intend to edit the obfuscated source to add features or fix bugs. True, and as I mentioned (see below) there is a lot in the license about the intent of the license, but the question was rather about whether the intent of the person who performs an action has any significance for the GPL allowing that. If you insist on that intent matters, then you have to explain why it could be OK to link GPL-compatible and GPL-incompatible code into one program when (i) the person doing it wants X, but not when he wants Y; or (ii) the program does X, but not when it does Y. There's also this: The act of running the Program is not restricted, and the output from the Program is covered only if its contents constitute a work based on the Program (independent of having been made by running the Program). Whether that is true depends on what the Program does. What the Program does is also intent. Incidentally, the latter paragraph also provides reason to believe that a PostScript file generated using a GPL font does not become tainted with the source requirements of the GPL. (No, it's not clear-cut; I'm not necessarily arguing that it's the case, just that it's possible.) But the PS file is no more output from the font than a binary executable is output from an object code file which was linked into it. The font is not run until the document is rendered. _Maybe_ you could make an argument that distilling a PS file is running it and that fonts in the PDF are output of the fonts in the PS, but that is shaky too. In particular, the procedures for actually drawing the glyphs (which are what commercial copyright holders are most keen on protecting) are generally left unchanged. It clearly says You may not copy, modify, sublicense, or distribute the Program except as expressly provided under this License. Any attempt otherwise to copy, modify, sublicense or distribute the Program is void, and will automatically terminate your rights under this License. and I don't see any reference in it to the intent of the licensee (only to the intent of the license, but that is something quite different). That's because intent is a subject of other parts of the license. Both its refer to the license as a whole. Furthermore I don't see that there would necessarily be any difference in intent. Certainly if one writes a program whose only purpose is to demonstrate a legal loophole there would be a difference in intent, but that isn't the interesting case. In the interesting case the intent is to make a single file program, incorporating various pieces of free software (some of which are GPL and some of which are GPL-incompatible), that does X. The X could be to display a certain picture; PS files can have this intent, but there are also C programs with the same intent. Well, let's take the Gimp. It processes one image file into another, and is GPLed. Does that have any implication on the legal status of either image? What if the original is GPLed? Especially given that most image formats are their own preferred format for modification, things are not so clear as they might seem. Gimp requires very precise input to produces the picture, which is why the GPL paragraph you quoted above is applicable; the output is not a work based on Gimp. Likewise, when I use a postscript printer driver, I don't claim that the PS file it produces is a work based on the driver. One could make the case that a font is an interpreted language, with the font renderer as the interpreter. _Postscript_ is very much an interpreted language, PS fonts are code libraries (with exception for pure bitmap fonts, which are rather data, but those are rare these days), and GhostScript is an example of an interpreter for that language. In that case, a rendered glyph could be considered output from the Program. Agreed. OTOH, the font could be considered data that is input by a font
Re: Font license recommendation
At 00.53 +0200 2002-08-03, Thomas Bushnell, BSG wrote: Lars Hellström [EMAIL PROTECTED] writes: I doubt this argument could work. However if it did then it certainly would provide a technical solution to the (obnoxious?) GPL incompatibility problem: just design the linker so that it pads the executable with markup saying beginning/end of material that is part of the work XXX, and then claim the file is an aggrevation of different works, which just happens to be interpreted as an executable program by the OS. Since things like intention matter--and not just technical mechanism--this is just FUD. FUD ? On what do you base your opinion that intent has any significance for whether the GPL allows an action? It clearly says You may not copy, modify, sublicense, or distribute the Program except as expressly provided under this License. Any attempt otherwise to copy, modify, sublicense or distribute the Program is void, and will automatically terminate your rights under this License. and I don't see any reference in it to the intent of the licensee (only to the intent of the license, but that is something quite different). Furthermore I don't see that there would necessarily be any difference in intent. Certainly if one writes a program whose only purpose is to demonstrate a legal loophole there would be a difference in intent, but that isn't the interesting case. In the interesting case the intent is to make a single file program, incorporating various pieces of free software (some of which are GPL and some of which are GPL-incompatible), that does X. The X could be to display a certain picture; PS files can have this intent, but there are also C programs with the same intent. And just to make sure we're clear on what my point is: Incorporating a GPLed font in a PS document does, in contrast to what you claimed, have (in many cases) unwanted legal implications; if it didn't then there would be a simple workaround for GPL-incompatibility. Lars Hellström
Re: Font license recommendation
At 04.42 +0200 2002-07-31, Thomas Bushnell, BSG wrote: Lars Hellström [EMAIL PROTECTED] writes: The problem with GPL'ing is that anyone who recieves a PS file using a GPL'ed font could then claim that the PS file in its entirety must be GPL'ed and thus request to get the (.tex or similar) sources for the PS file, since these would be the preferred form for making modifications. If the font is really separate: that is, if the encoding is done in such a way that it's easily extractable, then it clearly seems like a case of a mere aggregation. It odd to see such a conviction that this is aggregation, which is harmless here on this list, considering that it was recently claimed that a tarball (!) must be considered to be single work until proof of the contrary has been obtained, without any objections from the regulars. Can anyone think of any use other than aggregation for a tarball? But perhaps there are double standards at work ... I don't believe that interpretation of the GPL aggregation clause In addition, mere aggregation of another work not based on the Program with the Program (or with a work based on the Program) on a volume of a storage or distribution medium does not bring the other work under the scope of this License. is plausible enough to rely on in my case, but it could be interesting to examine the matter more closely. Webster's New Illustrated Dictionary defines aggregation as a collection of particulars and a particular as an individual thing or point or quality. Is it then the case that anything which is a collection of things with individuality becomes an aggregation? The it's just an aggregation argument against the GPL would then be that as long as you can tell, for each piece of code in a program, whether it is generated from GPLed source or non-GPLed source, then the program as a whole is merely an aggregation and the condition in the GPL that a combined work must be GPLed would not apply. I doubt this argument could work. However if it did then it certainly would provide a technical solution to the (obnoxious?) GPL incompatibility problem: just design the linker so that it pads the executable with markup saying beginning/end of material that is part of the work XXX, and then claim the file is an aggrevation of different works, which just happens to be interpreted as an executable program by the OS. Theoretical excursions aside, it seems to me that the Design Science License (as suggested by Martin Schröder), with an extra clause (as suggested by Walter Landry) that inclusion in documents is fine, will be appropriate for what I had in mind. In particular a renaming clause certainly is a *good* thing when it comes to fonts and the like. Lars Hellström
Re: Font license recommendation
At 01.14 +0200 2002-07-29, Thomas Bushnell, BSG wrote: Some document formats include programmatic fonts in the document. This is indeed the custom for PS and PDF, yes. Furthermore I'm afraid this is how the font would normally be used. I think here the question is whether the combination is font-program plus text is a single program or not. This comes up if the license you want is the GPL. It would be bizarre in the extreme, it seems to me, to regard the combination as a single program (at least, assuming you don't massively intertwine them). I think this would be a matter of mere aggregation. PDF files are mainly data, but it quite reasonable to think of a PS file as a program (a program that tells the printer to draw the thing you want to print). In fact, PS files are often more program-like than PS Type 1 fonts are! The problem with GPL'ing is that anyone who recieves a PS file using a GPL'ed font could then claim that the PS file in its entirety must be GPL'ed and thus request to get the (.tex or similar) sources for the PS file, since these would be the preferred form for making modifications. However, note that if the document format distributes font-programs in something other than source, and you want to use the GPL, you need to make sure the source gets sent along with the font-program somehow. (Perhaps the document format has some kind of comment syntax where you could stash it.) It could in principle be included as comments, but that would look truly bizarre. Another reason not to use GPL, then! At 15.25 +0200 2002-07-29, Henning Makholm wrote: Scripsit Boris Veytsman [EMAIL PROTECTED] It seems that you consider the inclusion of fonts to be the same as linking of libraries. Then LGPL might be what you need. The LGPL's rule would mean that it would be forbidden to distribute compound works linked in such a way that the font cannot be changed independently of the rest of the contents. In some jurisdiction this might prevent the production of hardcopy documents using the typeface. This sounds strange. Isn't the hardcopy rather output from the program? It would be better to give an explicit permission to use the font freely in documents. The case is so special that it is not advisable to rely on analogies with software. You mean I could say something like This font is free software; you can redistribute it and/or modify it under the terms of the GNU Lesser General Public License ... Furthermore the font can be included in documents without any additional restriction. ? I suspect the wording in that furthermore clause could be tricky however. Verbatim copying is too restrictive, since fonts are commonly subsetted as part of the inclusion process. With such an explicit permission, the GPL would seem to be suitable - the metafont (or whatever) source could play the role of .. well, source, and bitmapped renderings or translations into write-only formats (postscript type 1??) would count as binaries. The latter of these, yes. Bitmaps are generally deprecated these days. Of course, depending on one's personal preferences, a BSD style license could do the job, too. BSD style licenses doesn't seem to require that the source is made available. That it should be available was my main reason not to simply choose public domain. Lars Hellström
Re: Question(s) for clarifications with respect to the LPPL discussion
At 04.17 +0200 2002-07-23, Jeff Licquia wrote: On Mon, 2002-07-22 at 18:24, Lars Hellström wrote: At 01.31 +0200 2002-07-22, Jeff Licquia wrote: Right. The question is what modification rights do you have? There's good reason to believe that the must change the file name clause must apply to derived works as well, so each time a file changes, its name must change. The claim in that last sentence is certainly unproven, and the license text makes yours a highly unlikely interpretation. So you say. But why should I believe you? It certainly doesn't seem unlikely to me. (Remember, again, that I don't care about the intent of the license. I only care what it says.) [snip] Again: IF THAT'S WHAT IT MEANS, THEN WHY DOESN'T IT SAY THAT???!!!??? OK, at least now you're being clear that you in this thread apparently insisted on discussing a precise text, not as elsewhere at the same time rather the intent. This has made the last few turns rather pointless. Lars Hellström -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Encoding the name in the file contents
At Thu, 25 Jul 2002 12:50:49 -0700 (PDT), Walter Landry [EMAIL PROTECTED] wrote: Boris Veytsman [EMAIL PROTECTED] wrote: Let me tell you how the things are organized in the TeX world. There are dozens of TeX implementations. Some are free, some are commercial, some are open, some are closed. I would not be surprised if some of these are not written in C and do not use the standard web2c. The authors of these implementations package LaTeX with their systems. I see now. I was concerning myself with free software, whereas you have a desire to interoperate with proprietary software. Fair enough. What if this md5sum were computed using TeX? Assuming reasonable performance, would that be a solution? It would still be pointless, since there would be nothing to compare the computed checksum against, unless the file itself says what checksum it is supposed to have, and in that case we're just doing a more complicated variant of the \NeedsTeXFormat. Furthermore you most likely couldn't get anything near a reasonable performance for an md5sum implemented using TeX macros. There are, for example, no bit operations available in the language. If you think you would need any, then you would have to tabulate them, and that gets unreasonably expensive (about 20 times the cost of the LaTeX kernel and a couple of packages) already for byte operations. Boris Veytsman [EMAIL PROTECTED] wrote: Even if this were possible, did you consider the logistics nightmare of conversion of megabytes of LaTeX code written by hunderds of authors to the new authentificaiton scheme? Wouldn't this logistics nightmare happen with a license change as well? Why should there be any need to change anything but the text of the license? That's only one file. Lars Hellström -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Question(s) for clarifications with respect to the LPPL discussion
At 01.31 +0200 2002-07-22, Jeff Licquia wrote: On Sat, 2002-07-20 at 15:16, Henning Makholm wrote: Scripsit Lars Hellström [EMAIL PROTECTED] The discussion between Jeff and me turned up another main concern, regarding the distribution of modified works. In his opinion (which I now suspect holds for at least those jurisdictions where copyright is something which just arises rather than has to be claimed) it could be a problem that the LPPL does not say anything about the copyrights of the authors of the original (LPPLed work) to a modified derivative thereof. It appears that they in principle could later demand that an arbitrarily restrictive license should be applied for the derivative work. I don't think this is an actual problem. We have many licences that say you may modify and distribute your modifications if you do so-and-so, and we've always interpreted that as meaning and I promise that as long as you do so-and-so I will give my permission to the distibution of the derived work without any further requirements. Right. The question is what modification rights do you have? There's good reason to believe that the must change the file name clause must apply to derived works as well, so each time a file changes, its name must change. The claim in that last sentence is certainly unproven, and the license text makes yours a highly unlikely interpretation. The only thing it says about the licensing of modified files is: 7. You must distribute the modified file under a license that forbids distribution both of the modified file and of any files derived from the modified file with the filename of the original file. It forbids (requires that the licenses of the modified file and any files derived from that contains a clause that forbids) giving the modified file or any file derived from that the name of the original file, but it does not say anything about whether the modified file may be further modified without any change in its name. Had this been the intention then it would have been just as easy to say so, hence that is in all likelihood not how the text should be interpreted. At 22 Jul 2002 01:04:10 -0500, Jeff Licquia [EMAIL PROTECTED] wrote (under the subject Re: forwarded message from Jeff Licquia): I distribute it to my friend Ralph. Now Ralph modifies it: foo bar baz quux The question is: what name shall he give the new file? Let's assume that I don't care. Thus, this line baz is unencumbered. Of course, the line quux is his. But what about the other two lines? They are licensed under the LPPL, which states: If for any part of your program you want or need to use *distribution* conditions that differ from those in this license, then do not refer to this license anywhere in your program but instead distribute your program under a different license. You may use the text of this license as a model for your own license, but your license should not refer to the LPPL or otherwise give the impression that your program is distributed under the LPPL. Note that *distribution* conditions are waived (except for the filename thing), but *modification* conditions are not. So, when people modify files containing LPPLed work, they must honor the copyright on the part with LPPLed code as well. I've told you before: you're completely misinterpreting this paragraph; probably because you've taken it out of context. What it means is roughly that it is OK (although not free) to start a file with % pig.sty % Copyright 2002 M. Y. Name % % This program may be distributed and/or modified under the % conditions of the LaTeX Project Public License (either version 1.3 % of this license or (at your option) any later version), as long % as you in addition pay $99 to M. Y. Name before making any % modifications to this file. % The latest version of this LaTeX Project Public License is in % http://www.latex-project.org/lppl.txt % and version 1.3 or later is part of all distributions of LaTeX % version 2002/06/01 or later. \endinput % This renders this file useless, and must be % removed or worked around to get some use out of this file. ... % Now do some really cool stuff since that extra condition is a _modification_ condition. It is however not OK to say % pig.sty % Copyright 2002 M. Y. Name % % This program may be distributed and/or modified under the % conditions of the LaTeX Project Public License (either version 1.3 % of this license or (at your option) any later version), as long % as it is not given to Saddam Hussein, dictator of Iraq. % The latest version of this LaTeX Project Public License is in % http://www.latex-project.org/lppl.txt % and version 1.3 or later is part of all distributions of LaTeX % version 2002/06/01 or later. ... % Now do some really cool stuff (although it wouldn't totally surprise me if there was a US law requiring its citizens---and everybody else that rogue state might
Re: LaTeX Public Project License, Version 1.3 (DRAFT)
At 06.07 +0200 2002-07-17, Jeff Licquia wrote: You made some good points. Thank you. The problem is that *most of your good points simply aren't in the license*, and the license is all I can rely on when I try to figure out my rights. Some of my points certainly refer more to what is the custom (for how the license is interpreted) than to what is necessarily in it. Frank has however made clear that the entire text of the license certainly is under the knife and hence that these points are not clear in the draft isn't, IMHO, a serious problem. What most (La)TeX users participating in this discussion are interested in isn't primarily that the text of the license is preserved, but that the *spirit* of it (as reflected in common practice) is. So: - no, a file is not something covered by the LPPL. My point was that the LPPL by itself has no built-in relevance for a file. There must also be a legal notice (created by the copyright holder for that file) stating that the terms of the LPPL applies for this file. In the case of LaTeX (the work), this legal notice is in the file legal.txt, and it defines LaTeX (the work) to be the contents of a set of files, which are listed by name (in the file manifest.txt). In the case of the `pig' package that is used as an example in the LPPL, we find % This program consists of the files pig.dtx and pig.ins % and the derived file pig.sty. so that there is again a definition of which are the files of The Program. - yes, a tarball is a file by the normal definition of file. - no, since you aren't allowed to distribute the Program in modified form, non-free additional restrictions cannot be removed. I have not claimed the contrary. A program with additional non-free restrictions is not free, but that doesn't say the LPPL by itself is a non-free license, just that works that from a _modification_ viewpoint are non-free can be _distributed_ under the terms of the LPPL. What we ask is that (some version of) the LPPL without additional conditions is approved by Debian, not that all possible extensions of the LPPL are approved. If you don't agree, then point out the sections of the license that explicitly disagree with this assessment. On Mon, 2002-07-15 at 17:56, Lars Hellström wrote: At 11 Jul 2002 16:05:14 -0500, Jeff Licquia [EMAIL PROTECTED] wrote: Consider Program foo, distributed as foo-1.0.tar.gz under the LPPL. Noone would license foo-1.0.tar.gz under the LPPL. What is licensed under the LPPL are files archived in foo-1.0.tar.gz. Then the file foo-1.0.tar.gz itself has no license, and cannot be distributed at all. The matter of whether a file has a license has absolutely no relevance for whether it is techincally possible to distribute a file. Is it legally relevant? A license certainly grants various rights and so on, but I doubt it would be required by any existing legal system. Is it necessary for Debian to distribute it? That's mainly a matter of policy. The point of view that I believe to be relevant here is that creating a tarball is equivalent to copying the contents to a new file system. The owner of the medium (a file in another file system) in which this file system resides certainly has some rights to it, but licenses guarding files in this file system can restrict those rights. The situation is not unlike that which the publisher of an anthology is faced with: he has the right (largly acquired through various agreements) to print (and so on) the anthology, but the rights to the works contained in the anthology remain with the authors (or other copyright holders) of these works. Unpacking may be a suboptimal term in this case. What is primarily meant is the generation of .sty, .cls, etc. files from (mainly) .dtx files, as controlled by commands in .ins files. The process is more like the compilation of some sort of binary from the actual program sources than unpacking of compressed data. The reason the LPPL uses this term is probably that there has traditionally been two kinds of LaTeX distributions: packed (not including any generated files) and unpacked (including generated files, as well as their sources). I would agree. How to solve this is tricky, though, since technically these generated files are the output of the program in one sense. Obviously, you don't want to limit people's ability to process LaTeX documents into camera-ready output. You could, perhaps, define results of building the Program and output from using the Program, and limit them differently. The view taken in the LPPL is, although it may certainly need clarification in the license text, that the generated files are principally part of The Program, even though they need not actually be present in a copy of The Program for that to be complete. The idea that a program may have such virtual components could be seen as suspicious, but a compiled binary is in a similar sense virtually present in the sources. That the names of these virtual components need
Re: LaTeX Public Project License, Version 1.3 (DRAFT)
At 10.58 +0200 2002-07-16, Branden Robinson wrote: On Tue, Jul 16, 2002 at 12:56:22AM +0200, Lars Hellström wrote: You would probably find the current licence even less free. Richard Stallman is however (by various LaTeX team members) reported to be content with it as 'free'. You should probably be aware that the Debian Project has not sworn ideological fealty to Richard Stallman. I never thought that you did; if you had then this debate would probably had been over long ago. However, I do believe he would qualify as a counterexample to the hypothesis that Anyone who is serious about free software immediately recognises the LPPL as a non-free license. Whereas this hasn't been claimed on this list (that I know of), there has on occasion been quick dismissals of the LPPL where that hypothesis seems to have been taken for granted. :-) Lars Hellström -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: LaTeX Public Project License, Version 1.3 (DRAFT)
status of the program to author-maintained, and that the friend therefore challenges all takeover notices? In this case, accepting the challenge certainly makes less harm than rejecting it. The obvious problem is that we need a definition of challenge, perhaps in the form of a challenge protocol. There should also be a statute of limitations concerning challenges; a new Current Maintainer should be unchallengable after a certain time. (OTOH, that might make it easier for someone to hijack a program.) Those time limitations which you requested are already in place. Challenges must be made within two months, then the Current Maintainer is changed. As a special case, the previous Current Maintainer has another six months to return and make a challenge. That's it. Lars Hellström -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
