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