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

Re: Towards a new LPPL draft

On Fri, 2002-07-26 at 15:24, David Carlisle wrote:
> Jeff
> > I've seen that some people include the "LPPL 1.2 or any later version"
> > language into their license notice.  Those people would be fine
> > (although I would recommend that notice be given of this particular
> > license change as a gesture of goodwill to the community).
> No. I don't think the situation here is "fine".
> The situation you describe is probably the most common and most
> important case. The sample boilerplate we offer for people to use is of
> that form.
> Despite all the legal mumbo jumbo in the licence, the _intent_ of LPPL
> 1.2 (and 1.0 and 1.1) is I think clear to everyone.
>   If you make any changes, change the name. If you change the name, make
>   whatever changes you like.
> Now people who put a reference to LPPL in the form you quote are
> basically saying that they trust us not to abuse our power to make
> arbitrary changes to the licence that would allow their software to be
> misused.
> We have to be careful not to abuse that trust.

Right; that was why I made the comment about "goodwill".

The "fine-ness" I was referring to was that, for works that add the
"LPPL 1.2 or any later version" language to the license, we aren't
required by law to hunt them down.  Whether you want to hunt them down
or not is up to you.

> Speaking personally I could live with a solution that changed
>   If you make any changes, change the name. If you change the name, make
>   whatever changes you like.
> to
>   If you make any changes, change the name, or make sure this file will
>   not be loaded by a standard version of <whatever you normally use to
>   run the unmodified version>. If you do either of those things 
>   whatever changes you like.

This sounds very close to what I posted in the "try 2" thread.  If you
don't like what's there, then I'd be very interested in what you don't
like, as the delta in intent between what you wrote and what I wrote
seems very small.

> so in the geometry case the meaning would be
> if the file is used with latex, change the name if you make changes.
> If the file is used with non-latex make arbitrary changes.
> The problem is I see no way to word such a restriction given that
> geometry isn't distributed with latex, it's just a file stuck on an
> archive.  Also I'd want the restriction to apply to say pdflatex or
> elatex, which are formats made with unmodified latex code using non-texs
> (pdftex and etex respectively) so it isn't really the "user command"
> that is relevant.

I don't know if you've delved down to the API call suggestions yet, but
that's one way to provide that.

Essentially, third-party LaTeX extensions can hitch their chariot to
"Standard LaTeX" by making a macro call in their code and by licensing
under the "new" LPPL.  Personally, I think the protections are stronger,
as you're using code to enforce the distinction instead of just a

> Sorry this message is rather negative,
> despite possible appearance to the contrary, it is trying to be
> helpful:-)

Not a problem.  It's better to get these things out in the air

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

Reply to: