On Thu, Aug 08, 2002 at 04:43:59PM +0200, Lars Hellström wrote: > If you think such a license is non-free because the newfoobar in the first > argument of \ProvidesPackage is "functional" then it would be inconsistent > to not declare as non-free also a license that only requires a version > number change, e.g. > > % Copyright 2002 M. Y. Name, A. N. Other > % The newfoobar package ... license ... > \ProvidesPackage{foobar}[2002/07/02 v2.00] > > since this new version number would still be "functional". If you restrict > renaming to instances where the name cannot be reliably checked by computer > then you must put a similar restriction on version numbers. However I don't > believe that "appearing in a comment somewhere in the source, while being > contradicted in the code" is the normal interpretation of "carrying a > version number" in the community that has to interpret the DFSG. Happens all the time with shared C libraries. A shared object version number may bear no relationship to the version number on the associated product. In fact, Debian has a lot of experience with this very issue (e.g., FreeType 2.x has a shared library called libfreetype.so.6), and it occasionally causes confusion among our users. Therefore, I reject your analysis. DFSG 4 refers to names of works and version numbers for humans. It would be DFSG-non-free, for instance, to forbid a derivative work of FreeType 2.x from installing a shared library with the filename libfreetype.so.6. A shared object version is a technical mechanism for making reference to an inteface, just as a filename is a technical mechanism for identifying a set of bytes on a disk. DFSG-free licenses do not compel functional incompatibility, or the advertisement of same. -- G. Branden Robinson | "I came, I saw, she conquered." Debian GNU/Linux | The original Latin seems to have branden@debian.org | been garbled. http://people.debian.org/~branden/ | -- Robert Heinlein
Attachment:
pgpOpu2RXKpvw.pgp
Description: PGP signature