GPLv3 clarification - what constitutes IR

GPLv3 clarification - what constitutes IR

[laguest]

Hi,

I'm looking into the possibility of adding a SPIR-V
(https://www.khronos.org/registry/spir-v) backend to GCC or as a
plug-in. The output of which would be binary from the compiler, not
binutils, with an option to extract a textual representation using an -f
flag. The positive of this would be that any language that GCC supports
could be used for GPGPU and graphics shading.

But would the GCC IR exception (mentioned in
https://www.gnu.org/licenses/gcc-exception-3.1-faq.html) cause any
SPIR-V output from GCC become GPLv3 licenced?

I have also posted this to the GCC ML for discussion as I don't think
it's clear whether or not something like SPIR-V would fall under Target
Code or IR.

Thanks,
Luke A. Guest.

P.S: I currently cannot post from my domain for some reason. I don't know why.

Re: GPLv3 clarification - what constitutes IR

[Ian Lance Taylor via gcc]

On Mon, Mar 6, 2017 at 9:12 AM,  <laguest@mail.com> wrote:
>
> I'm looking into the possibility of adding a SPIR-V
> (https://www.khronos.org/registry/spir-v) backend to GCC or as a
> plug-in. The output of which would be binary from the compiler, not
> binutils, with an option to extract a textual representation using an -f
> flag. The positive of this would be that any language that GCC supports
> could be used for GPGPU and graphics shading.
>
> But would the GCC IR exception (mentioned in
> https://www.gnu.org/licenses/gcc-exception-3.1-faq.html) cause any
> SPIR-V output from GCC become GPLv3 licenced?
>
> I have also posted this to the GCC ML for discussion as I don't think
> it's clear whether or not something like SPIR-V would fall under Target
> Code or IR.

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.

Ian

Re: GPLv3 clarification - what constitutes IR

[Richard Biener]

On March 6, 2017 6:29:49 PM GMT+01:00, Ian Lance Taylor via gcc <gcc@gcc.gnu.org> wrote:
>On Mon, Mar 6, 2017 at 9:12 AM,  <laguest@mail.com> wrote:
>>
>> I'm looking into the possibility of adding a SPIR-V
>> (https://www.khronos.org/registry/spir-v) backend to GCC or as a
>> plug-in. The output of which would be binary from the compiler, not
>> binutils, with an option to extract a textual representation using an
>-f
>> flag. The positive of this would be that any language that GCC
>supports
>> could be used for GPGPU and graphics shading.
>>
>> But would the GCC IR exception (mentioned in
>> https://www.gnu.org/licenses/gcc-exception-3.1-faq.html) cause any
>> SPIR-V output from GCC become GPLv3 licenced?
>>
>> I have also posted this to the GCC ML for discussion as I don't think
>> it's clear whether or not something like SPIR-V would fall under
>Target
>> Code or IR.
>
>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.

Richard.

>Ian

Re: GPLv3 clarification - what constitutes IR

[Alexander Monakov]

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.

Hope that helps.
Alexander

Re: GPLv3 clarification - what constitutes IR

[Richard Biener]

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