checking GPL compatibility in MELT meta-plugin

[Basile Starynkevitch]

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

[Basile Starynkevitch]

On Thu, 2014-01-23 at 17:42 -0800, Ian Lance Taylor wrote:

> On Thu, Jan 23, 2014 at 1:28 PM, Basile Starynkevitch
> <bas...@starynkevitch.net> wrote:
> >
> > 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).
>

> The plugin_is_GPL_compatible symbol is implemented by GCC and may
> serve as an indication of intent by plugin developers. But it does
> not by itself indicate whether a plugin may be used. The rules for
> plugins are spelled out in the GCC Runtime Library Exception
> (http://www.gnu.org/licenses/gcc-exception-3.1.html). A plugin that
> follows those rules adds no restrictions to the generated code. A
> plugin that does not follow those rules does add restrictions to the
> generated code. This is true whether or not the plugin does anything
> with the plugin_is_GPL_compatible symbol.

In addition, and this might perhaps be more true for some future MELT
extensions than for other plugins, a plugin could be used for code
checking purposes (i.e. as a super-lint). In that view, one compile
his/her application with some MELT extension -or some other plugin- for
heuristic static analysis purposes - and won't distribute code so
compiled, but only distribute code compiled without any plugin (or MELT
extension).
Probably http://clang-analyzer.llvm.org/ is used this way also. And also
http://frama-c.com (developed by my colleagues from CEA, LIST) which is
a LGPL static analyzer separate from any compiler.

BTW, this is probably also the case (for proprietary software compiled
with plain GCC) regarding the debugging -g flag: I imagine that it is
more used by developers than on the finally released or distributed
binary...
I understand that http://www.gnu.org/licenses/gcc-exception-3.1.en.html
is only relevant for distribution (i.e. propagation or conveying, in
terms of GPLv3) of [binary] software compiled with GCC.... (If the
compiled binary is discarded or only internally used, does it apply?)

>
>
> > 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?)
>

> I think it would be reasonable for you to use something like
> plugin_is_GPL_compatible.

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

> If you are going to use it, then use it. Make it an error.


The reason I was using a warning not an error is that MELT could perhaps
in the future be used for static analysis of code (as or with -g), but
that in that scenario the real released executable would very probably
be compiled without MELT (and without -g) - and perhaps even by an older
version of GCC! But I could make it an error if you wish. I just believe
it should stay a warning....

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

> Hard to give an opinion on an incomplete phrase, but copying the error
> message in gcc/plugin.c ought to be fine.

Here are the precise messages for a given example. Assume you translate
an hypothetical your-foo.melt extension into your-foo.so module and that
file your-foo.melt does not use the MODULE_IS_GPL_COMPATIBLE macro to
claim GPL compatibility:

You'll first translate that your-foo.melt extension into a binary MELT
module using something like [see http://gcc-melt.org/tutousemelt.html
for details]

gcc -fplugin=melt -fplugin-arg-melt-mode=translatetomodule \
-fplugin-arg-melt-arg=your-foo.melt \
-c emptyfile.c -o /dev/null

During this translation you'll get messages from warmelt-outobj.melt:

warning: MELT module your-foo does not claim GPL compatibility
using MODULE_IS_GPL_COMPATIBLE macro
notice: see http://www.gnu.org/licenses/gcc-exception-3.1.en.html

and MELT would have produced a your-foo.so MELT binary module. Later on,
(perhaps a week after) you'll use that module to analyze (or perhaps
even optimize - which is against the GCC runtime exception if you
distribute the so compiled binary) some other-bar.cc file

g++ -fplugin=melt -fplugin-arg-melt-extra=your-foo \
-fplugin-arg-melt-mode=fooanalysis \
-c -O2 -Wall other-bar.cc

then you'll get from melt-runtime.cc:

warning: MELT module your-foo does not claim to be GPL compatible
notice: see http://www.gnu.org/licenses/gcc-exception-3.1.en.html

(I just added also the notice in svn.rev 207025.), should that be

warning: MELT module your-foo is not licensed under
a GPL-compatible license

or even
warning: MELT module your-foo is not licensed under
a GPL-compatible license, so usage of compiled binary
could be restricted see
http://www.gnu.org/licenses/gcc-exception-3.1.en.html


instead?

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

> Yes, I think that is a good idea.
>
> Hope this helps.


It did help a lot. Thanks Ian!


Cheers