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

Re: Revised LaTeX Project Public License (LPPL)



Branden Robinson writes:

 > Mandating technologies in license documents really rubs me the wrong
 > way.  

I'm not too happy about it either, but ...

 > The nice(?) thing about legal language is that you can use broad
 > terms to say what you mean, and as long as your meaning is clear and
 > unambiguous, the people are affected by it.

folks, all I see so far is that your broad terms do not take into account our
main concern, but only your concerns about how you view the world. That is
fine, but it doesn't bring us much further.  At least some of you will
hopefully acknowledge that I tried and try very hard to fullfil your concerns
while maintaing ours.

If you are prepared to think about how broad legal terms can unambiguous
prevent our concern of becoming a reality then I'm all for not being too
specific in places. Otherwise I can only say that the earlier draft had a very
simple clear and legal term (if you change it change its name) that the
majority (I wont dare to speak for everybody) of the LaTeX community was and
is happy with.

 > By being as specific as you
 > are, I think you're making it *more* likely, not less, than someone will
 > find and exploit a loophole in your carefully constructed license
 > document.

that is a danger, I agree, and again it would be nice if you can suggest a
phrasing that is "clear and unambiguous", but I don't see that this
 > 
 > Why not say something like:
 > 
 > "If you distribute modified copies of the work, you must ensure that its
 > modified status is clearly, unambiguously, and obviously communicated to
 > users of the work."?

actually fulfills this goal. At least not as long "unambiguously, and
obviously" is not further qualified. I'm sure there are people claiming that
the above will clearly allow to put a comment somewhere (for example at the
top of some file), saying that the file is modified, but that is (the way
LaTeX works) anything else than obvious and unambiguous as it will mean that
the user is required to wade through literally thousands of files to find out
if some of them has changed. They expect that if they see

Package: FOO 2003/04/08 v1.6c FOO formatting (FMi)

on two installations then this will provide the same code. Furthermore right
now they expect that if they see

You have requested package `FOO',
but the package provides `FOO-new'.

that they have then and only then run their document through a system
that provides a modified version of the original work FOO.

any modification that slips in a FOO variant into their setup without giving
them such a warning would be something considered an attempt to fool people
rather than provide them with a corrected/better/or-whatever-it-was-done-for
package.

[[this is the current situation, assuming an LPPL license that is not
requiring a fixed facility / or name change that expectation would probably
change to "expeciting to get a clear information that something is modified"]]

 > There.  The burden's on them, not you.  If they get too clever and sneaky,
 > this clause is there to catch them and make them liable to you for
 > copyright infringement.  The easiest way for them to comply with this
 > requirement is with your suggestion (2) above.  Otherwise, they'd better do
 > (1).  But saying what you want instead of how exactly you want it done is,
 > I think, a superior approach.

yes it is, but only if you have a suggestion that is clearly avoiding the
danger that a noticable number of people are likely to argue that all that is
needed is a static comment in the source file. If you have any suggestion for
this then I guess i would be with you.

just a minute ago your long mail on  "modification notification requirements"
came in and i have to read that in some more detail. At first glance I believe
that it is exactly (3) we are doing the license for and in some sense it is
due to that that we feel "clear and ambiguous" needs to be more than a
statement you proposed above.

Having just looked at Jeff's reply to you, I think his last suggestion would
be closer to achiving what we want, without having to phrase it in a way that
would be a restriction in technology or requiring a name change

so with something along those lines I guess we could avoid technological
restrictions or requirements and in fact make the license better as you
pointed out.

frank



Reply to: