On Sat, May 01, 1999 at 07:41:03PM +0100, James Troup wrote: > So, opinions? As James well knows, this sparked quite an argument on the "secret" IRC channel. I expect this to be a contentious issue, but I am in support of James's action as a harbinger of (hopefully) a new, clarified contrib policy. Why would it be a Good Thing to put programs that depend in a functional sense (in addition to those that depend in a technical sense; e.g., via dynamic linking to a non-free library) into contrib? 1) It pays close attention to the implications of the "compilation or execution" clause of the definition of our "main" section. * must not require a package outside of "main" for compilation or execution (thus, the package may not declare a "Depends" or "Recommends" relationship on a non-main package), Since the issue came up in the context of a client/server discussion, let me use an example from my own experience. What if all X servers were non-free? Of what utility then, would be all the X clients in the world, if one wanted to use only DFSG-free software? The answer is, practically none at all. I'd like to use xterm or rxvt...wait, damn, gotta install a non-free X server. I'd like to use GNOME...wait, damn, gotta install a non-free X server. It is practically a tautology to say that the utility of a client is strongly dependent on the availability of a server using the same communication protocol. 2) While every other Linux distribution on earth is busy loading up its CD's with non-free software, we continue to carry the banner as the distribution that doesn't cuff your hands, or fully recognize that which does. If this clarification of contrib were adopted and enforced, it would make the software in question no less available. Contrib isn't about whether something is DFSG-free or not. Contrib is about whether your program is useful in a microcosm of DFSG-free-only software. Clearly, packages like xtrs, which depends on proprietary ROM images from ancient computer hardware are not useful in such a microcosm. Neither are ICQ clients, if there is no DFSG-free ICQ server that supports a minimal set of functions. Neither are Quake server scanners or list utilities, if there is no DFSG-free Quake. In fact, this policy would help to educate people by informing them about what pieces of popular proprietary software need DFSG-free counterparts. Remember, Microsoft's own engineers have proposed taking heretofore open Internet protocols and doing their customary "embrance and extend" violence to them. To what extent Microsoft will do this is not yet known. But they are not the only commercial interest out there with this tactic at their disposal. What good will our operating system be if we let all, or even a significant minority of our wire protocols become closed property? We've already got a popular proprietary chat/messaging protocol. People are eschewing SMTP and IRC in favor of ICQ. Why? What are its strengths? The free software community needs to have its awareness raised about this. If we're not going to "clone" it, then it had better be a deliberate decision rather than one that is made for us by virtue of our own ignorance. Imagine a world with a standard, proprietary hypertext protocol. Imagine a world with a standard, proprietary mail transfer protocol. Imagine a world with a standard, proprietary name service protocol. Imagine a world with a standard, proprietary address resolution protocol. Where do you want to go today? -- G. Branden Robinson | Measure with micrometer, Debian GNU/Linux | mark with chalk, branden@ecn.purdue.edu | cut with axe, cartoon.ecn.purdue.edu/~branden/ | hope like hell.
Attachment:
pgpfVSiW7lvzV.pgp
Description: PGP signature