OpenPGP Card

['Lionel Elie Mamane']

On Tue, Sep 06, 2005 at 10:09:25AM +0200, Alon Bar-Lev wrote:

> Lionel Elie Mamane wrote:

>> But there is indeed a case to be made that if the library
>> implements a well-known, standard ABI, then linking to it is not a
>> GPL violation. <shrug> Legally it depends whether the linked
>> program is a "derived work" from the program or not.

> But PKCS#11 is not a library you link against!
> It is an API specification.
> There is no proprietary code you link into your program in order to
> implement this standard.

I thought we were talking about PKCS#11 "drivers" for specific cards,
and that you had to link this driver into your program (dynamically at
run-time) in order to use it. That _driver_ would be gpl-incompatible.

>> GnuPG doesn't *link* to RAID drivers or video drivers. They don't
>> end up "running linked together in a shared address space". They
>> communicate over syscalls or sockets; mechanisms that are
>> well-known as to be "GPL-safe" (as long as the coupling between
>> them isn't too tight).

> I think you should read PKCS#11 specification... You cannot call it
> "combining two parts into a program" PKCS#11 is a specification, you
> don't provide the implementation along with your program, the
> specification is EXACTLY the same as protocol or command line
> specification.

I had understood that it was not a _protocol_ but a library API. HTTP
is a _protocol_ for data interchange over the network. I thought
PKCS#11 was a _library_ API and that you linked (dynamically at
run-time) a particular "implementation" of it (the card driver) into
your program to use it. If that's not the case, my previous messages
are void and meaningless.

> Since you don't provide the PKCS#11 provider implementation along
> with your GPLed distribution and that there is a complete API
> specification of the interface, it does not fall into the "combined
> program".

Again assuming that the provider implementation is a library you link
against: That may or may not be true. I don't think that's legally
clearly established yet.


>> On the other hand, some people interpret the GPL in a way saying
>> that if a library implements a "standard" ABI, then one can link
>> GPL software to it. <shrug> I think it is a good idea to stick to
>> the copyright holder's interpretation.

> I don't understand this statement...

There are two statements:

First:

>> On the other hand, some people interpret the GPL in a way saying
>> that if a library implements a "standard" ABI, then one can link
>> GPL software to it.

This one says essentially the same thing as what you quoted
before. Some say standard ABI -> not combined program, but I don't
think this has been "proven" by case-law yet. It may be found true by
courts, or not.

Second:

>> I think it is a good idea to stick to the copyright holder's
>> interpretation.

A license means what the licensor means by it. If the licensor has
clearly told you that by *his* reading of the GPL that-and-that is
forbidden then you'd be in a tricky situation in front of a judge
explaining "I know that the licensor meant to forbid that, but the
text he gave me permits it, so he has permitted it.".

>>> I can show you that it GPLed program loads these drivers...
>> Yes, show me, I'm curious.

I had misundertood what you meant by "these drivers". I thought you
meant the display and printing drivers.

> Examples:
> opensc from www.opensc.org - LGPL uses PKCS#11
> pkcs11_login from www.opensc.org - LGPL uses PKCS#11

LGPL is not GPL. The difference is exactly that it permits linking to
non-(L)GPL code.

> openCryptoki from http://sourceforge.net/projects/opencryptoki - GPL uses
> PKCS#11

I downloaded opencryptoki-2.2.0.tar.gz . It is not GPL, it is under
the "Common Public License Version 0.5".

-- 
Lionel