OpenPGP Card

Alon Bar-Lev alon.barlev at
Tue Sep 6 18:26:05 CEST 2005

David Picon Alvarez wrote:

> If a library runs on a shared addressable space, FSF (which is GnuPG's
Copyright holder, I assume?) considers the combined result
> a derived work in the meaning of copyright law. This is the whole point of
the LGPL, to have a licence that allows linking libraries into
> non-free software, but which ensures distribution of the library will
always be on free terms and so on.

But this is the opposite the GPL program uses a none GPLed library with out
linkage to it!!! 
I don't understand why we always turn the facts around.

> You are wrong. The GPL does not talk of standards in the meaning you
propose. If a work links to a shared library and invokes its functions
> it is making use of the library in a manner similar to copying pages from
another book into your own book. This process creates a derived work of
> the library.
> Whether the library implements a patent-protected standard, a Trade Secret
or an open, non-patent-encumbered standard is for the purposes
> of the linking issue, irrelevant. Linking creates derivation.

No... You are wrong.
Let's say my Api is as follows:

int do_work (int argc, void *argv[]);

Now I load a shared library, get the do_work address and call it by:

int (*do_work)(int argc, void *argv[]) = get_do_work_address ();

char *args[] = {

do_work (2, argv);

What is the difference between calling this shared library or executing a
none GPLed "ls"?!?!?!?

There is an exception in the FAQ page... "If modules are designed to run
linked together in a shared address space, that almost surely means
combining them into one program."

Please note the word _ALMOST_, you tend to forget that every rule has an
The above implementation and PKCS#11 do not fall this category.

>> Hence... HTTP is a standard (RFCXXX, protocol), PKCS#11 is a standard
>> API), S/MIME is a standard (RFC, format) etc... There is not 
>> difference between them in term of implementing a compliance software.

> The difference is that when I write onto a socket to talk to an HTTP
server I do not copy its code onto my memory segment, I am making use
> of the server but not copying anything from its internals, which is why
HTTP does not lead to a derived work being created. Whereas when I link
> in a library I copy its code onto my memory segment, and I invoke its
functions in a manner equivalent to writing those functions onto my own
> code, which makes a derived work.

Again... I am sorry but I must disagree... WHERE THE CODE RUN  IS NOT AN
The issue is how tightly your code is with another code.
A protocol and API specification are the same, since they can replace one

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...
If the usage of PKCS#11 caused your application to violate the GPL license,
then the usage of the same API through SOAP will cause the same affect!

I cannot imagine that the lower who wrote the GPL meant that the open source
community's programmers should work so hard in order to implement their
software... I think this is your interpretation... I've written FSF and I
hope they will address this issue.

Best Regards,
Alon Bar-Lev.

More information about the Gnupg-users mailing list