checking GPL compatibility in MELT meta-plugin

[Basile Starynkevitch <basile at starynkevitch dot net>]

Hello All, [GCC list, MELT group, and David Malcolm -python plugin- and
Diego Novillo -plugin enthusiast & maintainer]

Reminder: IANAL, ie I (Basile) am not a lawyer! But I am a free software
enthusiast and I like a lot the GPLv3....

As you know, GCC has some technical devices to invite plugin developers
to make GPL compliant plugins.
http://gcc.gnu.org/onlinedocs/gccint/Plugin-API.html

This is done thru the plugin_is_GPL_compatible symbol. Of course, some
dishonest person could technically have & distribute a proprietary GCC
plugin defining that symbol (IANAL, but I believe it won't be accepted
in court, even if technically feasible). 

MELT http://gcc-melt.org/ is a domain specific language (GPLv3 licensed
and FSF copyrighted, since implemented in the MELT branch of GCC and the
MELT plugin for GCC) to extend GCC and I (Basile) am the main author of
MELT. I believe that MELT should have a technical device to invite
people to make GPL compliant extensions in MELT.

It is implemented by a runtime melt-runtime.cc & melt-runtime.h and by a
bootstrapped MELT translator coded in MELT (files melt/warmelt*.melt)
and also distributed in generated C++ form (files
melt/generated/warmelt*.cc) 

MELT is a lisp-y language, and is generally distributed as a plugin for
GCC. http://gcc-melt.org/download.html ; MELT is a meta-programmed
system: MELT code is translated to C++ code, and that is translated to
*.so which is dlopen-ed by the MELT runtime; the MELT translator is
coded in MELT. MELT is (like D.Malcolm's Python plugin) a "meta"-plugin,
in the sense that it enables other code (for MELT, in MELT lisp-y
dialect, for the Python plugin, in Python) to be "injected" or "glued"
into GCC ...

MELT is GPLv3 and I (Basile) try hard to favor (when technically
possible) GPL software (but I do know it is *not* a technical issue at
first). Let me explain a bit:

First, when the MELT plugin is built and installed, most of the source
code is installed also, and MELT won't run without it (the MELT runtime
contains some code in melt-runtime.cc to enforce that). Typically, MELT
is installed under $(gcc -print-file-name=plugin) which contains (in
addition of the files installed by GCC, e.g. by the gcc-4.8-plugin-dev
of a Debian/Sid distribution) a directory melt-sources/ which contains
all the source files in MELT (i.e. all *.melt files like
warmelt-macro.melt etc... ) and the corresponding generated files in C++
(i.e. warmel-macro*.cc). Some code in the MELT runtime is checking that
these files are accessible (in that sense MELT is more cautious than
many other software: you need most of MELT source code to run MELT
successfully!) but the checks are not perfect.

I would very much like MELT extensions to have, if possible, a GPLv3
compatible license (AFAIK, there are not many MELT extensions
today ....). So I devised a device to "help" that:

a MELT extension should use the case-insensitive
MODULE_IS_GPL_COMPATIBLE macro somewhere in the *.melt source code. I'm
using myself inside MELT, for example in warmelt-macro.melt file:

  ;; This MELT module is GPL compatible since it is GPLv3+ licensed.
  (module_is_gpl_compatible "GPLv3+")

The argument to module_is_gpl_compatible can be any constant string. By
human convention only that string explains a bit why the given module or
extension is GPL compatible.

when this macro is processed by the MELT translator (itself coded in
MELT) the generated C++ file contains :

   MELT_EXTERN const char melt_module_is_gpl_compatible[];
   const char melt_module_is_gpl_compatible[]= "warmelt-macro: GPLv3+";

where MELT_EXTERN is simply a C++ macro from melt-runtime.h :
   #define MELT_EXTERN extern "C"

