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 [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
