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} ***
