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:fe05:: with SMTP id w5-v6mr5427051ith.14.1527195626102; Thu, 24 May 2018 14:00:26 -0700 (PDT) X-Received: by 2002:a9d:604f:: with SMTP id v15-v6mr217921otj.11.1527195625883; Thu, 24 May 2018 14:00:25 -0700 (PDT) Path: eternal-september.org!reader01.eternal-september.org!reader02.eternal-september.org!feeder.eternal-september.org!news.gegeweb.eu!gegeweb.org!news.redatomik.org!newsfeed.xs4all.nl!newsfeed8.news.xs4all.nl!85.12.16.69.MISMATCH!peer02.ams1!peer.ams1.xlned.com!news.xlned.com!peer02.am4!peer.am4.highwinds-media.com!peer01.iad!feed-me.highwinds-media.com!news.highwinds-media.com!v8-v6no1384289itc.0!news-out.google.com!f20-v6ni1205itd.0!nntp.google.com!v8-v6no1384288itc.0!postnews.google.com!glegroupsg2000goo.googlegroups.com!not-for-mail Newsgroups: comp.lang.ada Date: Thu, 24 May 2018 14:00:25 -0700 (PDT) In-Reply-To: <0497e348-72b7-419c-b099-5095615dc572@googlegroups.com> 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> <0497e348-72b7-419c-b099-5095615dc572@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 21:00:26 +0000 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Received-Bytes: 19929 X-Received-Body-CRC: 1728508680 Xref: reader02.eternal-september.org comp.lang.ada:52652 Date: 2018-05-24T14:00:25-07:00 List-Id: On Thursday, May 24, 2018 at 3:56:55 PM UTC-5, Dan'l Miller wrote: > fixing distracting typos & buggy greying out of quoted replies:=20 > On Thursday, May 24, 2018 at 12:19:06 PM UTC-5, Simon Wright wrote:=20 > > "Dan'l Miller" writes:=20 > > > And the logical and reading-comprehension (and lack thereof)=20 > > > contortions contained in later replies along the branches of this=20 > > > thread seem to clearly and undeniably demonstrate what Shark8 aptly= =20 > > > called =E2=80=9Call the morass of licensing=E2=80=9D. Just read all = the later replies=20 > > > along the branches of this thread to see that different readers of &= =20 > > > commentators on the exact same license text in GPLv3 and/or its=20 > > > Runtime Library Exception v3.1 reach drastically different conclusion= s=20 > > > [mainly by cherry-picking different quotations from the license text= =20 > > > and then ignoring/eliding other passages of the license text].=20 > >=20 > > Now we're getting insulting.=20 >=20 > I keep saying that this is entirely nothing more than a reading-comprehen= sion problem and logical-deduction problem overtly cleverly crafted into (a= nd throughout) the language of the GPLv3 and RLEv3. I will request readin= g-comprehension & logical deduction again below (my own included*)=20 >=20 > * Please help me out: quote chapter & verse from statutory law or from tr= eaties or from GPLv3 or from RLEv3.1 such that the step-by-step detailed wa= lk-through below gets dismantled. I will read those seminal references.=20 >=20 > > > I later thought of a third category in answer to my own question that= =20 > > > depends on how much surgery can be deeply & intimately performed on= =20 > > > Target Code before evoking the =E2=80=9Cnotwithstanding=E2=80=9D clau= se in the=20 > > > RLEv3.1. At what point of wholesale re-writing of a percentage of th= e=20 > > > Target Code become an act of re-compiling, taking the Target Code=20 > > > written by GCC as mere IR to the re-compiler?=20 > >=20 > > This is relevant to target code derived from source subject to the=20 > > RLE.=20 >=20 > Specifically where in the set {GPLv3, RLEv3.1, copyright law's body of st= atutes in USCode, copyright treaties to which the USA is a signatory} does = it overtly clearly say anything even remotely in the ballpark of that sente= nce above? I want to read it with my own eyes. I want reading comprehensi= on. (And hearsay commentary on some forum from 2009 where people speculate= and parrot what other people say doesn't count; I want original sources an= d seminal references, such as quotations from members of that set above.)= =20 >=20 > > It has nothing to do with target code derived from source under=20 > > some other license, eg BSD 3-clause.=20 >=20 > Same request again for this sentence above.=20 >=20 > Btw, these 2 sentences are where I strongly believe that you are again fa= ctually incorrect.=20 >=20 > Let's walk step by step, but for brevity of writing here, let all readers= pause at each capitalized contractual-term below to go read their definiti= on and cascading-ramification usage in GPLv3 or RLEv3.1, so that reading co= mprehension is emphasized. Note that there exist 2 readings of the GPLv3 a= nd its RLEv3.1:=20 > a) once for GCC [henceforce G- prefix on the contractual-terms] and=20 > b) once for my app [henceforce M- prefix on contractual-terms]=20 > so that we can clearly see the G-to-M viral communicability of the licens= ing virus. Just to be clear M-Contractual-Term is shorthand for Contractua= l Term as defined in either GPLv3 or RLEv3.1 when those 2 documents are rea= d with my app in mind (as reading comprehension) when linking with FSF GCC'= s runtime. M-Contractual-Term is for when either the GPLv3 or RLEv3.1 or b= oth are read onto my app. Just to be clear G-Contractual-Term is shorthand= for Contractual Term as defined in either GPLv3 or RLEv3.1 when those 2 do= cuments are read with FSF GCC itself in mind (as reading comprehension). G= -Contractual-Term is for when either the GPLv3 or RLEv3 or both are read on= to GCC or its runtime.=20 >=20 > 1) The G-Source-Code term in GPLv3 initially-as-bootstrap refers to the s= ource code of FSF GCC as itself licensed under GPLv3. The G-Object-Code t= erm in GPLv3 initially-as-bootstrap refers to the object code of FSF GCC as= itself licensed under GPLv3. The source code of GCC's runtime is also G-S= ource-Code. The object code of GCC's runtime is also G-Object-Code back wh= en GCC was built.=20 >=20 > 2) But then when my app's source code causes (even indirectly) the invoca= tion of even a single subroutine in GCC's runtime (which is licensed via th= e RTEv3.1), then my app is linked with GCC's runtime library G-Object-Code)= .=20 >=20 > 3) #2's linkage causes my app's object code to be (dare I say, virally) t= ransformed for the time being into M-Object-Code as the contractual-term de= fined in GPLv3.=20 >=20 > 4) #3 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 G= PLv3.=20 >=20 > 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:=20 >=20 > 5.1) to comply with the various demands to provide my app's source code (= which just became M-Source-Code as my app reads onto GPLv3-with-RLEv3.1) or= =20 >=20 > 5.2) to comply with the various requisite expectations of good behavior i= n RLEv3.1 so that my app's M-Object-Code gets recategorized as M-Target-Cod= e so that my app gets out of the GPLv3's demands on M-Object-Code.=20 >=20 > 6) RLEv3.1 is predicated on my app being compiled by an M-Elligible-Compi= lation-Process.=20 >=20 > 7) RLEv3.1's M-Elligible-Compilation-Process is predicated on M-Eligible-= Compilation-Process being an M-Compilation-Process in the first place.=20 >=20 > 8) RLEv3.1's M-Compilation-Process is predicated on satisfying the variou= s contractual restrictions on M-Target-Code.=20 >=20 > 2 hypothetical cases A versus B:=20 >=20 > A9) RLEv3.1's M-Target-Code is satisfied if my app is, say, compiled to h= ardware-processor machine-code (or hardware-processor assembly language the= reof) and then merely link-loaded and then merely executed.=20 >=20 > A10) The logical-deduction chain of=20 > =E2=80=9Cif M-Target-Code satisfied=E2=80=9D=20 > begets=20 > =E2=80=9Cif M-Compilation-Process satisfied=E2=80=9D=20 > begets=20 > =E2=80=9Cif M-Eligible-Compilation-Process satisfied=E2=80=9D=20 > begets=20 > =E2=80=9Cif RLEv3.1 satisfied=E2=80=9D=20 > then has successfully recategorized (viral) M-Object-Code into mere (nonv= iral) M-Target-Code, dispensing with any need to provide source code or pro= vide Installation Information or provide Corresponding Source Code over in = GPLv3. My app's reading of GPLv3 and RLEv3.1 stops at this terminus. The = lifetime of the effective temporary instantiation of M-Object-Code and M-So= urce-Code as contractual terms that might need to be complied with has effe= ctively ended, as M-Target-Code eclipses M-Object-Code as per the special p= ermissions granted by the RTEv3.1. Whew! My app dodged that bullet.=20 >=20 > versus=20 >=20 > https://thenextweb.com/apple/2015/06/17/apples-biggest-developer-news-at-= wwdc-that-nobodys-talking-about-bitcode=20 >=20 > B9) 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), and perhaps for different eras of ARM p= rocessors soldered into iDevices.=20 >=20 > B10) Nonjailbroken iDevices are what is called a walled garden, where the= only apps (other than development mode, enterprise side-loading, and invit= ation-only testing) that are permitted to be downloadable to the iDevice ar= e those that have been approved by Apple for conveyance in the App Store.= =20 >=20 > B11) At some point Apple could require the availability of LLVM bitcode I= R for each app to be approved for the App Store. This could either by over= tly requiring LLVM bitcode IR files at time of submission or via a McSema-e= sque technology. The following steps don't really care which option Apple = takes, but let's write the wording up for the former.=20 >=20 > B12) Regardless of how the LLVM bitcode IR is actually generated for my a= pp (e.g., my GELI proposal; DragonEgg on a modern GCC release that is licen= sed via GPLv3-with-RLEv3.1), the =E2=80=9Cnotwithstanding=E2=80=9D clause i= n the 2nd sentence of RLEv3.1's attempt to define M-Target-Code is triggere= d, overriding any potential definitions of M-Target-Code in the 1st sentenc= e of RLEv3.1's attempt to define M-Target-Code. That is how =E2=80=9Cnotwi= thstanding=E2=80=9D works in legalese: literally if the 2nd sentence is sa= tisfied, the 2nd sentence drops a nuclear bomb on the 1st sentence, no matt= er what impervious bomb shelter the 1st sentence thought that it was hiding= within, literally leaving the attempted definition of M-Target-Code =E2=80= =A2with=E2=80=A2 all attempted definitions =E2=80=A2not=E2=80=A2 =E2=80=A2s= tanding=E2=80=A2**, blown to smithereens by the dropping of the =E2=80=9Cno= twithstanding=E2=80=9D nuclear-bomb regarding IR.=20 >=20 > ** hence the word: notwithstanding=20 >=20 > B13) Oopsies, in B12, M-Target-Code failed to get defined, due to the IR = nuclear bomb that got dropped. Where the absence of M-Target-Code occurs d= ownstream, let's put M-PhthphthphTC downstream so it is clear that M-Target= -Code is absent.=20 >=20 > B14) In RLEv3.1, M-Compilation-Process needs M-Target-Code to have been s= uccessfully defined. But instead M-PhthphthphTC is all that came out of B1= 2/B13. So now, M-Compilation-Process fails to get defined. Where the abse= nce of M-Compilation-Process occurs downstream, let's put M-PhthphthphCP do= wnstream so it is clear that M-Compilation-Process is absent.=20 >=20 > B15) In RLEv3.1, M-Eligible-Compilation-Process needs M-Compilation-Proce= ss to have been successfully defined. But instead M-PhthphthphCP is all th= at came out of B14. Where the absence of M-Eligible-Compilation-Process oc= curs downstream, let's put M-PhthphthphECP downstream so it is clear that M= -Eligible-Compilation-Process is absent.=20 >=20 > B16) RLEv3.1 grants its special magic of M-Target-Code in RLEv3.1 eclipsi= ng M-Object-Code in GPLv3 if and only if M-Eligible-Compilation-Process wou= ld have been successfully defined. But instead M-PhthphthphECP is all that= came out of B15. So the RTEv3.1's house-of-cards that RLEv3.1 tries to ca= refully build up collapses and no special magic occurs: M-Object-Code stay= s M-Object-Code; M-ObjectCode's and M-Source-Code's lifetimes live on for m= y app, over in GPLv3 when reading GPLv3 onto my app.=20 >=20 > B17) Now back over in GPLv3, M-Object-Code must provide its M-Source-Code= to all possessors of M-Object-Code in one or more GPLv3-specified ways.=20 >=20 > B18) 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.=20 >=20 > B19) I don't possess M-Installation-Information and M-Corresponding-Sourc= e, but Apple does.=20 >=20 > B20) Apple would be wise to side-step the B18's demand for providing M-In= stallation-Information and M-Corresponding-Source-Code by prohibiting apps = built by GPLv3-with-RLEv3.1-licensed compiler processes.=20 >=20 > B21) 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-co= mpiled 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).=20 >=20 > The outcome of B9 through B21 are one of the counterexamples to the falla= cious theorem that GCC imposes no GPL-based restrictions on an app's object= code or target code or Object Code or Target Code that were written by GCC= as part of compiling that app. We sought to disprove the fallacious theor= em. It is disproven by finding at least one counterexample. Q.E.D.=20 >=20 > > > GCC is licensed as GPLv3-with-RLEv3.1=20 > >=20 > > No, it's not.=20 >=20 > (sigh #1) Okay, to speak less colloquially, how about instead: GCC-wit= h-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.=20 >=20 > (sigh #2) The RLEv3.1 under which the runtime is conveyed is intimately= intertwined with the GPLv3 license under which the compiler proper is conv= eyed (except in the, say, 0.1% case of people who refrain from utilizing th= e runtime in any way whatsoever). As shown in the detailed walk-through ab= ove, there is a natural complex interplay (not unlike a ping-pong game or p= endulum swinging) between not only GCC's GPLv3 and GCC runtime's RLEv3.1 wh= en read onto GCC from GCC's standpoint, but also between those license docu= ments reading onto GCC's/runtime and the dragged-in reading of those docume= nts onto my app for RLEv3.1 to enact its magic of the eclipse*** of the vir= al M-Object-Code by the successfully-defined nonviral M-Target-Code instead= .=20 >=20 > *** eclipsing in the situation of garden-variety execution of M-Target-Co= de, but not eclipsing in the situation of App Store's re-compilation of M-O= bject-Code due to the failure of the attempt to define M-Target-Code due in= turn to RLEv3.1's =E2=80=9Cnotwithstanding=E2=80=9D clause dropping its nu= clear bomb, scorched-earthing all the attempts to define RLEv3.1's downstre= am contractual-terms=20 >=20 > > GCC is licensed as GPL, its runtimes are licensed with=20 > > RLE. I can see it might/would be difficult to explain the consequences= =20 > > to a small business, but your continued diatribes do nothing to help.= =20 >=20 > I think that my walk-through above is quite lucid at explaining step-by-s= tep what occurs as the crank-handle of the language is mechanically turned,= as written, as interpreted in the plain-language meanings of the contractu= al-terms as defined in GPLv3 and RLEv3.1. But then again perhaps I am fact= ually incorrect somewhere somehow. That small business's mileage might var= y in various jurisdictions of differing systems of law that somehow cause a= different sequence of contractual interpretation than the one that itemize= d above.=20 >=20 > I am not a lawyer. I cannot do any of this for that small business; that= small business needs to go counsel with an attorney who passed the bar in = that small business's jurisdiction. But as a citizen of the USA and of Tex= as, I am fully permitted to interpret all this for myself for my own person= al usage, based on my amateur understanding of all these topics that I have= self-studied.=20 >=20 > > > Note that there does exist at least one way in the language overtly= =20 > > > stated in GPLv3 and its Runtime Library Exception v3.1 that the Objec= t=20 > > > Code can be forced (dare I say, virally) to be GPLv3-licensed when th= e=20 > > > Corresponding Source Code was permissively licensed open-source or=20 > > > even EULA-licensed closed source. We do all see that, don't we?=20 > >=20 > > No.=20 >=20 > Then read the walk-through above, while looking up each G- and M- contrac= tual-term in the GPLv3 and RLEv3.1 to achieve deep reading comprehension st= ep-by-step.=20 >=20 > > >> [sjw] I don't think that it would contravene the GPL to modify GCC s= o=20 > > >> that it emitted an intermediate representation, provided that you=20 > > >> convey the source form of such modification with a compiler binary.= =20 > > >=20 > > > Hey, you found one of those =E2=80=9CGPL[-based] restrictions on the = generated=20 > > > code=E2=80=9D that Shark8 and Simon Clubley are yearning to eliminate= in some=20 > > > hypothetical non-GNAT Ada compiler. Yea! Good job! Attaboy! You= =20 > > > only needed to find one counter-example to the fallacious theorem=20 > > > regarding GCC having absolutely no such =E2=80=9CGPL[-based] restrict= ions on=20 > > > the generated code=E2=80=9D. You found one. Yea!=20 > >=20 > > WTF?=20 >=20 > That is what it feels like to have a =E2=80=9CEureka!=E2=80=9D moment.=20 >=20 > > >> What could well cause trouble, and violation of the GCC Runtime=20 > > >> Library Exception, would be to use that modified compiler on source= =20 > > >> of an RTS that was covered by the GCC Runtime Library Exception.=20 > > >=20 > > > Hey, you found another one of those =E2=80=9CGPL[-based] restrictions= on the=20 > > > generated code=E2=80=9D that Shark8 and Simon Clubley are yearning to= =20 > > > eliminate in some hypothetical non-GNAT Ada compiler. Yea! Good job= !=20 > > > Attaboy! You only needed to find one counter-example to the=20 > > > fallacious theorem regarding GCC having absolutely no such=20 > > > =E2=80=9CGPL[-based] restrictions on the generated code=E2=80=9D. Bu= t you have found=20 > > > two. Yea!=20 > >=20 > > Again I say, WTF?=20 >=20 > And another =E2=80=9CEureka!=E2=80=9D moment of the genesis of understand= ing. Great. Now I greyed my whole reply out as a quote. Unhide the walkthrough= , please, if viewing via the Google Groups WWW page.