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 _______________________________________________ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
