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

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.

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.


  reply	other threads:[~2017-05-26 14:44 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 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 [this message]
2017-05-26 18:48         ` Max Filippov
2017-05-22 21:09 ` [RFC 5/5] libgcc: xtensa: use built-in configuration Max Filippov
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).