Re: code signing with foreign function interface?

[joakim]

"Stephen J. Turnbull" <address@hidden> writes:

> address@hidden writes:
>
>  > - Emacs FFI loads the dll and checks that the desired licensed text in
>  >   binary form is present, and then proceeds to use the dll. If the text
>  >   is not present, refuse to proceed.
>
> I don't understand what you hope to accomplish with this.  On the one
> side, I don't see how this prevents infringing binary distributions.
> One who is violating the GPL anyway is unlikely to deliberately
> *remove* the key which will surely be present in the sample module he
> derives his code from.

Aparently I totaly suck at explaining this idea.

Also I dont quite understand your objection above.

>
> On the other, it will interfere with private use of DLLs without the
> key, which (a) is not restricted at all by the GPL, and (b) is very
> likely quite legitimate in the case of older GPLed or LGPLed DLLs (ie,
> all that exist today).

I didnt mean that existing dynamic linkage would change. I meant to add
a new facility.

> And if you're serious about a true FFI that can be called from Lisp,
> the situation is even worse: very likely the user wishes to call
> routines from a library which doesn't know or care that Emacs exists.

Yes. The bit about code signing in my other mail was about that.
The DLL either is delivered with the signature, or the user can add
it. The user shouldnt be able to add it withouth knowing that he is
violating the GPL.

> So I don't see how it addresses the objections to the use of DLLs
> and/or FFI, while noticeably restricting the exercise of rights
> granted under the GPL.

It shouldnt, AFAICS.


-- 
Joakim Verona