Re: forwarded message from Jeff Licquia
On Sat, 2002-07-20 at 18:41, Glenn Maynard wrote:
> On Sun, Jul 21, 2002 at 01:15:42AM +0200, Frank Mittelbach wrote:
> > i have heard that statement before, but to me it doesn't follow from DSFG 4
> > and others (regulars on this list I presume) have in my understanding also
> > expressed that. Not everybody --- the camp is clearly divided.
>
> I havn't seen dissention on this issue. Some people have said that they
> don't like it (many DD's don't like #4; that's why it's a a compromise),
> and others (eg. Thomas and Branden) have pointed out that renaming may
> not necessarily accomplish what you want.
>
> The rest of this seems, to me, like you're trying to use #4 in ways it
> wasn't intended to be used. I'll leave replies to people more experienced
> with Latex and the DFSG than myself.
To an extent, we've covered this already. Here's my current thinking on
the situation.
First of all, requiring a source file rename is, I think, obviously OK;
renaming "foo.c" to "bar.c" doesn't really affect your rights, and is
mostly an annoyance (tracking down Makefile references and so on).
Requiring a binary file rename is also OK; I think we might even do this
now.
A C include file is more of a problem, because there are references to
the original source file in other programs. You now need to patch all
other C programs that use the include file to include your modified
version. This may cross the bounds of what you're allowed to require
under DFSG 3 (but I'm not going to say definitely one way or the other).
Since LaTeX is essentially a macro collection, we have lots of
interconnected filename references. On the face of it, requiring
filename changes for each individual file is too restrictive, as it can
require large amounts of overhead due to cascading filename changes, and
it forbids modified versions from processing standard documents (as in:
you can't change what "article" does, you can only add
"article-hacked").
However, as it turns out, there is a process where you can limit
filename changes and provide "macro substitution" at runtime on
filenames, so that (for example) "article-foo" can be called when
"article" is referenced in a document. This reduces the problem back
down to the level of changing C source file names; it's an annoyance to
have to write the redefinitions, but nothing more. This also requires
changing the name of the "binary", but that's OK too.
So, it's my understanding that this is DFSG-free.
> > I can accept the argument: that you want it excluded and intend to change the
> > clause in this way, but this is a different argument then (and I don't think
> > that this is actually the consensus within Debian right now).
>
> The DFSG is a set of guidelines, not a legal document; it has room for
> interpretation. Debian doesn't change the DFSG to indicate the details
> of every debian-legal decision that required interpretation. Yes, this
> means there's some ambiguity if all a person has for reference is the
> DFSG text. (That's one reason these things are discussed publically.)
Strictly speaking, not even debian-legal is "authoritative". A
maintainer may do what (s)he wants with a package no matter what
debian-legal says. However, it's likely that a maintainer who went
against clear consensus on d-legal would find lots of people invoking
the Technical Committee and/or filing General Resolutions to override
them, so it generally doesn't happen.
--
To UNSUBSCRIBE, email to debian-legal-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Reply to: