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

Re: forwarded message from Jeff Licquia

Henning Makholm writes:
 > Scripsit Frank Mittelbach <frank.mittelbach@latex-project.org>
 > > There are a number of myths it seems concerning what is allowed or
 > > not and how LPPL must or can be applied.
 > > here are some of them:
 > >  - to fork you have to rename every package under LPPL
 > > all of them wrong (and explained over and over again by now)
 > It has been *asserted* over and over again that this is wrong, but
 > that assertation does not seem to be consistent with the actual
 > license text we're discussing. It says that each *file* must be
 > renamed if it is changed, and since each package is a file that has
 > the package name as its file name, it logically follows that one would
 > have to rename all packages.
 > Have I overlooked something in the license?

no. *each* file that you change must be renamed, but where is the problem
here? I think it has also been demonstrated that is neither excessive nor in
conflict with DSFG 3+4

You would only have to rename all files if you change all files. It does not
follow that if you change only some, that you also have to change those that
you do not intend to fork. Note that there are many individual works (each
consisting typically of a small number of files) that are licensed these days
under LPPL. So if you like to fork, say, the varioref package (a package for
generating extended reference to sections and the like) you give varioref.sty
a new name and that's it. You don't have to rename anything else though you
may want to document your changes by using the .dtx method in which case you
probably end up with a new work consisting of

 varioref2.dtx varioref2.sty varioref2.ins

but this is neither a requirement nor something that follows from the license.

same if true if you fork the kernel (i gave an example for the dolloar->euro

 > > so let us come back to the question whether the intentions behind LPPL (eg
 > > our abstract principles) are in conflict with DSFG and if not try to help us
 > > reformulating it so that everything gets clearer.
 > I'm confused about what you mean here. Since it already has been
 > established that the ideal goals seem to be compatible, why do you
 > insist that we "come back" to that question instead of moving on to
 > "reformulating it so that everything gets clearer"?

is it established? if so fine, I wasn't so sure seeing arguments like

  But we can not tolerate means to reach this goal, that are
  against our principles, against our ethics.


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

Reply to: