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.