[Please follow up to both lists.] On Thu, 2002-07-04 at 16:08, C.M. Connelly wrote: > > Frank Mittelbach asks that reviews be done of the draft of version > 1.3 of the LaTeX Public Project License rather than of the current > version (1.2). > > That draft is included below.
First of all, this license is nasty. The restrictions on modification are complex; the license itself predicts failure to understand its terms. Some of its terms are dependent on external factors that cannot be determined objectively by examining the Program alone. In some cases, the Program may even deceive licensees as to their rights to modify the Program. For these reasons alone, I would strongly recommend that this license not be used. Additionally, it's pretty clear that the intent of this license is to create a cabal of "approved" maintainers, and to place "unapproved" maintainers in a complex legal trap that's easy to trip. Such elitism is completely against the spirit of the DFSG and the motivations of the Debian Project, and offends the sensibilities of the whole community. If LaTeX adopts this license, then I would recommend moving LaTeX to non-free immediately and forking it if possible to preserve the (ostensibly free) current status it enjoys. > Individual files of The Program... Note that no definition of the word "file" is provided. I believe this could be construed as a loophole of some kind, and is definitely a flaw in the license. Consider Program "foo", distributed as "foo-1.0.tar.gz" under the LPPL. "foo-1.0.tar.gz" is a file by any reasonable definition, and can be reasonably construed to not contain additional restrictions beyond the LPPL. If Debian changes the file name to, say, "foo_1.0.orig.tar.gz", doesn't it then follow that Debian can change any part of that file at will? They attempt to close this loophole below, with the "unpacking" clause. I don't think they're successful. > ...may bear supplementary > and/or superseding conditions on modification of themselves and on the > distribution of modified versions of themselves, but *no* file of The > Program may bear supplementary or superseding conditions on the > distribution of an unmodified copy of the file. A distributor wishing > to distribute a complete, unmodified copy of The Program therefore > needs to check the conditions only in this license and nowhere else. Assuming the LPPL is found to be DFSG-free by itself, it cannot guarantee that a Program is DFSG-free without reading about each file's additional restrictions. (Yes, this can be true anyway, but no other free license I know of explicitly supports this practice, and some attempt to prevent it.) > Activities other than distribution and/or modification (including > maintenance) of The Program are not covered by this license; they are > outside its scope. In particular, the act of running The Program is > not restricted. An important clause, probably taken from the GPL. Its importance will be clear later. > You may distribute a complete, unmodified copy of The Program. > Distribution of only part of The Program is not allowed. This clause is also important for reasons that will be clear later. > 3. You must not distribute the modified file with the filename of the > original file. > > 4. In the modified file, you must acknowledge the authorship and > name of the original file, and the name (if any) of the program > which contains it. > > 5. You must change any identification string in the file to indicate > clearly that the modified file is not part of The Program. > > 6. You must change any addresses in the modified file for the > reporting of errors in the file or in The Program generally to > ensure that reports for files no longer maintained by the original > maintainers will be directed to the maintainers of the modified > files. These mandatory modifications may make it non-free. 3, 4, and 5 are probably OK, but I'm not sure about 6. > 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. This is odious. As people take and modify files, those files will begin to accumulate "forbidden names" over time. Unless those names are explicitly listed, the risk will increase over time that someone will inadvertently reuse a filename and run afoul of this clause. Further, the prospect of combining two files into one presents itself. Such a file would have to avoid any file name used for any previous version of either of the two files. Determining derivation could also be a problem. If two separate branches of development use the same filename, who wins? IMHO, the whole business about filenames should be stripped. One is already not allowed to distribute modified versions of the Program, and one is already forced to notify in the file itself when the file is modified. File names are not endorsements, and should never be interpreted as such. > 8. You must do either (A) or (B): > > (A) distribute a copy of The Program (that is, a complete, > unmodified copy of The Program) together with the modified > file; if your distribution of the modified file is made by > offering access to copy the modified file from a designated > place, then offering equivalent access to copy The Program > from the same place meets this condition, even though third > parties are not compelled to copy The Program along with the > modified file; > > (B) provide to those who receive the modified file information > that is sufficient for them to obtain a copy of The Program; > for example, you may provide a Uniform Resource Locator (URL) > for a site that you expect will provide them with a copy of > The Program free of charge (either the version from which > your modification is derived, or perhaps a later version). We must, therefore, distribute patches only. This isn't ideal, but it's not fatal either. > Note that in the above, `distribution' of a file means making the > file available to others by any means. This includes, for instance, > installing the file on any machine in such a way that the file is > accessible by users other than yourself. In other words, you are not allowed to hack on LaTeX in a directory that is world readable, or on a system where more than one person has the root password, or on any system without access control on files, or in a directory that is backed up regularly, etc. You are also effectively forbidden from working on LaTeX as a team; it could be done, but many of the tools that make teams work (revision control, autobuilders, etc.) would be very difficult, if not impossible, to set up. Given RMS's distaste for access controls, could this be construed as "discrimination against persons or groups"? > Changing the name of a file (other than as necessitated by the file > conventions of the target file systems) is considered to be a > modification of the file. Since Debian renames the original tarball in its source format, mere distribution of the Debian source package constitutes a modification (with the resulting invokation of clauses 1-8). The packager would be forced, I think, to use DBS to avoid that. It would be interesting to find out if copyright law supports their assertion that renaming a file constitutes modification. > If The Program is distributed in a packed form with a number of files > to be generated by some unpacking method from the distributed files, > then these derived files are logically (even if not physically > present) part of The Program and are covered by this license > independently of the method of their generation. This is where the license tries to avoid the loophole described above. However, remember that: > Activities other than distribution and/or modification (including > maintenance) of The Program are not covered by this license; they are > outside its scope. In particular, the act of running The Program is > not restricted. So, if I am allowed to modify and distribute the tarball (as a "file" under the LPPL), then the user is allowed to unpack the tarball and use its contents. The user may not have permission to distribute or modify the files contained in the tarball outside of the tarball itself. (Although there is no revokation clause, so who knows?) > An individual file of The Program may bear additional conditions that > supplement and/or supersede the conditions in this license if, and only > if, such additional conditions exclusively concern modification of the > file or distribution of a modified version of the file. The conditions > on individual files of The Program therefore may differ only with > respect to the kind and extent of modification of those files that > is allowed, and with respect to the distribution of modified versions > of those files. If any files within the Program did happen to contain additional restrictions that made the file non-free, then the file would have to be removed from the tarball before it could be uploaded to main. However: > You may distribute a complete, unmodified copy of The Program. > Distribution of only part of The Program is not allowed. Thus, the presence of even a single non-free file will pollute the entire Program's legal status, since we aren't allowed to remove it. > If a file of The Program is intended to be used with LaTeX (that is, > if it is a LaTeX software file), then the following additional > conditions, which supplement and/or supersede the conditions > above, apply to the file according to its filename extension: > > - You may not modify any file with filename extension `.ins' since > these are installation files containing the legal notices that are > placed in the files they generate. If those files contain anything besides 100% pure ASCII legal notices (for example, if they are XML formatted), then this is definitely non-free, as they force a file format and/or character encoding upon you regardless of their status as a legal notice. > The Program has the status `author-maintained' if the Copyright Holder > explicitly states that The Program can only be maintained by the > Copyright Holder. > > The Program has the status `maintained' if the Current Maintainer has > made provisions to receive bug reports for The Program (for example, > by supplying a valid email address). It is not required for the > Current Maintainer to acknowledge or act upon bug reports. > > The Program changes from status `maintained' to `unmaintained' if the > Current Maintainer of the program cannot be reached through the > provided means of communication for a period of six months and there > are no signs of active maintenance otherwise. However, a change in this status does not automatically cause changes to the advertised status of the Program within the Program itself. Thus, it is impossible to say with certainty whether the licensee has any additional rights due to a Program's advertised status. > 3b. Otherwise if the Current Maintainer was unreachable and if after > two months your intention was neither challenged by the Current > Maintainer nor by other people, you may arrange for a change of > The Program to reflect you as the (new) Current Maintainer. Other people may "challenge" a takeover notice. This makes it possible for a group of people to force an unmaintained program to stay unmaintained by simply "challenging" any takeover notices. This may even be possible after the fact if the challenger asserts that the takeover notice was not posted prominently enough. 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.) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
