On 5/13/05, Humberto Massa Guimarães <[EMAIL PROTECTED]> wrote: > "This might be relevant if we planned on distributing only non-working > copies of Quagga." > > The copies of Quagga that Debian distributes are non-working; try to execute > a Debian package...
I'm not sure what you mean here. I can do something like: $ apt-get install quagga ... Starting Quagga daemons (prio:10):. $ This shows that installing the package is equivalent to running quagga. According to the debian readme, this doesn't have ssl, even if you've installed the suggested libsnmp. To run the version which includes ssl support, I have to use different commands, such as: mkdir t cd t I_WANT_OPENSSL=yes apt-get -b source quagga dpkg -i quagga*.deb These commands are easily deduced from the debian readme. Of course, this might not work on the first try, because you might also need to install some of the dependencies (such as libcap-dev, tetex-bin and texinfo). And, of course, you need to be root or you can't install debian packages. But "it might not work" is not the same thing as "it won't work". And, clearly, there is some intent to distribute a version of Quagga with SSL support. So, what can we do about this? Personally, I like Ted T'so's suggestion (that Quagga be packaged with an alternate ssl implementation so that we can legally distribute quagga with ssl support). As long as there isn't some significant aspect of quagga which only work with the versions of ssl which have silly trademark promoting requirements (like requiring the openssl.org boilerplate to be present when you mention openssl's features) we should be fine. If we don't do that, we might cause someone or some group (perhaps some of us) to get stuck with paying openssl.org some heavy license fee, to release openssl under gpl compatible terms. Or, maybe we'll create a situation requiring some other sort of settlement. And, if that's not necessary, why should we do such a thing? I don't know what the probability of legal action is in this specific case, nor what the probabilities are that it would succeed, but as a general rule (where this doesn't leave us stuck in contradictions) we try to respect upstream's wishes in the context of their software. For a strictly legal point of view, I'll quote http://practice.findlaw.com/20questions-1203.html "More copyright litigation can definitely be expected ." On the social contract side of the fence: giving some precedence and respect to the stated wishes and requirements of upstream (when dealing with their software) tends to be in the best interests of the free software community. -- Raul
