CryptoAPI

[Vladimir Vukicevic]

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