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