I think we've moved to a part of the debate where it would be helpful to summarize current thinking on the license. I encourage everyone to read this carefully, as I'm sure there are new concepts here for everyone involved.
First of all, I'm assuming that all issues outside of the file renaming problem are resolved in principle; that is, that the LaTeX team has expressed their willingness to fix the problem. This would include things like the definition of "file", the problem with archive files and DFSG 9, etc. If you've got an issue that isn't the file renaming thing and you haven't seen a resolution on it, now is the time to speak up. Now, for the file renaming issue. There are two parts that I foresee to resolving the file renaming problem. The first is the license text itself, and the second is the procedures document for fulfilling the conditions of the license. The license text would say something like this: ----- The Program may be modified in any way as long as one of the following conditions are met: - No part of Standard LaTeX is changed. - The Program does not represent itself as Standard LaTeX in any way, including the name and any diagnostic output. The Project distributes a file with the Program, foo.tex, that describes some procedures we have set up to allow derived works to fulfill these conditions. ----- The procedures file would reference an API call. The exact API is up to the LaTeX Project, of course; for now, we'll call it "register". All macro packages, extensions, etc. that are a part of Standard LaTeX would contain this API call, which would register the string "LaTeX". The procedures that would be described in the procedures document would reference the following ways of modifying LaTeX: 1. Copy the file you want to modify to a different filename, and modify the copy. You don't need to touch the "register" call in any way if you don't want to. 2. Edit the "register" call in the file to say something besides "LaTeX", modify the kernel to allow that extra string, and make sure that the modified kernel does not represent itself as LaTeX in name, diagnostic output, etc. 3. Change or remove the behavior of the "register" call entirely (which is a kernel modification), and make sure that the modified kernel does not represent itself as LaTeX in name, diagnostic output, etc. (Option 3 might be expressly discouraged by the LaTeX Project, but it is important nevertheless.) In addition, Standard LaTeX would have the option of refusing to use any component that did not use the "register" call to register "LaTeX". Under option 3, this behavior could be changed to include more accepted strings, completely neutered, or even removed entirely - but the result would be a modified work, and must therefore not call itself LaTeX. This makes it a little more clear that we are not putting a "zone of invariance" around some portion of the LaTeX code within the license, which may clear up some of the objections I've been trying to understand before now. LaTeX contributors who value the ability to preserve compatibility could, under this license, be careful not to collide with another file name in LaTeX currently, use the name "LaTeX" in the "register" call, and license their work under the LPPL. This would, essentially, make their add-on a part of Standard LaTeX, and it would be treated the same as any other part of Standard LaTeX with regards to modification. Please let me know whether this would work for you. I'm interested both in the LaTeX Project's reaction and Debian's. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
