At 03:02 AM 9/23/2005, Frank Mittelbach wrote:
> > Is section 6b intended to require, as a strict interpretation of it would
> > seem to state, that all of the modules in my package shall require a
> > "prominent notice detailing the nature of the changes", even though only
> > one module contains anything derived from LaTeX code? (I would think
> > but that's what the letter of it appears to me to currently say.)
>I think common sense would suggest that this is not the case and not intended
>(well wouldn't intended by me who is one of the authors of LPPL). now let's
>see: i think the question is what is the "Derived Work" in your case, i think
>it is reasonable to interpret it only as the module that actually contains
>that original code in variation. if we do this then, 11. gives you what you
> 11. This license places no restrictions on works that are unrelated to
> the Work, nor does this license place any restrictions on aggregating
> such works with the Work by any means.
>perhaps that should say "the Work or a Derived Work" to make this clearer.
That makes sense. I think I was thinking that if I refer to my whole
collection of modules as the "Work" when I put them under the LPPL, that
that would mean that the whole collection would be considered the "Derived
Work" with regards to the license for the LaTeX code I borrowed.
It might be worth making that a little clearer too -- I'm having a hard
time coming up with a good phrasing for it, but something like changing the
wording of the beginning of 6b to "Every component of the Derived Work that
contains material derived from the Work also contains prominent
notices...." might be useful (albeit wordy). But I'll agree that it's not
a significant problem, certainly!
> > Meanwhile, for the 30 lines that _have_ been derived from LaTeX code --
> > nearly every line has been changed in some way. I would imagine that a
> > statement along the lines of "[This section] is based on a heavily
> > version of the array implementation in lttab.dtx from the LaTeX kernel,
> > version [whatever]" would satisfy the intent of the restriction, in
> that it
> > makes it clear that none of this code shall be assumed to be
> > unmodified. Is this in fact sufficient to comply? (I'm a little unsure
> > whether the word "detailing" is intended to require a detailed
> > accounting....)
>again I would say it is sufficient, but I'm sure there will be somebody
>stating that the license states something different.
Yeah, well.... :)
>the problem here is that the phrasing in 6 was written to cover Derived Works
>that are intended as a replacement of the original Work, eg you change
>lttabs.dtx with the intention to fix bugs, say, and to be used instead of
>lttabs by users.
>the idea of taking the code of say a LaTeX package to turn it into a context
>module or a plain tex thing was kind of overlooked.
>I mean, detailing your work and the changes is still something worth doing
>always :-) but is a somewhat mod point if the target is a different domain.
Indeed -- that's part of the reason I was bringing this up. I don't think
the alternate cases are just limited to cases where the revised code is
targeting a different domain in the sense of ConTeXt versus LaTeX, either
-- for instance, the listings package has a vast number of clever TeX
programming hacks that would be very useful in other LaTeX packages that
otherwise are completely unrelated.
>it may ask for a rewording at some stage, but that would need some thought.
I'd be glad to offer suggestions, if you'd like, when you get to that stage.
>as for 6d, I hope you realise that all you would need to do is to say that the
>original is found at CTAN or something, but again that is also written with
>the thought of derived works in the same domain so again this isn't really
>that important either for works like the one you outlined (and thus would fall
>into a similar: should be thought about category)
That was my impression based on how people seem to be doing things in
practice, but thanks for making it explicit.
There's a pedantic point to be made there, though, since CTAN (at present)
only provides the most recent version of a file -- which, after a while, is
unlikely to be the version that the Derived Work is based on. So that
really only rather loosely fills the requirement, if one's being very picky.
> > Also, is there a standard wording for "This file is licensed under the
> > LPPL, and parts of it are derived from file XYZ so you need to observe
> > LPPL file-identification restrictions with regards to that as well"?
>not yet to my knowledge, but your line looks already quite good to me. what
> "This file is licensed under the LPPL, and parts of it are derived from
> XYZ so you need to observe the LPPL file-identification restrictions with
> regards to this file name".
Sounds good; I'll use that.
I do find it interesting that I haven't seen this sort of thing in practice
-- for instance, the array.sty package (not to pick on you; it's just the
most recent example I was looking at) derives partly from newarray.sty, but
there isn't actually an explicit statement that I can't chop those parts
back out and create a "newarray" package out of them.
(I'm also not completely sure that that evidence is relevant; all the
examples I can think of seem to have come about as a result of direct
agreements between the authors, rather than a result of someone picking up
someone else's LPPL-licensed work. So the LPPL doesn't directly apply.)
> > What about "This file is licensed under the LPPL, except that I don't
> > whether you call your derived work the same thing as I'm calling this,
> > parts of it are derived from file XYZ so you need to observe the LPPL
> > file-identification restrictions with regards to that"?
>the statement "except that I don't care whether you call your derived work the
>same thing as I'm calling this" is unnecessary if the LPPL is observed, but it
>gives the wrong impression as it indicates (to my ear) that one could keep the
>name without obeying anything (which would then most likely violate the LPPL)
>so i think this is not a good plan
Makes sense. I'll avoid that, then.
In any case, to summarize: this definitely addresses all my practical
concerns with regards to the work I'm doing. There are a few things I'd
suggest as improvements to the LPPL wording whenever the process for the
next version starts happening, but none of them are things that I consider
anywhere near important enough to hurry that process for -- and I figure
that, with 1.3a being so recent, it's probably a few years away still.