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.
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. Packagers who distribute libOpenSSL with Wine would then be responsible for meeting the OpenSSL license requirements for advertising and attribution.
That said on the licensing side, I have no idea whether the OpenSSL code actually provides the functionality we need to implement the CryptoAPIs. Has anyone looked into this yet?
The other alternative is to ask the libgcrypt team if they are willing to consider LGPL-ing their library so that we can use it. Has anyone asked?
-Gav