On Tue, Apr 15, 2003 at 10:29:44PM +0200, Frank Mittelbach wrote:
> Branden Robinson writes:
> > Please make restrictions attach to distributions of modification, not
> > the act of modifying in and of itself.
>
> we think it is neither of users nor of people actively supporting (read: user
> support) and maintaining a large software system, that modification is done
> without minimal preparation for a potential distribution (because accidental
> distributions happen often enough and that puts the burden on the maintainers)
> but we think it is okay to make this a recommendation rather than a license
> requirement (as it is in the LPPL 1.2 version, e.g., there we had the
> recommendation
>
> A Recommendation on Modification Without Distribution
> -----------------------------------------------------
>
> It is wise never to modify a file of The Program, even for your own
> personal use, without also meeting the above eight conditions for
> distributing the modified file. While you might intend that such
> modified files will never be distributed, often this will happen by
> accident -- you may forget that you have modified the file; or it may
> not occur to you when allowing others to access the modified file
> that you are thus distributing it and violating the conditions of
> this license. It is usually in your best interest to keep your copy
> of The Program identical with the public one. Many programs provide
> ways to control the behavior of that program without altering its
> licensed files.
Okay; that sounds fine. I think it's a very good idea to have a
separate "how to understand this license" document where you make your
intentions and philosophies clear. If more authors did that,
debian-legal wouldn't have to mail them with so many questions. :)
> > E.g.
> >
> > 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 to whomever you choose as long as
> > the following conditions are met:
>
> as i said, ok though I would probably shorten the last sentense to simply
>
> You may distribute your Derived Work as long as the following conditions
> are met:
Sounds great!
> > > a. You must ensure that each modified file of the Derived Work is
> > > clearly distinguished from the original file. This must be
> > > achieved by causing each such modified file to carry prominent
> > > notices detailing the nature of the changes,
> >
> > 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".
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?
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.
> > > c. In every file of the Derived Work you must ensure that any
> > > addresses for the reporting of errors do not refer to the Current
> > > Maintainer's addresses in any way.
> >
> > This is somewhat new ground for a DFSG-free license. Is it *really*
> > that important?
>
> yes, we think it is. It is protecting the original author and/or maintainer
> from receiving unnecessary misdirected (and that's the point) call for help
> support on a product for which he made no offer to support. again this may be
> a community difference, but in the TeX community people understand the
> bug/support address as an offer for to give support for a particular file
> (Work) in which it is found.
I understand the rationale. I'm concerned about the wording. Would the
following violate 5(c)?
% LaTeX-Foobar 1.2.9, copyright 2001--2003 John A. Doe
%
% Please report errors to <johndoe@example.com>.
%
% MODIFIED BY Jack Smith 2003/04/10 to improve widow and orphan
% handling.
%
% Please report errors in this version to <jacksmith@example.com> and do
% not use John Doe's address.
> > If so, I'd like to hear advocates of it explain why
> > it's more free than, say, a prohibition against the creator of a Derived
> > Work calling the Current Maintainer on the phone to ask for technical
> > support.
>
> I don't see that one relates to the other.
It depends on what you mean by "in any way".
> > Note that I'm not passionately opposed to 5c);
>
> I hope so; that becoming a stumbling block would be a shame.
Well, it's only a stumbling block if your understanding of it is very,
very aggressive, or if the license affords a very, very aggressive
interpretation of that clause.
Recall that the LaTeX Project's official understanding of the terms of
the LPPL may not be how other people who use the license on their own
works understand it. The Debian Project doesn't want its developers or
users to be taken to court because someone decided to interpret the LPPL
differently from you guys, if we avoid it by taking reasonable steps to
ensure clarity in the license document.
--
G. Branden Robinson | Suffer before God and ye shall be
Debian GNU/Linux | redeemed. God loves us, so He
branden@debian.org | makes us suffer Christianity.
http://people.debian.org/~branden/ | -- Aaron Dunsmore
Attachment:
pgpVXZtH7Z2Sc.pgp
Description: PGP signature