From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=unavailable autolearn_force=no version=3.4.4 X-Received: by 2002:a24:6ed2:: with SMTP id w201-v6mr1727787itc.4.1527278531696; Fri, 25 May 2018 13:02:11 -0700 (PDT) X-Received: by 2002:a9d:5608:: with SMTP id e8-v6mr434690oti.5.1527278531422; Fri, 25 May 2018 13:02:11 -0700 (PDT) Path: eternal-september.org!reader01.eternal-september.org!reader02.eternal-september.org!feeder.eternal-september.org!news.gegeweb.eu!gegeweb.org!usenet-fr.net!proxad.net!feeder1-2.proxad.net!209.85.166.216.MISMATCH!v8-v6no2461868itc.0!news-out.google.com!f20-v6ni2196itd.0!nntp.google.com!u74-v6no2461437itb.0!postnews.google.com!glegroupsg2000goo.googlegroups.com!not-for-mail Newsgroups: comp.lang.ada Date: Fri, 25 May 2018 13:02:11 -0700 (PDT) In-Reply-To: Complaints-To: groups-abuse@google.com Injection-Info: glegroupsg2000goo.googlegroups.com; posting-host=47.185.233.194; posting-account=zwxLlwoAAAChLBU7oraRzNDnqQYkYbpo NNTP-Posting-Host: 47.185.233.194 References: <5c2523c1-9ea5-453c-b80e-9cb0dcd16de0@googlegroups.com> <293cf892-1320-49e6-a25f-a36ea098cd34@googlegroups.com> <294fa0cd-ec72-4f0f-8065-0a3d5e1087fa@googlegroups.com> User-Agent: G2/1.0 MIME-Version: 1.0 Message-ID: <81f24e27-8c4a-42e5-8f96-9ac3780a72af@googlegroups.com> Subject: Re: DragonEgg has been revived From: "Dan'l Miller" Injection-Date: Fri, 25 May 2018 20:02:11 +0000 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Xref: reader02.eternal-september.org comp.lang.ada:52683 Date: 2018-05-25T13:02:11-07:00 List-Id: 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. >=20 > 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 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.=20 The senario B is written to focus on a hypothetical FSF=C2=A0GNAT (that has= the IR-file-writing extension that you propose) that is compiling an iOS= =C2=A0app 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 resemb= les this Scenario B, the more that it could conceivably apply to the GNAT f= or MacOS over time, regarding submitting MacOS apps to the Mac App Store, w= hich might be an intended use-case for the GNAT-for-MacOS builds that you m= aintain. Let's walk step by step, but for brevity of writing here (to avoid copy-pas= ting 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 contrac= tual-term is mentioned below. Please pause your reading below at each capi= talized contractual-term below to go read their definition and cascading-ra= mification usage in GPLv3 or RLEv3.1, so that you untangle the reading-comp= rehension/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 vi= rally: 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 &=C2=A0linking 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 cont= ractual-terms; R mnemonic for runtime] d) once for my app [henceforce with an M- prefix on contractual-terms; M mn= emonic for my or Miller, whichever you prefer] so that we can clearly see the R-to-M viral communicability of the licensin= g virus (and the lack of G-to-M communicability). Just to be clear M-Contractual-Term is shorthand for Contractual Term as de= fined in either GPLv3 or RLEv3.1 when those 2 documents are read with my ap= p in mind (called in legalese jargon: reading the license onto my app) when= linking with FSF GCC's runtime by FSF=C2=A0GCC. 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 de= fined 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 G= CC=C2=A0runtime) when FSF GCC's runtime is built by FSF=C2=A0GCC. R-Contra= ctual-Term is for when Contractual Term in either the GPLv3 or RLEv3.1 or b= oth are read onto GCC's runtime. Just to be clear W-Contractual-Term is shorthand for Contractual Term as de= fined in either GPLv3 or RLEv3.1 when those 2 documents are read with IR-fi= le-writing extension in mind (called in legalese jargon: reading the licens= e onto IR-file-writing extension) when building FSF GCC-the-compiler-proper= with any capable C/C++ compilers. W-Contractual-Term is for when Contract= ual Term in either the GPLv3 or RLEv3.1 or both are read onto IR-file-writi= ng extension. Just to be clear G-Contractual-Term is shorthand for Contractual Term as de= fined in either GPLv3 or RLEv3.1 when those 2 documents are read with GCC-t= he-compiler-proper in mind (called in legalese jargon: reading the license = onto GCC-the-compiler-proper) when building FSF GCC-the-compiler-proper wit= h 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 differe= nt legalese term that gets overtly defined in the contract, separate from a= ny dictionary meaning(s) (and baggage and ambiguity and preconceptions) tha= t it might have in commonfolk's everyday commonplace life or that it might = have in technical jargon known commonly among technical experts. The viral= ity of the license is communicable via the contractual-terms in initial-cap= italized 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 th= e object code of FSF GCC as itself licensed under GPLv3. 2)=C2=A0Let's assume that the IR-file-writing extension to GCC has already = been imported into the GCC directory tree from some permissive licensed ext= ernal repository of source code, e.g., UofIllinois/NCSA. (Btw, to skip a f= ew steps, let's assume that the IR-file-writing extension is not a separate= ly/later compiled plug-in, but rather it is literally in the GCC G-Source-C= ode tree.) Copyright applies first &=C2=A0foremost to a document, which fo= r source code is the source-code file (analogous to an individual encyclope= dia volume), not the directory tree as a mere compilation (analogous to a s= et 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 co= ntain a copyright notice evoking GPLv3 or those files still have their copy= right notice that evokes the UofIllinois/NCSA license. Let's assume the mo= re-subtle case: they still have their UofIllinois/NCSA license notificatio= n. 3)=C2=A0As the build of GCC=C2=A0gets 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 do= es the license of the derivative-work .o object-file file. (Hold your fire= ; see next 2 steps.) 4)=C2=A0The build of GCC gets around to linking the .o files (or library ar= chives thereof) of IR-file-writing extension to at other G-Object-Code from= step #1. 5)=C2=A0step #4 causes IR-file-writing extension's object code to be (dare = I say, virally) transformed into W-Object-Code as the contractual-term defi= ned 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 exte= nsion's source code (which just became W-Source-Code as GPLv3 reads onto th= e IR-file-writing extension) or 6.1.1)=C2=A0Note what just happened there in 6.1:=C2=A0 despite whatever ap= parent blah-blah-blah UofIllinois/NCSA GPLv3-compatible license-grant appea= red atop W-Source-Code's files, the provide-the-source-code terms of GPLv3'= W-Object-Code just eclipsed that UofIllinois/NCSA=C2=A0license-grant. Thi= s 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 i= n step step #B28=C2=A0below is not as widely known.) 6.2)=C2=A0Note that because W-Object-Code was linked with G-Object-Code (in= stead of with R-Object-Code) and because G-Object-Code is licensed with GPL= v3 unamended, RLEv3.1 shall not get evoked (even if the IR-file-writing ext= ension were to have invoked at least one subroutine in GCC's runtime). Bec= ause RLEv3.1 doesn't get evoked, RLEv3.1 isn't read onto the IR-file-writin= g extension, leaving W-Object-Code's demands to provide W-Source-Code stand= ing in GPLv3 unamended. 6.2.1)=C2=A0License 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 ut= ilized to build the GCC runtime. 8)=C2=A0During 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)=C2=A0During 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 G= PLv3. 10)=C2=A0Because of step #9, the only right to convey R-Object-Code is to s= atisfy 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 RLEv= 3.1, f is then deemed R-Runtime-Library as per the definition in RLEv3.1. 12)=C2=A0Because 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 t= o satisfy the =E2=80=9Cnot otherwise based on [R-]Runtime[-]Library=E2=80= =9D clause in the attempted definition of R-Independent-Module. Hence, R-I= ndependent-Module fails to be defined here. Where the absence of R-Indepen= dent-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 g= et 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-C= ode'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)=C2=A0Because 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)=C2=A0License analysis of R-Source-Code and R-Object-Code has reached = its natural-conclusion terminus. 16)=C2=A0The GCC compiler that contains both G-Object-Code and W-Object-Cod= e from prior steps then starts compiling my app's source code. 17) But then when my app's source code causes (even indirectly) the invocat= ion of even a single subroutine in R-Source-Code, then my app is linked wit= h R-Object-Code). 18) Step #17's linkage causes my app's object code to be (dare I say, viral= ly) transformed for the time being into M-Object-Code as the contractual-te= rm defined in GPLv3. 19) Step #18 causes my app's source code to be (dare I say, virally) transf= ormed 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-Gr= ant-of-Additional-Permission, so that my app gets out of the GPLv3's demand= s on M-Object-Code. 21) RLEv3.1 is predicated on my app being compiled by an M-Elligible-Compil= ation-Process. 22) RLEv3.1's M-Elligible-Compilation-Process is predicated on M-Eligible-C= ompilation-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 ha= rdware-processor machine-code (or hardware-processor assembly language ther= eof) and then merely link-loaded and then merely executed. A25) The logical-deduction chain of =E2=80=9Cif M-Target-Code satisfied=E2=80=9D begets =E2=80=9Cif M-Compilation-Process satisfied=E2=80=9D begets =E2=80=9Cif M-Eligible-Compilation-Process satisfied=E2=80=9D begets =E2=80=9Cif RLEv3.1 satisfied=E2=80=9D then has successfully recategorized (viral) M-Object-Code into mere (nonvir= al) M-Target-Code, dispensing with any need to provide source code or provi= de Installation Information or provide Corresponding Source Code over in GP= Lv3. GPLv3 and RLEv3.1 reading onto my ap stops at this terminus, ending t= he GPLv3 and RLEv3.1 license examination for my app. The lifetime of the e= ffective temporary instantiation of M-Object-Code and M-Source-Code as cont= ractual terms that might need to be complied with has effectively ended, as= M-Target-Code eclipses M-Object-Code as per the special permissions grante= d by the RTEv3.1. Whew! My app dodged that bullet. versus https://thenextweb.com/apple/2015/06/17/apples-biggest-developer-news-at-ww= dc-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 i= OS App Store (which is where I suspect as a totally wild guess that Apple w= as heading with this re-compiler if all iOS frameworks become available on = MacOS), and perhaps for different eras of ARM processors soldered into iDev= ices. B25) Nonjailbroken iDevices are what is called a walled garden, where the o= nly apps (other than development mode, enterprise side-loading, and invitat= ion-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 re= quiring LLVM bitcode IR files at time of submission. B27) For each file in M-Source-Code, the GCC=C2=A0compilation in step #16 w= rites an IR=C2=A0file 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 sen= tences. =C2=A0Due to step #B27 being an M-Object-File is in fact IR, the = =E2=80=9Cnotwithstanding=E2=80=9D clause in the 2nd sentence of RLEv3.1's a= ttempt to define M-Target-Code is triggered, overriding any potential defin= itions of M-Target-Code in the 1st sentence of RLEv3.1's attempt to define = M-Target-Code. That is how =E2=80=9Cnotwithstanding=E2=80=9D works in lega= lese: literally if the 2nd sentence is satisfied, the 2nd sentence drops a= nuclear bomb on the 1st sentence, no matter what impervious bomb shelter t= he 1st sentence thought that it was hiding within, literally leaving the at= tempted definition of M-Target-Code =E2=80=A2with=E2=80=A2 all attempted de= finitions =E2=80=A2not=E2=80=A2 =E2=80=A2standing=E2=80=A2** or equivalentl= y literally the attempt to define M-Target-Code in the 1st sentence did =E2= =80=A2not=E2=80=A2 =E2=80=A2withstand=E2=80=A2 the nuclear-bomb blast deton= ated in the 2nd sentence**, because the 1st sentence was blown to smitheree= ns by the dropping of the =E2=80=9Cnotwithstanding=E2=80=9D nuclear-bomb re= garding 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 occu= rs downstream, let's put M-PhthphthphTC downstream so it is clear that M-Ta= rget-Code is absent. B30) In RLEv3.1, M-Compilation-Process needs M-Target-Code to have been suc= cessfully defined. But instead M-PhthphthphTC is all that came out of step= s #B28/#B29. So now, M-Compilation-Process fails to get defined. Where th= e absence of M-Compilation-Process occurs downstream, let's put M-Phthphthp= hCP 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-Proces= s occurs downstream, let's put M-PhthphthphECP downstream so it is clear th= at M-Eligible-Compilation-Process is absent. B32) In RLEv3.1, M-Grant-of-Additional-Permission needs M-Eligible-Compilat= ion-Process to have been successfully defined. But instead M-PhthphthphECP= is all that came out of step #B31. So now, M-Grant-of-Additional-Permissi= on fails to get defined, eliding all of section 1 of RLEv3.1.=20 B33) Regardless of step #B32, in RLEv3.1, R-No-Weakening-of-the-GCC-Copylef= t 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)=C2=A0Step #B33 re-affirms M-Object-Code's provide-M-Source-Code dema= nd over in GPLv3. B33.2)=C2=A0And to the point of the walled-garden on nonjailbroken iDevices= , step #B33 re-affirms M-Object-Code's provide-M-Installation-Information d= emand over in GPLv3. B33.3)=C2=A0Step #B33 re-affirms M-Object-Code's provide-M-Installation-Inf= ormation'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)=C2=A0RLEv3.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-Addition= al-Permission would have been successfully defined. But instead the failed= attempt to define M-Grant-of-Additional-Permission caused Section 1 of RLE= v3.1 to self-elide itself. So the RTEv3.1's house-of-cards that RLEv3.1 tr= ies 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 m= ust 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 anal= ysis: Because iDevices are not limited to substantially industrial usage (= e.g., within jet-fighter cockpits, with telephone-switch central offices, o= n factory floors), it sure seems like (in any plain-language reading of GPL= v3) 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 pro= hibiting apps built by GPLv3-with-RLEv3.1-licensed compilation processes. B39) Although it might have been done for historically different reasons, h= ow convenient for Apple to have discontinued usage of GPLv3-with-RLEv3.1-li= censed compilation processes, because it seems that LLVM-world permits IR a= ctivities that GCC-world does not permit (at least without the FSF-GCC-comp= iled apps and the walled-garden into which those apps are being installed a= ll being open-source as per the GPLv3 and its RLEv3.1 amendment).