Re: Bug#153257: TeX Licenses & teTeX (Was: Re: forwarded message from Jeff Licquia)
On Thu, 8 Aug 2002 18:15:19 -0500, Branden Robinson <branden@debian.org> wrote:
>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.
You're avoiding the question. I am furthermore well aware of the custom to
employ multiple version number systems in parallel; for example each of the
.dtx files that constitute the source for the LaTeX kernel has its own
series of version numbers, quite independently of the version numbering of
LaTeX as a whole.
>Therefore, I reject your analysis.
Saying so perhaps makes you feel better, but it doesn't make the analysis
go away.
>DFSG 4 refers to names of works and version numbers for humans.
You're repeating your claim, but you do not give any new support for it.
>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.
Compiled shared libraries are, because of their rigidity, poor analogies to
LaTeX packages, but that is another point. Since I am at the moment merely
examining your interpretation of DFSG:4 -- and either want to find that it
is not as extreme as it has seemed at times, or establish that your
interpretation is unrepresentative of Debian (it could of course happen
that I will fail in doing either, but that is yet another point) -- I did
not say anything about _filenames_, but only about names and version
numbers that can be inspected by programs.
For a shared library, it is more useful to think about "development branch
names" and version numbers subordinate to a development branch. Suppose
that a particular shared library mechanism encourages libraries to declare
what development branch they belong to, and that this information is made
available to programs that link themselves to these libraries -- perhaps
via a function that can be called before the library is linked, or perhaps
as a variable/constant that only becomes available after linking. Is it
then your interpretation of DFSG:4 that a license which requires modified
variants of the library to use a new branch name in this declaration is
non-free?
I think it would be a pity if it was, because there are good reasons why
programs should have available such information about the libraries to
which they link. A program that links to an "encryption" shared library
should have the ability to detect that the library it found was from the
"superficial" development branch and therefore reject to run unless the
user started it with a switch to accept this development branch. A stricter
program might even reject the "main" branch of "encryption", and by default
only accept using the "paranoid" branch (which is only half as fast, but
takes care to work around a glitch, only affecting 5% of the messages sent,
in the format that would otherwise allow the NSA to break the encryption in
a day). In particular the case when the main branch of development is
rejected is important, because main branches have a tendency to get
reinstalled when one doesn't expect it.
Lars Hellström
Reply to: