Re: LaTeX Public Project License, Version 1.3 (DRAFT)
You made some good points. 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. So:
- no, a "file" is not "something covered by the LPPL".
- 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.
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 <licquia@debian.org> wrote:
> >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.
>
> 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'.
That's great. We've respectfully disagreed with RMS in the past, and
may very well disagree with him in the future.
> >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.
> "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.
> >These mandatory modifications may make it non-free. 3, 4, and 5 are
> >probably OK, but I'm not sure about 6.
>
> What would be the problem? With physical machinery, you as a rule will void
> your warranty if you change it without the concent of the manufacturer. I
> would say that you would involve yourself in fraudulent proceedings if you
> then sell a modifed machine to someone else without clearly informing that
> person that the manufacturer is no longer responsible for the machine.
> Certainly, with computer programs there are no warranties, but bug reports
> serve a similar purpose.
Thinking about this a little more, I don't think 6 is non-free. The
important part is that it doesn't tell you what you must modify the
report address to; it simply requires you to strip the standard report
address. That's more in line with disclaimers of warranty and such,
which are OK.
> >> 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.
>
> I'd say the clause _requires_ you to list them, since the license for the
> modified file would not otherwise fulfill the conditions. The person
> modifying an already modified file is not bound by the license of the
> original file, but only by that of the modified file, and thus it would be
> the one who offers an incorrect license for a modified file that is in
> violation of the license of the original file.
Actually, the modified file must still honor the original license unless
explicitly granted permission not to.
This paragraph appears to grant that permission:
> 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.
However, you will note that the clause applies to distribution
conditions only. No clause of the license covers what conditions
modified files may be modified under. Therefore, the only rights you
have regarding modification are rights under the LPPL, which require
another name change.
> >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?
>
> That matter is not regulated in the LPPL, and there is probably no way of
> doing that either. Noone has claimed that it would make the world perfect.
Lack of perfection is not a valid excuse to shrug off criticism. We're
not asking for theoretical perfection; we're asking you to fix a finite,
explicit list of problems.
Indeed, it would seem that if it's impossible for a license to avoid
ambiguity, that could be seen as a fundamental flaw in a license. Of
course, some licenses are intended to be ambiguous, so that the
copyright holder has latitude in prosecuting users at a whim. For free
licenses, though, ambiguity is considered bad.
> The problem is that history has shown that if modified files exist which
> occupy the name of the original then the result is a mess noone wants. The
> license imposes conditions on modification to prevent this mess from
> arising, by making it considerably more difficult to legally create files
> that may be mistaken for files in The Program. It is not foolproof, but it
> certainly serves its purpose.
It is also non-free as you describe it here.
The problem is that you are trying to take on the responsibility of
preventing messes. That's fine, though I doubt you'll be able to
prevent all messes without a proprietary license.
However, you're also limiting people's ability to improve the software
when you limit their ability to muck it up. Freedom is about not having
to ask people's permission to think differently, or even to be wrong.
> Now you're trying to hack without forking. Stop trying---you have nothing
> to gain from it!
[...]
> Again: If you want to hack, then make a proper fork first.
[...]
> The Current Maintainers are allowed to work on it as a team. Other people
> are adviced to fork before they hack.
No elitism here, surely.
Again, assuming they're allowed to fork (which, I will point out, is
still unproven).
> >It would be interesting to find out if copyright law supports their
> >assertion that renaming a file constitutes modification.
>
> Hmmm... You mean would the courts overrule the definition in the license of
> what "modification" means when it is used in that same license? Sounds
> silly to me; the license says it does not restrict activites other than
> distribution and modification, but if it then defines that renaming is
> modification then surely the internally consistent interpretation that
> renaming is restricted should apply. Then again, you never knows for sure
> with courts.
No; I'm just saying that you do get certain rights via fair use. I
don't know if "mv foo bar" is fair use or not, but I suspect that it
is. Certainly it would if "foo" were an illegal name on the user's
system (but that exception is already covered in the license).
> >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.
>
> I take it that this refers to your classification of files as free or
> non-free, and a corresponding organisation in different directories.
No. It refers to our classification of *packges* as free or non-free.
Furthermore, non-free packages are not part of Debian proper; they do
not receive the same support and QA, generally speaking.
We do not distribute individual files from "projects"; we distribute
them in aggregate form, usually in the same form we receive them from
upstream software authors.
> >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.
>
> But the tarball is not The Program.
Again, this is unproven.
> Nor is it required that the files of
> The Program are given any particular organisation into a specific directory
> structure or even that all of The Program resides on the same physical
> medium.
Really?
The implication of this assertion is that I can remove any file I wish,
even though I can't change them without the whole renaming business.
That seems to contradict the Project's goal that LaTeX work in a
predictable manner on all systems that have it. If you can't predict
that the "article" object will be available when you need it, then
that's a pretty serious deficiency.
Also, technically, hard links and symlinks aren't files (at least, not
under my definition of "file"; do you understand the importance of
definitions yet?). So:
/usr/share/latex/article.sty -> /usr/share/latex/article-hacked.sty
would be allowed under this interpretation of the license. Bada boom,
bada bing; I've just subverted the Project's stated goals within the
terms of the license. :-)
> It is however also the case that some modifications of .ins files may be
> desirable. .dtx files may contain variant sections of code and it is
> sometimes useful to generate a file with a different set of such variant
> sections than the official .ins file does. The natural way of creating the
> necessary command for this is to modify the .ins file, but the current (as
> well as the draft under discussion for) LPPL prohibits this. It seems to me
> that a better restriction would be to say something like
>
> In addition, all files generated by running a modified .ins
> file must meet the conditions in the license for modified files.
>
> Hence `classes2.ins' would not be allowed to generate an incorrect
> `book.cls', but it would be allowed to generate any `book2.cls'. Whether
> `classes2.ins' could also be allowed to generate a `book.cls' with the
> original legal notice is a trickier matter. I don't see that it would
> compromise the integrity of The Program, and it could be useful to supply a
> different argument to \usedir, but there could also be problems with it.
Legal notices can be invariant; there's no problem there. (Though
questions of charset conversion and the like may be important; I don't
know. Are legal notices stored in TeX-style, or do you actually embed
UTF-8 or ISO-8859-1 or whatever in them?)
The general problems of requiring filename changes still apply, but I
would agree that something like what you describe is better than what's
currently in the license.
> Even if challenges are made just to be mean to someone else (or to obstruct
> improvements in a program, perhaps to gain relative advantage for a
> competing program), one still has the option to fork the program. I doubt
> any other scheme could really be useful. What if for example the Copyright
> Holder has died in an accident but told a friend the day before that he had
> decided to change the maintenance 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.
Assuming that right exists, then IMHO it would be better to dispense
with the "Current Maintainer" stuff, and just let people fork the
program if the current maintainers slack off, are killed, etc.
But again, it's not spelled out in the license.
> >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.
Right. But I still don't know what constitutes a challenge, what
guidelines are followed to determine whether a challenge is legitimate
or not, or what would give me the right to object under the "pertinent
community" provision of 2b.
--
To UNSUBSCRIBE, email to debian-legal-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Reply to: