On Fri, Aug 14, 1998 at 01:03:46PM -0500, Manoj Srivastava wrote: > >>"Michael" == Michael Bramer <michael@weh.rwth-aachen.de> writes: > Michael> It is not acceptable, that a official announce debian-redhat > Michael> projekt produce non-free software! > Sheer Hyprocrisy. It is, isn't it? Imagine, a project to produce a completely free OS, defining that OS by using non free programs. > It si OK to have the DFSG which is non-free > (no license to redistribute that I can see); it is OK to have most of > our software depend on a license that itself is non-free (taken a > look at the GPL lately?), but it is not OK for the LCS? How do you > justify that? We follow the FSSTND, which is also non-free. Explain > that one. Like you said. The DFSG doesn't refer to documents. Maybe it should. Maybe it should in part. Maybe it definitely shouldn't. And the LCS is, at the moment, free to put it's documentation under a non-free license, and have it in main. But ./validate isn't a document. It's a program. Its sole purpose is to get run. Therefore it's software, and therefore the DFSG applies. Saying that it's not really software, it's really a standard seems to be pointless sophistry to me. After all, aren't the KDE/Qt folks trying to create a standard in their work on the desktop? It's not a bad standard, and even better it's not exclusionary with other possible desktop standards, so maybe Debian should support it -- after all, if Qt is a standard not software we shouldn't have any qualms whatsoever about putting it in main, right? But, rhetoric aside, I thought ./validate wasn't meant to be the standard anyway -- that the LCS was all about making a paper standard that anyone could fulfill. Is this standard going to be completely enforced by ./validate, or will the standard be more like the Debian Policy document, and ./validate be more like lintian -- thorough, but not necessarily all encompassing? And if it's not, then it's entirely possible that distributions that satisfy ./validate *won't* satisfy the LCS. Or vice-versa -- after all lintian reports E's on some perfectly good packages, why shouldn't ./validate? And is the problem really in making a copy of the program and changing that, in making a copy of the standard and changing that, or in claiming that a non-conformant system *is* conformant? I personally would assume that the whole problem is with the last of these -- there's no point in a standard if it doesn't make requirements for conformace. There's not much use being able to say "foo is Unix", if foo doesn't have to have "ls", "/dev/null" or a "#" prompt somewhere. And there's not much point saying something is LCS-compliant if it doesn't implement enough functionality for it to be useful. It seems to be that it should be quite alright to make a copy of the standard and change it, and pass it around or whatever, so long as that doesn't let people say that their non-compliant systems *are* compliant. And that similarly people should be able to make a copy of ./validate, and change it, and pass it around or whatever, so long as they don't start claiming that satisfying the new ./validate makes them LCS- compliant. (Which, IMO, should be done with trademarks, rather than copyrights, as others have already pointed out. Making sure the official ./validate is easily and publically available would also help, IMO. cf the Open Source trademark, and the guidelines for it) And finally, the pragmatic argument. The DFSG exists because it's fundamentally a better way to write software. People are happier, and the software is better. But what use is improving ./validate? It's not going to change the standard, so it's not going to do any good, right? No. While the current ./validate is perfect as a base for a validation suite, it's not as useful as it might be. It doesn't have convenient networking support (I can't check that my (hypothetical) network of hacked up Slackware machines are LCS compliant without doing each one separately), it doesn't fit into a system particularly well (./ this, ./ that -- so much for packaging it as a .deb for bragging rights), and it doesn't have a particularly nice interface (and you can't even link it to free libraries like libreadline to give it one). And if I want to do any of these things, I have to rewrite the entire thing from scratch if I want to do any of these things. Honestly, I don't see why this is still an issue, let alone an emotive one. We've already decided that philosophically, we prefer a free solution over a non-free one where it's possible, and practically, there still seems to be a means of legal recourse, and still getting any benefits that the free software community may be wishing to add. Cheers, aj -- Anthony Towns <aj@humbug.org.au> <http://azure.humbug.org.au/~aj/> I don't speak for anyone save myself. PGP encrypted mail preferred. Remember to breathe.
Attachment:
pgpqR9zpf7x3i.pgp
Description: PGP signature