CryptoAPI

[Patrik Stridvall]

> > > 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.

This issue has been discussed before (see mailing list archive).

I think that the general consensus is that the GPL certainly could be
interpreted (and indeed likely to be interpreted by a court) as not
covering such cases as above, especially since the GPL obviously do not
cover a GPL:ed application on Windows it would be ridiculous to make it
legal distribute Wine and a Windows binary but not Winelib and make it
illegal to do that with a Linux binary that dynamicly links to whatever
version of Winelib installed of the system. The fact that a version of
Winelib might exist that links to a GPL:ed library is a ridiculous
ground for an court case. You might as well argue that distribution 
of any Windows binary is illegal since somebody might run it on a
illegal (pirated) version of Windows.

Beside the GPL doesn't cover use, only distribution, so if the user
would install a Winelib that uses a GPL library that would be
completely legal as far as that user would be concern despite the
fact that he has a non-GPL:ed application that uses Winelib.

That would effectively close any "have no legal uses" argument
eventhough that argument is ridiculous regardless of this since
even though no non-GPL:ed Wine implementation of CryptoAPI currently
exists the application might be used with limited functionality until
such time or that matter use the real ADVAPI.DLL from
a legally bought copy of Windows instead. 

Beside I don't think any copyright holder of a GPL library would 
dare sue the Wine project or any user of Winelib, even disregarding
their non existing chances of success, because of PR reason.

However Alexandre has clearly expressed that he doesn't want Wine
to be a legal test bed, if not primarily for the legal issues, so
because he doesn't want an unsuspecting company using Winelib be
"cruficed" on Slashdot or wherever for alleged GPL violation. :-)

While I, in some meaning, agree, I do not believe that we should
refrain from doing so because of fear of what might never be.
Obviously we should turn off the use of any GPL:ed library by default.

Anyway, unless or until Alexandre changes his mind, I think that
you should submit all general code that needn't use a specific
library and distribute that rest as a patch. Preferable so
that Winelib could dynamically load it so it could be 
distributed seperately in binary form as well.