dlls/advapi32/crypt.c

[Patrik Stridvall]

> Patrik Stridvall wrote:
> > 
> > > On another note, however, I was re-reading the CryptoAPI
> > > thread and I don't
> > > think that Vladimir Vukicevic's questions were really
> > > answered from September
> > > 3rd.
> > 
> > Can you be a little more specific?
> > 
> > As far using GPL:ed libraries, that is a question that
> > really can't be properly answered without a real court
> > case.
> 
> I think that Vladimir's suggestion that OpenSSL could be
> used as an alternative back end did not recieve sufficient
> attention.  He wasn't sure that that was a good approach 
> given the fact that it would arguably cause difficulty for
> people who wanted to run GPLed apps on top of Wine+OpenSSL.

Well. If we only permit linking with libraries that have
GPL compatible licenses, we will seriously limit our choices.
Sure I, since GPL is a dominant license, fully agree that
all linking to non-GPL:ed libraries should be optional.

Of course the question of what is optional is vague too. See below.

Also note that this is an entirely different issue than the issues
concerning GPL:ed libraries.

In the case above it is 100% clear that only the distributor
of the GPL:ed application can have any legal liabillities
for possible violation of the GPL. It is not out immediate
concern.

Beside since they, because of the GPL, must have the source
code they can always disable things like crypto that might
not have a 100% GPL compatible Winelib implementation.

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.

However, I'm a little afraid of that for the GPL to be truely
meaningful, especially in the case of Wine, you will have
define the boundaries of copyright a little to strict for my liking.
 
> Since the number of GPLed Windows apps that do not have Linux
> counterparts is vanishingly small, the OpenSSL option seems to 
> me more appropriate than using a libgcrypt back end.  The 
> OpenSSL license does not have the viral properties that the
> GPL has (it's an old-style BSD-type license, complete with the
> advertising clause),  and therefore we should be able to weak-link
> Wine with libOpenSSL without any license contamination.  

Agreed.

> Packagers
> who distribute libOpenSSL with Wine would then be responsible
> for meeting the OpenSSL license requirements for advertising 
> and attribution.

Of course but that is not our immediate concern, the same would
be if we link with any proprietary library. Any distributor of
such libraries whether in conjuction with Wine(lib) or seperately
must of course fullfull the licensing requirements of such
libraries (including but not limited to pay any license fees).

Actually in some meaning we already do, since proprietary 
implemenatations of both X Windows and OpenGL exists and
Wine(lib) will happily dynamically link with them and
use them if they exists. Wine(lib):s use of them obviously
do not gives any license to distribute them, but that is not
our concern.

This of course raises they question if we mandatorily
link to libraries, like X Windows or OpenGL, that both
have GPL and non-GPL compatible implemtations:

Do we optionally or mandatorily link to a non GPL compatible library?

Does this matter from a legal perspetive as concerning 
whether a Winelib user violate the GPL or not?

In addition does it matter whether the GPL compatible library is:
1. Complete
2. Close to complete
3. Has only basic functionallity
4. Unusably buggy
5. Unimplemented stubs
6. In the planing state
7. A theoretical construction
In that case why?