dlls/advapi32/crypt.c

[Patrik Stridvall]

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

It is not the effort that is the real problem. The problem is that
since ADVAPI32 might use libgcrypt (that is GPL:ed library) it possible
to for a non-GPL:ed Winelib application to indirectly via the ADVAPI
to "link" to libgrypt. This would violate the GPL:ed in some meaning.
Of course the authors of the  Winelib application might be entirely 
unaware of this  fact but it is still teoretical violation. 

This is, of course, in some meaning absurd, but ask yourself this:
What meaning have the GPL for libraries if you can just wrap a
intermediate library with a GPL compatible license (like Winelib:s ADVAPI
"library") around it and circumvent the GPL?

Of course a distinct possibility exists that a court of law will find
that the GPL (as applied to libraries) is meaningless or at least
meaningless
in the case of Wine. But are you willing to be the defendent in a test case?
Alexandre is not.

Still IMHO even in the worst case what will likely happend is that.
1. Richard Stallman (or somebody else) sends a GPL violation notice.
2. Slashdot debate the case and possibly hang us out. :-)
3. We will discuss on the list what to do and possible remove the offending
code.
4. If we do not the debate on Slashdot and elsewhere will continue
5. If we still persist the chances that we will be sued is still quite small
since
   A) The cases of winning is close to zero
   B) There is little or no chance to profit even regardless of this.

Of course there is moral aspect of this but ask yourself this:
"Is it immoral to shatter somebodies unrealistic expectations?"

In short there is no legal risk at all IMHO but Alexandre has said earlier
that he doesn't want code using GPL:ed libraries if not to protect himself
or the Wine project, so to protect possible users of Wine if not from legal
issues so from bad PR.

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

That is probably a good idea. But you can't use libgcrypt at least not
without asking the libgcrypt authors if it is OK that Wine(lib) uses
libgcrypt despite the fact that it makes it possible for non-GPL:ed
Winelib applications to indirectly use libgcrypt.
And you better ask Alexandre whether is OK with him to include
the code under such circumstances.