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

Re: Bug#153257: TeX Licenses & teTeX (Was: Re: forwarded message from Jeff Licquia)



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.

> 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.

> 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.)

The intent of the phrase "The license must explicitly permit distribution
of software built from modified source code" is precisely to disallow
restrictions on functionality.  I know this because that very point was
discussed vigorously when the Social Contract was written.

Whether the DFSG spells this out or not is not the point; the document
is a set of Guidelines, and in addition to being vague it has some flaws.
For example, it doesn't say what termination conditions are acceptable
in a free license.  It is perfectly possible to write a horribly non-free
license that meets every term in the DFSG.  We know this, that's why we
don't apply it blindly.

[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.
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.

> [...] 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.

In that community, the normal interpretation of "carrying a version number"
is the Version: header in the package metadata (which is replicated in
the filename of the package).  Depending on context, this may refer to
the "upstream part" of the version, or the "debian revision number".

-- 
Richard Braakman
"I sense a disturbance in the force"
"As though millions of voices cried out, and ran apt-get."
  (Anthony Towns about the Debian 3.0 release)



Reply to: