On Thu, May 25, 2017 at 1:31 PM, Max Filippov <jcmvb...@gmail.com> wrote: > On Thu, May 25, 2017 at 11:24 AM, augustine.sterl...@gmail.com > <augustine.sterl...@gmail.com> wrote: > >> Please note that by using a plugin mechanism, there are licensing >> issues that come into play, that are different from the usual >> licensing issues. I would be absolutely sure that you all are OK with >> how the runtime exception applies to this new situation. > > All code used for building the configuration shared object is either GPL > (part of binutils) or MIT (xtensa configuration overlay), so it should be ok?
You are in effect introducing a new kind of plugin mechanism. I won't comment on whether it should use the existing plugin mechanism or not, but it's important to stress that the GCC Runtime Library Exception (https://www.gnu.org/licenses/gcc-exception-3.1.en.html) has rules that apply here. In effect, if you want to distribute the binary produced by GCC, all the plugins that you use must be available under a GPL-compatible license. The people to whom you distribute the binary produced by GCC must be able to themselves build the plugin used to create the binary. The plugin may not have any proprietary source code. One way that the GCC plugin mechanism makes that clear is by requiring the plugin to define a symbol named, literally, "plugin_is_GPL_compatible". While there is no enforcement mechanism as such, this ensures that the person creating the plugin acknowledges that at the very least the plugin is supposed to be under a GPL compatible license. I think that if you are going to introduce a new plugin mechanism, you should adopt the same approach. Ian
