Re: Bug#153257: TeX Licenses & teTeX (Was: Re: forwarded message from Jeff Licquia)
On Fri, 9 Aug 2002 03:11:36 +0300, Richard Braakman <dark@xs4all.nl> wrote:
>On Thu, Aug 08, 2002 at 04:43:59PM +0200, Lars Hellström wrote:
>> I suggest that this interpretation of "name" here is at best an implausible
>> one. For one thing the word "name" has a number of interpretations, as it
>> is a very general term. If your legalistic interpretation really was all
>> that the author(s) of the DFSG had in mind there then wouldn't "title" had
>> been a much more natural choice? I strongly suspect that "title" _is_ the
>> proper legal term.
>
>I'll concur that a legalistic intepretation was probably not intended,
>since it's clear from a reading of the DFSG that it is not written
>in legalese. I think that Branden's interpretation is pretty close
>to the actual intent, though. Note that some of your audience does not
>have to guess what the author(s) had in mind, because they were reading
>along when the Social Contract was written and/or participating in the
>discussion.
This last bit is an interesting piece of information which, although it on
second thought shouldn't be surpring, has been far from appearent earlier
in the discussion. (I've rather gotten the impression that the DFSG is like
the Torah (even though the text is not necessarily final yet) and
debian-legal is like the ongoing compilation of the Talmud, but having
Methuselah around opens up some new perspectives.) My apologies to anyone
who might have been offended.
>> My main objection to your interpretation is however that "name" is used in
>> parallel to "version number", which is a much more precise term. "version
>> number" is not a legal term -- the legal term would probably rather be
>> "edition" -- but something very practical and technical in nature. [...]
>
>There's a much more simple and plausible reason for why the DFSG uses
>the words "name" and "version number": these are the primary attributes
>that identify a Debian package.
A very plausible reason indeed! It makes much more sense than Branden's
comments on the subject.
Yet, within this explanation lies the hint of a worrying possibility: that
there is something severly Debian-centric about the thinking behind this
guideline. If one was to work under the assumption that "Software exists
chiefly in the form of a debian package; people unpack them mainly for
efficiency reasons." then changing the package name (or at least version
number) is a reasonable flag that it has been modified, but reality is
quite different. For single program packages the concept of the Package may
still be appearent enough for the flag to be seen, but for such composite
(from jillions of Programs) packages as teTeX (and, I suspect, Emacs) that
flag is nearly pointless. In a text editor it doesn't matter that much if
the scripts are modified since they anyway operate under continuous user
supervision, and hence the lack of a useful mechanism for flagging
modifications is not an issue with Emacs, but with TeX it is.
>> furthermore the case that version numbers often have a functional purpose.
>> Programs regularly inspect and interpret the version numbers of other
>> programs, and they may behave quite differently depending on what version
>> numbers they find. Admittedly this may be uncommon in the world of C
>> programs, where communication between different programs is quite an
>> endeavour, but it is common practice for packages that get loaded into an
>> interpreter and the LaTeX way of reacting to version numbers is definitely
>> not the most restrictive in this area.
>
>The DFSG is written with compiled programs in mind; its references to
>"source" and "binary" make that clear. However it is not uncommon
>for C programs to make decisions based on version numbers. The dynamic
>linker does that.
>
>For example, nearly every program in the distribution, when it starts,
>looks for a library that identifies itself as "libc.so.6" and loads it.
>No other identification string will do. This library is normally provided
>by the package we call libc6, which its authors call glibc. If glibc came
>with a license that said that if you change it, you can't install it as
>"libc.so.6", then we would certainly NOT consider this a free license.
>(This goes for every other shared library, glibc is just an obvious example.)
C shared libraries are poor analogies to LaTeX packages; the version
identification in "libc6" is more like the version identification in "LaTeX
2e". Indeed the difference between two LaTeX classes is often most like the
difference between two development branches of a shared library. Sometimes
a branch is created because some developer wants to try out new features,
and then it happens that the branches later are reintegrated. This has
happened for example with the doc package: there once was a newdoc package
which had additional features, but those was later reintegrated into the
main doc package; I have now written a package xdoc2 (there was also an
xdoc1, but I gave up on that before I released it) that is another further
development of the current doc, and perhaps that too will get reintegrated
with the main development branch some day. However, most branching/forking
of LaTeX classes and packages happen because of aesthetical reasons, and
then reintegratation doesn't happen because there is no common goal for the
branches.
To put it another way: not even LPPL v1.2 restricts functionality as
severly as one would if the name libc.so.6 was reserved for a single
development branch, because it does not prevent the user from making a
modified version of a .cls file that is also a .cls file. The reason that
the class (development branch of LaTeX class) name is specified in the
\documentclass command is that LaTeX users are generally very particular
about what they use: knowing the exact development branch is important!
Also observe that LPPL v1.2 makes an explicit exception for .fd files, just
because that is the only kind of file in a LaTeX system where the function
determines the entire file name.
[snip]
>[example snipped]
>
>Your example simply shows that it's a mistake to assume that the version
>number of a software package is the same as its interface version number.
No, it does not. There is _nothing_ in the example which indicates that the
interface has changed (except possibly that the integral part of the
verison number changed, but that has little significance for LaTeX
packages).
>With some libraries this is the case, if their sole purpose is to provide
>a certain interface, but even then there is usually a patchlevel indication
>that is not functional. Certainly if a license requires changes to a
>version number, then it should allow the version number to have a
>non-functional part.
It would seem that the term "functional" needs to be analysed further. Is
every trait of program A that can be examined by program B functional? If
the term is to have any content at all, and unless you believe that the
soul (or something like that) enables all humans to reach insights about
computing that programs are logically unable to, then the answer is
obviously no. Thus there can be non-functional aspects of program A that
program B can check.
Lars Hellström
Reply to: