dlls/advapi32/crypt.c

Vladimir Vukicevic vladimir at ximian.com
Mon Sep 17 13:41:20 CDT 2001


On Sat, 2001-09-15 at 02:12, Patrik Stridvall wrote:
> In short. GPL:ed Winelib applications is not our concern
> and we shouldn't IMHO make it one beyond making sure
> that all linking to non GPL compatible libraries is optional.
> 
> GPL:ed libraries is, as said above, a different story, that 
> from a legal point of view is an unresolved issue. The "answer"
> of that question regardless of what it will be, will, be very 
> important since it might, unless it is too vague, define the 
> boundaries of copyright in a more definite way.

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.

There's also something to be said for following Microsoft's API for
crypto back-ends, so that proprietary back-ends (i.e. those dealing with
hardware keys, etc.) could function within the wine cryptoapi framework.
In this case, each individual provider (RSA, DSS, etc.) would then be
implemented either in terms of gcrypt, or OpenSSL, or libcrypt, or any
other.

	- Vlad






More information about the wine-devel mailing list