On Fri, May 26, 2017 at 7:44 AM, Ian Lance Taylor <i...@google.com> wrote: > 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.
Thanks, that's how I understood that. I've added a note to the plugin README: https://github.com/jcmvbkbc/xtensa-dynconfig/blob/master/README > 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. Sure I can add such requirement to this mechanism and implement that check. -- Thanks. -- Max
