public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
From: Max Filippov <jcmvbkbc@gmail.com>
To: Ian Lance Taylor <iant@google.com>
Cc: "augustine.sterling@gmail.com" <augustine.sterling@gmail.com>,
		"gcc-patches@gcc.gnu.org" <gcc-patches@gcc.gnu.org>,
		"linux-xtensa@linux-xtensa.org" <linux-xtensa@linux-xtensa.org>,
	Le-Chun Wu <lcwu@google.com>
Subject: Re: [RFC 2/5] gcc: xtensa: make configuration dynamic
Date: Fri, 26 May 2017 18:48:00 -0000	[thread overview]
Message-ID: <CAMo8BfKDi3BV0ZkY6S6iGcfCG0=TEU7+F9yD9cEAxtcUWNtjpA@mail.gmail.com> (raw)
In-Reply-To: <CAKOQZ8w_y+w_cmmhPo91jQmn=YA_CWygZ04138HaUi5xg1VZ9A@mail.gmail.com>

On Fri, May 26, 2017 at 7:44 AM, Ian Lance Taylor <iant@google.com> wrote:
> On Thu, May 25, 2017 at 1:31 PM, Max Filippov <jcmvbkbc@gmail.com> wrote:
>> On Thu, May 25, 2017 at 11:24 AM, augustine.sterling@gmail.com
>> <augustine.sterling@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

  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:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

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

  git send-email \
    --in-reply-to='CAMo8BfKDi3BV0ZkY6S6iGcfCG0=TEU7+F9yD9cEAxtcUWNtjpA@mail.gmail.com' \
    --to=jcmvbkbc@gmail.com \
    --cc=augustine.sterling@gmail.com \
    --cc=gcc-patches@gcc.gnu.org \
    --cc=iant@google.com \
    --cc=lcwu@google.com \
    --cc=linux-xtensa@linux-xtensa.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* 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).