From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on ip-172-31-74-118.ec2.internal X-Spam-Level: X-Spam-Status: No, score=-1.9 required=3.0 tests=BAYES_00,FREEMAIL_FROM autolearn=ham autolearn_force=no version=3.4.4 X-Received: by 2002:a05:620a:410a:: with SMTP id j10mr19931442qko.410.1593520126231; Tue, 30 Jun 2020 05:28:46 -0700 (PDT) X-Received: by 2002:aca:3b54:: with SMTP id i81mr15150660oia.84.1593520126041; Tue, 30 Jun 2020 05:28:46 -0700 (PDT) Path: eternal-september.org!reader01.eternal-september.org!feeder.eternal-september.org!news.gegeweb.eu!gegeweb.org!usenet-fr.net!proxad.net!feeder1-2.proxad.net!209.85.160.216.MISMATCH!news-out.google.com!nntp.google.com!postnews.google.com!google-groups.googlegroups.com!not-for-mail Newsgroups: comp.lang.ada Date: Tue, 30 Jun 2020 05:28:45 -0700 (PDT) In-Reply-To: Complaints-To: groups-abuse@google.com Injection-Info: google-groups.googlegroups.com; posting-host=47.185.233.35; posting-account=zwxLlwoAAAChLBU7oraRzNDnqQYkYbpo NNTP-Posting-Host: 47.185.233.35 References: <4d9fa282-830d-42f7-a3bf-ba127cb2ad06o@googlegroups.com> <8332f305-299f-45d7-9f9d-2cad924b24d8o@googlegroups.com> <9d941aca-2eb6-4f35-a346-c290c4666bdfo@googlegroups.com> <76def2a5-667c-4009-b3b9-f0cf1c13a51bo@googlegroups.com> <3b5b2360-684c-4149-8662-98b53319cf94o@googlegroups.com> User-Agent: G2/1.0 MIME-Version: 1.0 Message-ID: <4dabaf9e-8bd5-4c5f-a665-7e2ec48342aao@googlegroups.com> Subject: Re: Ada on Apple's new procesors From: Optikos Injection-Date: Tue, 30 Jun 2020 12:28:46 +0000 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Xref: reader01.eternal-september.org comp.lang.ada:59260 List-Id: On Tuesday, June 30, 2020 at 6:16:40 AM UTC-5, Fabien Chouteau wrote: > On Thursday, June 25, 2020 at 6:15:47 PM UTC+2, Optikos wrote: > > this later closed-source processing of the app by Apple for nonjailbrok= en ARM-based Macs and iDevices to distribute via the App Store seems to vio= late terms of at least the RLE if not GPLv3 too. >=20 > The Apple app store is incompatible with the GPL since long ago: https://= www.fsf.org/blogs/licensing/more > about-the-app-store-gpl-enforcement Yes, when the developer's app is GPLed, the App Store's terms and the GPL's= terms are mutually incompatible. Historically, GPLing an app would have b= een by developer choice (unless somehow violating the RLE which was rare in= practice because using garden-variety unmodified IR-unadorned GNAT, GCC, a= nd so forth resulted in an Eligible Compilation Process in RLE). > I don't see anything new here. What is new here is that there appear to be well-reasoned ways (e.g., the W= ide legal theory along this thread) that GNAT-LLVM could =E2=80=A2force=E2= =80=A2 a developer's app to GPLed against the developer's will by easy-to-e= nact-in-GNAT-LLVM violations of the RLE's terms that cause the Compilation = Process to not achieve the stricter Eligible Compilation Process definition= , due to Apple's closed-source manipulations of LLVM IR bitcode. Perhaps the work-around is that GNAT-LLVM-based developers of apps should = =E2=80=A2never=E2=80=A2 submit LLVM IR bitcode to Apple's App Store's app-i= ntake procedure. In the past as far back as 2015, submitting bitcode inste= ad of machine code was optional. It is unclear with the new ARM-based Macs= , whether that optionality will continue in the future, or whether that opt= ionality has already been curtailed. (Conversely, under the Narrow legal theory along this thread, your claim is= correct, nothing has changed: if an app-developer doesn't want to suffer = the mutual incompatibility of the GPL and Apple App Store, then don't choos= e GPL as the license for the app, because despite its name LLVM IR bitcode = is merely assembly language which is unregulated by RLE.)