Re: DragonEgg has been revived

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

On Friday, May 25, 2018 at 3:28:04 AM UTC-5, Simon Wright wrote:
> I modify GCC so that it emits some intermediate representation which
> might, for example, act as input to an LLVM assembler. My modifications
> are released under the GPL.
> 
> Explain to me exactly how that, on its own, causes any object code
> generated via that compiler to fall under the GPL if the source code was
> licensed under e.g. a BSD license.

I already have done that in a reply above, but I will try again, trying to be even more lucid.  Simon Wright, please pay especial attention to steps #B28, #B29, #B33, #B33.1, #B33.2, #B33.3, #B35, and #B36, because those are the points where the communicability of the license virus occurs, which is the communicability of viral license which you claimed did not exist:

> On Wednesday, May 23, 2018 at 2:26:49 AM UTC-5, Simon Wright wrote:
>> Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> writes:
>>
>> > What I would like to see is an Ada compiler that can generate code
>> > for a wide range of targets without any GPL restrictions on the
>> > generated code.
>>
>> Pretty sure that's called GCC. 

The senario B is written to focus on a hypothetical FSF GNAT (that has the IR-file-writing extension that you propose) that is compiling an iOS app to LLVM bitcode IR for submission to the iDevices' iOS App Store.  Clearly, the more that submitting a MacOS app to the Mac App Store resembles this Scenario B, the more that it could conceivably apply to the GNAT for MacOS over time, regarding submitting MacOS apps to the Mac App Store, which might be an intended use-case for the GNAT-for-MacOS builds that you maintain.

Let's walk step by step, but for brevity of writing here (to avoid copy-pasting sentences from the GPLv3 and RLEv3.1), all readers should open up
https://www.gnu.org/licenses/gpl-3.0.en.html
and
https://www.gnu.org/licenses/gcc-exception-3.1.html
in adjacent WWWbrowser tabs/windows right now to read along as each contractual-term is mentioned below.  Please pause your reading below at each capitalized contractual-term below to go read their definition and cascading-ramification usage in GPLv3 or RLEv3.1, so that you untangle the reading-comprehension/logic-puzzle riddle that is cleverly encoded throughout GPLv3 and RLEv3.1.

Note that there exist 3 readings of the GPLv3 and its RLEv3.1 for the case that Simon Wright brings up above, one for each build of software, because it is the build (especially the linking) at which the license can spread virally:
a) once for building GCC-the-compiler-proper pristine as it was prior to b below [henceforce with a G- prefix on the contractual-terms; G mnemonic for GCC] and
b) once for compiling & linking the IR file-writing that Simon Wright proposes [henceforce with a W- prefix on the contractual-terms; W mnemonic for writing or Wright, whichever you prefer] and
c) once for building GCC's runtime [henceforce with a R- prefix on the contractual-terms; R mnemonic for runtime]
d) once for my app [henceforce with an M- prefix on contractual-terms; M mnemonic for my or Miller, whichever you prefer]
so that we can clearly see the R-to-M viral communicability of the licensing virus (and the lack of G-to-M communicability).

Just to be clear M-Contractual-Term is shorthand for Contractual Term as defined in either GPLv3 or RLEv3.1 when those 2 documents are read with my app in mind (called in legalese jargon: reading the license onto my app) when linking with FSF GCC's runtime by FSF GCC.  M-Contractual-Term is for when Contractual Term in either the GPLv3 or RLEv3.1 or both are read onto my app.

Just to be clear R-Contractual-Term is shorthand for Contractual Term as defined in either GPLv3 or RLEv3.1 when those 2 documents are read with GCC's runtime in mind (called in legalese jargon: reading the license onto the GCC runtime) when FSF GCC's runtime is built by FSF GCC.  R-Contractual-Term is for when Contractual Term in either the GPLv3 or RLEv3.1 or both are read onto GCC's runtime.

Just to be clear W-Contractual-Term is shorthand for Contractual Term as defined in either GPLv3 or RLEv3.1 when those 2 documents are read with IR-file-writing extension in mind (called in legalese jargon: reading the license onto IR-file-writing extension) when building FSF GCC-the-compiler-proper with any capable C/C++ compilers.  W-Contractual-Term is for when Contractual Term in either the GPLv3 or RLEv3.1 or both are read onto IR-file-writing extension.

Just to be clear G-Contractual-Term is shorthand for Contractual Term as defined in either GPLv3 or RLEv3.1 when those 2 documents are read with GCC-the-compiler-proper in mind (called in legalese jargon: reading the license onto GCC-the-compiler-proper) when building FSF GCC-the-compiler-proper with any capable C/C++ compilers.  G-Contractual-Term is for when Contractual Term in either the GPLv3 or RLEv3.1 or both are read onto GCC-the-compiler-proper.

