From: Richard Biener <richard.guenther@gmail.com>
To: Alexander Monakov <amonakov@ispras.ru>
Cc: Ian Lance Taylor <iant@google.com>,Ian Lance Taylor via gcc
<gcc@gcc.gnu.org>,laguest@mail.com,help@softwarefreedom.org,laguest@archeia.com
Subject: Re: GPLv3 clarification - what constitutes IR
Date: Mon, 06 Mar 2017 18:03:00 -0000 [thread overview]
Message-ID: <A33490E3-FB64-4E34-A120-FBEEB5EA3F3E@gmail.com> (raw)
In-Reply-To: <alpine.LNX.2.20.13.1703062042010.2449@monopod.intra.ispras.ru>
On March 6, 2017 6:55:10 PM GMT+01:00, Alexander Monakov <amonakov@ispras.ru> wrote:
>On Mon, 6 Mar 2017, Richard Biener wrote:
>> >I am not a lawyer and this is not legal advice.
>> >
>> >Generating SPIR-V output would not cause that output to become GPLv3
>> >licensed. However, linking the result against the GCC support
>> >libraries, as is normally required for any program generated by GCC,
>> >and then distributing the resulting executable to other people,
>would
>> >require you to use an eligible compilation process (as defined by
>the
>> >GCC Runtime Library Exception license that you cite). What this
>means
>> >in practice is that you can not take SPIR-V, do further processing
>it
>> >using a proprietary compiler, link the result with the GCC runtime
>> >libraries, and then distribute the resulting program to anybody
>else.
>> >
>> >I don't think it is necessary to determine whether SPIR-V is "target
>> >code" or "intermediate representation" to draw that conclusion.
>>
>> Note we already have the HSAIL and PTX backends which have the very
>same
>> (non-)problem. Both invoke a proprietary compiler for final
>compilation.
>
>Sorry, to me this statement sounds a bit ambiguous, so allow me to
>clarify:
>there is no mandatory invocation of proprietary code generators taking
>place as
>part of GCC invocation (I think there's none at all in case of HSAIL,
>and in
>case of PTX it's done for the purpose of syntax checking and can be
>omitted).
>
>Translation of HSAIL/PTX assembly to GPU binary code takes place when
>the
>host executable runs, on user's machine, by invoking corresponding
>libraries (in
>case of PTX it's NVIDIA's CUDA driver library).
>
>There is no support for translating HSAIL/PTX on the developer's
>machine and
>linking the resulting GPU binary code into GCC-produced executable.
Yes, the final compilation taking part 'after' distribution might be a working loophole here. Not sure if that was intended though (and both PTX and HSAIL and up being dynamically linked with libgomp).
I suppose some bits of clarifying documentation would be nice here.
Richard.
>Hope that helps.
>Alexander
prev parent reply other threads:[~2017-03-06 18:03 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-03-06 17:12 laguest
2017-03-06 17:29 ` Ian Lance Taylor via gcc
2017-03-06 17:39 ` Richard Biener
2017-03-06 17:55 ` Alexander Monakov
2017-03-06 18:03 ` Richard Biener [this message]
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=A33490E3-FB64-4E34-A120-FBEEB5EA3F3E@gmail.com \
--to=richard.guenther@gmail.com \
--cc=amonakov@ispras.ru \
--cc=gcc@gcc.gnu.org \
--cc=help@softwarefreedom.org \
--cc=iant@google.com \
--cc=laguest@archeia.com \
--cc=laguest@mail.com \
/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).