Re: code signing with foreign function interface?

[Stephen J. Turnbull]

address@hidden writes:
 > "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.

AFAICS, it is infringing on copyright of Emacs to deliver a module for
Emacs that is not licensed under the GPL or comes without source (or a
GPL-permitted alternative to source).  I doubt that people who do this
would balk at adding a signature, or removing the check from their
"value-added" distribution of Emacs, or otherwise finding a way to
inhibit it, because "our users demand the convenience".  Users really
do demand convenience, you know.  Users who care more about freedom
than convenience generally also want the source up front, and won't
need such a check.

This means that users would have to check that their copy of Emacs
does the checks, and that the modules don't subvert the check as
described below.  However, with the current policy, if your Emacs has
FFI or an on-demand DLL loader, you know that it does not conform to
Emacs policy, and you know that the modules you are loading are
considered suspect by the FSF.

 > > 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.

I know you mean to add a new facility.

 > 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.

But how do you plan to ensure that?  Suppose I deliver a module with
part of the code in elisp and part in a DLL.  `(progn (shell-command
"emacs-sign-it /path/to/my-module") (require 'my-module))' and we're
golden! no?  If the user can do it, so can a program.  The only way I
can see to prevent this would be to protect the signing utility with a
password.  Even that can be worked around with a little social
engineering: "Installing this module requires your permission under
the GPL.  Please type your signing password in the following dialog."
Users sophisticated enough to see through that are sophisticated
enough to demand source in advance; they're not the ones the current
policy is (mostly) aimed at protecting.

BTW, AFAIK, users can't violate the GPL.  Only distributors can.

 > > 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.

Emacs cannot tell if the user has made an explicit decision to load
the module or not, but sometimes will refuse to load the module even
though the user definitely wants it loaded (and the user may even know
that the module *is* GPL and why that matters).  That's a "noticeable"
restriction.  You may not consider it a big deal, but others might.  I
don't know, so I used the word "noticeable" rather than "unacceptable". ;-)