Note that what a human being calls, say, target code might or might not be Target Code as a contractual-term.  The capital letters there are a different legalese term that gets overtly defined in the contract, separate from any dictionary meaning(s) (and baggage and ambiguity and preconceptions) that it might have in commonfolk's everyday commonplace life or that it might have in technical jargon known commonly among technical experts.  The virality of the license is communicable via the contractual-terms in initial-capitalized letters, so pay extra special attention to contractual-terms that start with capital letters.

1) The G-Source-Code term in GPLv3 refers to the source code of FSF GCC as itself licensed under GPLv3.   The G-Object-Code term in GPLv3 refers to the object code of FSF GCC as itself licensed under GPLv3.

2) Let's assume that the IR-file-writing extension to GCC has already been imported into the GCC directory tree from some permissive licensed external repository of source code, e.g., UofIllinois/NCSA.  (Btw, to skip a few steps, let's assume that the IR-file-writing extension is not a separately/later compiled plug-in, but rather it is literally in the GCC G-Source-Code tree.)  Copyright applies first & foremost to a document, which for source code is the source-code file (analogous to an individual encyclopedia volume), not the directory tree as a mere compilation (analogous to a set of encyclopedia volumes that just happen to be conceptualized as orderly sitting together on a shelf).  So either the files in that IR-file-writing extension were updated at time of importation to the GCC source-tree to contain a copyright notice evoking GPLv3 or those files still have their copyright notice that evokes the UofIllinois/NCSA license.  Let's assume the more-subtle case:  they still have their UofIllinois/NCSA license notification.

3) As the build of GCC gets around to compiling each source-code file in the IR-file-writing extension, the effective license for the moment of IR-file-writing extension's source code remains UofIllinois/NCSA, as does the license of the derivative-work .o object-file file.  (Hold your fire; see next 2 steps.)

4) The build of GCC gets around to linking the .o files (or library archives thereof) of IR-file-writing extension to at other G-Object-Code from step #1.

5) step #4 causes IR-file-writing extension's object code to be (dare I say, virally) transformed into W-Object-Code as the contractual-term defined in GPLv3.

6) As per the various M-Object-Code clauses in GPLv3, the only right that I have to convey the W-Object-Code is 6.1:

6.1) to comply with the various demands to provide the IR-file-writing extension's source code (which just became W-Source-Code as GPLv3 reads onto the IR-file-writing extension) or

6.1.1) Note what just happened there in 6.1:  despite whatever apparent blah-blah-blah UofIllinois/NCSA GPLv3-compatible license-grant appeared atop W-Source-Code's files, the provide-the-source-code terms of GPLv3' W-Object-Code just eclipsed that UofIllinois/NCSA license-grant.  This is the viral spread of the GPL license that is most widely known, because it dates all the way back to the GPLv1 era circa 1989.  (The RLEv3.1 one in step step #B28 below is not as widely known.)

6.2) Note that because W-Object-Code was linked with G-Object-Code (instead of with R-Object-Code) and because G-Object-Code is licensed with GPLv3 unamended, RLEv3.1 shall not get evoked (even if the IR-file-writing extension were to have invoked at least one subroutine in GCC's runtime).  Because RLEv3.1 doesn't get evoked, RLEv3.1 isn't read onto the IR-file-writing extension, leaving W-Object-Code's demands to provide W-Source-Code standing in GPLv3 unamended.

6.2.1) License analysis of W-Source-Code and W-Object-Code has reached its natural-conclusion terminus.

7) After the build of GCC-the-compiler-proper finishes, that GCC is then utilized to build the GCC runtime.

8) During step #7, GCC runtime's source code is already R-Source-Code because it is licensed via GPLv3-as-amended-by-RLEv3.1 (or GPLv3-with-RLEv3.1 for short).

9) During the compilation of each R-Source-Code file, the object files of GCC's runtime become R-Object-Code as the contractual-term defined in GPLv3.

10) Because of step #9, the only right to convey R-Object-Code is to satisfy GPLv3's provide-the-R-Source-Code demand.

11) Because each file f in R-Source-Code is a file whose prologue atop its source file states that the only right I have to copy this file is via RLEv3.1, f is then deemed R-Runtime-Library as per the definition in RLEv3.1.

12) Because of step #11 and because R-Object-File is a derivative work under copyright law of R-Source-Code, each file f in R-Source-Code fails to satisfy the “not otherwise based on [R-]Runtime[-]Library” clause in the attempted definition of R-Independent-Module.  Hence, R-Independent-Module fails to be defined here.  Where the absence of R-Independent-Module occurs downstream, let's put R-PhthphthphIM downstream so it is clear that R-Independent-Module is absent.

