public inbox for
 help / color / mirror / Atom feed
From: Max Filippov <>
To: Ian Lance Taylor <>
Cc: "" <>,
		"" <>,
		"" <>,
	Le-Chun Wu <>
Subject: Re: [RFC 2/5] gcc: xtensa: make configuration dynamic
Date: Fri, 26 May 2017 18:48:00 -0000	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <>

On Fri, May 26, 2017 at 7:44 AM, Ian Lance Taylor <> wrote:
> On Thu, May 25, 2017 at 1:31 PM, Max Filippov <> wrote:
>> On Thu, May 25, 2017 at 11:24 AM,
>> <> 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
> ( 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

> 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

-- Max

  reply	other threads:[~2017-05-26 18:41 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-05-22 21:09 [RFC 0/5] xtensa: support dynamic configuration Max Filippov
2017-05-22 21:09 ` [RFC 5/5] libgcc: xtensa: use built-in configuration Max Filippov
2017-05-22 21:09 ` [RFC 4/5] gcc: xtensa: add __XCHAL_* builtins Max Filippov
2017-05-22 21:09 ` [RFC 2/5] gcc: xtensa: make configuration dynamic Max Filippov
2017-05-25 18:25   ` augustine.sterling
2017-05-25 20:57     ` Max Filippov
2017-05-26 15:04       ` Ian Lance Taylor via gcc-patches
2017-05-26 18:48         ` Max Filippov [this message]
2017-05-22 21:09 ` [RFC 3/5] gcc: xtensa: support dynconfig on windows Max Filippov
2017-05-22 21:31 ` [RFC 1/5] gcc: xtensa: allow XCHAL_* macros to be non-constant Max Filippov
2017-05-22 21:49   ` augustine.sterling
2017-05-23  2:19     ` Max Filippov
2017-05-25 18:24   ` augustine.sterling
2017-06-14 17:23     ` Max Filippov

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='' \ \ \ \ \ \ \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).