New subject: dlls/advapi32/crypt.c

15 Sep 2001


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

RE: dlls/advapi32/crypt.c