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:1458:: with SMTP id 85-v6mr29246itg.55.1527206959686; Thu, 24 May 2018 17:09:19 -0700 (PDT) X-Received: by 2002:a9d:5887:: with SMTP id x7-v6mr250804otg.14.1527206959553; Thu, 24 May 2018 17:09:19 -0700 (PDT) Path: eternal-september.org!reader01.eternal-september.org!reader02.eternal-september.org!feeder.eternal-september.org!news.uzoreto.com!weretis.net!feeder6.news.weretis.net!feeder.usenetexpress.com!feeder-in1.iad1.usenetexpress.com!border1.nntp.dca1.giganews.com!nntp.giganews.com!v8-v6no1536830itc.0!news-out.google.com!f20-v6ni1345itd.0!nntp.google.com!v8-v6no1536828itc.0!postnews.google.com!glegroupsg2000goo.googlegroups.com!not-for-mail Newsgroups: comp.lang.ada Date: Thu, 24 May 2018 17:09:19 -0700 (PDT) In-Reply-To: <1758ba60-2171-4967-bc75-6176f9f18ec1@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> <1758ba60-2171-4967-bc75-6176f9f18ec1@googlegroups.com> User-Agent: G2/1.0 MIME-Version: 1.0 Message-ID: <01ca3de2-42df-4e05-94b3-fdee2ff88b42@googlegroups.com> Subject: Re: DragonEgg has been revived From: "Dan'l Miller" Injection-Date: Fri, 25 May 2018 00:09:19 +0000 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Xref: reader02.eternal-september.org comp.lang.ada:52657 Date: 2018-05-24T17:09:19-07:00 List-Id: On Thursday, May 24, 2018 at 1:07:02 PM UTC-5, Lucretia wrote: > On Thursday, 24 May 2018 17:44:22 UTC+1, Dan'l Miller wrote: >=20 > > Oh great. Now I have convinced myself that there is enough sketchiness= /dodginess in this vicinity to question whether Apple's forthcoming App-Sto= re LLVM-bitcode-IR recompiler wouldn't satisfy any one or more required ter= ms of any GPLv3-with-RLEv3.1-licensed compiler (FSF or otherwise) in such a= s way as to cause both: > > 1) the app to need to provide its Source Code; > > and > > 2) Apple to need to provide the Installation Information and Correspond= ing Source Code on a =E2=80=9Cconsumer=E2=80=9D device that is not-=E2=80= =9Csufficiently=E2=80=9D =E2=80=9Cindustrial=E2=80=9D, where that consumer = device (e.g., an Apple iDevice) might be a User Product in the terms of GPL= v3. > > and thus > > 3) merely compiling the app with GPLv3-with-RLEv3.1-licensed compiler (= and the app invoking at least one subroutine in the RLEv3.1-licensed runtim= e) could conceivably be enough for Apple to reject such apps from the App S= tore, so that Apple need not satisfy #2 above. > >=20 > > https://thenextweb.com/apple/2015/06/17/apples-biggest-developer-news-a= t-wwdc-that-nobodys-talking-about-bitcode > >=20 > > Apparently Apple is either working on a McSema-esque technology or woul= d require the app to be > > (also?) provided in the form of LLVM-bitcode-IR (in addition? to ARM-pr= ocessor machine-code) at the > > time of submission to the App Store for approval. >=20 > They're not doing anything of the sort. They used to use fat binaries con= taining both m68k and powerpc, > then both 32/64 bit x86. For this they'll use LLVM bitcode, which is IR c= ompiled to LLVM's bitcode, > something that's been in LLVM since it started. One of the major pros abo= ut that bitcode is that you can > then do aggressive linking and stripping before installation. Fat binaries was an option within the 2nd conceivable option that I listed = there. If truly fat (i.e., where in the future Apple would permit or require MacOS= Intel Target Code along with iOS ARM Target Code along with optionally LLV= M bitcode IR) when/if Apple ever unifies iOS & MacOS apps, then it seems FS= F GNAT on MacOS could still be utilized for building apps for submission to= the Mac App Store. But if Apple in the future were to unify MacOS & iOS apps via requiring LLV= M bitcode IR as the sole format when submitting an app for App-Store approv= al, then is seems that compiling an app with FSF GNAT on MacOS would preclu= de closed-source apps from being submitted to the Mac App Store. My point of listing conceivable potential futures was that no one can defin= itively predict what Apple will do. We can merely list all the conceivable= or likely foreseeable possibilities and then we might have a, say, 75% cha= nce of Apple's future decision actually being on that list. Uncertainty and =E2=80=9Call the morass of licensing surrounding=E2=80=9D G= CC galore. > We talked about a similar mechanism for a platform neutral binary for Ami= gaOS NG BITD, but that never > happened, well it did sort of with Tao, but it never got anywhere and Tao= went out of business. Likewise: Had it been GPLv3 during the 1990s instead of GPLv2, it seems from my analy= sis of GPLv3 and RLEv3.1 that OSF/1's ANDF (architecture-neutral distributi= on format) would have also trigged the =E2=80=9Cnotwithstanding=E2=80=9D cl= ause of Target Code in RLEv3.1 back in the first half of the 1990s during t= he era of the so-called =E2=80=98UNIX wars=E2=80=99 (which in turn triggers= the provide-the-Source-Code demands in the Object Code clauses of GPLv3).