13) In RLEv3.1, R-Grant-of-Additional-Permission needs R-Independent-Module to have been successfully defined.  But instead M-PhthphthphIM is all that came out of step #12.  So now, R-Grant-of-Additional-Permission fails to get defined.

14) In RLEv3.1, R-No-Weakening-of-the-GCC-Copyleft self-evokes itself, even in step #13's absence of R-Grant-of-Additional-Permission (or equivalently in the presence of step #13's M-PhthphthphIM).  This re-affirms R-Object-Code's provide-R-Source-Code demand over in GPLv3, just in case the this-is-an-amendment-of-GPLv3 language in RLEv3.1's preamble left any doubt.

15) Because of steps #13 and #14, RLEv3.1 did not grant any additional permissions beyond the terms of GPLv3, leaving R-Object-Code's demands to provide R-Source-Code standing in GPLv3 unamended.

15.1) License analysis of R-Source-Code and R-Object-Code has reached its natural-conclusion terminus.

16) The GCC compiler that contains both G-Object-Code and W-Object-Code from prior steps then starts compiling my app's source code.

17) But then when my app's source code causes (even indirectly) the invocation of even a single subroutine in R-Source-Code, then my app is linked with R-Object-Code).

18) Step #17's linkage causes my app's object code to be (dare I say, virally) transformed for the time being into M-Object-Code as the contractual-term defined in GPLv3.

19) Step #18 causes my app's source code to be (dare I say, virally) transformed for the time being into M-Source-Code as the contractual term defined in GPLv3.

20) As per the various M-Object-Code clauses in GPLv3, the only right that I have to convey the M-Object-Code is either:

20.1) to comply with the various demands to provide M-Source-Code or

20.2) to comply with the various requisite expectations of good behavior in RLEv3.1 so that M-Object-Code gets recategorized as M-Target-Code via R-Grant-of-Additional-Permission, so that my app gets out of the GPLv3's demands on M-Object-Code.

21) RLEv3.1 is predicated on my app being compiled by an M-Elligible-Compilation-Process.

22) RLEv3.1's M-Elligible-Compilation-Process is predicated on M-Eligible-Compilation-Process being an M-Compilation-Process in the first place.

23) RLEv3.1's M-Compilation-Process is predicated on satisfying the various contractual restrictions on M-Target-Code.

2 hypothetical cases A versus B:

A24) RLEv3.1's M-Target-Code is satisfied if my app is, say, compiled to hardware-processor machine-code (or hardware-processor assembly language thereof) and then merely link-loaded and then merely executed.

A25) The logical-deduction chain of
“if M-Target-Code satisfied”
begets
“if M-Compilation-Process satisfied”
begets
“if M-Eligible-Compilation-Process satisfied”
begets
“if RLEv3.1 satisfied”
then has successfully recategorized (viral) M-Object-Code into mere (nonviral) M-Target-Code, dispensing with any need to provide source code or provide Installation Information or provide Corresponding Source Code over in GPLv3.  GPLv3 and RLEv3.1 reading onto my ap stops at this terminus, ending the GPLv3 and RLEv3.1 license examination for my app.  The lifetime of the effective temporary instantiation of M-Object-Code and M-Source-Code as contractual terms that might need to be complied with has effectively ended, as M-Target-Code eclipses M-Object-Code as per the special permissions granted by the RTEv3.1.  Whew!  My app dodged that bullet.

versus

https://thenextweb.com/apple/2015/06/17/apples-biggest-developer-news-at-wwdc-that-nobodys-talking-about-bitcode

B24) Apple's forthcoming LLVM-bitcode-IR re-compiler for iOS take my app's M-Object-Code and re-compiles it for, say, both the Mac App Store and the iOS App Store (which is where I suspect as a totally wild guess that Apple was heading with this re-compiler if all iOS frameworks become available on MacOS), and perhaps for different eras of ARM processors soldered into iDevices.

B25) Nonjailbroken iDevices are what is called a walled garden, where the only apps (other than development mode, enterprise side-loading, and invitation-only testing) that are permitted to be downloadable to the iDevice are those that have been approved by Apple for conveyance in the App Store.

B26) At some point Apple could require the availability of LLVM bitcode IR for each app to be approved for the App Store.  This could be by overtly requiring LLVM bitcode IR files at time of submission.

B27) For each file in M-Source-Code, the GCC compilation in step #16 writes an IR file that is deemed M-Object-Code by the (anti-)definition of M-Object-Code as being all files output by the compiler that are not M-Source-Code.

B28)  In RLEv3.1, the attempt to define M-Target-Code is comprised of 2 sentences.  Due to step #B27 being an M-Object-File is in fact IR, the “notwithstanding” clause in the 2nd sentence of RLEv3.1's attempt to define M-Target-Code is triggered, overriding any potential definitions of M-Target-Code in the 1st sentence of RLEv3.1's attempt to define M-Target-Code.  That is how “notwithstanding” works in legalese:  literally if the 2nd sentence is satisfied, the 2nd sentence drops a nuclear bomb on the 1st sentence, no matter what impervious bomb shelter the 1st sentence thought that it was hiding within, literally leaving the attempted definition of M-Target-Code •with• all attempted definitions •not• •standing•** or equivalently literally the attempt to define M-Target-Code in the 1st sentence did •not• •withstand• the nuclear-bomb blast detonated in the 2nd sentence**, because the 1st sentence was blown to smithereens by the dropping of the “notwithstanding” nuclear-bomb regarding IR.

** hence the word: notwithstanding

B29) Oopsies, in step #B28, M-Target-Code failed to get defined, due to the IR nuclear bomb that got dropped.  Where the absence of M-Target-Code occurs downstream, let's put M-PhthphthphTC downstream so it is clear that M-Target-Code is absent.

B30) In RLEv3.1, M-Compilation-Process needs M-Target-Code to have been successfully defined.  But instead M-PhthphthphTC is all that came out of steps #B28/#B29.  So now, M-Compilation-Process fails to get defined.  Where the absence of M-Compilation-Process occurs downstream, let's put M-PhthphthphCP downstream so it is clear that M-Compilation-Process is absent.

B31) In RLEv3.1, M-Eligible-Compilation-Process needs M-Compilation-Process to have been successfully defined.  But instead M-PhthphthphCP is all that came out of step #B30.  Where the absence of M-Eligible-Compilation-Process occurs downstream, let's put M-PhthphthphECP downstream so it is clear that M-Eligible-Compilation-Process is absent.

B32) In RLEv3.1, M-Grant-of-Additional-Permission needs M-Eligible-Compilation-Process to have been successfully defined.  But instead M-PhthphthphECP is all that came out of step #B31.  So now, M-Grant-of-Additional-Permission fails to get defined, eliding all of section 1 of RLEv3.1. 

B33) Regardless of step #B32, in RLEv3.1, R-No-Weakening-of-the-GCC-Copyleft self-evokes itself, even in step #B32's absence of R-Grant-of-Additional-Permission (or equivalently in the presence of step #B32's M-PhthphthphIM).

B33.1) Step #B33 re-affirms M-Object-Code's provide-M-Source-Code demand over in GPLv3.

B33.2) And to the point of the walled-garden on nonjailbroken iDevices, step #B33 re-affirms M-Object-Code's provide-M-Installation-Information demand over in GPLv3.

B33.3) Step #B33 re-affirms M-Object-Code's provide-M-Installation-Information's M-Corresponding-Source-Code demand over in GPLv3.

B33.4) ... just in case the this-is-an-amendment-of-GPLv3 language in RLEv3.1's preamble left any doubt of B33.1, B33.2, and B33.3.

B34) RLEv3.1 would have granted its special magic of M-Target-Code in RLEv3.1 eclipsing M-Object-Code in GPLv3 if and only if M-Grant-of-Additional-Permission would have been successfully defined.  But instead the failed attempt to define M-Grant-of-Additional-Permission caused Section 1 of RLEv3.1 to self-elide itself.  So the RTEv3.1's house-of-cards that RLEv3.1 tries to carefully build up collapses and no special magic occurs:  M-Object-Code stays M-Object-Code; M-ObjectCode's and M-Source-Code's lifetimes live on for my app, over in GPLv3 when reading GPLv3 onto my app.

B35) Now back over in GPLv3, as re-affirmed in step #B33.1, M-Object-Code must provide its M-Source-Code to all possessors of M-Object-Code in one or more GPLv3-specified ways.

B36) Steps #B33.2 and #B33.3 re-affirmed the need for this step #B36's analysis:  Because iDevices are not limited to substantially industrial usage (e.g., within jet-fighter cockpits, with telephone-switch central offices, on factory floors), it sure seems like (in any plain-language reading of GPLv3) an iDevice would be a M-User-Product on which M-Object-Code is going be installed behind not-jail-broken logistical barriers that would require M-Installation-Information and M-Corresponding-Source-Code to be provided.

B37) I don't possess M-Installation-Information and M-Corresponding-Source, but Apple does.

B38) Wouldn't it be wise for Apple to side-step the step #B36's demand for providing M-Installation-Information and M-Corresponding-Source-Code by prohibiting apps built by GPLv3-with-RLEv3.1-licensed compilation processes.

B39) Although it might have been done for historically different reasons, how convenient for Apple to have discontinued usage of GPLv3-with-RLEv3.1-licensed compilation processes, because it seems that LLVM-world permits IR activities that GCC-world does not permit (at least without the FSF-GCC-compiled apps and the walled-garden into which those apps are being installed all being open-source as per the GPLv3 and its RLEv3.1 amendment).