On Mon, 2001-09-03 at 15:36, Dan Kegel wrote:
Vladimir Vukicevic wrote:
I had recently thought to start implementing CryptoAPI as well, when someone pointed out your message to me. Have you made any progress? I had planned to implement it as a single monolithic replacement that provided the most common cryptography providers (at least inititally), using libgcrypt. libgcrypt is the back-end library under GnuPG; unfortunately, it is currently under the GPL, so there would be issues with shipping it with wine. I'm not sure what the chances are of getting libgcrypt relicensed under the LGPL -- it's a very nice library. (www.gnupg.org, from CVS)
However, OpenSSL's license is incompatible with the GPL, hence any GPL'd applications that wish to use an OpenSSL-backed CryptoAPI implementation would be unable to do so.
I'm not so sure about this. Question: is it possible to write GPL'd software under Windows that links into, say, USER32.DLL? Answer: yes, because USER32.DLL is considered part of the operating system. It might be that cryptoapi's dll is also considered part of the win32 operating system api, thus allowing even gpl'd apps to dynamically link to it without violating the gpl.
Sure, but I think it's a fine line to walk.. The Microsoft-provided ADVAPI32.DLL is considered part of the OS, but the API itself is not. If you were to create a replacement ADVAPI32.DLL for use under Windows, I don't think it would be legal for GPL apps to link with it; but hey, IANAL, as they say. In any case, the line is even blurrier with wine, since wine itself isn't part of the OS -- so someone wanting to port a GPL'd windows app [for the sake of argument let's pretend that some exist ;-)] to Linux using winelib might have issues.
- Vlad