Submit for inclusion in Emacs?

[luismbo]

Have you considering submitting this project for inclusion in Emacs? If this FFI and libffi were part of the standard Emacs distribution, FFI-using libraries would be much, much more convenient to develop and distribute.

[aaptel]

I suspect the only way for this ffi to be included in emacs would be to enforce gpl compliance like it's done in emacs when loading modules i.e. checking for the presence of a "plugin_is_gpl_compatible" symbol.

[vermiculus]

Is it acceptable from an FSF perspective to allow a package option to selectively check for this symbol? That way folks who believe they should only use GPL-compatible software can be assured they'll continue to do so without the side-effect of holding up everyone else.

One thing I think is necessary to consider here is whether FF-interfaced libraries are considered 'compiled together' in a way that is potentially incompatible with the GPL/v2/v3. If emacs-ffi were to be released as part of emacs, then using a non-GPL library would be no different (in theory, and in my opinion) than running a non-GPL tool via shell-command-to-string.

[aaptel]

Is it acceptable from an FSF perspective to allow a package option to selectively check for this symbol?

You have to ask on the emacs-devel mailing list.

[vermiculus]

Yep.

[tromey]

I'm completely fine with submitting it for inclusion. I have assignment papers; and I think probably the other contributions are small enough not to need them.

John W. asked on irc the other day if I'd do it, so I may send an email to emacs-devel.

I think the major issues are the dlopen/symbol-checking thing, and perhaps that the API still has some warts. Oh and there are some bugs, but some of those would be easier to fix in-core.

[ArneBab]

Did you move forward with this?

[suhail-singh]

For everyone's situational awareness, per the recent discussion on emacs-devel
on the topic (see https://yhetil.org/emacs/86bk1v8430.fsf@gnu.org/ for a
summary of the sticking point and Eli's opinion on the matter), emacs-ffi will
not be accepted in Emacs.

The reasons for the above have to do with the Emacs project's ethical stance.
Specifically, for the Emacs project, a user's verification of the GPL compliance
for a used library is not sufficient. Given the lack of a standardized method
for shared libraries to declare their licenses, projects like emacs-ffi can,
at most, only request confirmation from users. This approach, however, falls
short of the standards expected by the Emacs project.

I believe this issue can now be closed.

[Thaodan]

IMHO it is not possible to do any kind of GPL verification which doesn't defeat the point of the GPL: user freedom.

Checking the license with a symbol that labels the library GPL compliant is mostly window dressing, it is not enforceable and nothing prevents a library from "falsely" claiming it.
The only other solution is to have a list of allowed, sanctioned libraries by the FSF.

Technical improvements restricted by control of RMS/the FSF, control that isn't likely given up. FFI and dynamic modules mean less control for them.