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