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. Regardless of this if you want any code using a GPL:ed library in the CVS you need to convince Alexandre to change his mind. What other questions are unanswered?
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 -- Gavriel State, CEO TransGaming Technologies Inc. http://www.transgaming.com gav(a)transgaming.com
Gavriel State wrote:
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?
FWIW, Peter Gutmann (author of another SSL API, http://www.cs.auckland.ac.nz/~pgut001/cryptlib/ ), says wine is welcome to use his code:
Dan Kegel wrote:
On an unrelated note, a couple people on wine-devel are thinking of implementing support for Microsoft's CryptoAPI in Wine (hopefully based on an existing crypto library, if one can be found that is suitable, license-wise). Any wisdom you could throw their way would probably be appreciated.
Euurgghh, that'd be like implementing RPC over SMB support for... oh hang on, that's already been done :-). The two problems are (1) it's a pretty awful design (and I'm using the word "design" loosely here, accretion might be a better word) and (2) it's a great pile of semi-documented, uncontrolled functions, structures, constants... hmm, it really is like RPC over SMB.
Anyway, if you do want to implement it you're welcome to use cryptlib for it (you can use it for Wine under whatever terms Wine requires), cryptlib has an API-mapping layer (look at cryptapi.c) which maps any API to the native cryptlib functions (a bit like the Win32 vs NT native API) so by unplugging cryptapi.c and plugging in a CryptoAPI-compatible interface you should be able to do a lot of what you want - there's support for certificate stores and all the usual stuff which CryptoAPI needs in there.
(As the above may indicate, I've looked at doing this a bit myself, but couldn't really work up much enthusiasm for it).
Peter.
- Dan
On September 14, 2001 9:40 pm, Dan Kegel wrote:
Gavriel State wrote:
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?
FWIW, Peter Gutmann (author of another SSL API, http://www.cs.auckland.ac.nz/~pgut001/cryptlib/ ),
says wine is welcome to use his code: ...
Hmm, I was unaware of that project. I asume that you have already contacted the author and has his approval at least for the wine project. But have you also clarified the situation with winelib applications both GPL and otherwise? I just want to clarify this as this seems to be the main area of concern. I have briefly visited the site and the API seems to support everything we need and I will consider using it. However, I did not find a license on the site. - Travis _________________________________________________________ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com
On Sat, 15 Sep 2001, Travis Michielsen wrote:
On September 14, 2001 9:40 pm, Dan Kegel wrote:
Gavriel State wrote:
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?
FWIW, Peter Gutmann (author of another SSL API, http://www.cs.auckland.ac.nz/~pgut001/cryptlib/ ),
says wine is welcome to use his code: ...
Hmm, I was unaware of that project. I asume that you have already contacted the author and has his approval at least for the wine project. But have you also clarified the situation with winelib applications both GPL and otherwise? I just want to clarify this as this seems to be the main area of concern. I have briefly visited the site and the API seems to support everything we need and I will consider using it. However, I did not find a license on the site.
There seems to be some conditions if you click "downloading". Alas, those usage conditions on the site doesn't even come close to conforming with something like the Debian Free Software Guidelines, much less the GPL...
participants (5)
-
Dan Kegel -
Gavriel State -
Ove Kaaven -
Patrik Stridvall -
Travis Michielsen