Concluding the LPPL debate, try 2
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 debian-legal-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Reply to: