Martin Paljak wrote:
So if I had an application, 100% GPL and it implemented a 'celan' pkcs#11 interface that loaded pkcs11-spy (LGPL?) what in turn loads a StrangeToken$$$ pkcs11 module, that would not be good ?

all code in an application at compile time and runtime must be under GPL compatible license. so the application cannot use the pkcs#11 header by
RSA because it is not gpl compatible. even if such a replacement header
is used, whatever shared object is loaded must be under GPL code too.

the only way is to split this into two processes and use remote procedure calls (like openct does between ifdhandler and the application, by using dbus, corba, dcom, dcop, rpc, ice, x11, whatever),
so one process can be GPL + LGPL parts (they combine fine), and
the other process can be LGPL + proprietory parts (they combine fine too).

of course an application might grant an exemption in addition to the
GPL. like many applications under GPL allow to link them with openssl,
even despite the openssl advertising clause.

an application could add such an exemption for opensc with rsa header files, so it could use both the rsa header file itself and allow
the module it is loading to use that one too. (but it is much easier
for me to improve the rewritten pkcs#11 header till it is 100% compatible, than to talk to dozends of program authors and ask
them to change their license).

an application could also add a general waiver for their plugin
interface, for example allow plugins of any kind to be loaded,
with no concern for the license (e.g. pam modules, pkcs#11 modules, etc.). but that has problems in itself, and is usualy done by not
using the GPL at all, but using LGPL instead.

In summary: there is a license problem, opensc-pkcs11 using the
rsa header files is incompatible with e.g. login. this needs
to be fixed. we can ask authors to change their license, or
we can replace the code with the problematic license. we have
a replacement code, and I find it easiest to work on it.

Regards, Andreas
_______________________________________________
opensc-devel mailing list
opensc-devel@lists.opensc-project.org
http://www.opensc-project.org/mailman/listinfo/opensc-devel

Reply via email to