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:a6b:b903:: with SMTP id j3-v6mr3074877iof.90.1527189982000; Thu, 24 May 2018 12:26:22 -0700 (PDT) X-Received: by 2002:a9d:4712:: with SMTP id a18-v6mr211224otf.1.1527189981730; Thu, 24 May 2018 12:26:21 -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.215.MISMATCH!u74-v6no1306222itb.0!news-out.google.com!b185-v6ni952itb.0!nntp.google.com!v8-v6no1299219itc.0!postnews.google.com!glegroupsg2000goo.googlegroups.com!not-for-mail Newsgroups: comp.lang.ada Date: Thu, 24 May 2018 12:26:21 -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: Subject: Re: DragonEgg has been revived From: "Dan'l Miller" Injection-Date: Thu, 24 May 2018 19:26:21 +0000 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Xref: reader02.eternal-september.org comp.lang.ada:52647 Date: 2018-05-24T12:26:21-07:00 List-Id: On Thursday, May 24, 2018 at 12:19:06 PM UTC-5, Simon Wright wrote: > "Dan'l Miller" writes: > > And the logical and reading-comprehension (and lack thereof) > > contortions contained in later replies along the branches of this > > thread seem to clearly and undeniably demonstrate what Shark8 aptly > > called =E2=80=9Call the morass of licensing=E2=80=9D. Just read all th= e later replies > > along the branches of this thread to see that different readers of & > > commentators on the exact same license text in GPLv3 and/or its > > Runtime Library Exception v3.1 reach drastically different conclusions > > [mainly by cherry-picking different quotations from the license text > > and then ignoring/eliding other passages of the license text]. >=20 > Now we're getting insulting. I keep saying that this is a reading-comprehension problem and logical-dedu= ction problem overtly crafted into (and throughout) the language of the GPL= v3 and RLEv3. I will request reading-comprehension & logical deduction aga= in below (my own included, help me out: quote chapter & verse from statutor= y law or from treaties or from GPLv3 or from RLEv3.1 such that the step-by-= step detailed walk-through below gets dismantled; I will read those seminal= references). > > I later thought of a third category in answer to my own question that > > depends on how much surgery can be deeply & intimately performed on > > Target Code before evoking the =E2=80=9Cnotwithstanding=E2=80=9D clause= in the > > RLEv3.1. At what point of wholesale re-writing of a percentage of the > > Target Code become an act of re-compiling, taking the Target Code > > written by GCC as mere IR to the re-compiler? >=20 > This is relevant to target code derived from source subject to the > RLE. Specifically where in the set {GPLv3, RLEv3.1, copyright law's body of stat= utes in USCode, copyright treaties to which the USA is a signatory} does it= overtly clearly say anything even remotely in the ballpark of that sentenc= e above? I want to read it with my own eyes. I want reading comprehension= . (And hearsay commentary on some forum from 2009 where people speculate a= nd parrot what other people say doesn't count; I want original sources and = seminal references, such as quotations from members of that set above.) > It has nothing to do with target code derived from source under > some other license, eg BSD 3-clause. Same request again for this sentence above. Btw, these 2 sentences are where I strongly believe that you are again fact= ually incorrect. Let's walk step by step, but for brevity of writing here, let all readers p= ause at each capitalized contractual-term below to go read their definition= and cascading-ramification usage in GPLv3 or RLEv3.1, so that reading comp= rehension is emphasized. Note that there exist 2 readings of the GPLv3 and= its RLEv3.1: once for GCC [henceforce G- prefix on the contractual-terms]= and once for my app [henceforce M- prefix on contractual-terms] so that we= can clearly see the G-to-M viral communicability of the licensing virus. = 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 (as reading comprehension) when linking with FSF GCC's runtime. = 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 FSF G= CC itself in mind (as reading comprehension). 1) The G-Source-Code term in GPLv3 initially refers to the source code of F= SF GCC as itself licensed under GPLv3. 2) But then when my app's source code causes (even indirectly) the invocati= on of even a single subroutine in GCC's runtime (which is licensed via the = RTEv3.1), then my app is linked with GCC's runtime library G-Object-Code). 3) #2's linkage causes my app's object code to be (dare I say, virally) tra= nsformed for the time being into M-Object-Code as the contractual-term defi= ned in GPLv3. 4) #3 causes my app's source code to be (dare I say, virally) transformed f= or the time being into M-Source-Code as the contractual term defined in GPL= v3. 5) As per the various M-Object-Code clauses in GPLv3, the only right that I= have to convey the M-Object-Code is either: 5.1) to comply with the various demands to provide my app's source code (wh= ich just became M-Source-Code as my app reads onto GPLv3-with-RLEv3.1) and 5.2) to comply with the various requisite expectations of good behavior in = RLEv3.1 so that my app's M-Object-Code gets recategorized as M-Target-Code = so that my app gets out of the GPLv3's demands on M-Object-Code. 6) RLEv3.1 is predicated on my app being compiled by an M-Elligible-Compila= tion-Process. 7) RLEv3.1's M-Elligible-Compilation-Process is predicated on M-Eligible-Co= mpilation-Process being an M-Compilation-Process in the first place. 8) RLEv3.1's M-Compilation-Process is predicated on satisfying the various = contractual restrictions on M-Target-Code. 2 hypothetical cases A versus B: A9) RLEv3.1's M-Target-Code is satisfied if my app is, say, compiled to har= dware-processor machine-code (or hardware-processor assembly language there= of) and then merely link-loaded and then merely executed. A10) 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 successfully recategorized M-Object-C= ode into mere M-Target-Code, dispensing with any need to provide source cod= e or provide Installation Information or provide Corresponding Source Code = over in GPLv3. My app's reading of GPLv3 and RLEv3.1 stops at this terminu= s. 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 s= pecial permissions in 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 B8) 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 iO= S App Store (which is where I suspect as a totally wild guess that Apple wa= s heading with this re-compiler), and perhaps for different eras of ARM pro= cessors soldered into iDevices. B9) Nonjailbroken iDevices are what is called a walled garden, where the on= ly apps (other than development mode, enterprise side-loading, and invitati= on-only testing) that are permitted to be downloadable to the iDevice are t= hose that have been approved by Apple for conveyance in the App Store. B10) At some point Apple could require the availability of LLVM bitcode IR = for each app to be approved for the App Store. This could either by overtl= y requiring LLVM bitcode IR files at time of submission or via a McSema-esq= ue technology. The following steps don't really care which option Apple ta= kes, but let's write the wording up for the former. B11) Regardless of how the LLVM bitcode IR is actually generated for my app= (e.g., my GELI proposal; DragonEgg on a modern GCC release that is license= d via GPLv3-with-RLEv3.1), the =E2=80=9Cnotwithstanding=E2=80=9D 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 =E2=80=9Cnotwith= standing=E2=80=9D works in legalese: literally if the 2nd sentence is sati= sfied, 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 w= ithin. B12) Oopsies, in B11, M-Target-Code failed to get defined, due to the IR nu= clear bomb that got dropped. Where the absence of M-Target-Code occurs dow= nstream, let's put M-PhthphthphTC downstream so it is clear that M-Target-C= ode is absent. B13) In RTEv3.1, M-Compilation-Process needs M-Target-Code to have been suc= cessfully defined. But instead M-PhthphthphTC is all that came out of B11/= B12. So now, M-Compilation-Process fails to get defined. Where the absenc= e of M-Compilation-Process occurs downstream, let's put M-PhthphthphCP down= stream so it is clear that M-Compilation-Process is absent. B14) In RTEv3.1, M-Eligible-Compilation-Process needs M-Compilation-Process= to have been successfully defined. But instead M-PhthphthphCP is that cam= e out of B13. Where the absence of M-Eligible-Compilation-Process occurs d= ownstream, let's put M-PhthphthphECP downstream so it is clear that M-Eligi= ble-Compilation-Process is absent. B15) RTEv3.1 grants its special magic of M-Target-Code in RTEv3.1 eclipsing= M-Object-Code in GPLv3 if M-Eligible-Compilation-Process would have been s= uccessfully defined. But instead of M-PhthphthphECP is all that came out o= f B14. So the RTEv3.1's house-of-cards that it tries to carefully build up= collapses and no special magic occurs: M-Object-Code stays M-Object-Code;= M-ObjectCode and M-Source-Code's lifetime lives on for my app, over in GPL= v3 reading onto my app. B16) Now back over in GPLv3, M-Object-Code must provide its M-Source-Code t= o all possessors of M-Object-Code in one or more GPLv3-specified ways. B17) 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 i= nstalled behind not-jail-broken logistical barriers that would require M-In= stallation-Information and M-Corresponding-Source-Code to be provided. B18) I don't have M-Installation-Information and M-Corresponding-Source, bu= t Apple does. B19) Apple would be wise to side-step the B17's demand for providing M-Inst= allation-Information and M-Corresponding-Source-Code by prohibiting apps bu= ilt by GPLv3-with-RLEv3.1-licensed compiler processes. B20) 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 they are being installed all bei= ng open-source as per the GPLv3 and its RLEv3.1 amendment). > > GCC is licensed as GPLv3-with-RLEv3.1 >=20 > No, it's not. (sigh #1) Okay, to speak less colloquially, how about instead: GCC-with-= its-runtime is a GPLv3-with-RLEv3.1-licensed =E2=80=A2compilation process= =E2=80=A2? Focus on =E2=80=9Ccompilation process=E2=80=9D as a whole enchi= lada (as RLEv3.1 does) instead of on =E2=80=98compiler=E2=80=99 versus =E2= =80=98runtime=E2=80=99 compartmentally. (sigh #2) The RLEv3.1 under which the runtime is conveyed is intimately i= ntertwined with the GPLv3 license under which the compiler proper is convey= ed (unless in the, say, 0.1% case of people who refrain from utilizing the = runtime in any way whatsoever). As shown in the detailed walk-through abov= e, there is a natural complex interplay (not unlike a ping-pong game or pen= dulum swinging) between not only GCC's GPLv3 and GCC runtime's RLEv3.1 when= read from GCC's standpoint, but also between GCC's/runtime's reading of th= ose documents and my app's dragged-in reading of those documents for RLEv3.= 1 to enact its magic of eclipsing* the viral M-Object-Code via the successf= ully-defined nonviral M-Target-Code instead.=20 * in the situation of garden-variety execution of M-Target-Code, but not in= App Store's re-compilation of M-Object-Code due to the failure of the atte= mpt to define M-Target-Code due in turn to RLEv3.1's =E2=80=9Cnotwithstandi= ng=E2=80=9D clause dropping its nuclear bomb, scorched-earthing all the att= empts to define RLEv3.1's downstream contractual-terms > GCC is licensed as GPL, its runtimes are licensed with > RLE. I can see it might/would be difficult to explain the consequences > to a small business, but your continued diatribes do nothing to help.=20 I think that my walk-through above is quite lucid at explaining step-by-ste= p what occurs as the crank-handle of the language is mechanically turned, a= s written, as interpreted in the plain-language meanings of the contractual= -terms as defined in GPLv3 and RLEv3.1. But then again perhaps I am factua= lly incorrect somewhere somehow. That small business's mileage might vary = in various jurisdictions of differing systems of law that somehow cause a d= ifferent sequence of contractual interpretation than the one that itemized = above. I am not a lawyer. I cannot do any of this for that small business; that s= mall business needs to go counsel with an attorney who passed the bar in th= at small business's jurisdiction. But as a citizen of the USA and of Texas= , I am fully permitted to interpret all this for myself for my own personal= usage, based on my amateur understanding of all these topics that I have s= elf-studied. > > Note that there does exist at least one way in the language overtly > > stated in GPLv3 and its Runtime Library Exception v3.1 that the Object > > Code can be forced (dare I say, virally) to be GPLv3-licensed when the > > Corresponding Source Code was permissively licensed open-source or > > even EULA-licensed closed source. We do all see that, don't we? >=20 > No. Then read the walk-through above, while looking up each G- and M- contractu= al-term in the GPLv3 and RLEv3.1 to achieve deep reading comprehension step= -by-step. > >> [sjw] I don't think that it would contravene the GPL to modify GCC so > >> that it emitted an intermediate representation, provided that you > >> convey the source form of such modification with a compiler binary. > > > > Hey, you found one of those =E2=80=9CGPL[-based] restrictions on the ge= nerated > > code=E2=80=9D that Shark8 and Simon Clubley are yearning to eliminate i= n some > > hypothetical non-GNAT Ada compiler. Yea! Good job! Attaboy! You > > only needed to find one counter-example to the fallacious theorem > > regarding GCC having absolutely no such =E2=80=9CGPL[-based] restrictio= ns on > > the generated code=E2=80=9D. You found one. Yea! >=20 > WTF? That is what it feels like to have a =E2=80=9CEureka!=E2=80=9D moment. > >> What could well cause trouble, and violation of the GCC Runtime > >> Library Exception, would be to use that modified compiler on source > >> of an RTS that was covered by the GCC Runtime Library Exception. > > > > Hey, you found another one of those =E2=80=9CGPL[-based] restrictions o= n the > > generated code=E2=80=9D that Shark8 and Simon Clubley are yearning to > > eliminate in some hypothetical non-GNAT Ada compiler. Yea! Good job! > > Attaboy! You only needed to find one counter-example to the > > fallacious theorem regarding GCC having absolutely no such > > =E2=80=9CGPL[-based] restrictions on the generated code=E2=80=9D. But = you have found > > two. Yea! >=20 > Again I say, WTF? And another =E2=80=9CEureka!=E2=80=9D moment of the genesis of understandin= g.