This is the mail archive of the
mailing list for the GCC project.
Re: GPLv3 clarification - what constitutes IR
- From: Alexander Monakov <amonakov at ispras dot ru>
- To: Richard Biener <richard dot guenther at gmail dot com>
- Cc: 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, help at softwarefreedom dot org, laguest at archeia dot com
- Date: Mon, 6 Mar 2017 20:55:10 +0300 (MSK)
- 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> <755C98CF-0062-48E4-B575-862481D60CB3@gmail.com>
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.