Re: What makes software copyrightable anyway?
De: Raul Miller [mailto:moth.debian@gmail.com]
>
>
> On 5/13/05, Humberto Massa Guimarães <humberto.massa@almg.gov.br>
> 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
Reply to: