dlls/advapi32/crypt.c

[Patrik Stridvall]

> Vladimir Vukicevic <vladimir at ximian.com> writes:
> 
> > I think that the discussion of OpenSSL vs. libgcrypt isn't really
> > necessary -- there's no reason why two implementations of CryptoAPI
> > can't be done, one using the gcrypt backend, one using OpenSSL.
> > Granted, this is a duplication of effort, but I think there 
> is enough
> > interest that it shouldn't be too difficult to do both.  
> Also, it's easy
> > enough to ship two different advapi32.so's, or even create an
> > intermediate cryptoapi layer that supports plugins, so that 
> the option
> > always remains with the distributor or user whether to go with a GPL
> > implementation, a BSD implementation, or even a commercial
> > implementation.
> 
> As far as the main tree is concerned, everything has to be under the
> Wine license (or compatible). It's not acceptable to depend on a
> library that would impose extra conditions on the Wine/Winelib
> user. 

The problem is what constitutes extra conditions is extremly vague.

If you have a Winelib application that don't for example use say any crypto 
functions, you really can't be said either to use or to derive a new work 
from a completely unused and/or unnessary library.

If you do use any crypto function, well, whether that imposes any extra 
conditions is an extremely difficult legal issue that really can't
be answered without a real court case. It might depend on whether the
use is optional but it might not. That is what I have been trying
to point out in my recent messages.

So just saying that "I don't want any libraries that imposed extra
conditions on the Wine/Winelib user" is not really a very informative
answer.

What you mean is (I guess):
1. No use of libraries under the GPL or other viral licenses
2. No use of commersial libraries (end user and/or developer must pay for
it)

Or do you mean something else? Anyway see below.

> And this is not solved by having a choice between two different
> sets of extra conditions.

Note that you always have the choice of NOT using crypto.
If Wine didn't include a working crypto implementation that 
would be the only choice wouldn't it?

As long as it doesn't effect the performance or maintainabillity 
of Wine in negative way more choices are always better than
less IMHO.