CryptoAPI

Travis Michielsen tjmichielsen at yahoo.com
Thu Sep 6 15:03:15 CDT 2001


On September 4, 2001 3:04 am, Patrik Stridvall wrote:
> > > > 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.

Hmm, GPL applications are likely to be important so we will likely have to 
use a library that has a compatible license.  However, OpenSSL license is 
apparently compatible with wine's so that is a benefit.

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

Hmm, if only distribution is covered, then can we still write code for a GPL 
library (use) as long as the library isn't shipped with wine and test for it 
on the user's system?

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

I tend to agree with Alexandre and suggest little or no work in this area 
proceed until the legal debate is over.  It seems only best for the project 
to avoid the possibility of legal action against us, especially for something 
we don't fully understand.

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

Hmm, I never thought about libgcrypt, but if we can somehow use it legally 
then it could be a possible back-end as opposed to or inconjunction with 
OpenSSL.  Naturally, I would prefer not to re-invent the wheel by having to 
re-write every needed algorithm used in the M$ API, if we can find a library 
that is legal in all circumstances :-!

But has anyone considered the following:
-Writing code that interfaces with either OpenSSL or libgcrypt depending on 
what the USER (or any winelib developer) requires AND has installed on their 
system.  Providing this is legal.  From what I understand this *should* be 
legal long as we're not DISTRIBUTING whatever is illegal to do so.
-Use OpenSSL by default if it is more compatible with our own license.
-Disabling the cryptoAPI to winelib developers by default to make them aware 
of these issue and allow them to choose the interface that matches their 
requirements.
-Provide adequate documentation that discusses these points and touches the 
legalities of this software.

One thing we should probably do no matter what is contact the developers for 
both OpenSSL and libgcrpyt and make them aware of out situation. (and 
possibly see which one or both is willing to bend on their license(s)).

Oh and one other possibility may be to find a way to modify our own license 
such that it fits this problem.  However, I'm not sure how willing Alexandre 
or any of us are about doing this (...again?, I think it's has been done 
before).

 - Travis

_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com





More information about the wine-devel mailing list