OpenPGP Card

Zeljko Vrba zvrba at globalnet.hr
Tue Sep 6 18:59:19 CEST 2005


Alon Bar-Lev wrote:
>
> Again... I am sorry but I must disagree... WHERE THE CODE RUN  IS NOT AN
> ISSUE.
> The issue is how tightly your code is with another code.
> A protocol and API specification are the same, since they can replace one
> another...
>
I would agree with this. Why does the actual _mechanism_ of DATA sharing
matter? Can somebody explain, what is the difference between calling
PKCS#11 as a shared library and passing a message to some daemon to
pefrorm the work and return the result?

The amount of sharing and coupling between the two modules is EXACTLY
THE SAME, the only difference is the MECHANISM used to accomplish that
sharing (i.e. shared address space in the case of dynamic library or
UNIX sockets in the case of stand-alone daemon).

What's more, UNIX sockets can be implemented via shared memory. What
would GPL say in _that_ case?

And I would try again to emphasize DATA sharing, not CODE sharing. You
use PKCS#11 API to share DATA with the library[1]. In my opinion, data
sharing does not and cannot (in any common-sense interpretation)
constitute a "derivative work". Then again, I'm not a lawyer.

The application calling PKCS#11 one way or another shares ONLY data with
it, not its code! And I don't think that GPL says anything about data
sharing. So it would be (maybe) legal and GPL-compliant to link in
proprietary PKCS#11 .so into GnuPG.

[1] There are some cases when you can register a callback to be called
by PKCS#11 into you application. This is again a moot point, since even
Windows do that: call app callback from the kernel (e.g. the ubiquitous
"WndProc").

Paradoxically, it seems that GnuPG would be allowed to used
closed-source MS CAPI because it is delivered as a "part of the
operating system". The way CAPI works is:

your application -> CAPI -> back-end driver

So your application interacts with CAPI (delivered as a part of the
operating system - an exception permitted by the GPL, as someone quoted
in this thread), and CAPI interacts with the back-end driver for the
particular hardware device.

>
> In your view I can write a PKCS#11 daemon that exposes SOAP as protocol...
> And this way to use PKCS#11 in GPLed application.
> But I cannot use the PKCS#11 directly...
>
> This is CRAZY!!! You are fooling your-self if you think there is a
> difference between the two...
 >
Yes, I agree with this viewpoint. The only difference is in the
MECHANISM to accomplish the sharing.

BTW, let us know when you get the reply from the FSF. I'm really curious..
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 254 bytes
Desc: OpenPGP digital signature
Url : /pipermail/attachments/20050906/63ade901/signature-0001.pgp


More information about the Gnupg-users mailing list