Re: A few more LPPL concerns
Mark Rafn writes:
> 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".
delightful? not really when you are (as I did) spent a whole week every night
till 2 in moring in front of your computer and then being woken up by my twins
between 6 and 7 next morning :-)
> 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.
I hope that perhaps my last post (or seond last) has helped there.
>
> 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.
not quite. all the stuff about stricting modification of indiviual files
further in some cases has gone as it was a leftover (and modguide was changed
back to cfgguide)
> > 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.
it is a thing where i guess a different wording culd help. Boris has already
pointed out the rationale behind it. On the other hand it is clearly going
over the top to disallow modification without renaming the moment more than a
single person is envolved. However the sysadmin case is on the other side of
the fence (sorry Nick to disappoint you, just saw your post :-) as it
typically means providing a "non-latex" under the label of "latex" to
unsuspecting users and depriving them of their expectation to get identical
documents.
so in case of Nick's company example i would expect them to call their
modified latex company-latex or whatever, ie forking at kernel level and if
necessarily forking via the cfguide suggestion so that every file can be
changed easily individually if they want to change much. even more so in the
case of a sysadmin for an installation with varying number of people, eg in an
university or so.
but i agree this may not be a distribution in legal sense and the wording may
have to change and closed groups should probably generally be exempt.
=====================================
> > 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.
that paragraph was in the original license only as an ensurance for
distributors of a work under LPPL as a reassurance that even though LPPL works
basically on file level (where FILE is not properly defined, i know Jeff :-)
that he or she doesn'T have to go through all files of thework to find out it
it is distributable. That was felt necessary because in the early '90 many
latex packages contained licenses of the form: you are not allowed to
distributed this commercially, or some such statement, and the major
distributions for TeX where the commercial tex implementors.
so we wanted to give them an explicit assurance that any work onder LPPL is
distributable by them (at least when unchanged) without any problems
whatsoever.
it was also partly necessary because we had these special clauses for further
restrictions for certain types of files in the first version.
as this is now gone it is probably more confusing than helping
> But the exception for "modification or distribution of modified versions",
> makes this pretty meaningless, doesn't it?
right.
> > 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.
>
> This recommendation is simply for clarity, not because of any conceptual
> objection.
sounds like an interesting idea.
thanks for the input
frank
--
To UNSUBSCRIBE, email to debian-legal-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Reply to: