Re: LPPL, take 2
Branden Robinson writes:
> > > Are you gravely opposed to external changelogs, as might be generated
> > > by, say, cvs2cl -- even if those changelogs have to be distributed along
> > > with the modified files of the Derived Work?
> >
> > yes, we are. This is not how the LaTeX world works. The license is to support
> > the users, the authors, and the maintainers of the Work and Changelogs are
> > totally alien to LPPL type of software; there is no requirement to produce,
> > let alone distribute, them. Very few users (authors or system maintainers)
> > would know how to look for one. Furthermore distributions are usually
> > splitting things up into runnable versions, often source and extra
> > documentation are quite difficult to find, other than documentation directly
> > in the files being used.
>
> I understand that, but again there is a difference between exhortation
> and requirement. The GNU GPL has a similar requirement, but the FSF
> itself does not generally follow this practice, since it *is* part of
> their culture to use ChangeLog files and tools like "cvs2cl".
well i guess the above part of the license is essentially derived from GPL
(one way or the other) ... and since GPL is a free software license ... and
perhaps even DSFG free :-) ... i could probably end the argument here ---
except that I happen to agree with you mostly
> Can you predict that the LaTeX community will never change such that
> revision-control systems will be used which track rationales for
> committed changes as file metadata?
certainly not, if could predict future i would be in a different business then
i'm now.
I use cvs and changelogs etc all the time so do others. BUT ...
> I'm not saying that your requirement should be dropped altogether; your
> intention is perfectly reasonable. I'm saying that it shouldn't be a
> license violation for someone to check an LPPLed LaTeX package into CVS
> and maintain their own version, tracking the reasons for their changes
> via CVS commit messages and a ChangeLog file, as long as if and when
> they distribute it they either:
>
> 1) distribute the complete and accurate ChangeLog corresponding to the
> modified LPPL-licensed file(s) in question; OR
> 2) insert the contents of the complete and accurate ChangeLog into the
> body of the modified LPPL-licensed file(s) in question
>
> Both approaches seem reasonable to me, and to reflect real-world
> software development practice.
they are reasonable approaches and reflect real-world software development
practice of a certain kind but not more. TeX world has a two-level
distribution process in which packaging in major distributions (external to
the distribution of the author of the Work) is done according to runtime and
space considerations with the result that it is often very difficult for a
user to reconstruct the full original distribution of the author. This is not
really a good situation in several respects but it is real life software
practice in this part of the world. So users often only have direct and easy
access to the actual runtime files and everything else including readmes etc
are difficult to obtain or find.
And while I agree that future working in the community may change, this is not
the case right now, so to have a license that requires things in a way useful
to the user is important in our opinion. On the other hand this is mainly a
requirement for the case 5a2; for 5a1 the situation is different as the
Derived Work is experienced as a seperate entity that can stay alongside with
the original Work.
However, as compromise we suggest
5. If you are not the Current Maintainer of The Work, you may modify
your copy of The Work, thus creating a Derived Work based on The Work.
You may distribute your Derived Work as long as the following conditions
are met:
a. You must ensure that each modified file of the Derived Work
is clearly distinguished from the original file. This must be
achieved by ensuring that at least one of the following
additional conditions is met:
1. The modified file is distributed with a different
Filename than the original file.
2. If the original Work identifies itself to the user when run
then the Derived Work clearly identifies itself as a modified
version of the original Work to the user when run.
3. The license notice for The Work specifies that the file or class
of files (for example, files that are named a certain way) may be
modified without renaming.
b. You must ensure that no part of the Derived Work identifies itself as the
original, unmodified Work to the user in any way when run.
c. You must ensure that each such modified file carries prominent notices
detailing the nature of the changes, or a prominent reference to another
file containing a complete and accurate log of the changes that is
distributed as part of the Derived Work.
d. You must change or remove any addresses in the Derived Work for
the reporting of errors to ensure that error reports for the Derived
Work are not mistakenly directed to the maintainers of the
original Work.
unless you have a variant suggestion that better supports our concerns while
also taking care of yours.
Note that above we also addressed the concern by (I think Walter) concerning
5a2 so that it now only requires run-time identification if the original used
runtime identification
if the above is something we can all live with then i would prepare a new
draft version that contains (hopefully) all the discussion points.
frank
Reply to: