[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kfm-devel
Subject:    Re: openssl license
From:       George Staikos <staikos () kde ! org>
Date:       2001-09-12 1:37:47
[Download RAW message or body]

On Tuesday 11 September 2001 12:29, Marc Mutz wrote:

> On Monday 10 September 2001 18:01, George Staikos wrote:
> > In any case, the best solution is to
> > write a new implementation of SSL which is licence compatible and
> > follows a KDE-ish design philosophy.
>
> Think again. This is the worst of all possible solutions. Your other
> post to this thread below sounds much much better and sane.

   My other post is what we're doing now and it's not enough.

> It's generally bad when politics dictates cryptography and security
> measures. "Getting rid of OpenSSL" because of licensing issues is
> politics par exellence.

   Getting rid of OpenSSL because 

    - it doesn't fit the KDE development framework (it's very difficult to 
work with and we see many many bug reports).  
    - it has broken BC 7 out of 7 times that I have checked recently.  This 
results in me responding to infinite bug reports and emails.  I'm getting 
sick of it.
    - it has terrible memory requirements and startup time impact.
    - we can't link to it because it's so heavy, and this makes it hard to 
use the crypto lib for crypto elsewhere.
    - it's licence causes a severe problem and it's licence cannot 
be changed.
    - it's very inefficient.  There are places where I've had to do 
rediculous amounts of copying buffers back and forth.
    - it forces us to use char* all over instead of our safer C++ types.

> It's always better to work around the politics. Here, we could bug the
> openssl people to drop the advert clause or - if that doesn't work out
> - - explicitely allow linking of our stuff against theirs.

    The OpenSSL licence can never be changed.  This is a known and accepted 
fact.  I've been through this already with the OpenSSL team and they are very 
sick of hearing about this.

    I can't guarantee that I will be able to complete this task, but I sure 
hope to try once I polish off the last remaining functionality requirements 
for our currently SSL implementation.

-- 

George Staikos

[prev in list] [next in list] [prev in thread] [next in thread]