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:f9c3:: with SMTP id l186-v6mr3133589ith.15.1527107457978; Wed, 23 May 2018 13:30:57 -0700 (PDT) X-Received: by 2002:a9d:738f:: with SMTP id j15-v6mr25845otk.6.1527107457654; Wed, 23 May 2018 13:30:57 -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!u74-v6no172460itb.0!news-out.google.com!f20-v6ni119itd.0!nntp.google.com!v8-v6no164978itc.0!postnews.google.com!glegroupsg2000goo.googlegroups.com!not-for-mail Newsgroups: comp.lang.ada Date: Wed, 23 May 2018 13:30:57 -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> User-Agent: G2/1.0 MIME-Version: 1.0 Message-ID: <59458046-3144-464e-af80-631b80a65930@googlegroups.com> Subject: Re: DragonEgg has been revived From: "Dan'l Miller" Injection-Date: Wed, 23 May 2018 20:30:57 +0000 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Xref: reader02.eternal-september.org comp.lang.ada:52627 Date: 2018-05-23T13:30:57-07:00 List-Id: On Wednesday, May 23, 2018 at 2:27:30 PM UTC-5, Chris M Moore wrote: > On 23/05/2018 16:51, Dan'l Miller wrote: >=20 > >=20 > > You are so GPLv2; that is the way it was under GPLv2 back in the old da= ys. Newsflash: nearly a decade ago, they relicensed modern releases of FSF= GCC as GPLv3 with Runtime Exception v3.1 which does in fact have licensing= restrictions on Target Code and on Eligible Compilation Process (via Runti= me Exception v3.1) by merely passing, say, MIT/X11-licensed or BSD-licensed= source code through the modern GCC compiler to generate the Target Code fo= r that MIT/X11-licensed or BSD-licensed executable or DLL. Simon, you are = =E2=80=A2factually incorrect=E2=80=A2 nowadays (post-GPLv2) in your claim = =E2=80=9Cthat the GCC compiler itself doesn't assert any licensing restrict= ions over target code generated by it beyond that derived from the original= source code=E2=80=9D, because the =E2=80=A2=E2=80=A2GPLv3 license of the m= odern GCC compiler itself=E2=80=A2=E2=80=A2 spreads (dare I say, virally) t= o the otherwise MIT/X11-licensed or BSD-licensed Target Code >=20 > Nope. The Eligible Compilation Process covers the compilation process=20 > itself, not the end product. This was introduced to stop non-GPLed=20 > plugins to gcc. See https://lwn.net/Articles/301959/ Independent of why historically it was devised, the wording of Runtime Exce= ption v3.1 is quite clearly applying to cases beyond merely that one histor= ical case: =E2=80=9CThe "Compilation Process" transforms code entirely represented in = =E2=80=A2=E2=80=A2non-intermediate=E2=80=A2=E2=80=A2 languages designed for= human-written code, and/or in Java Virtual Machine byte code, into Target = Code.=E2=80=9D Is intermediate representation written out as a file meeting the terms/defi= nition of Target Code in the Runtime Exception? The following quotation an= swers that question: =E2=80=9C"Target Code" refers to output from any compiler for a real or vir= tual target processor architecture, in executable form or suitable for inpu= t to an assembler, loader, linker and/or execution phase. Notwithstanding t= hat, Target Code does not include data in any format that is used as a comp= iler intermediate representation, or used for producing a compiler intermed= iate representation.=E2=80=9D The key word there is =E2=80=9Cnotwithstanding=E2=80=9D. It means that eve= n if supposedly target code meets any of the definitions in the first sente= nce, its ability to actually be Target Code is ruined/spoiled by the second= sentence. I'm pretty sure that =E2=80=9Cdata in =E2=80=A2=E2=80=A2any for= mat=E2=80=A2=E2=80=A2=E2=80=9D and =E2=80=9Ccompiler intermediate represent= ation=E2=80=9D are pretty big clues about LLVM bitcode IR's standing in the= terms of this Runtime Exception v3.1. Chris, you are fixated on one case in history. The language of the Runtime= Exception v3.1 that they authored is much broader than than one historical= motivating case. Just read the Runtime Exception v3.1 yourself and you wi= ll see that the word plug-in never appears at all. Now imagine that all of= LLVM and/or Polly outside of GCC is substantially equivalent to that non-G= PLed plugin to GCC, but simply starts executing after a GCC compiler finish= es executing by reading some sort of IR file written by GCC. Whether it wa= s an actual plug-in into an orifice within GCC matters not one whit. What = matters is whether a file that was not-Source-Code and not-Target-Code was = written by GCC to feed into a downstream executable. Let's walk step by step: A) If a supposed Eligible Compilation Process is not a Compilation Process,= then it certainly is not an Eligible Compilation Process (due to failing t= o comply with the the terms governing what a Compilation Process is). B) If a supposed Compilation Process produces some non-Target-Code derivati= ve work representing Source Code, then it certainly is not a Compilation Pr= ocess (due to failing to comply with the terms governing what a Compilation= Process is: needing to produce not-IR Target Code from not-IR Source Code= ). C) If a supposed Target Code triggers any of the =E2=80=9Cnotwithstanding= =E2=80=9D, then it certainly is not Target Code (due to failing to comply w= ith the =E2=80=9Cnotwithstanding=E2=80=9D IR terms). D) The =E2=80=9Cnotwithstanding=E2=80=9D IR terms on Target Code spoil ever= ything downstream from meeting their definitions in the Runtime Exception v= 3.1. E) Without meeting the Runtime Exception v3.1's definitions downstream from= the =E2=80=9Cnotwithstanding=E2=80=9D, the only remaining right a conveyor= has to convey Object Code via GPLv3 is to satisfy the provide-source-code = terms of GPLv3, E.a) because the =E2=80=9Cnotwithstanding=E2=80=9D IR terms spoiled meeting= Target Code's definition, E.b) because the spoiled not-Target-Code and =E2=80=9Cnon-intermediate=E2= =80=9D both in turn spoiled meeting Compilation Process's definition, E.c) because the spoiled not-Compilation-Process in turn spoiled Eligible C= ompilation Process's definition, E.d) because the spoiled not-Eligible-Compilation-Process in turn spoiled t= he Runtime Exception v3.1, and E.e) because the spoiled Runtime Exception v3.1 spoiled itself so completel= y as a valid amendment to the GPLv3 (i.e., the Runtime Exception converted = itself into a big NO-OP), leaving only Object Code in GPLv3 as specifying t= he terms to convey the IR or the resulting machine-code. So in fewer words, I nope your nope.