De: Raul Miller [mailto:[EMAIL PROTECTED] > > > 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):. > $
What did Debian distribute? A working copy of Quagga? No, the only "working" copy of Quagga is in *YOUR* machine, after *you* got it from the Net or CD, installed the files in the right places, etc. > > This shows that installing the package is equivalent to running > quagga. More of the same. The package does not come installed from Debian. > > 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". > It still does not configure that Debian is distributing some "working" version of Quagga. > And, clearly, there is some intent to distribute a version of > Quagga with SSL support. > > So, what can we do about this? What are the exact terms of distribution of Quagga, libssl, and libsnmp? > > 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. I don't think it's necessary. But I do think that we should ask the guys from Quagga to clarify their license (add a linking exemption). If they don't agree, then, as a matter of courtesy, we should try the other remedies, not excluding zapping Quagga out of the repo if needed. > > 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. > Agreed. -- HTH, Massa
