Re: A few more LPPL concerns
On Sun, 2002-07-21 at 15:30, Mark Rafn wrote:
> Thanks Boris and Frank for explanations of how some forks could be made.
> It's a delightful edge case for us, and gives Debian a chance to reflect
> on where the lines are and just how much liberty is required in order to
> be "free enough".
>
> My current personal opinion is that the individual filename restrictions,
> especially where the filename is part of the API, make it too proprietary
> to comfortably distribute as part of Debian. I still can't tell whether
> this is a wording issue or a fundamental disagreement.
>
> Presuming it's a wording issue, there are also a few smaller issues in the
> LPPL-1.3 draft (
> http://lists.debian.org/debian-legal/2002/debian-legal-200207/msg00007.html
> is still the latest version, right?) that would be good to address in the
> next iteration.
You might be interested in my original flame which started this whole
roller coaster going:
http://lists.debian.org/debian-legal/2002/debian-legal-200207/msg00036.html
> > 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.
>
> Did this bother anyone else, or am I out in left field again? I don't
> think it's actually enforceable, as it becomes a use constraint rather
> than a distribution (in the normal sense of the word) constraint, but even
> the attempt is unpleasant. I can accept (unhappily) some hoops required
> to give out modified copies of your software. I cannot accept that a
> Debian customer isn't allowed to change the software on a machine she owns
> (but isn't the sole user) without following these hoops.
I addressed this a little bit in my post. Basically, if the
modification terms are themselves DFSG-free, then the DFSG is satisfied
despite this clause. However, this does have implications for forked
development of files, particularly team development.
> > 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.
>
> I'm not sure what this is intended to do, and it would certainly be
> clearer if it were written in the active voice. What is a licensee
> allowed or not allowed to do based on this paragraph that is not otherwise
> covered? It seems either a limit on the restrictions that the recipient
> can put on new files, or a guarantee that the main license supersedes
> individual files.
>
> But the exception for "modification or distribution of modified versions",
> makes this pretty meaningless, doesn't it?
See my analysis of the licensing status of the tarball. If the tarball
itself is licensed under the LPPL, then one may rename and modify it.
This clause attempts to get around that loophole.
> > MAINTENANCE OF THE PROGRAM
>
> I'd be tempted to split this section and all references to the current
> maintainer and maintenance status into a seperate document. Dual-license
> the software, such that the LPPL is available to anyone who recieves the
> package, and the "LP Maintainer License" is available to people who fit
> the requirements as defined in that document.
I'm not a big fan of the "Current Maintainer" stuff, although I
understand the LaTeX Project's need to reassure their users that the
program will not be abandoned. Again, I posted some specific criticisms
in my above post.
--
To UNSUBSCRIBE, email to debian-legal-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Reply to: