[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: OpenSSL, SUN and ECC (patent issue)




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
<20020924090429.GR3298@wiggy.net> 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++

Attachment: pgpjGOGzMmU3A.pgp
Description: PGP signature


Reply to: