Hi,
On Fri, Oct 11, 2002 at 01:23:25AM +0300, Richard Braakman wrote: > (Did you forget to send to the mailing list? Feel free to quote > me in public.) done. > On Thu, Oct 10, 2002 at 11:59:54PM +0200, Toni Mueller wrote: > > On Thu, Oct 10, 2002 at 10:16:50PM +0300, Richard Braakman wrote: > > > We've discussed it on this list already, but the remaining open question > > > is, what patents do they have that they refer to here? > > ok, I've searched on lists.debian.org before posting for "openssl sun", > > but got zero results. A pointer/date would be very nice! > It was in two threads that started on September 24, subjects "Sun's ECC Thanks - I looked (see below). > No, I'm talking about algorithms, not implementations. Whether ECC is > patent-encumbered or not does not depend on the implementation. Agreed. > > > If ECC is not patent-encumbered, then their license clause has no effect. Yes. I'd prefer to not find out the hard way, fwiw. > Make a careful distinction between patent infringement and copyright > infringement when you read that clause. Their offer is to promise not > to sue for patent infringement under certain conditions. That offer > does not affect the _copyright_ license which you get from the rest > of the OpenSSL license. They didn't add any copyright restrictions, > they only offer to relax potential patent restrictions. Oh - I see what you mean, but shipping this code poses many people at risk of inadvertantly infringing on a patent if there is one in the first place, because many people would just use the code in good faith that the "Open" on the packkage label and the settings in which they aquired the code, eg. as part of a Linux distro, suggests that there is no problem. Checking the exact legal status of the code for the individual situation is way beyond most potential users of the code. Also, contrary to most other parts of a common Linux distro and Debian in particular, this clause requires each user to check their legal settings *individually* since the clause discriminates between various classes of users. This generates a very clear usability problem, imho. At least after the recent serious of security problems in Open Source Software, the public standing of Linux & Co has been damaged. Now add unclear licensing situations and one spectacular show case, and corporate IT will drop it in favour of maybe expensive, maybe broken, but at least legally unproblematic software in which cases the vendor sort of guarantees that the code is obtained and used legally, provided you paid your dues to him. No need to answer not only technical questions, but consult a lawyer, too, before booting up your company's servers... (ok, that's somewhat biased in the light of the licensing fuss esp. M$ makes, but if we get into the same league, even "by accident", this would be *very*bad*). Apart from that I'd consider it a severe flaw in Debian's DFSG if it would require strict "free" licenses for the copyright of software to go in, but be rather lax for potential patent clauses on the same software which can be much more devastating since they are much less obvious. Ie, a copyright situation is easy to check - just take the license, and it's all there, no hidden gotchas. A patent can lurk somewhere in the dark and surface at the least convenient moment as eg. most GIF users should have seen. > You are free to refuse the "covenant", in which case you risk being > sued for patent infringement -- but that risk would apply to *any* > implementation of the same algorithm, regardless of its author or license. Yes. Damn. I'd like to concentrate on computing instead of attending a law school. > So the real question is whether the algorithm is patent-encumbered. "Yes." > Sun claims that they have patents covering it, but they're pretty vague > about which patents those might be. Of course - would you present your contenders with your hot spots on a silver tablet? Maybe in a situation where you want to hold off expensive court cases until your wallet is healthy again? > My conclusion is: the extra clause does not make the code any less free > than the unadorned OpenSSL license would have. However, Sun might have > patents that _do_ make the ECC code less free than other parts of OpenSSL > (and would have done so even if they had released under only the OpenSSL > license). If they have such patents, then the extra clause is not enough > to make the algorithm free. That's imho right in general, but please observe that the special SUN clauses have been spilt all over the OpenSSL code, even in places that were formerly unaffected. Removing the offending files breaks the rest of the code. Now one of the questions is, does this kind of spill augment the scope of the SUN claims, or not? This is becoming a rather mirky legal case with a high risk potential. Maybe Debian can consider using other code where at least no big vendor has their fingers in. It'd be better to err on the cautious side. Imho the questions in <[EMAIL PROTECTED]> still stand. Do we have an attorney at hand, or within reach, who could please clear the topic up? Does Debian just do business-as-usual, or can we maybe work with the FSF to find out the "real" meaning? Thank you! Best, --Toni++
pgpHK5xrFiQzX.pgp
Description: PGP signature
