This is the mail archive of the
mailing list for the GCC project.
Re: GPLv3 clarification - what constitutes IR
- From: Richard Biener <richard dot guenther at gmail dot com>
- To: Ian Lance Taylor <iant at google dot com>,Ian Lance Taylor via gcc <gcc at gcc dot gnu dot org>,laguest at mail dot com
- Cc: help at softwarefreedom dot org,GCC Development <gcc at gcc dot gnu dot org>,laguest at archeia dot com
- Date: Mon, 06 Mar 2017 18:39:49 +0100
- Subject: Re: GPLv3 clarification - what constitutes IR
- Authentication-results: sourceware.org; auth=none
- References: <trinity-180f0916-3b71-44db-8057-43cf8d8fd894-1488820351946@3capp-mailcom-lxa08> <CAKOQZ8wAe=RvnnHmMBi=oNKCBYkS3uXAFS7BzjhSmMWWfqywemail@example.com>
On March 6, 2017 6:29:49 PM GMT+01:00, Ian Lance Taylor via gcc <firstname.lastname@example.org> wrote:
>On Mon, Mar 6, 2017 at 9:12 AM, <email@example.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
>> flag. The positive of this would be that any language that GCC
>> 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
>> 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.