If the module_is_gpl_compatible macro is not used in the MELT source
code of some extension, a warning and a notice happens; in that case
(lines 2102 and following of file melt/warmelt-outobj.melt ...) I have:

    (warning_at 
      ()
      "MELT module $1 does not claim GPL compatibility using
MODULE_IS_GPL_COMPATIBLE macro" omodnam)
    (inform_at ()
      "See http://www.gnu.org/licenses/gcc-exception-3.1.en.html";)

However, the MELT extension does become translated to C++ code.

The C++ code itself may have the melt_module_is_gpl_compatible symbol.
If it is missing, the MELT runtime complains (file melt-runtime.cc near
line 9628)

  if (!MELTDESCR_OPTIONAL(melt_module_is_gpl_compatible))
    warning (0, "MELT module %s does not claim to be GPL compatible",
	     MELTDESCR_REQUIRED (melt_modulename));


Notice that MELT is very often generating C++ code and dlopening it.
This is the common way for MELT to function & run. In particular, it may
emit temporary C++ code, notably when simply evaluating a MELT
expression, or for the "findgimple" mode of MELT - see middle of
http://gcc-melt.org/tutousemelt.html for an explanation and compile and
dlopen that code. There is no reason for that temporary C++ code to be
GPL (it is temporary and is deleted when MELT finishes, and the source
is just some program argument -fplugin-arg-melt-gimple-pattern=... to
the MELT plugin & to gcc).





So my concrete questions to the GCC community are:

Do meta-plugins like MELT (& probably Python plugin) should be concerned
about having some device to check compatibility with GPL licensing? I
believe that yes... (David Malcolm: what is your feeling on this? How do
you deal with that concern inside your Python plugin?)

Can I just leave a warning, not an error, when the MELT macro
module_is_gpl_compatible is not used in some user-provided *.melt code?

Are my warning messages good enough; should I speak of "claim to be GPL
compatible" in them, or should it be something else, e.g. "assert to be
GPL compatible" or "promise to be GPL compatible", or "is GPL
compatible" [which cannot be technically checked, only legally!]; please
recall that English is not my native language! So any better suggestions
are welcome!

Is it ok or good to give the
http://www.gnu.org/licenses/gcc-exception-3.1.en.html URL in a notice
message?

Is the MELT macro name module_is_gpl_compatible good enough? I was also
thinking of extension_is_gpl_compatible.... (I generally speak of *.melt
extension files producing *.cc generated C++ files compiled into *.so
MELT modules which are dlopened by the MELT runtime which is itself a
GCC plugin...)

Is the C++ symbol name in the generated C++ code
melt_module_is_gpl_compatible good enough (I really want it to start
with melt_ since this is a convention for the MELT runtime, to avoid
collisions with GCC symbols)?

I just committed today (jan.23, 2014) some patches to the MELT branch of
GCC (svn rev.206976) I also make a temporary MELT plugin snapshot
available on http://gcc-melt.org/melt-plugin-snapshot.tar.bz2 which is a
symlink to  
http://gcc-melt.org/melt-plugin-snapshot-r206976-2014jan23.tar.bz2 
This MELT plugin snapshot is probably buggy and instable. I barely
tested the features I just added.

If you (specially high-level members of GCC community, i.e. global
reviewers, plugin reviewers, or steering committee members, but also
other plain members like me) believe that all this is crappy or wrong,
please tell and I will revert my latest patches regarding all this. If
you believe it should be improved, please also tell. If you think it is
useful, please say so. If you have any comments about naming or
messages, please help!

Your feedback is expected and welcome!

Regards.

PS: if this is welcomed it will be part of next MELT plugin (i.e. MELT
plugin 1.1 - but I don't promise any date for its future release).

PPS: I have some meeting tomorrow and might not have time to read or
answer emails.

-- 
Basile STARYNKEVITCH         http://starynkevitch.net/Basile/
email: basile<at>starynkevitch<dot>net mobile: +33 6 8501 2359
8, rue de la Faiencerie, 92340 Bourg La Reine, France
*** opinions {are only mine, sont seulement les miennes} ***