[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Question(s) for clarifications with respect to the LPPL discussion



On Fri, 2002-07-19 at 05:15, Frank Mittelbach wrote:
> so what i present here is essentially a set of concerns and comments that I
> gathered from the various mails that people put up as a problem with LPPL or
> rather as a problem behind the ideas behind LPPL (rereading and compiling took
> me roughly 7 hours last night and 4 this morning --- which makes me feel that
> i'm too slow a worker these days).

Thanks for the effort.  I generally agree with the points made, both
that they cover the issue well and that I concur with their analysis,
with the exceptions I note below.

> -----------------------------------------------------------------
> | Block a)
> | Concerns (not really ordered)
> -----------------------------------------------------------------
> 
> 
> Concern 1: requiring a change of filename in case of modification 
>            in case of distribution
> =================================================================
> 
> this seems to me the major stumbling point  for most people and (unfortunately
> the most important point for us)
> 
> Argument 1.1: the need to fix a file because of a security problem
> 
> Argument 1.2: the need to fix a file because of a bug
> 
> Argument 1.3: the wish to change a file because of improvements made
> 
> Argument 1.4: when keeping the name somebody else has to approve
> (http://lists.debian.org/debian-legal/2002/debian-legal-200207/msg00086.html)
> 
> Argument 1.5: Changes to the LaTeX kernel to support new code (e.g klingon
>               example) are made impossible this way

I refer you here to the excellent reply by Henning Makholm, with which I
entirely concur.

> Concern 2: the ability to make modification without filename changes
>            in case of private or "closed" use
> =================================================================
> 
> Argument: 2.1: change article.cls to run klingon and to share it with friends
>                on SuperH architecture 
> (http://lists.debian.org/debian-legal/2002/debian-legal-200207/msg00086.html)

I think this is a sub-question of Concern 1, above.  If Concern 1 is
addressed, then we get Concern 2 for free.

> Concern 3: the uselessness of the approach taken by LPPL
> ========================================================
> 
> Argument 3.1: write a new (unrelated/related?) package from scratch
>               and give it the same name as the original one.
> 
> Argument 3.2: Trademarks and certification marks are tools better suited to
>               controlling endorsements of conformance with a standard or set
>               of usage practices.
> (http://lists.debian.org/debian-legal/2002/debian-legal-200207/msg00071.html)
> 
> Argument 3.3: If the core can be changed in any way without changing it
>               directly, then you can break output exactly as well by this
>               mechanism as you could by editing it directly.
> (http://lists.debian.org/debian-legal/2002/debian-legal-200207/msg00190.html)
> 
> Argument 3.4: why have a complex license if you probably never
> 	      legally enforce it?

These are more practical arguments that relate to Clause 1.  If a
particular license meets the DFSG, it isn't a large problem for us if
the license is complex or inconvenient, though we obviously prefer
simple and clear licenses (although note that if we can't decipher the
license, we're likely to mark it as non-free just to cover ourselves). 
However, it is important to recognize that some of your restrictions end
up serving no purpose except disqualifying your license for DFSG
compliance, which (I would think) would motivate you to alter or remove
those restrictions.

> ----------------------------------------------------------------------
> | Block b)
> | Some more comments from mails, you tell me please if they are relevant (for
> | determining LPPL to be DFSG-complient or not) and whether or not you agree
> | with them:
> ----------------------------------------------------------------------
> 
> From: Mark Rafn <dagon@dagon.net>
> From: Jeff Licquia <licquia@debian.org>
> http://lists.debian.org/debian-legal/2002/debian-legal-200207/msg00162.html
> 
>  > It's gross, and I lose respect for the software author who put the stupid
>  > requirement in the license, but it doesn't stop me fixing it nor
>  > distributing the result, so it's free enough for Debian.
> 
>  I see your point, gross as it is. :-)

For reference, the "gross" point here is the fact that we have the power
to product independent works that change LaTeX's behavior under even the
most restrictive interpretation of the LPPL.  The only way to prevent
that would be to license LaTeX under a "no modification allowed by
anyone under any circumstances" license, which would be clearly
non-free.

> ----------------------------------------------------------------------
> | Block d)
> | Finally some snippets from mails or pointers to mails
> | that i thought worth thinking about or
> | commenting on (is isn't the full list probably) ...
> ----------------------------------------------------------------------
> From: David Carlisle <davidc@nag.co.uk>
> http://lists.debian.org/debian-legal/2002/debian-legal-200207/msg00195.html
> 
>  LPPL does not (unlike some other licences:-) insist that any derived code
>  is licenced in the same way, but it does state that any derived works,
>  apart from having different names, should be licenced with a licence
>  that forbids renaming back to the original.

I believe that I pointed out in another message that the question of
third-party modification of modified derivatives of LaTeX is very
confusing right now, since the LPPL explicitly restricts license
changing to the distribution terms.

An example: "foo.tex" is a part of LaTeX.  I modify it and distribute it
as "foo-jeff.tex".  Someone else gets "foo-jeff.tex" and wants to modify
it further.  What is that person allowed to do, and what does that
person need to do?


-- 
To UNSUBSCRIBE, email to debian-legal-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org



Reply to: