Re: checking GPL compatibility in MELT meta-plugin

[Basile Starynkevitch <basile at starynkevitch dot net>]

On Thu, 2014-01-23 at 17:42 -0800, Ian Lance Taylor wrote:
> On Thu, Jan 23, 2014 at 1:28 PM, Basile Starynkevitch
> <basile@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

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