Re: DragonEgg has been revived

["Dan'l Miller" <optikos@verizon.net>]

On Wednesday, May 23, 2018 at 2:27:30 PM UTC-5, Chris M Moore wrote:
> On 23/05/2018 16:51, Dan'l Miller wrote:
> 
> <snip>
> 
> > You are so GPLv2; that is the way it was under GPLv2 back in the old days.  Newsflash: nearly a decade ago, they relicensed modern releases of FSF GCC as GPLv3 with Runtime Exception v3.1 which does in fact have licensing restrictions on Target Code and on Eligible Compilation Process (via Runtime Exception v3.1) by merely passing, say, MIT/X11-licensed or BSD-licensed source code through the modern GCC compiler to generate the Target Code for that MIT/X11-licensed or BSD-licensed executable or DLL.  Simon, you are •factually incorrect• nowadays (post-GPLv2) in your claim “that the GCC compiler itself doesn't assert any licensing restrictions over target code generated by it beyond that derived from the original source code”, because the ••GPLv3 license of the modern GCC compiler itself•• spreads (dare I say, virally) to the otherwise MIT/X11-licensed or BSD-licensed Target Code
> 
> Nope.  The Eligible Compilation Process covers the compilation process 
> itself, not the end product.  This was introduced to stop non-GPLed 
> plugins to gcc.  See https://lwn.net/Articles/301959/

Independent of why historically it was devised, the wording of Runtime Exception v3.1 is quite clearly applying to cases beyond merely that one historical case:

“The "Compilation Process" transforms code entirely represented in ••non-intermediate•• languages designed for human-written code, and/or in Java Virtual Machine byte code, into Target Code.”

Is intermediate representation written out as a file meeting the terms/definition of Target Code in the Runtime Exception?  The following quotation answers that question:

“"Target Code" refers to output from any compiler for a real or virtual target processor architecture, in executable form or suitable for input to an assembler, loader, linker and/or execution phase. Notwithstanding that, Target Code does not include data in any format that is used as a compiler intermediate representation, or used for producing a compiler intermediate representation.”

The key word there is “notwithstanding”.  It means that even if supposedly target code meets any of the definitions in the first sentence, its ability to actually be Target Code is ruined/spoiled by the second sentence.  I'm pretty sure that “data in ••any format••” and “compiler intermediate representation” are pretty big clues about LLVM bitcode IR's standing in the terms of this Runtime Exception v3.1.

Chris, you are fixated on one case in history.  The language of the Runtime Exception v3.1 that they authored is much broader than than one historical motivating case.  Just read the Runtime Exception v3.1 yourself and you will see that the word plug-in never appears at all.  Now imagine that all of LLVM and/or Polly outside of GCC is substantially equivalent to that non-GPLed plugin to GCC, but simply starts executing after a GCC compiler finishes executing by reading some sort of IR file written by GCC.  Whether it was an actual plug-in into an orifice within GCC matters not one whit.  What matters is whether a file that was not-Source-Code and not-Target-Code was written by GCC to feed into a downstream executable.

Let's walk step by step:

A) If a supposed Eligible Compilation Process is not a Compilation Process, then it certainly is not an Eligible Compilation Process (due to failing to comply with the the terms governing what a Compilation Process is).

B) If a supposed Compilation Process produces some non-Target-Code derivative work representing Source Code, then it certainly is not a Compilation Process (due to failing to comply with the terms governing what a Compilation Process is:  needing to produce not-IR Target Code from not-IR Source Code).

C) If a supposed Target Code triggers any of the “notwithstanding”, then it certainly is not Target Code (due to failing to comply with the “notwithstanding” IR terms).

D) The “notwithstanding” IR terms on Target Code spoil everything downstream from meeting their definitions in the Runtime Exception v3.1.

E) Without meeting the Runtime Exception v3.1's definitions downstream from the “notwithstanding”, the only remaining right a conveyor has to convey Object Code via GPLv3 is to satisfy the provide-source-code terms of GPLv3,
E.a) because the “notwithstanding” IR terms spoiled meeting Target Code's definition,
E.b) because the spoiled not-Target-Code and “non-intermediate” both in turn spoiled meeting Compilation Process's definition,
E.c) because the spoiled not-Compilation-Process in turn spoiled Eligible Compilation Process's definition,
E.d) because the spoiled not-Eligible-Compilation-Process in turn spoiled the Runtime Exception v3.1,
and
E.e) because the spoiled Runtime Exception v3.1 spoiled itself so completely as a valid amendment to the GPLv3 (i.e., the Runtime Exception converted itself into a big NO-OP), leaving only Object Code in GPLv3 as specifying the terms to convey the IR or the resulting machine-code.

So in fewer words, I nope your nope.