DragonEgg has been revived

DragonEgg has been revived

[Simon Clubley]

[I apologise if this has already been covered in the walls of text
which have been flying around recently, but I have not seen this
mentioned yet.]

I've just discovered that DragonEgg has been revived for GCC 8.x
and LLVM 6.x, although there is nothing in the announcement about Ada:

http://lists.llvm.org/pipermail/llvm-dev/2017-August/116705.html

Simon.

-- 
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Microsoft: Bringing you 1980s technology to a 21st century world

DragonEgg has been revived

[Dan'l Miller]

Simon, you can finish where Xiang Leslie ZHAI left off:

https://reviews.llvm.org/D35667

Re: DragonEgg has been revived

[Luke A. Guest]

Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> wrote:
> [I apologise if this has already been covered in the walls of text
> which have been flying around recently, 

;)


> I've just discovered that DragonEgg has been revived for GCC 8.x
> and LLVM 6.x, although there is nothing in the announcement about Ada:

Yeah it’s been mentioned here before. It’s in the archives. I built it but
didn’t do much else, tbh there’s not much source there and from what I know
it can’t do much.

Re: DragonEgg has been revived

[Dan'l Miller]

On Monday, May 21, 2018 at 4:37:13 PM UTC-5, Simon Clubley wrote:
> [I apologise if this has already been covered in the walls of text
> which have been flying around recently, but I have not seen this
> mentioned yet.]
> 
> I've just discovered that DragonEgg has been revived for GCC 8.x
> and LLVM 6.x, although there is nothing in the announcement about Ada:
> 
> http://lists.llvm.org/pipermail/llvm-dev/2017-August/116705.html
> 
> Simon.
> 
> -- 
> Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
> Microsoft: Bringing you 1980s technology to a 21st century world

Simon, how fervently do you seek an LLVM-backended GNAT?  Over on other threads in recent days, I have been commenting on a proposed alternative to DragonEgg.

Re: DragonEgg has been revived

[Simon Clubley]

On 2018-05-21, Luke A  Guest <laguest@archeia.com> wrote:
>
> Yeah it?s been mentioned here before. It?s in the archives. I built it but
> didn?t do much else, tbh there?s not much source there and from what I know
> it can?t do much.
>

Thanks Luke; I missed that discussion.

It looks like there's nothing to get excited about then.

Thanks,

Simon.

-- 
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Microsoft: Bringing you 1980s technology to a 21st century world

Re: DragonEgg has been revived

[Simon Clubley]

On 2018-05-21, Dan'l Miller <optikos@verizon.net> wrote:
>
> Simon, how fervently do you seek an LLVM-backended GNAT?  Over on other
> threads in recent days, I have been commenting on a proposed alternative to
> DragonEgg.

What I would like to see is an Ada compiler that can generate code
for a wide range of targets without any GPL restrictions on the
generated code.

I'm not really bothered how that happens but LLVM seems like an
interesting option.

The real question however is will this Ada compiler still work with
the versions of the toolchains available 2-5 years from now or will
it fall into disuse just like DragonEgg did ?

There's a confidence problem here. I can write C and C++ code in 2018
for some random embedded target knowing there's a very very good chance
I will still be able to compile that code on the freely available
toolchains which will exist 5 years from now.

I don't currently have that confidence with the Ada compilers which are
available in 2018.

As I have said before, the language is _really_ good, but the compiler
situation is lousy.

Simon.

-- 
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Microsoft: Bringing you 1980s technology to a 21st century world

Re: DragonEgg has been revived

[Luke A. Guest]

Simon Clubley <

> What I would like to see is an Ada compiler that can generate code
> for a wide range of targets without any GPL restrictions on the
> generated code.

Wouldn’t we all.

> 
> I'm not really bothered how that happens but LLVM seems like an
> interesting option.
> 
> The real question however is will this Ada compiler still work with
> the versions of the toolchains available 2-5 years from now or will
> it fall into disuse just like DragonEgg did ?

It would depend on how well it’s maintained and how many people step up to
help out.

> There's a confidence problem here. I can write C and C++ code in 2018
> for some random embedded target knowing there's a very very good chance
> I will still be able to compile that code on the freely available
> toolchains which will exist 5 years from now.

Well even with those languages it might not compile.

> I don't currently have that confidence with the Ada compilers which are
> available in 2018.
> 
> As I have said before, the language is _really_ good, but the compiler
> situation is lousy.

We need a new one not controlled by a company/monopoly.

Re: DragonEgg has been revived

[Dan'l Miller]

On Tuesday, May 22, 2018 at 7:41:52 AM UTC-5, Luke A. Guest wrote:
> Simon Clubley wrote:
> > I'm not really bothered how that happens but LLVM seems like an
> > interesting option.
> > 
> > The real question however is will this Ada compiler still work with
> > the versions of the toolchains available 2-5 years from now or will
> > it fall into disuse just like DragonEgg did ?
> 
> It would depend on how well it’s maintained and how many people step up to
> help out.

How well maintained it is depends almost entirely on how clean the design is to be easily maintainable in the first place.  DragonEgg failed miserably at that goal (if DragonEgg even had that as a goal at all).  As I have said on other c.l.a threads in the past few days, DragonEgg's ‘guiding principle’ that the original author effectively seemed to have on his mind was evidently ‘metastasizing cancer’ as opposed to ‘quarantining’.

Instead of what DragonEgg pursued, this is what GELI (pronounced ‘jelly’), the wise person's rebuttal to DragonEgg should pursue to usher in a new era for Ada:

A) GELI must be focused on GNAT-only.
▶︎ Abandon DragonEgg's goal of LLVM back-end for non-Ada languages in GCC.
▶︎ All the GCC languages other than Ada already have an LLVM-backended compiler.  Let them go forth & prosper on their own.

B) GELI must have an extraordinarily-clean dotted line for the Liskov-substitution-principle (LSP) laser to cut an ultra-precise low-drama boundary between FSF GCC and the GELI project.
▶︎ Abandon DragonEgg's touch-too-much.
▶︎ GELI would pursue no-drama coexistence, a single low-drama rarely-modified interface-with-GNAT, and quarantining as a victorious strategy for easy maintenance long-term, perhaps indefinitely, as GELI is unlikely to be embraced lovingly by either the GCC or the LLVM communities.

B.a) The Ada iterator/cursor in GNAT that walks GNAT's full-semantically-adorned Ada IR tree to feed snippets to GIGI appears to be the least-churn lowest-drama interface in the vicinity of any member of  the set {GIGI, GENERIC, C IR tree, high GIMPLE, low GIMPLE, RTL, the rest of GNAT's GCC back-end}.
▶︎ The history of GNAT almost screams “Cut here along the dotted line” regarding that iterator/cursor.

B.b) Hence, the name GELI as initialism for:  GIGI-alternative Emits LLVM IR.
▶︎ i.e., emits LLVM IR in DRAM to a copy of the entirety of LLVM's source code imported wholesale into GCC repository as a single GNAT executable to comply with the Target Code clause of GPLv3 and the Eligible Compilation Process clause of the Runtime Exception.
▶︎ Emitting any IR–either GCC or LLVM–to a file [or mmap()ed memory] from GCC would fail to comply with the Target Code and Eligible Compilation Process causes, which in turn would make any downstream machine code generated be staunchly GPLv3, i.e., no Runtime Exception, no GMGPL.
▶︎ Moral of the story:  absolutely never emit any IR to a file (or mmap()ed shared memory.

C) Unlike DragonEgg, GELI and LLVM would absolutely not be strewn throughout GCC source code.
▶︎ No touching of GCC or LLVM source code* means no maintenance whatsoever of LLVM or the vast bulk of GNAT/GCC, other than copying them in verbatim.
▶︎ Import all of GCC and all of LLVM verbatim except for merge conflicts at the extraordinarily few places where GELI touches/modifies GCC.
▶︎ GELI would merely invoke LLVM, presenting LLVM with garden-variety LLVM IR, so GELI shall not touch/modify LLVM whatsoever, other than verbatim copying of the entirety of LLVM's source code into the GCC repository and building it.

* other than the set {the Ada iterator/cursor, its factory (method), the “llvm-” prefixed targets on the GNAT command line, scripts invoking additional tests}

D) All the ISA targets that LLVM supports now and in the future would be prefixed with “llvm-” on GNAT's command line.
▶︎ This assures that no one is ever confused due to similarly-named targets in GCC-world versus LLVM-world.
▶︎ GNAT users will know precisely which back-end is generating the machine code:  GELI feeding LLVM versus GIGI feeding GCC-back-end.

E) Additional test-cases, test-drivers, or test-suites might need to be added to stress test and regression test topics that are currently not tested or not tested well in ACATS or any of GCC's existing tests.

F) To be easily maintainable, GELI would have strictly-enforced prohibitions on modifying •anything• in GCC other than:

F.a) the GELI-replacement iterator/cursor in Ada for the Ada current iterator/cursor in GNAT that walks the fully-semantically-adorned Ada IR tree, and a factory or factory method thereof to instantiate the correct GELI-feeding one versus the GIGI-feeding one, depending on whether an LLVM or GCC ISA target was selected on the GNAT command line.

F.b) GELI's source code and the entirety of LLVM's source code and any additional test suites would merely be present co-existing in the GCC repository.
▶︎ Only the Ada iterator/cursor, its factory (method), the “llvm-”-prefixed LLVM targets on GNAT's command line, and scripts that merely invoke additional test suites would be the places at which the GELI project would not be mere coexistence of additional files & directories in FSF GCC repository.

G) If GELI's development stresses GCC or LLVM in ways that reveal a bug in GCC or in LLVM, then try to find a way of replicating the bug outside of GELI in FSF GNAT, FSF GCC at large, Clang, Flang, LLVM, or any other non-GELI project on planet Earth.
▶︎ Try very diligently to never predicate a bug fix (or worse, new-feature request) at GCC or LLVM on GELI.
▶︎ This means GELI should go the extra mile (or ten miles) to use GCC or LLVM verbatim as is, enacting workarounds in already-extant GCC or in already-extant LLVM whenever practical.

Hence, GELI would be easily maintainable, focusing only on what DragonEgg does not focus on at all:
• the river of new Ada features & bug-fixes semantically adorned on the Ada IR by FSF GNAT;
• the addition & removal of LLVM ISA targets begetting changes to the “llvm-”-prefixed targets on GNAT's command-line;
• the rare changes in FSF GNAT to the interface to the Ada iterator/cursor that feeds GIGI;
• wholesale importing the entirety of new releases of LLVM at, say, major.minor releases of GCC.

> > There's a confidence problem here. I can write C and C++ code in 2018
> > for some random embedded target knowing there's a very very good chance
> > I will still be able to compile that code on the freely available
> > toolchains which will exist 5 years from now.

It would seem that GELI would increase your confidence via:

1) providing an alternate 2nd-source for machine-code generation of targets for some embedded processor (when GCC lacks a target, LLVM might support it);

2) providing an easily maintainable quarantining of the churn with as little drama as possible in widely-available open-source repository;

3) complying fully with the Target Code and Eligible Compilation Process causes of the GPLv3 and its Runtime Exception to assure that machine code generated by this GELI-feeds-LLVM back-end would be distributable as you please for execution

3.1) Importation of GCC-emitted-as-Target-Code machine code into McSema for reworking would still be encumbered by GPLv3, as that machine code would be deemed IR by the Target Code & Eligible Compilation Process clauses.

> > As I have said before, the language is _really_ good, but the compiler
> > situation is lousy.
> 
> We need a new one not controlled by a company/monopoly.

Re: DragonEgg has been revived

[Shark8]

On Tuesday, May 22, 2018 at 6:29:10 AM UTC-6, Simon Clubley wrote:
> 
> What I would like to see is an Ada compiler that can generate code
> for a wide range of targets without any GPL restrictions on the
> generated code.

I'm getting ready to restart work on Byron. I figure that perhaps an Implementation Manual/Design Document would help explain the design underneath it and welcome new contributors. 

> 
> I'm not really bothered how that happens but LLVM seems like an
> interesting option.

I have mixed feelings on LLVM -- it would be nice to grab all the targets for it, but I also think it's a stupid idea to build the compiler specifically for it.

> 
> The real question however is will this Ada compiler still work with
> the versions of the toolchains available 2-5 years from now or will
> it fall into disuse just like DragonEgg did ?
> 
> There's a confidence problem here. I can write C and C++ code in 2018
> for some random embedded target knowing there's a very very good chance
> I will still be able to compile that code on the freely available
> toolchains which will exist 5 years from now.
> 
> I don't currently have that confidence with the Ada compilers which are
> available in 2018.

Yeah; that's one of the big problems Byron [Ada 2012 in Ada 2012] is intended to address; the other big one is to escape the stupid morass of licensing issues.

> 
> As I have said before, the language is _really_ good, but the compiler
> situation is lousy.

Very much agreed.
I really wish I had the capital to realize my vision of a complete Integrated Development Environment (in the APSE sense) fully formally verified for both Ada and VHDL -- I think that has a LOT of potential for whole-systems.

Re: DragonEgg has been revived

[Dan'l Miller]

On Tuesday, May 22, 2018 at 2:40:24 PM UTC-5, Shark8 wrote:
> On Tuesday, May 22, 2018 at 6:29:10 AM UTC-6, Simon Clubley wrote:
> > 
> > What I would like to see is an Ada compiler that can generate code
> > for a wide range of targets without any GPL restrictions on the
> > generated code.
> 
> I'm getting ready to restart work on Byron. I figure that perhaps an Implementation Manual/Design Document would help explain the design underneath it and welcome new contributors. 
> 
> > 
> > I'm not really bothered how that happens but LLVM seems like an
> > interesting option.
> 
> I have mixed feelings on LLVM -- it would be nice to grab all the targets for it, but I also think it's a stupid
> idea to build the compiler specifically for it.

Writing a compiler “specifically for” LLVM?  I thought that the whole premise of Byron was to write an Ada compiler for multiple back-ends:
1) libFirm:  https://pp.ipd.kit.edu/firm
2) LLVM
3) GCC
4) Graal for JVM:  http://www.graalvm.org
5) CLR for .NET & Mono
and so forth.

Compared to Byron's laudable long-term clean-room-design goals, my GELI proposal* for an LLVM-backended GNAT is an interim stop-gap, focusing only on likely-not-clean-room generation of LLVM bitcode IR within a single GPLv3 GNAT executable, causing only ISAs' machine-code (not the IR) to be generated by LLVM-embedded-within-GNAT.

* described in a prior reply above

> Yeah; that's one of the big problems Byron [Ada 2012 in Ada 2012] is intended to address; the other big
> one is to escape the stupid morass of licensing issues.

What is so bad about GPLv3 with Runtime Exception …

1) … unless a person really really wants to re-work GCC-emitted machine code as lifted to LLVM bitcode IR via, say, McSema as not-GPLv3ed derivative works, needing disclosure of all source code?**
or

2) … unless a person really really wants to write LLVM bitcode IR out to a file to execute it on Sulong/GraalVM as not-GPLv3ed derivative works, needing disclosure of all source code?**
or

3) Can anyone think of any other precise downsides of GPLv3 •with• Runtime Exception?

I think all the downsides other than those 2 listed above are with GPL •without• Runtime Exception, correct?

** Due to the Target Code clauses of GPLv3 and the Eligible Compilation Process of GPLv3's Runtime Exception, all downstream derivative works are staunchly GPLv3 with the Runtime Exception overtly revoking itself due to the (clearly) IR or the machine-code-as-IR.

Re: DragonEgg has been revived

[Dan'l Miller]

On Tuesday, May 22, 2018 at 3:17:11 PM UTC-5, Dan'l Miller wrote:
> On Tuesday, May 22, 2018 at 2:40:24 PM UTC-5, Shark8 wrote:
> > On Tuesday, May 22, 2018 at 6:29:10 AM UTC-6, Simon Clubley wrote:
> > > 
> > > What I would like to see is an Ada compiler that can generate code
> > > for a wide range of targets without any GPL restrictions on the
> > > generated code.
> > 
> > I'm getting ready to restart work on Byron. I figure that perhaps an Implementation Manual/Design Document would help explain the design underneath it and welcome new contributors. 
> > 
> > > 
> > > I'm not really bothered how that happens but LLVM seems like an
> > > interesting option.
> > 
> > I have mixed feelings on LLVM -- it would be nice to grab all the targets for it, but I also think it's a stupid
> > idea to build the compiler specifically for it.
> 
> Writing a compiler “specifically for” LLVM?  I thought that the whole premise of Byron was to write an Ada compiler for multiple back-ends:
> 1) libFirm:  https://pp.ipd.kit.edu/firm
> 2) LLVM
> 3) GCC
> 4) Graal for JVM:  http://www.graalvm.org
> 5) CLR for .NET & Mono
> and so forth.
> 
> Compared to Byron's laudable long-term clean-room-design goals, my GELI proposal* for an LLVM-backended GNAT is an interim stop-gap, focusing only on likely-not-clean-room generation of LLVM bitcode IR within a single GPLv3 GNAT executable, causing only ISAs' machine-code (not the IR) to be generated by LLVM-embedded-within-GNAT.
> 
> * described in a prior reply above
> 
> > Yeah; that's one of the big problems Byron [Ada 2012 in Ada 2012] is intended to address; the other big
> > one is to escape the stupid morass of licensing issues.
> 
> What is so bad about GPLv3 with Runtime Exception …
> 
> 1) … unless a person really really wants to re-work GCC-emitted machine code as lifted to LLVM bitcode IR via, say, McSema as not-GPLv3ed derivative works, needing disclosure of all source code?**
> or
> 
> 2) … unless a person really really wants to write LLVM bitcode IR out to a file to execute it on Sulong/GraalVM as not-GPLv3ed derivative works, needing disclosure of all source code?**
> or
> 
> 3) Can anyone think of any other precise downsides of GPLv3 •with• Runtime Exception?

I just thought of another one:

3) … unless a person really really wants to write LLVM bitcode IR out to a file to have Polly grind on it with all sorts of advanced optimizations.

Polly and GraalVM of course beget doing to them what was described above for LLVM:

H) Import the entirety of Polly within the GCC repository for compilation (along with the entirety of LLVM) into a single GNAT executable, so that LLVM bitcode IR is never emitted as a file by GNAT just to utilize Polly's polyhedral optimizations with GELI->LLVM.

H.a) Add all the command-line options for Polly to GNAT.

I) Import the entirety of GraalVM within the GCC repository for compilation into a single GNAT executable, so that LLVM bitcode IR is never emitted as a file by GNAT just to utilize GELI->LLVM->GraalVM's Sulong & Polyglot.

I.a) Add all the command-line options for GraalVM to GNAT.

Re: DragonEgg has been revived

[Shark8]

On Tuesday, May 22, 2018 at 2:17:11 PM UTC-6, Dan'l Miller wrote:
> On Tuesday, May 22, 2018 at 2:40:24 PM UTC-5, Shark8 wrote:
> > On Tuesday, May 22, 2018 at 6:29:10 AM UTC-6, Simon Clubley wrote:
> > > 
> > > What I would like to see is an Ada compiler that can generate code
> > > for a wide range of targets without any GPL restrictions on the
> > > generated code.
> > 
> > I'm getting ready to restart work on Byron. I figure that perhaps an Implementation Manual/Design Document would help explain the design underneath it and welcome new contributors. 
> > 
> > > 
> > > I'm not really bothered how that happens but LLVM seems like an
> > > interesting option.
> > 
> > I have mixed feelings on LLVM -- it would be nice to grab all the targets for it, but I also think it's a stupid
> > idea to build the compiler specifically for it.
> 
> Writing a compiler “specifically for” LLVM?  I thought that the whole premise of Byron was to write an Ada compiler for multiple back-ends:
> 1) libFirm:  https://pp.ipd.kit.edu/firm
> 2) LLVM
> 3) GCC
> 4) Graal for JVM:  http://www.graalvm.org
> 5) CLR for .NET & Mono
> and so forth.

Byron certainly is about multiple backends -- but there's been a lot of talk about an "LLVM Ada compiler" here in the past, to the point where the implications really were designing a compiler specifically to it.

> 
> Compared to Byron's laudable long-term clean-room-design goals, my GELI proposal* for an LLVM-backended GNAT is an interim stop-gap, focusing only on likely-not-clean-room generation of LLVM bitcode IR within a single GPLv3 GNAT executable, causing only ISAs' machine-code (not the IR) to be generated by LLVM-embedded-within-GNAT.

Hm interesting. 

> 
> > Yeah; that's one of the big problems Byron [Ada 2012 in Ada 2012] is intended to address; the other big
> > one is to escape the stupid morass of licensing issues.
> 
> What is so bad about GPLv3 with Runtime Exception …

In itself, not so much -- the biggest problem with anything GCC [meaning GNAT in the context of Ada] is that there's all the morass of licensing surrounding it: FSF GNAT vs PGL GNAT vs AdaCore Pro GNAT -- all have different restrictions and capabilities and it's just a big mess -- especially for any small to medium business to sort out.

I want a clean break from ALL of that.

> 
> 1) … unless a person really really wants to re-work GCC-emitted machine code as lifted to LLVM bitcode IR via, say, McSema as not-GPLv3ed derivative works, needing disclosure of all source code?**
> or
> 
> 2) … unless a person really really wants to write LLVM bitcode IR out to a file to execute it on Sulong/GraalVM as not-GPLv3ed derivative works, needing disclosure of all source code?**
> or
> 
> 3) Can anyone think of any other precise downsides of GPLv3 •with• Runtime Exception?

The issue isn't GPL with Exception -- it's the idiocy that AdaCore has embraced with respect to GNAT, essentially making it unapproachable and confusing as compared to C, FreePascal, or many other implementations.

> 
> I think all the downsides other than those 2 listed above are with GPL •without• Runtime Exception, correct?

The technical considerations; yes. (But we're touching 'legal' and 'business' when it comes to getting more companies using Ada; and the whole GNAT situation is not conducive to that.)

> 
> ** Due to the Target Code clauses of GPLv3 and the Eligible Compilation Process of GPLv3's Runtime Exception, all downstream derivative works are staunchly GPLv3 with the Runtime Exception overtly revoking itself due to the (clearly) IR or the machine-code-as-IR.

The viral nature of GPL is also a turn-off for a lot of companies, regardless of runtime exception.

Re: DragonEgg has been revived

[Dan'l Miller]

On Tuesday, May 22, 2018 at 5:33:29 PM UTC-5, Shark8 wrote:
> On Tuesday, May 22, 2018 at 2:17:11 PM UTC-6, Dan'l Miller wrote:
> > On Tuesday, May 22, 2018 at 2:40:24 PM UTC-5, Shark8 wrote:
> > > On Tuesday, May 22, 2018 at 6:29:10 AM UTC-6, Simon Clubley wrote:
> > > > 
> > > > What I would like to see is an Ada compiler that can generate code
> > > > for a wide range of targets without any GPL restrictions on the
> > > > generated code.
> > > 
> > > I'm getting ready to restart work on Byron. I figure that perhaps an Implementation Manual/Design Document would help explain the design underneath it and welcome new contributors. 
> > > 
> > > > 
> > > > I'm not really bothered how that happens but LLVM seems like an
> > > > interesting option.
> > > 
> > > I have mixed feelings on LLVM -- it would be nice to grab all the targets for it, but I also think it's a stupid
> > > idea to build the compiler specifically for it.
> > 
> > Writing a compiler “specifically for” LLVM?  I thought that the whole premise of Byron was to write an Ada compiler for multiple back-ends:
> > 1) libFirm:  https://pp.ipd.kit.edu/firm
> > 2) LLVM
> > 3) GCC
> > 4) Graal for JVM:  http://www.graalvm.org
> > 5) CLR for .NET & Mono
> > and so forth.
> 
> Byron certainly is about multiple backends -- but there's been a lot of talk about an "LLVM Ada compiler" here in the past, to the point where the implications really were designing a compiler specifically to it.
> 
> > 
> > Compared to Byron's laudable long-term clean-room-design goals, my GELI proposal* for an LLVM-backended GNAT is an interim stop-gap, focusing only on likely-not-clean-room generation of LLVM bitcode IR within a single GPLv3 GNAT executable, causing only ISAs' machine-code (not the IR) to be generated by LLVM-embedded-within-GNAT.
> 
> Hm interesting. 
> 
> > 
> > > Yeah; that's one of the big problems Byron [Ada 2012 in Ada 2012] is intended to address; the other big
> > > one is to escape the stupid morass of licensing issues.
> > 
> > What is so bad about GPLv3 with Runtime Exception …
> 
> In itself, not so much -- the biggest problem with anything GCC [meaning GNAT in the context of Ada] is that there's all the morass of licensing surrounding it: FSF GNAT vs PGL GNAT vs AdaCore Pro GNAT -- all have different restrictions and capabilities and it's just a big mess -- especially for any small to medium business to sort out.
> 
> I want a clean break from ALL of that.

As do we all.  If GELI project is clever, mods & extensions to LLVM-world can be accomplished outside of GCC-world (e.g., with UofIllinois/NCSA license) if they are not derivative works of anything in GCC.  These value-adds to LLVM-world could occasionally be useful to Byron.  The only things that come to mind are:
1) the no-files always-in-DRAM way of avoiding writing LLVM bitcode IR* to files between LLVM-world's stages (but I am not entirely unsure so far that this might already exist in LLVM-world);
2) chaining Polly stages flexibly amongst LLVM stages by •not• executing Polly executable multiple** times;
3) command-line parsing for LLVM-world topics,
3.1) e.g., command-line parsing for “llvm-”-prefixed targets
3.2) e.g., command-line parsing for chaining Polly amongst LLVM-world stages;
4) fresh new test suite.

* regardless of whatever the content of that LLVM bitcode IR is

** see page 8 of https://polly.llvm.org/publications/grosser-diploma-thesis.pdf

Conversely, I haven't been clever enough to yet figure out a way that GELI could be clean-room in the “southbound” LLVM-bitcode-IR direction (for Byron's usage) while actually being clean-room in input-to-GELI direction on the “north” side of GELI.  So far I haven't been clever enough for GELI's north-side awareness of GNAT's fully-semantically-adorned Ada IR snippets to not make •all• of GELI downstream-southbound a derivative work of GNAT (and thus licensed by GPLv3-with-Runtime-Exception), including the generated LLVM bitcode IR being effectively tainted transitively by awareness of the content & boundary of the snippet from GNAT's Ada-IR tree.  That taint ruins any attempt to keep the LLVM bitcode IR clean room.  If all roads in GELI lead to being a tainted derivative work of GNAT's Ada-IR tree then why attempt the immense hassle of clean-room designing the LLVM bitcode IR at all (other than to help out Byron)?

I am open to ideas there though.

> The viral nature of GPL is also a turn-off for a lot of companies, regardless of runtime exception.

I agree wholeheartedly.  That is why we need Byron (or for one of the closed-source Ada compilers to get aggressively super-competitive with GNAT).

Re: DragonEgg has been revived

[Simon Wright]

Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> writes:

> What I would like to see is an Ada compiler that can generate code for
> a wide range of targets without any GPL restrictions on the generated
> code.

Pretty sure that's called GCC.

People are perfectly happy to use GCC for C-based commercial projects in
spite of the fact that libgcc, and GNU libstdc++, if you're that way
inclined, have *exactly* the same runtime exception as FSF GNAT's RTS
and the GNAT Pro RTS.

The formal position is that the GCC compiler itself doesn't assert any
licensing restrictions over target code generated by it beyond that
derived from the original source code.

I can see that people, especially commercial lawyers, might be confused
about this, especially if they read all the hot air that's been blasting
over this newsgroup lately. It's a good thing that that's unlikely.

Seems to me that one could in theory get over the licensing issue by
writing an independent BSD-licensed RTS. Not that this is a small task;
deliberately omitting finalization, exception propagation, full tasking,
and multiprocessors would make it just about feasible for a small team,
I think. But I may be seeing through rose-tinted specs because of having
based Cortex GNAT RTS on FSF GCC.

Re: DragonEgg has been revived

[Luke A. Guest]

Simon Wright <s.org> wrote:

> People are perfectly happy to use GCC for C-based commercial projects in
> spite of the fact that libgcc, and GNU libstdc++, if you're that way
> inclined, have *exactly* the same runtime exception as FSF GNAT's RTS
> and the GNAT Pro RTS.

It’s not just the licensing stupidity with Ada libs. On the C or C++ front,
they can easily go to Clang and get more targets, I.e. iOS, Ada programmers
can’t.

Like

Re: DragonEgg has been revived

[Dan'l Miller]

On Wednesday, May 23, 2018 at 2:26:49 AM UTC-5, Simon Wright wrote:
> Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> writes:
> 
> > What I would like to see is an Ada compiler that can generate code for
> > a wide range of targets without any GPL restrictions on the generated
> > code.
> 
> Pretty sure that's called GCC.

Pretty sure that you haven't read the Target Code clauses in GPLv3 and Eligible Compilation Process clauses in the Runtime Exception.  GPL restrictions galore on the generated code there in those two.

Just because IR-based technologies haven't historically been utilized widely yet in the enterprise (and thus receive the attention of Sarbanes-Oxley compliance in the finance department and contract compliance in the legal department), doesn't mean that technologies in the ballpark of McSema (resurrect IR from hardware-processor machine code) and GraalVM (mix LLVM IR with JVM bytecode via Polyglot) will not be utilized by the enterprise tomorrow.

> People

historically  (There, fixed that for you; tomorrow's IR-IR-everywhere-for-world-plus-dog is a new era.)

> are perfectly happy to use GCC for C-based commercial projects in
> spite of the fact that libgcc, and GNU libstdc++, if you're that way
> inclined, have *exactly* the same runtime exception as FSF GNAT's RTS
> and the GNAT Pro RTS.
> 
> The formal position is that the GCC compiler itself doesn't assert any
> licensing restrictions over target code generated by it beyond that
> derived from the original source code.

You are so GPLv2; that is the way it was under GPLv2 back in the old days.  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 Runtime 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 for that MIT/X11-licensed or BSD-licensed executable or DLL.  Simon, you are •factually incorrect• nowadays (post-GPLv2) in your claim “that the GCC compiler itself doesn't assert any licensing restrictions over target code generated by it beyond that derived from the original source code”, because the ••GPLv3 license of the modern GCC compiler itself•• spreads (dare I say, virally) to the otherwise MIT/X11-licensed or BSD-licensed Target Code

1) if that Target-Code hardware-processor's machine-code is lifted by, say, McSema back to LLVM bitcode IR
or

2) if somehow a GCC-written IR derived from that MIT/X11-licensed or BSD-licensed source code and then fed into, say, LLVM and/or Polly and/or GraalVM stand-alone* executable(s) which then itself produces the hardware-processor machine-code
or

* i.e., as they are packaged today as executables that are invoked downstream (long) after modern GCC's executable finished executing

3) #1 & #2 above are just the first 2 examples of emerging technology in the IR domain and in the rework-the-machine-code domain.
3.1) For example, imagine an anti-malware add-on (that, for the sake of discussion here, violates the Target Code or Eligible Compilation Process clauses of a modern-GCC-written executable or DLL) to operating systems that reworks the machine-code at link-load time to eliminate:
3.1.1) buffer-overrun injection of worms; and/or
3.1.2) removes viruses/etc-malware that have attached themselves to the executable or DLL and/or
3.1.3) randomizes the layout of the machine code each link-loader-time so that malware cannot easily recognize that executable or DLL.

4) Indeed, viruses that modify a modern-GCC-written Target Code to insert the virus into machine code could quite easily violate either the Target Code clause of GPLv3 or the Eligible Compilation Process clause of the Runtime Exception or both (unless the virus fully complied with the entirety of GPLv3, including providing its source code to those people to whom the virus was distributed/infected).

Please note that each of #1, #2, #3.1, and #4 are all performed by a party other than the original developer of the MIT/X11-licensed source code.  Note especially that each of #1, #3.1, and #4 can clearly all be performed by a party other than the person who invoked the GCC compiler to write out that executable or DLL file.  (Only #2 seems to need an overt extra act at the time of GCC-compilation.)

On the surface (conceivably shockingly preposterously), merely running a closed-source permissive-licensed modern-GCC-compiled executable or DLL through, say, McSema can allow the downstream 3rd-party person who lifted the GCC-compiled machine code to that LLVM bitcode IR to then demand the source code (!) to that otherwise closed-source (!) permissively-licensed executable o DLL, because not only is the IR GPLv3-licensed, but, more bizarrely more importantly, the GCC-compiled hardware-processor machine-code executable or DLL is retroactively (!) GPLv3-licensed (!) under the Target Code and/or Eligible Compilation Process clauses' overt retroactive revocation of rights on the machine code that was generated by modern GCC.  This seems preposterous, but merely mechanically turning the crank of the Target Code & Eligible Compilation Process language in GPLv3 & its Runtime Exception seems to quite directly say this (at least to me under my plain-language reading of the terms of the license contract, as I am permitted to do for myself under Texas contract law).

disclaimer:
[I am not a lawyer who has passed the bar in any jurisdiction whatsoever.  Do not rely on any of this for any purpose.  Seek the counsel of an attorney duly certified for the system of law within the jurisdiction(s) in which you reside or operate.]

Pretty sure all this above are examples of what Shark8 would use the term “all the morass of licensing surrounding” GPLv3-with-Runtime-Exception-v3.1-licensed modern GCC.

> I can see that people, especially commercial lawyers, might be confused
> about this, especially if they read

the Target Code clauses or Eligible Compilation Process clauses of the Runtime Exception v3.1 (There, fixed that for you; that is what they need to read.)

> all the hot air that's been blasting over this newsgroup lately.

Yeah right.  Encouraging people to actually read the Target Code and Eligible Compilation Process clauses of the Runtime Exception v3.1 and revealing why it is important that they do so is dismissed as “hot air … blasting”.

Re: DragonEgg has been revived

[Dan'l Miller]

[fixed typos]
On Wednesday, May 23, 2018 at 2:26:49 AM UTC-5, Simon Wright wrote: 
> Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> writes: 
> 
> > What I would like to see is an Ada compiler that can generate code for 
> > a wide range of targets without any GPL restrictions on the generated 
> > code. 
> 
> Pretty sure that's called GCC. 

Pretty sure that you haven't read the Object Code clauses in GPLv3 and the Target Code clauses and Eligible Compilation Process clauses in the Runtime Exception v3.1.  GPL restrictions galore on the generated code there in Target Code & Eligible Compilation Process (in Runtime Exception v3.1) interacting with Object Code, where Object Code is •everything• not Source Code (in GPLv3).  IR would therefore be Object Code due to being not Target Code and not Source Code.

Just because IR-based technologies haven't historically been utilized widely yet in the enterprise (and thus receive the attention of Sarbanes-Oxley internal-controls compliance in the finance department and contract compliance in the legal department), doesn't mean that technologies in the ballpark of McSema (resurrect IR from hardware-processor machine code) and GraalVM (mix LLVM IR with JVM bytecode to produce hardware-processor machine-code via Polyglot) will not be utilized by the enterprise tomorrow. 

> People 

historically  (There, fixed that for you; tomorrow's IR-IR-everywhere-for-world-plus-dog is a new era.) 

> are perfectly happy to use GCC for C-based commercial projects in 
> spite of the fact that libgcc, and GNU libstdc++, if you're that way 
> inclined, have *exactly* the same runtime exception as FSF GNAT's RTS 
> and the GNAT Pro RTS. 
> 
> The formal position is that the GCC compiler itself doesn't assert any 
> licensing restrictions over target code generated by it beyond that 
> derived from the original source code. 

You are so GPLv2; that is the way it was under GPLv2 back in the old days.  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 Runtime 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 for that MIT/X11-licensed or BSD-licensed executable or DLL.  Simon, you are •factually incorrect• nowadays (post-GPLv2) in your claim “that the GCC compiler itself doesn't assert any licensing restrictions over target code generated by it beyond that derived from the original source code”, because the ••GPLv3 license of the modern GCC compiler itself•• spreads (dare I say, virally) to the otherwise MIT/X11-licensed or BSD-licensed Target Code 

1) if that Target-Code hardware-processor's machine-code is lifted by, say, McSema back to LLVM bitcode IR 
or 

2) if somehow a GCC-written IR derived from that MIT/X11-licensed or BSD-licensed source code and then fed into, say, LLVM and/or Polly and/or GraalVM stand-alone* executable(s) which then itself produces the hardware-processor machine-code 
or 

* i.e., as they are packaged today as executables that are invoked downstream (long) after modern GCC's executable finished executing 

3) #1 & #2 above are just the first 2 examples of emerging technology in the IR domain and in the rework-the-machine-code domain. 
3.1) For example, imagine an anti-malware add-on (that, for the sake of discussion here, violates the Target Code or Eligible Compilation Process clauses of a modern-GCC-written executable or DLL) to operating systems that reworks the machine-code at link-load time to eliminate: 
3.1.1) buffer-overrun injection of worms; and/or 
3.1.2) removes viruses/etc-malware that have attached themselves to the executable or DLL and/or 
3.1.3) randomizes the layout of the machine code each link-loader-time so that malware cannot easily recognize that executable or DLL. 

4) Indeed, viruses that modify a modern-GCC-written Target Code to insert the virus into machine code could quite easily violate either the Target Code clause of GPLv3 or the Eligible Compilation Process clause of the Runtime Exception or both (unless the virus fully complied with the entirety of GPLv3, including providing its source code to those people to whom the virus was distributed/infected). 

Please note that each of #1, #2, #3.1, and #4 are all performed by a party other than the original developer of the MIT/X11-licensed source code.  Note especially that each of #1, #3.1, and #4 can clearly all be performed by a party other than the person who invoked the GCC compiler to write out that executable or DLL file.  (Only #2 seems to need an overt extra act at the time of GCC-compilation.) 

On the surface (conceivably shockingly preposterously), merely running a closed-source permissive-licensed modern-GCC-compiled executable or DLL through, say, McSema can allow the downstream 3rd-party person who lifted the GCC-compiled machine code to that LLVM bitcode IR to then demand the source code (!) to that otherwise closed-source (!) permissively-licensed executable o DLL, because not only is the IR GPLv3-licensed, but, more bizarrely more importantly, the GCC-compiled hardware-processor machine-code executable or DLL is retroactively (!) GPLv3-licensed (!) under the Target Code and/or Eligible Compilation Process clauses' overt retroactive revocation of rights on the machine code that was generated by modern GCC.  This seems preposterous, but merely mechanically turning the crank of the Target Code & Eligible Compilation Process language in GPLv3 & its Runtime Exception seems to quite directly say this (at least to me under my plain-language reading of the terms of the license contract, as I am permitted to do for myself under Texas contract law). 

disclaimer: 
[I am not a lawyer who has passed the bar in any jurisdiction whatsoever.  Do not rely on any of this for any purpose.  Seek the counsel of an attorney duly certified for the system of law within the jurisdiction(s) in which you reside or operate.] 

Pretty sure all this above are examples of where Shark8 would use the term “all the morass of licensing surrounding” GPLv3-with-Runtime-Exception-v3.1-licensed modern GCC. 

> I can see that people, especially commercial lawyers, might be confused 
> about this, especially if they read 

the Target Code clauses or Eligible Compilation Process clauses of the Runtime Exception v3.1 (There, fixed that for you; that is what they need to read.) 

> all the hot air that's been blasting over this newsgroup lately. 

Yeah right.  Encouraging people to actually read the Target Code and Eligible Compilation Process clauses of the Runtime Exception v3.1 and revealing why it is important that they do so is dismissed as “hot air … blasting”.

Re: DragonEgg has been revived

[Dan'l Miller]

[fixed typos and buggy graying out] 
On Wednesday, May 23, 2018 at 2:26:49 AM UTC-5, Simon Wright wrote: 
> Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> writes: 
> 
> > What I would like to see is an Ada compiler that can generate code for 
> > a wide range of targets without any GPL restrictions on the generated 
> > code. 
> 
> Pretty sure that's called GCC. 

Pretty sure that you haven't read the Object Code clauses in GPLv3 and the Target Code clauses and Eligible Compilation Process clauses in the Runtime Exception v3.1.  GPL restrictions galore on the generated code there in Target Code & Eligible Compilation Process (in Runtime Exception v3.1) interacting with Object Code, where Object Code is •everything• not Source Code (in GPLv3).  IR would therefore be Object Code due to being not Target Code and not Source Code. 

Just because IR-based technologies haven't historically been utilized widely yet in the enterprise (and thus receive the attention of Sarbanes-Oxley internal-controls compliance in the finance department and contract compliance in the legal department), doesn't mean that technologies in the ballpark of McSema (resurrect IR from hardware-processor machine code) and GraalVM (mix LLVM IR with JVM bytecode to produce hardware-processor machine-code via Polyglot) will not be utilized by the enterprise tomorrow. 

> People 

historically  (There, fixed that for you; tomorrow's IR-IR-everywhere-for-world-plus-dog is a new era.) 

> are perfectly happy to use GCC for C-based commercial projects in 
> spite of the fact that libgcc, and GNU libstdc++, if you're that way 
> inclined, have *exactly* the same runtime exception as FSF GNAT's RTS 
> and the GNAT Pro RTS. 
> 
> The formal position is that the GCC compiler itself doesn't assert any 
> licensing restrictions over target code generated by it beyond that 
> derived from the original source code. 

You are so GPLv2; that is the way it was under GPLv2 back in the old days.  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 Runtime 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 for that MIT/X11-licensed or BSD-licensed executable or DLL.  Simon, you are •factually incorrect• nowadays (post-GPLv2) in your claim “that the GCC compiler itself doesn't assert any licensing restrictions over target code generated by it beyond that derived from the original source code”, because the ••GPLv3 license of the modern GCC compiler itself•• spreads (dare I say, virally) to the otherwise MIT/X11-licensed or BSD-licensed Target Code 

1) if that Target-Code hardware-processor's machine-code is lifted by, say, McSema back to LLVM bitcode IR 
or 

2) if somehow a GCC-written IR derived from that MIT/X11-licensed or BSD-licensed source code and then fed into, say, LLVM and/or Polly and/or GraalVM stand-alone* executable(s) which then itself produces the hardware-processor machine-code 
or 

* i.e., as they are packaged today as executables that are invoked downstream (long) after modern GCC's executable finished executing 

3) #1 & #2 above are just the first 2 examples of emerging technology in the IR domain and in the rework-the-machine-code domain. 
3.1) For example, imagine an anti-malware add-on (that, for the sake of discussion here, violates the Target Code or Eligible Compilation Process clauses of a modern-GCC-written executable or DLL) to operating systems that reworks the machine-code at link-load time to eliminate: 
3.1.1) buffer-overrun injection of worms; and/or 
3.1.2) removes viruses/etc-malware that have attached themselves to the executable or DLL and/or 
3.1.3) randomizes the layout of the machine code each link-loader-time so that malware cannot easily recognize that executable or DLL. 

4) Indeed, viruses that modify a modern-GCC-written Target Code to insert the virus into machine code could quite easily violate either the Target Code clause of GPLv3 or the Eligible Compilation Process clause of the Runtime Exception or both (unless the virus fully complied with the entirety of GPLv3, including providing its source code to those people to whom the virus was distributed/infected). 

Please note that each of #1, #2, #3.1, and #4 are all performed by a party other than the original developer of the MIT/X11-licensed source code.  Note especially that each of #1, #3.1, and #4 can clearly all be performed by a party other than the person who invoked the GCC compiler to write out that executable or DLL file.  (Only #2 seems to need an overt extra act at the time of GCC-compilation.) 

On the surface (conceivably shockingly preposterously), merely running a closed-source permissive-licensed modern-GCC-compiled executable or DLL through, say, McSema can allow the downstream 3rd-party person who lifted the GCC-compiled machine code to that LLVM bitcode IR to then demand the source code (!) to that otherwise closed-source (!) permissively-licensed executable o DLL, because not only is the IR GPLv3-licensed, but, more bizarrely more importantly, the GCC-compiled hardware-processor machine-code executable or DLL is retroactively (!) GPLv3-licensed (!) under the Target Code and/or Eligible Compilation Process clauses' overt retroactive revocation of rights on the machine code that was generated by modern GCC.  This seems preposterous, but merely mechanically turning the crank of the Target Code & Eligible Compilation Process language in GPLv3 & its Runtime Exception seems to quite directly say this (at least to me under my plain-language reading of the terms of the license contract, as I am permitted to do for myself under Texas contract law). 

disclaimer:
[I am not a lawyer who has passed the bar in any jurisdiction whatsoever.  Do not rely on any of this for any purpose.  Seek the counsel of an attorney duly certified for the system of law within the jurisdiction(s) in which you reside or operate.] 

Pretty sure all this above are examples of where Shark8 would use the term “all the morass of licensing surrounding” GPLv3-with-Runtime-Exception-v3.1-licensed modern GCC. 

> I can see that people, especially commercial lawyers, might be confused 
> about this, especially if they read 

the Target Code clauses or Eligible Compilation Process clauses of the Runtime Exception v3.1 (There, fixed that for you; that is what they need to read.) 

> all the hot air that's been blasting over this newsgroup lately. 

Yeah right.  Encouraging people to actually read the Target Code and Eligible Compilation Process clauses of the Runtime Exception v3.1 and revealing why it is important that they do so is dismissed as “hot air … blasting”.

Re: DragonEgg has been revived

[Chris M Moore]

On 23/05/2018 16:51, Dan'l Miller wrote:

<snip>

> You are so GPLv2; that is the way it was under GPLv2 back in the old days.  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 Runtime 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 for that MIT/X11-licensed or BSD-licensed executable or DLL.  Simon, you are •factually incorrect• nowadays (post-GPLv2) in your claim “that the GCC compiler itself doesn't assert any licensing restrictions over target code generated by it beyond that derived from the original source code”, because the ••GPLv3 license of the modern GCC compiler itself•• spreads (dare I say, virally) to the otherwise MIT/X11-licensed or BSD-licensed Target Code

Nope.  The Eligible Compilation Process covers the compilation process 
itself, not the end product.  This was introduced to stop non-GPLed 
plugins to gcc.  See https://lwn.net/Articles/301959/

-- 
sig pending (since 1995)

Re: DragonEgg has been revived

[Dan'l Miller]

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:
> 
> <snip>
> 
> > You are so GPLv2; that is the way it was under GPLv2 back in the old days.  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 Runtime 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 for that MIT/X11-licensed or BSD-licensed executable or DLL.  Simon, you are •factually incorrect• nowadays (post-GPLv2) in your claim “that the GCC compiler itself doesn't assert any licensing restrictions over target code generated by it beyond that derived from the original source code”, because the ••GPLv3 license of the modern GCC compiler itself•• spreads (dare I say, virally) to the otherwise MIT/X11-licensed or BSD-licensed Target Code
> 
> Nope.  The Eligible Compilation Process covers the compilation process 
> itself, not the end product.  This was introduced to stop non-GPLed 
> plugins to gcc.  See https://lwn.net/Articles/301959/

Independent of why historically it was devised, the wording of Runtime Exception v3.1 is quite clearly applying to cases beyond merely that one historical case:

“The "Compilation Process" transforms code entirely represented in ••non-intermediate•• languages designed for human-written code, and/or in Java Virtual Machine byte code, into Target Code.”

Is intermediate representation written out as a file meeting the terms/definition of Target Code in the Runtime Exception?  The following quotation answers that question:

“"Target Code" refers to output from any compiler for a real or virtual target processor architecture, in executable form or suitable for input to an assembler, loader, linker and/or execution phase. Notwithstanding that, Target Code does not include data in any format that is used as a compiler intermediate representation, or used for producing a compiler intermediate representation.”

The key word there is “notwithstanding”.  It means that even if supposedly target code meets any of the definitions in the first sentence, its ability to actually be Target Code is ruined/spoiled by the second sentence.  I'm pretty sure that “data in ••any format••” and “compiler intermediate representation” 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 will 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-GPLed plugin to GCC, but simply starts executing after a GCC compiler finishes executing by reading some sort of IR file written by GCC.  Whether it was 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 to comply with the the terms governing what a Compilation Process is).

B) If a supposed Compilation Process produces some non-Target-Code derivative work representing Source Code, then it certainly is not a Compilation Process (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 “notwithstanding”, then it certainly is not Target Code (due to failing to comply with the “notwithstanding” IR terms).

D) The “notwithstanding” IR terms on Target Code spoil everything downstream from meeting their definitions in the Runtime Exception v3.1.

E) Without meeting the Runtime Exception v3.1's definitions downstream from the “notwithstanding”, 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 “notwithstanding” IR terms spoiled meeting Target Code's definition,
E.b) because the spoiled not-Target-Code and “non-intermediate” both in turn spoiled meeting Compilation Process's definition,
E.c) because the spoiled not-Compilation-Process in turn spoiled Eligible Compilation Process's definition,
E.d) because the spoiled not-Eligible-Compilation-Process in turn spoiled the Runtime Exception v3.1,
and
E.e) because the spoiled Runtime Exception v3.1 spoiled itself so completely 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 the terms to convey the IR or the resulting machine-code.

So in fewer words, I nope your nope.

Re: DragonEgg has been revived

[Chris M Moore]

On 23/05/2018 21:30, Dan'l Miller wrote:
> 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:
>>
>> <snip>
>>
>>> You are so GPLv2; that is the way it was under GPLv2 back in the old days.  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 Runtime 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 for that MIT/X11-licensed or BSD-licensed executable or DLL.  Simon, you are •factually incorrect• nowadays (post-GPLv2) in your claim “that the GCC compiler itself doesn't assert any licensing restrictions over target code generated by it beyond that derived from the original source code”, because the ••GPLv3 license of the modern GCC compiler itself•• spreads (dare I say, virally) to the otherwise MIT/X11-licensed or BSD-licensed Target Code
>>
>> Nope.  The Eligible Compilation Process covers the compilation process
>> itself, not the end product.  This was introduced to stop non-GPLed
>> plugins to gcc.  See https://lwn.net/Articles/301959/
> 
> Independent of why historically it was devised, the wording of Runtime Exception v3.1 is quite clearly applying to cases beyond merely that one historical case:
> 
> “The "Compilation Process" transforms code entirely represented in ••non-intermediate•• languages designed for human-written code, and/or in Java Virtual Machine byte code, into Target Code.”
> 
> Is intermediate representation written out as a file meeting the terms/definition of Target Code in the Runtime Exception?  The following quotation answers that question:
> 
> “"Target Code" refers to output from any compiler for a real or virtual target processor architecture, in executable form or suitable for input to an assembler, loader, linker and/or execution phase. Notwithstanding that, Target Code does not include data in any format that is used as a compiler intermediate representation, or used for producing a compiler intermediate representation.”
> 
> The key word there is “notwithstanding”.  It means that even if supposedly target code meets any of the definitions in the first sentence, its ability to actually be Target Code is ruined/spoiled by the second sentence.  I'm pretty sure that “data in ••any format••” and “compiler intermediate representation” are pretty big clues about LLVM bitcode IR's standing in the terms of this Runtime Exception v3.1.

You might like to read the comments in the article I referenced earlier. 
  They specifically mention llvm plugins to gcc.  Now if you're wanting 
to do something else with IRs that isn't supported/allowed, wouldn't 
that just be abusing Free Software for your own nefarious ends?

> 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 will 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-GPLed plugin to GCC, but simply starts executing after a GCC compiler finishes executing by reading some sort of IR file written by GCC.  Whether it was 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.

Apparently llvm is GPL compatible so dragonegg appears to be legal.  But 
what you describe in the para above is what the what the Eligible 
Compilation Process stuff was designed to prevent.

Simon W was saying that FSF gnat/gnat pro can produce non-GPLed 
software.  It seems we can also do it via dragonegg.  But dumping the IR 
to a file is not allowed.  I can't see how that's a restriction on the 
target code generated as you asserted.

<snip>

> 
> So in fewer words, I nope your nope.
> 

Nope ** 3

-- 
sig pending (since 1995)

Re: DragonEgg has been revived

[Dan'l Miller]

On Wednesday, May 23, 2018 at 5:18:20 PM UTC-5, Chris M Moore wrote:
> On 23/05/2018 21:30, Dan'l Miller wrote:
> > 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 will 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-GPLed plugin to GCC, but simply starts executing after a GCC compiler finishes executing by reading some sort of IR file written by GCC.  Whether it was 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.
> 
> Apparently llvm is GPL compatible so dragonegg appears to be legal.  But 
> what you describe in the para above is what the what the Eligible 
> Compilation Process stuff was designed to prevent.

Oh, so the Runtime Exception actually is designed with legal teeth to prevent doing something, eh?  I am glad that you in your own mind finally convinced yourself that you have disproven the fallacious theorem to be disproven.  Q.E.D. by violent agreement, eh?  (See below for the original fallacious theorem from Simon to be disproven.)

> Simon W was saying that FSF gnat/gnat pro can produce non-GPLed 
> software.

  No, that is what I have been saying in prior comments in this thread:  in practice, what are actual encumbrances on the executables & DLLs written by FSF GNAT?  I listed 3.  Simon went further than that though to claim that there exist absolutely no restrictions related to GPLv3 on the executables and DLLs written by modern GCC.  Let us quote him to review:

shark8 wrote:
> What I would like to see is an Ada compiler that can generate code for 
> a wide range of targets ••without •any• GPL restrictions on the generated 
> code••. 

Simon Wright wrote:
> Pretty sure that's called GCC.

No, Simon, both Chris Moore and I have both shown that the Eligible Compilation Process prohibits certain categories of manipulations of the generated code, both code-in-the-form-of-true-IR and code-in-the-form-of-machine-code-lifted-back-to-IR-by-e.g.-McSema.  We are attacking your ignoring the “any” there in shark8's laudable expectation/goal.

>  It seems we can also do it via dragonegg.  But dumping the IR 
> to a file is not allowed.  I can't see how that's a restriction on the 
> target code generated as you asserted.

That is correct:  you don't see it.  McSema, Chris, McSema.  Read about the DARPA-funded lifter that lifts Target Code to LLVM bitcode IR, then read the “Target Code does not include data in •any format• that is … used for producing a compiler intermediate representation” and then re-read it 10 times while pondering that opcodes and their parameters in machine-code are mere data in a particular format.  “Any format that is … used for producing [IR]”.  (You really need to read less hearsay from 2009 about plug-ins and instead read current-era 2018 material.)

Re: DragonEgg has been revived

[Simon Wright]

"Dan'l Miller" <optikos@verizon.net> writes:

> On Wednesday, May 23, 2018 at 2:26:49 AM UTC-5, Simon Wright wrote: 
>> Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> writes: 
>> 
>> > What I would like to see is an Ada compiler that can generate code
>> > for a wide range of targets without any GPL restrictions on the
>> > generated code.
>> 
>> Pretty sure that's called GCC. 
>
> Pretty sure that you haven't read the Object Code clauses in GPLv3 and
> the Target Code clauses and Eligible Compilation Process clauses in
> the Runtime Exception v3.1.  GPL restrictions galore on the generated
> code there in Target Code & Eligible Compilation Process (in Runtime
> Exception v3.1) interacting with Object Code, where Object Code is
> •everything• not Source Code (in GPLv3).  IR would therefore be Object
> Code due to being not Target Code and not Source Code.

You are confusing GPLv3 with the GCC Runtime Library Exception.

GPLv3 section 1 para 4 says

   The “Corresponding Source” for a work in object code form means all
   the source code needed to generate, install, and (for an executable
   work) run the object code and to modify the work, including scripts
   to control those activities. However, it does not include the work's
   System Libraries, or general-purpose tools or generally available
   free programs which are used unmodified in performing those
   activities but which are not part of the work. [...]

and it's clear that the GCC compiler itself is a 'generally available
free program'.

See also the FAQ[1]:

   [Q] Can I use GPL-covered editors such as GNU Emacs to develop
   nonfree programs? Can I use GPL-covered tools such as GCC to compile
   them?
 
   Yes, because the copyright on the editors and tools does not cover
   the code you write. Using them does not place any restrictions,
   legally, on the license you use for your code.
   
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.

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.

[1] https://www.gnu.org/licenses/gpl-faq.html#CanIUseGPLToolsForNF

Re: DragonEgg has been revived

[Simon Wright]

"Dan'l Miller" <optikos@verizon.net> writes:

> shark8 wrote:
>> What I would like to see is an Ada compiler that can generate code
>> for a wide range of targets ••without •any• GPL restrictions on the
>> generated code••.
>
> Simon Wright wrote:
>> Pretty sure that's called GCC.
>
> No, Simon, both Chris Moore and I have both shown that the Eligible
> Compilation Process prohibits certain categories of manipulations of
> the generated code, both code-in-the-form-of-true-IR and
> code-in-the-form-of-machine-code-lifted-back-to-IR-by-e.g.-McSema.  We
> are attacking your ignoring the “any” there in shark8's laudable
> expectation/goal.

One last time, when you say "Eligible Compilation Process" you are using
a phrase contained in the GCC Runtime Library Exception, not one
contained in GPLv3.

So all this argument is about code that is originally covered by the
Exception, which includes libgcc and the full version of the Ada RTS
(and libgfortran, ...).

It seems likely that LLVM doesn't use libgcc (on macOS, it uses
libSystem, as does GCC itself, via symlinks).

Which leaves (for us) the Ada RTS.

Oh, and by the way, the Exception does not prohibit using a
GPL-compatible plugin or whatever. The McSema problem (I couldn't see,
at first glance, any discussion of a problem?) would seem to be that it
relies on a proprietary tool (IDA?).

Re: DragonEgg has been revived

[Dan'l Miller]

Let us review, where Simon Wright and Chris Moore got off-track in this thread:

First, Simon Clubley yearns for a splendid & laudable goal:

On Tuesday, May 22, 2018 at 7:29:10 AM UTC-5, Simon Clubley wrote:
> On 2018-05-21, Dan'l Miller wrote:
> >
> > Simon, how fervently do you seek an LLVM-backended GNAT?  Over on other
> > threads in recent days, I have been commenting on a proposed alternative to
> > DragonEgg.
> 
> What I would like to see is an Ada compiler that can generate code
> for a wide range of targets without any GPL restrictions on the
> generated code.

Then, Shark8 yearns for much the same splendid & laudable goal:

On Tuesday, May 22, 2018 at 5:33:29 PM UTC-5, Shark8 wrote:
> On Tuesday, May 22, 2018 at 2:17:11 PM UTC-6, Dan'l Miller wrote:
> > What is so bad about GPLv3 with Runtime Exception …
> 
> In itself, not so much -- the biggest problem with anything GCC [meaning GNAT in the context of Ada] is
> that there's all the morass of licensing surrounding it: FSF GNAT vs PGL GNAT vs AdaCore Pro GNAT
> -- all have different restrictions and capabilities and it's just a big mess -- especially for any small to
> medium business to sort out.
> 
> I want a clean break from ALL of that.

Note that implied in the context of the subtext of their implied communication, Shark8 and Simon Clubley both consider FSF GCC as licensed by GPLv3 with Runtime Library Exception v3.1 (RLEv3.1) as either certainly or perhaps ••not providing•• the splendid & laudable goal for which they both yearn.

Btw, the hair-splitting between whether it is “certainly … not providing” versus “perhaps not providing” is caught up in what Shark8 aptly calls:  “all the morass of licensing” regarding the interplay of variants of the GPLv3 stand-alone, GPLv3 with RLEv3.1, GMGPLv3, any possessor can ‘upgrade’ to later GPL editions or GPL-compatible amendments for all downstream copies, and so forth.

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 “all the morass of licensing”.  Just read all the 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].

Earlier in this thread, I proposed a harsh-rebuke of DragonEgg as a drastically-different replacement for DragonEgg.  To facilitate herding cats that such a GPLv3-with-RLEv3.1-licensed LLVM-backended compiler would actually be good enough, I posed the question:

On Tuesday, May 22, 2018 at 2:17:11 PM UTC-6, Dan'l Miller wrote:
> ••••What is so bad about GPLv3 with Runtime Exception•••• …
>
> 1) … unless a person really really wants to re-work GCC-emitted machine code as lifted to LLVM bitcode
> IR via, say, McSema as not-GPLv3ed derivative works, needing disclosure of all source code?** 
> or 
>
> 2) … unless a person really really wants to write LLVM bitcode IR out to a file to execute it on
> Sulong/GraalVM as not-GPLv3ed derivative works, needing disclosure of all source code?** 
> 
> 3) Can anyone think of any other precise downsides of GPLv3 •with• Runtime Exception? 
>
> I think all the downsides other than those 2 listed above are with GPL •without• Runtime Exception,
> correct? 

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 “notwithstanding” 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?

3) #1 & #2 above are just the first 2 examples of emerging technology in the IR domain and in the rework-the-machine-code domain. 
3.1) For example, imagine an anti-malware add-on (that, for the sake of discussion here, violates the Target Code or Eligible Compilation Process clauses of a modern-GCC-written executable or DLL) to operating systems that reworks the machine-code at link-load time to eliminate: 
3.1.1) buffer-overrun injection of worms; and/or 
3.1.2) removes viruses/etc-malware that have attached themselves to the executable or DLL and/or 
3.1.3) randomizes the layout of the machine code each link-loader-time so that malware cannot easily recognize that executable or DLL. 

Btw, while we are on the topic of re-compiling Target Code, it seems that another act on the Target Code written by FSF GCC as licensed by GPLv3-with-RLEv3.1 might be dodgy/sketchy/perhaps-not-permitted-without-providing-original-source-code-as-per-GPLv3's-terms:

4) Imagine a (closed-source EULA-licensed paid-software) machine-code-to-machine-code translator/re-compiler that coverts from one ISA-and-ABI to another drastically-different ISA-and-ABI.  The input Target Code written by FSF GCC could be considered IR to this re-compiler.  The resulting output machine-code on the drastically-different ISA and ABI could* revert under the RLEv3.1 to full-fledged GPLv3.

* if someone were to consider the input Target Code as IR, much the same as the McSema line of reasoning.

And then the Installation Information portion of the GPLv3 could come into play, unless the re-compiled drastically-different-ISA-&-ABI machine-code was installed on something “industrial” sufficiently resembling a fighter-jet cockpit or telephone switch in a central office or metal-stamping machine on a factory floor.  So that close-source re-compiler that someone paid money to EULA-license its usage must now be provided along with the source code for free to any possessor on any hardware whose “significant mode of use” is at least partially non-“industrial”.

A “morass of licensing” indeed!  Gee, the more we look into all these portions of the GPLv3 and/or its deeply-intertwined RLEv3.1, the more & more “all the morass of licensing” that is revealed.  (Thank you, Simon Wright.  Your diligence motivated me to find evermore morass.)

On Thursday, May 24, 2018 at 2:19:12 AM UTC-5, Simon Wright wrote:
> "Dan'l Miller" writes:
> 
> > On Wednesday, May 23, 2018 at 2:26:49 AM UTC-5, Simon Wright wrote: 
> >> Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> writes: 
> >> 
> >> > What I would like to see is an Ada compiler that can generate code
> >> > for a wide range of targets without any GPL restrictions on the
> >> > generated code.
> >> 
> >> Pretty sure that's called GCC. 

Here is where the fallacious theorem was postulated.  Shark8 years for “generat[ing] code for … targets without ••••••••••any•••••••••• GPL restrictions on the generated code”.   Because RLEv3.1 is nothing more than an amendment to GPLv3, and because GCC is licensed as GPLv3-with-RLEv3.1, here Shark8's “GPL” of course refers to GPLv3 with RLEv3.1 except in the above-mentioned “morass-of-licensing” ways that RLEv3.1 degenerates back down to full-fledged GPLv3 as RLEv3.1 terms are violated.  It is both GPLv3 ••and its amendments intimately intertwined with GPLv3•• that Simon Clubley and Shark8 here are yearning to have absolutely none of:  zero, zilch, empty set, naught, null, nada.  

(And yes, someone could arrive at an FSF GCC that is licensed by full-fledged GPLv3 by fully eliminating the RLEv3.1-licensed code, but, say, 99.9% of the users of FSF GCC don't do that.  Let's not contort ourselves into discussing the, say, 0.1% corner case.  Therefore, these “GPL restrictions” that Shark8 and Simon Clubley yearn to eliminate is some future non-GNAT compiler can originate in either GPLv3 proper or its intimately-intertwined-with-GPLv3 amendment:  RLEv3.1.  Both GPLv3 proper and RLE3.1.  Period.)

Hence, the fallacious theorem can be •disproven• by finding even a single counter-example “GPL[-based] restriction[] on the generated code” written by GCC.  Find more than one?  Then an even-better set of counter-examples for even stronger disproving.

Note that “generated code” there conforms to GPLv3's Object Code, which is anything not Source Code derived from the Source Code.  Note that “generated code” need not satisfy the terms of Target Code, because that is precisely what Simon Clubley and Shark8 are focusing their attention on:  all the ways that would-be Target Code isn't Target Code such that would-have-been Target Code in the RLEv3.1 degenerates down to GPLv3-licensed Object Code, whose only right to convey is granted by also providing the Source Code (and Installation Information if not installed complicatedly/obfuscatedly/cryptically on a device insufficiently “industrial”).

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?

> > Pretty sure that you haven't read the Object Code clauses in GPLv3 and
> > the Target Code clauses and Eligible Compilation Process clauses in
> > the Runtime Exception v3.1.  GPL restrictions galore on the generated
> > code there in Target Code & Eligible Compilation Process (in Runtime
> > Exception v3.1) interacting with Object Code, where Object Code is
> > •everything• not Source Code (in GPLv3).  IR would therefore be Object
> > Code due to being not Target Code and not Source Code.
> 
> You are confusing GPLv3 with the GCC Runtime Library Exception.

  No, you are confusing GPLv3-with-Runtime-License-Exception-v3.1-licensed GCC in the fallacious theorem with some other compiler (e.g., GNAT Pro GPL Community Edition) that is licensed by full-fledged GPLv3.  Don't change the subject to some other full-fledged-GPLv3-licensed compiler.  No muddying the waters; stay on the topic of the fallacious theorem that is focused entirely on FSF GCC.  (Other than the, say, 0.1% who forego all utilization of the GCC runtime and can thus avoid the RLEv3.1,) the only (remaining) way that FSF GCC is licensed by full-fledged GPLv3 is •degenerately• by not satisfying one or more logical-deduction paths through the RLEv3.1.  Such a lack of satisfaction of one or more logical-deduction paths through the RLEv3.1 causes RLEv3.1 to become a big NO-OP as an amendment to GPLv3, leaving only full-fledged GPLv3 standing unamended.

It is precisely these subtle self-eliding & self-spreading logical-deduction paths of intertwined contract-terms (such as cleverly encoded in the RLEv3.1, but also elsewhere in the not-sufficiently-industrial Installation Information and Corresponding Source Code clauses of the GPLv3-proper) that Simon Clubley and most especially Shark8 are yearning to have none of:  zero, zilch, empty set, naught, null, nada.

Hence, to disprove the fallacious theorem, all we need to do is find one real-world activity that someone can unimpededly actually do with executables or DLLs produced by, say, a closed-source EULA-licensed compiler:
1) that would have caused a lack of satisfying one or more logical-deduction paths through the RLEv3 had the executable or DLL been compiled by FSF GCC;
or
2) that would have caused some evocation of Installation Information and Corresponding Source Code clauses of GPLv3-proper had the executable or DLL been compiled by FSF GCC and linked with its runtime;
or
3) that would have evoked any other category of subtle clauses in GPLv3-proper or in any amendment to GPLv3 to force doing something with Source Code or Installation Information or Corresponding Source Code that is (or was intended to have been) licensed by either a permissive open-source license or a close-source license or lack thereof.

> GPLv3 section 1 para 4 says
> 
>    The “Corresponding Source” for a work in object code form means all
>    the source code needed to generate, install, and (for an executable
>    work) run the object code and to modify the work, including scripts
>    to control those activities. However, it does not include the work's
>    System Libraries, or general-purpose tools or generally available
>    free programs which are used unmodified in performing those
>    activities but which are not part of the work. [...]
> 
> and it's clear that the GCC compiler itself is a 'generally available
> free program'.
> 
> See also the FAQ[1]:
> 
>    [Q] Can I use GPL-covered editors such as GNU Emacs to develop
>    nonfree programs? Can I use GPL-covered tools such as GCC to compile
>    them?
>  
>    Yes, because the copyright on the editors and tools does not cover
>    the code you write. Using them does not place any restrictions,
>    legally, on the license you use for your code.
>    
> 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 “GPL[-based] restrictions on the generated code” 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 “GPL[-based] restrictions on the generated code”.  You found one.  Yea!

> 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 “GPL[-based] restrictions on the generated code” 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 “GPL[-based] restrictions on the generated code”.  But you have found two.  Yea!

Simon Wright, keep looking and digging on ways that new tech causes people to accidentally ‘step in a pile of dung’ that they didn't intend to step into via the terms of the GPLv3 and RLEv3.1.  You'll eventually find more than the 2 ways that you have already found to not satisfy
1) the logical-deduction paths through the RLEv3.1 so that, without RLEv3.1, •all• not-Source-Code* written by FSF GCC is forced to be considered Object Code under GPLv3, where that Object Code is linked with GPLv3-licensed runtime code to make (dare I say, virally) the entire resulting executable or DLL licensed under the GPLv3-proper (i.e., without RLEv3.1 because the RLEv3.1 went poof due to its chain of logical deductions eliding themselves as they are overtly constructed to do under certain conditions)
or
2) the not-sufficiently-industrial terms of the Installation Information and Corresponding Source Code clauses of the GPLv3-proper, as some new tech moves from industrial usage into the residence.

* which for the sake of argument here is (or was intended to have been!) licensed either as permissively open-source, such as via MIT/X11 license or BSD license or as closed-source

Re: DragonEgg has been revived

[Dan'l Miller]

On Thursday, May 24, 2018 at 10:38:10 AM UTC-5, Dan'l Miller wrote:
> Here is where the fallacious theorem was postulated.  Shark8 years for “generat[ing] code for … targets
> without ••••••••••any•••••••••• GPL restrictions on the generated code”.  

Btw, I meant:
Shark8 yearns for, not years for (although I am pretty sure that he has been yearning for that for years).

> Btw, while we are on the topic of re-compiling Target Code, it seems that another act on the Target Code
> written by FSF GCC as licensed by GPLv3-with-RLEv3.1 might be dodgy/sketchy/perhaps-not-permitted
> without-providing-original-source-code-as-per-GPLv3's-terms: 
>
> 4) Imagine a (closed-source EULA-licensed paid-software) machine-code-to-machine-code
> translator/re-compiler that coverts from one ISA-and-ABI to another drastically-different ISA-and-ABI.
> The input Target Code written by FSF GCC could be considered IR to this re-compiler.  The resulting
> output machine-code on the drastically-different ISA and ABI could* revert under the RLEv3.1 to
> full-fledged GPLv3. 
>
> * if someone were to consider the input Target Code as IR, much the same as the McSema line of
> reasoning. 
>
> And then the Installation Information portion of the GPLv3 could come into play, unless the re-compiled
> drastically-different-ISA-&-ABI machine-code was installed on something “industrial” sufficiently
> resembling a fighter-jet cockpit or telephone switch in a central office or metal-stamping machine on a
> factory floor.  So that close-source re-compiler that someone paid money to EULA-license its usage
> must now be provided along with the source code for free to any possessor on any hardware whose
> “significant mode of use” is at least partially non-“industrial”. 

Oh great.  Now I have convinced myself that there is enough sketchiness/dodginess in this vicinity to question whether Apple's forthcoming App-Store LLVM-bitcode-IR recompiler wouldn't satisfy any one or more required terms of any GPLv3-with-RLEv3.1-licensed compiler (FSF or otherwise) in such as 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 Corresponding Source Code on a “consumer” device that is not-“sufficiently” “industrial”, where that consumer device (e.g., an Apple iDevice) might be a User Product in the terms of GPLv3.
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 runtime) could conceivably be enough for Apple to reject such apps from the App Store, so that Apple need not satisfy #2 above.

https://thenextweb.com/apple/2015/06/17/apples-biggest-developer-news-at-wwdc-that-nobodys-talking-about-bitcode

Apparently Apple is either working on a McSema-esque technology or would require the app to be (also?) provided in the form of LLVM-bitcode-IR (in addition? to ARM-processor machine-code) at the time of submission to the App Store for approval.

Dang it.  The possibility of sketchiness/dodginess in this vicinity of FSF GCC licensing (regarding IR tools outside of my control, downstream from me complicating my life upstream) erodes part of my motivation for GELI as proposed earlier in a branch of this thread

GELI project:
(i.e., the GPLv3-with-RLEv3.1-licensed GNAT-with-LLVM-&-Polly-backend), where GELI would be an LSP peer of the GIGI tree-transducer in FSF GNAT.  When an “llvm-”-prefixed target name is on the GNAT command line, GELI would shunt* off to LLVM-world from the point of the Ada iterator/cursor walking GNAT's fully-semantically-adorned Ada-IR tree.  (Non-“llvm-”-prefixed targets on the GNAT command line would utilize the traditional GIGI-GENERIC-highGIMPLE-lowGIMPLE-RTL backend.)

* all within one GCC executable without writing out any IR to files, so as to comply with my stricter interpretation of the terms of RLEv3.1 intertwined with the terms of GPLv3.

One of my prime motivators for GELI and its GPLv3-with-RLEv3.1-licensed LLVM-backended FSF GNAT was to utilize Ada2012 to write iDevice apps for submission to the App Store (since on-nonjailbroken-iDevice debugging by gdb is disallowed nowadays due to gdb's lack of codesigning after Apple's switchover to LLVM-world toolchain).

Dang it.   Hmmmmm.   Must rethink how to help Byron's generation of LLVM bitcode IR arrive sooner.

Re: DragonEgg has been revived

[Simon Wright]

"Dan'l Miller" <optikos@verizon.net> writes:

> Let us review, where Simon Wright and Chris Moore got off-track in
> this thread:

You review if you want to. You're still wrong.

> 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 “all the morass of licensing”.  Just read all the 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].

Now we're getting insulting.

> 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 “notwithstanding” 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?

This is relevant to target code derived from source subject to the
RLE. It has nothing to do with target code derived from source under
some other license, eg BSD 3-clause.

>                 GCC is licensed as GPLv3-with-RLEv3.1

No, it's not. 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. 

> 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?

No.

>> [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 “GPL[-based] restrictions on the generated
> code” 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 “GPL[-based] restrictions on
> the generated code”.  You found one.  Yea!

WTF?

>> 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 “GPL[-based] restrictions on the
> generated code” 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
> “GPL[-based] restrictions on the generated code”.  But you have found
> two.  Yea!

Again I say, WTF?

Re: DragonEgg has been revived

[Lucretia]

On Thursday, 24 May 2018 17:44:22 UTC+1, Dan'l Miller  wrote:

> Oh great.  Now I have convinced myself that there is enough sketchiness/dodginess in this vicinity to question whether Apple's forthcoming App-Store LLVM-bitcode-IR recompiler wouldn't satisfy any one or more required terms of any GPLv3-with-RLEv3.1-licensed compiler (FSF or otherwise) in such as 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 Corresponding Source Code on a “consumer” device that is not-“sufficiently” “industrial”, where that consumer device (e.g., an Apple iDevice) might be a User Product in the terms of GPLv3.
> 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 runtime) could conceivably be enough for Apple to reject such apps from the App Store, so that Apple need not satisfy #2 above.
> 
> https://thenextweb.com/apple/2015/06/17/apples-biggest-developer-news-at-wwdc-that-nobodys-talking-about-bitcode
> 
> Apparently Apple is either working on a McSema-esque technology or would require the app to be (also?) provided in the form of LLVM-bitcode-IR (in addition? to ARM-processor machine-code) at the time of submission to the App Store for approval.

They're not doing anything of the sort. They used to use fat binaries containing both m68k and powerpc, then both 32/64 bit x86. For this they'll use LLVM bitcode, which is IR compiled to LLVM's bitcode, something that's been in LLVM since it started. One of the major pros about that bitcode is that you can then do aggressive linking and stripping before installation.

We talked about a similar mechanism for a platform neutral binary for AmigaOS NG BITD, but that never happened, well it did sort of with Tao, but it never got anywhere and Tao went out of business.

Re: DragonEgg has been revived

[Dan'l Miller]

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 “all the morass of licensing”.  Just read all the 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].
> 
> Now we're getting insulting.

I keep saying that this is a reading-comprehension problem and logical-deduction problem overtly crafted into (and throughout) the language of the GPLv3 and RLEv3.  I will request reading-comprehension & logical deduction again below (my own included, help me out: quote chapter & verse from statutory 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 “notwithstanding” 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?
> 
> 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 statutes in USCode, copyright treaties to which the USA is a signatory} does it overtly clearly say anything even remotely in the ballpark of that sentence 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 and 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 factually incorrect.

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 definition and cascading-ramification usage in GPLv3 or RLEv3.1, so that reading comprehension 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 defined in either GPLv3 or RLEv3.1 when those 2 documents are read with my app 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 defined in either GPLv3 or RLEv3.1 when those 2 documents are read with FSF GCC itself in mind (as reading comprehension).

1) The G-Source-Code term in GPLv3 initially refers to the source code of FSF GCC as itself licensed under GPLv3.

2) But then when my app's source code causes (even indirectly) the invocation 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) transformed for the time being into M-Object-Code as the contractual-term defined in GPLv3.

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 GPLv3.

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 (which 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-Compilation-Process.

7) RLEv3.1's M-Elligible-Compilation-Process is predicated on M-Eligible-Compilation-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 hardware-processor machine-code (or hardware-processor assembly language thereof) and then merely link-loaded and then merely executed.

A10) The logical-deduction chain of “if M-Target-Code satisfied” begets “if M-Compilation-Process satisfied” begets “if M-Eligible-Compilation-Process satisfied” begets “if RLEv3.1 satisfied” then successfully recategorized M-Object-Code into mere M-Target-Code, dispensing with any need to provide source code or provide 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-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 special permissions in the RTEv3.1.  Whew!  My app dodged that bullet.

versus

https://thenextweb.com/apple/2015/06/17/apples-biggest-developer-news-at-wwdc-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 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 processors soldered into iDevices.

B9) Nonjailbroken iDevices are what is called a walled garden, where the only apps (other than development mode, enterprise side-loading, and invitation-only testing) that are permitted to be downloadable to the iDevice are those 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 overtly requiring LLVM bitcode IR files at time of submission or via a McSema-esque technology.  The following steps don't really care which option Apple takes, 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 licensed via GPLv3-with-RLEv3.1), the “notwithstanding” 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 “notwithstanding” works in legalese:  literally if the 2nd sentence is satisfied, 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 within.

B12) Oopsies, in B11, M-Target-Code failed to get defined, due to the IR nuclear bomb that got dropped.  Where the absence of M-Target-Code occurs downstream, let's put M-PhthphthphTC downstream so it is clear that M-Target-Code is absent.

B13) In RTEv3.1, M-Compilation-Process needs M-Target-Code to have been successfully defined.  But instead M-PhthphthphTC is all that came out of B11/B12.  So now, M-Compilation-Process fails to get defined.  Where the absence of M-Compilation-Process occurs downstream, let's put M-PhthphthphCP downstream 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 came out of B13.  Where the absence of M-Eligible-Compilation-Process occurs downstream, let's put M-PhthphthphECP downstream so it is clear that M-Eligible-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 successfully defined.  But instead of M-PhthphthphECP is all that came out of 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 GPLv3 reading onto my app.

B16) 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.

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 installed behind not-jail-broken logistical barriers that would require M-Installation-Information and M-Corresponding-Source-Code to be provided.

B18) I don't have M-Installation-Information and M-Corresponding-Source, but Apple does.

B19) Apple would be wise to side-step the B17's demand for providing M-Installation-Information and M-Corresponding-Source-Code by prohibiting apps built by GPLv3-with-RLEv3.1-licensed compiler processes.

B20) 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-compiled apps and the walled-garden into which they are being installed all being open-source as per the GPLv3 and its RLEv3.1 amendment).


> >                 GCC is licensed as GPLv3-with-RLEv3.1
> 
> 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 •compilation process•?  Focus on “compilation process” as a whole enchilada (as RLEv3.1 does) instead of on ‘compiler’ versus ‘runtime’ compartmentally.

  (sigh #2) The RLEv3.1 under which the runtime is conveyed is intimately intertwined with the GPLv3 license under which the compiler proper is conveyed (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 above, there is a natural complex interplay (not unlike a ping-pong game or pendulum 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 those 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 successfully-defined nonviral M-Target-Code instead. 

* 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 attempt to define M-Target-Code due in turn to RLEv3.1's “notwithstanding” clause dropping its nuclear bomb, scorched-earthing all the attempts 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. 

I think that my walk-through above is quite lucid at explaining step-by-step what occurs as the crank-handle of the language is mechanically turned, as 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 factually incorrect somewhere somehow.  That small business's mileage might vary in various jurisdictions of differing systems of law that somehow cause a different 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 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 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 self-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?
> 
> No.

Then read the walk-through above, while looking up each G- and M- contractual-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 “GPL[-based] restrictions on the generated
> > code” 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 “GPL[-based] restrictions on
> > the generated code”.  You found one.  Yea!
> 
> WTF?

That is what it feels like to have a “Eureka!” 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 “GPL[-based] restrictions on the
> > generated code” 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
> > “GPL[-based] restrictions on the generated code”.  But you have found
> > two.  Yea!
> 
> Again I say, WTF?

And another “Eureka!” moment of the genesis of understanding.

Re: DragonEgg has been revived

[G. B.]

Dan'l Miller <optikos@verizon.net> wrote:

> 3) #1 & #2 above are just the first 2 examples of emerging technology in
> the IR domain and in the rework-the-machine-code domain. 
> 3.1) For example, imagine an anti-malware add-on (that, for the sake of
> discussion here, violates the Target Code or Eligible Compilation Process
> clauses of a modern-GCC-written executable or DLL) to operating systems
> that reworks the machine-code at link-load time to eliminate: 
> 3.1.1) buffer-overrun injection of worms; and/or 
> 3.1.2) removes viruses/etc-malware that have attached themselves to the
> executable or DLL and/or 
> 3.1.3) randomizes the layout of the machine code each link-loader-time so
> that malware cannot easily recognize that executable or DLL. 


Or, remove redundant code like that
which performs license management.

Re: DragonEgg has been revived

[Dan'l Miller]

fixing distracting typos:
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 “all the morass of licensing”.  Just read all the 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]. 
> 
> Now we're getting insulting. 

I keep saying that this is entirely nothing more than a reading-comprehension problem and logical-deduction problem overtly cleverly crafted into (and throughout) the language of the GPLv3 and RLEv3.  I will request reading-comprehension & logical deduction again below (my own included*)

* Please help me out: quote chapter & verse from statutory 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 “notwithstanding” 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? 
> 
> 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 statutes in USCode, copyright treaties to which the USA is a signatory} does it overtly clearly say anything even remotely in the ballpark of that sentence 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 and 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 factually incorrect. 

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 definition and cascading-ramification usage in GPLv3 or RLEv3.1, so that reading comprehension is emphasized.  Note that there exist 2 readings of the GPLv3 and its RLEv3.1:
a) once for GCC [henceforce G- prefix on the contractual-terms] and
b) 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 defined in either GPLv3 or RLEv3.1 when those 2 documents are read 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 both 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 documents 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 onto GCC or its runtime.

1) The G-Source-Code term in GPLv3 initially-as-bootstrap refers to the source code of FSF GCC as itself licensed under GPLv3.   The G-Object-Code term 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-Source-Code.  The object code of GCC's runtime is also G-Object-Code back when GCC was built.

2) But then when my app's source code causes (even indirectly) the invocation 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) transformed for the time being into M-Object-Code as the contractual-term defined in GPLv3. 

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 GPLv3. 

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 (which just became M-Source-Code as my app reads onto GPLv3-with-RLEv3.1) or 

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-Compilation-Process. 

7) RLEv3.1's M-Elligible-Compilation-Process is predicated on M-Eligible-Compilation-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 hardware-processor machine-code (or hardware-processor assembly language thereof) and then merely link-loaded and then merely executed. 

A10) The logical-deduction chain of
“if M-Target-Code satisfied”
begets
“if M-Compilation-Process satisfied”
begets
“if M-Eligible-Compilation-Process satisfied”
begets
“if RLEv3.1 satisfied”
then has successfully recategorized (viral) M-Object-Code into mere (nonviral) M-Target-Code, dispensing with any need to provide source code or provide 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-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 special permissions granted by the RTEv3.1.  Whew!  My app dodged that bullet. 

versus 

https://thenextweb.com/apple/2015/06/17/apples-biggest-developer-news-at-wwdc-that-nobodys-talking-about-bitcode 

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 processors soldered into iDevices. 

B10) Nonjailbroken iDevices are what is called a walled garden, where the only apps (other than development mode, enterprise side-loading, and invitation-only testing) that are permitted to be downloadable to the iDevice are those that have been approved by Apple for conveyance in the App Store. 

B11) 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 overtly requiring LLVM bitcode IR files at time of submission or via a McSema-esque technology.  The following steps don't really care which option Apple takes, but let's write the wording up for the former. 

B12) 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 licensed via GPLv3-with-RLEv3.1), the “notwithstanding” 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 “notwithstanding” works in legalese:  literally if the 2nd sentence is satisfied, 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 within, literally leaving the attempted definition of M-Target-Code •with• all attempted definitions •not• •standing•**, blown to smithereens by the dropping of the “notwithstanding” nuclear-bomb regarding IR. 

** hence the word: notwithstanding

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 downstream, let's put M-PhthphthphTC downstream so it is clear that M-Target-Code is absent. 

B14) In RLEv3.1, M-Compilation-Process needs M-Target-Code to have been successfully defined.  But instead M-PhthphthphTC is all that came out of B12/B13.  So now, M-Compilation-Process fails to get defined.  Where the absence of M-Compilation-Process occurs downstream, let's put M-PhthphthphCP downstream so it is clear that M-Compilation-Process is absent. 

B15) In RLEv3.1, M-Eligible-Compilation-Process needs M-Compilation-Process to have been successfully defined.  But instead M-PhthphthphCP is all that came out of B14.  Where the absence of M-Eligible-Compilation-Process occurs downstream, let's put M-PhthphthphECP downstream so it is clear that M-Eligible-Compilation-Process is absent. 

B16) RLEv3.1 grants its special magic of M-Target-Code in RLEv3.1 eclipsing M-Object-Code in GPLv3 if and only if M-Eligible-Compilation-Process would 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 carefully build up collapses and no special magic occurs:  M-Object-Code stays M-Object-Code; M-ObjectCode's and M-Source-Code's lifetimes live on for my app, over in GPLv3 when reading GPLv3 onto my app. 

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. 

B18) 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 installed behind not-jail-broken logistical barriers that would require M-Installation-Information and M-Corresponding-Source-Code to be provided. 

B19) I don't possess M-Installation-Information and M-Corresponding-Source, but Apple does. 

B20) Apple would be wise to side-step the B18's demand for providing M-Installation-Information and M-Corresponding-Source-Code by prohibiting apps built by GPLv3-with-RLEv3.1-licensed compiler processes. 

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-compiled 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). 

The outcome of B9 through B21 are one of the counterexamples to the fallacious 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 theorem.  It is disproven by finding at least one counterexample.  Q.E.D.

> >                 GCC is licensed as GPLv3-with-RLEv3.1 
> 
> 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 •compilation process•?  Focus on “compilation process” as a whole enchilada (as RLEv3.1 does) instead of on ‘compiler’ versus ‘runtime’ compartmentally. 

  (sigh #2) The RLEv3.1 under which the runtime is conveyed is intimately intertwined with the GPLv3 license under which the compiler proper is conveyed (except 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 above, there is a natural complex interplay (not unlike a ping-pong game or pendulum swinging) between not only GCC's GPLv3 and GCC runtime's RLEv3.1 when read onto GCC from GCC's standpoint, but also between those license documents reading onto GCC's/runtime and the dragged-in reading of those documents onto my app for RLEv3.1 to enact its magic of the eclipse*** of the viral M-Object-Code by the successfully-defined nonviral M-Target-Code instead. 

*** eclipsing in the situation of garden-variety execution of M-Target-Code, but not eclipsing in the situation of App Store's re-compilation of M-Object-Code due to the failure of the attempt to define M-Target-Code due in turn to RLEv3.1's “notwithstanding” clause dropping its nuclear bomb, scorched-earthing all the attempts 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. 

I think that my walk-through above is quite lucid at explaining step-by-step what occurs as the crank-handle of the language is mechanically turned, as 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 factually incorrect somewhere somehow.  That small business's mileage might vary in various jurisdictions of differing systems of law that somehow cause a different 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 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 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 self-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? 
> 
> No. 

Then read the walk-through above, while looking up each G- and M- contractual-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 “GPL[-based] restrictions on the generated 
> > code” 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 “GPL[-based] restrictions on 
> > the generated code”.  You found one.  Yea! 
> 
> WTF? 

That is what it feels like to have a “Eureka!” 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 “GPL[-based] restrictions on the 
> > generated code” 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 
> > “GPL[-based] restrictions on the generated code”.  But you have found 
> > two.  Yea! 
> 
> Again I say, WTF? 

And another “Eureka!” moment of the genesis of understanding.

Re: DragonEgg has been revived

[Dan'l Miller]

fixing distracting typos & buggy greying out of quoted replies: 
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 “all the morass of licensing”.  Just read all the 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]. 
> 
> Now we're getting insulting. 

I keep saying that this is entirely nothing more than a reading-comprehension problem and logical-deduction problem overtly cleverly crafted into (and throughout) the language of the GPLv3 and RLEv3.  I  will request reading-comprehension & logical deduction again below (my own included*) 

* Please help me out: quote chapter & verse from statutory 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 “notwithstanding” 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? 
> 
> 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 statutes in USCode, copyright treaties to which the USA is a signatory} does it overtly clearly say anything even remotely in the ballpark of that sentence 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 and 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 factually incorrect. 

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 definition and cascading-ramification usage in GPLv3 or RLEv3.1, so that reading comprehension is emphasized.  Note that there exist 2 readings of the GPLv3 and its RLEv3.1: 
a) once for GCC [henceforce G- prefix on the contractual-terms] and 
b) 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 defined in either GPLv3 or RLEv3.1 when those 2 documents are read 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 both 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 documents 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 onto GCC or its runtime. 

1) The G-Source-Code term in GPLv3 initially-as-bootstrap refers to the source code of FSF GCC as itself licensed under GPLv3.   The G-Object-Code term 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-Source-Code.  The object code of GCC's runtime is also G-Object-Code back when GCC was built. 

2) But then when my app's source code causes (even indirectly) the invocation 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) transformed for the time being into M-Object-Code as the contractual-term defined in GPLv3. 

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 GPLv3. 

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 (which just became M-Source-Code as my app reads onto GPLv3-with-RLEv3.1) or 

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-Compilation-Process. 

7) RLEv3.1's M-Elligible-Compilation-Process is predicated on M-Eligible-Compilation-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 hardware-processor machine-code (or hardware-processor assembly language thereof) and then merely link-loaded and then merely executed. 

A10) The logical-deduction chain of 
“if M-Target-Code satisfied” 
begets 
“if M-Compilation-Process satisfied” 
begets 
“if M-Eligible-Compilation-Process satisfied” 
begets 
“if RLEv3.1 satisfied” 
then has successfully recategorized (viral) M-Object-Code into mere (nonviral) M-Target-Code, dispensing with any need to provide source code or provide 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-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 special permissions granted by the RTEv3.1.  Whew!  My app dodged that bullet. 

versus 

https://thenextweb.com/apple/2015/06/17/apples-biggest-developer-news-at-wwdc-that-nobodys-talking-about-bitcode 

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 processors soldered into iDevices. 

B10) Nonjailbroken iDevices are what is called a walled garden, where the only apps (other than development mode, enterprise side-loading, and invitation-only testing) that are permitted to be downloadable to the iDevice are those that have been approved by Apple for conveyance in the App Store. 

B11) 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 overtly requiring LLVM bitcode IR files at time of submission or via a McSema-esque technology.  The following steps don't really care which option Apple takes, but let's write the wording up for the former. 

B12) 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 licensed via GPLv3-with-RLEv3.1), the “notwithstanding” 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 “notwithstanding” works in legalese:  literally if the 2nd sentence is satisfied, 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 within, literally leaving the attempted definition of M-Target-Code •with• all attempted definitions •not• •standing•**, blown to smithereens by the dropping of the “notwithstanding” nuclear-bomb regarding IR. 

** hence the word: notwithstanding 

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 downstream, let's put M-PhthphthphTC downstream so it is clear that M-Target-Code is absent. 

B14) In RLEv3.1, M-Compilation-Process needs M-Target-Code to have been successfully defined.  But instead M-PhthphthphTC is all that came out of B12/B13.  So now, M-Compilation-Process fails to get defined.  Where the absence of M-Compilation-Process occurs downstream, let's put M-PhthphthphCP downstream so it is clear that M-Compilation-Process is absent. 

B15) In RLEv3.1, M-Eligible-Compilation-Process needs M-Compilation-Process to have been successfully defined.  But instead M-PhthphthphCP is all that came out of B14.  Where the absence of M-Eligible-Compilation-Process occurs downstream, let's put M-PhthphthphECP downstream so it is clear that M-Eligible-Compilation-Process is absent. 

B16) RLEv3.1 grants its special magic of M-Target-Code in RLEv3.1 eclipsing M-Object-Code in GPLv3 if and only if M-Eligible-Compilation-Process would 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 carefully build up collapses and no special magic occurs:  M-Object-Code stays M-Object-Code; M-ObjectCode's and M-Source-Code's lifetimes live on for my app, over in GPLv3 when reading GPLv3 onto my app. 

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. 

B18) 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 installed behind not-jail-broken logistical barriers that would require M-Installation-Information and M-Corresponding-Source-Code to be provided. 

B19) I don't possess M-Installation-Information and M-Corresponding-Source, but Apple does. 

B20) Apple would be wise to side-step the B18's demand for providing M-Installation-Information and M-Corresponding-Source-Code by prohibiting apps built by GPLv3-with-RLEv3.1-licensed compiler processes. 

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-compiled 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). 

The outcome of B9 through B21 are one of the counterexamples to the fallacious 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 theorem.  It is disproven by finding at least one counterexample.  Q.E.D. 

> >                 GCC is licensed as GPLv3-with-RLEv3.1 
> 
> 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 •compilation process•?  Focus on “compilation process” as a whole enchilada (as RLEv3.1 does) instead of on ‘compiler’ versus ‘runtime’ compartmentally. 

  (sigh #2) The RLEv3.1 under which the runtime is conveyed is intimately intertwined with the GPLv3 license under which the compiler proper is conveyed (except 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 above, there is a natural complex interplay (not unlike a ping-pong game or pendulum swinging) between not only GCC's GPLv3 and GCC runtime's RLEv3.1 when read onto GCC from GCC's standpoint, but also between those license documents reading onto GCC's/runtime and the dragged-in reading of those documents onto my app for RLEv3.1 to enact its magic of the eclipse*** of the viral M-Object-Code by the successfully-defined nonviral M-Target-Code instead. 

*** eclipsing in the situation of garden-variety execution of M-Target-Code, but not eclipsing in the situation of App Store's re-compilation of M-Object-Code due to the failure of the attempt to define M-Target-Code due in turn to RLEv3.1's “notwithstanding” clause dropping its nuclear bomb, scorched-earthing all the attempts 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. 

I think that my walk-through above is quite lucid at explaining step-by-step what occurs as the crank-handle of the language is mechanically turned, as 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 factually incorrect somewhere somehow.  That small business's mileage might vary in various jurisdictions of differing systems of law that somehow cause a different 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 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 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 self-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? 
> 
> No. 

Then read the walk-through above, while looking up each G- and M- contractual-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 “GPL[-based] restrictions on the generated 
> > code” 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 “GPL[-based] restrictions on 
> > the generated code”.  You found one.  Yea! 
> 
> WTF? 

That is what it feels like to have a “Eureka!” 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 “GPL[-based] restrictions on the 
> > generated code” 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 
> > “GPL[-based] restrictions on the generated code”.  But you have found 
> > two.  Yea! 
> 
> Again I say, WTF? 

And another “Eureka!” moment of the genesis of understanding.

Re: DragonEgg has been revived

[Dan'l Miller]

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: 
> 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 “all the morass of licensing”.  Just read all the 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]. 
> > 
> > Now we're getting insulting. 
> 
> I keep saying that this is entirely nothing more than a reading-comprehension problem and logical-deduction problem overtly cleverly crafted into (and throughout) the language of the GPLv3 and RLEv3.  I  will request reading-comprehension & logical deduction again below (my own included*) 
> 
> * Please help me out: quote chapter & verse from statutory 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 “notwithstanding” 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? 
> > 
> > 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 statutes in USCode, copyright treaties to which the USA is a signatory} does it overtly clearly say anything even remotely in the ballpark of that sentence 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 and 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 factually incorrect. 
> 
> 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 definition and cascading-ramification usage in GPLv3 or RLEv3.1, so that reading comprehension is emphasized.  Note that there exist 2 readings of the GPLv3 and its RLEv3.1: 
> a) once for GCC [henceforce G- prefix on the contractual-terms] and 
> b) 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 defined in either GPLv3 or RLEv3.1 when those 2 documents are read 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 both 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 documents 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 onto GCC or its runtime. 
> 
> 1) The G-Source-Code term in GPLv3 initially-as-bootstrap refers to the source code of FSF GCC as itself licensed under GPLv3.   The G-Object-Code term 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-Source-Code.  The object code of GCC's runtime is also G-Object-Code back when GCC was built. 
> 
> 2) But then when my app's source code causes (even indirectly) the invocation 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) transformed for the time being into M-Object-Code as the contractual-term defined in GPLv3. 
> 
> 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 GPLv3. 
> 
> 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 (which just became M-Source-Code as my app reads onto GPLv3-with-RLEv3.1) or 
> 
> 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-Compilation-Process. 
> 
> 7) RLEv3.1's M-Elligible-Compilation-Process is predicated on M-Eligible-Compilation-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 hardware-processor machine-code (or hardware-processor assembly language thereof) and then merely link-loaded and then merely executed. 
> 
> A10) The logical-deduction chain of 
> “if M-Target-Code satisfied” 
> begets 
> “if M-Compilation-Process satisfied” 
> begets 
> “if M-Eligible-Compilation-Process satisfied” 
> begets 
> “if RLEv3.1 satisfied” 
> then has successfully recategorized (viral) M-Object-Code into mere (nonviral) M-Target-Code, dispensing with any need to provide source code or provide 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-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 special permissions granted by the RTEv3.1.  Whew!  My app dodged that bullet. 
> 
> versus 
> 
> https://thenextweb.com/apple/2015/06/17/apples-biggest-developer-news-at-wwdc-that-nobodys-talking-about-bitcode 
> 
> 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 processors soldered into iDevices. 
> 
> B10) Nonjailbroken iDevices are what is called a walled garden, where the only apps (other than development mode, enterprise side-loading, and invitation-only testing) that are permitted to be downloadable to the iDevice are those that have been approved by Apple for conveyance in the App Store. 
> 
> B11) 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 overtly requiring LLVM bitcode IR files at time of submission or via a McSema-esque technology.  The following steps don't really care which option Apple takes, but let's write the wording up for the former. 
> 
> B12) 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 licensed via GPLv3-with-RLEv3.1), the “notwithstanding” 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 “notwithstanding” works in legalese:  literally if the 2nd sentence is satisfied, 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 within, literally leaving the attempted definition of M-Target-Code •with• all attempted definitions •not• •standing•**, blown to smithereens by the dropping of the “notwithstanding” nuclear-bomb regarding IR. 
> 
> ** hence the word: notwithstanding 
> 
> 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 downstream, let's put M-PhthphthphTC downstream so it is clear that M-Target-Code is absent. 
> 
> B14) In RLEv3.1, M-Compilation-Process needs M-Target-Code to have been successfully defined.  But instead M-PhthphthphTC is all that came out of B12/B13.  So now, M-Compilation-Process fails to get defined.  Where the absence of M-Compilation-Process occurs downstream, let's put M-PhthphthphCP downstream so it is clear that M-Compilation-Process is absent. 
> 
> B15) In RLEv3.1, M-Eligible-Compilation-Process needs M-Compilation-Process to have been successfully defined.  But instead M-PhthphthphCP is all that came out of B14.  Where the absence of M-Eligible-Compilation-Process occurs downstream, let's put M-PhthphthphECP downstream so it is clear that M-Eligible-Compilation-Process is absent. 
> 
> B16) RLEv3.1 grants its special magic of M-Target-Code in RLEv3.1 eclipsing M-Object-Code in GPLv3 if and only if M-Eligible-Compilation-Process would 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 carefully build up collapses and no special magic occurs:  M-Object-Code stays M-Object-Code; M-ObjectCode's and M-Source-Code's lifetimes live on for my app, over in GPLv3 when reading GPLv3 onto my app. 
> 
> 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. 
> 
> B18) 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 installed behind not-jail-broken logistical barriers that would require M-Installation-Information and M-Corresponding-Source-Code to be provided. 
> 
> B19) I don't possess M-Installation-Information and M-Corresponding-Source, but Apple does. 
> 
> B20) Apple would be wise to side-step the B18's demand for providing M-Installation-Information and M-Corresponding-Source-Code by prohibiting apps built by GPLv3-with-RLEv3.1-licensed compiler processes. 
> 
> 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-compiled 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). 
> 
> The outcome of B9 through B21 are one of the counterexamples to the fallacious 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 theorem.  It is disproven by finding at least one counterexample.  Q.E.D. 
> 
> > >                 GCC is licensed as GPLv3-with-RLEv3.1 
> > 
> > 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 •compilation process•?  Focus on “compilation process” as a whole enchilada (as RLEv3.1 does) instead of on ‘compiler’ versus ‘runtime’ compartmentally. 
> 
>   (sigh #2) The RLEv3.1 under which the runtime is conveyed is intimately intertwined with the GPLv3 license under which the compiler proper is conveyed (except 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 above, there is a natural complex interplay (not unlike a ping-pong game or pendulum swinging) between not only GCC's GPLv3 and GCC runtime's RLEv3.1 when read onto GCC from GCC's standpoint, but also between those license documents reading onto GCC's/runtime and the dragged-in reading of those documents onto my app for RLEv3.1 to enact its magic of the eclipse*** of the viral M-Object-Code by the successfully-defined nonviral M-Target-Code instead. 
> 
> *** eclipsing in the situation of garden-variety execution of M-Target-Code, but not eclipsing in the situation of App Store's re-compilation of M-Object-Code due to the failure of the attempt to define M-Target-Code due in turn to RLEv3.1's “notwithstanding” clause dropping its nuclear bomb, scorched-earthing all the attempts 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. 
> 
> I think that my walk-through above is quite lucid at explaining step-by-step what occurs as the crank-handle of the language is mechanically turned, as 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 factually incorrect somewhere somehow.  That small business's mileage might vary in various jurisdictions of differing systems of law that somehow cause a different 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 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 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 self-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? 
> > 
> > No. 
> 
> Then read the walk-through above, while looking up each G- and M- contractual-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 “GPL[-based] restrictions on the generated 
> > > code” 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 “GPL[-based] restrictions on 
> > > the generated code”.  You found one.  Yea! 
> > 
> > WTF? 
> 
> That is what it feels like to have a “Eureka!” 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 “GPL[-based] restrictions on the 
> > > generated code” 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 
> > > “GPL[-based] restrictions on the generated code”.  But you have found 
> > > two.  Yea! 
> > 
> > Again I say, WTF? 
> 
> And another “Eureka!” moment of the genesis of understanding.

Great.  Now I greyed my whole reply out as a quote.  Unhide the walkthrough, please, if viewing via the Google Groups WWW page.

Re: DragonEgg has been revived

[Chris M Moore]

On 24/05/2018 20:26, Dan'l Miller wrote:
> 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 “all the morass of licensing”.  Just read all the 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].
>>
>> Now we're getting insulting.

I think condescending is more accurate.  He used the phrase "Dear boy" 
on me earlier.  For the record Dan'l, I'm 51 and a half.

> I keep saying that this is a reading-comprehension problem and logical-deduction problem overtly crafted into (and throughout) the language of the GPLv3 and RLEv3.  I will request reading-comprehension & logical deduction again below (my own included, help me out: quote chapter & verse from statutory 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 saw an interesting quote on lwn today: "I don't see myself ever 
winning an argument with a robot who knows better, and is implemented in 
proprietary software that I cannot adjust. (Pete Zaitcev)"  Made me 
wonder...

>>> 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 “notwithstanding” 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?
>>
>> 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 statutes in USCode, copyright treaties to which the USA is a signatory} does it overtly clearly say anything even remotely in the ballpark of that sentence 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 and parrot what other people say doesn't count; I want original sources and seminal references, such as quotations from members of that set above.)

I mean who uses "overtly clearly"?

>> 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.

Imagine for a moment that you're Einstein.  Let's do a thought 
experiment!  Say you use McSema on Microsoft Office binaries, fiddle 
with the source code generated to improve it and then sell the resulting 
llvm compiled office suite over the internet.  Do you think Microsoft 
will sue you or not?

> Btw, these 2 sentences are where I strongly believe that you are again factually incorrect.
> 
> Let's walk step by step, but for brevity of writing here,

<snort> I'm glad I wasn't drinking my tea.

  let all readers pause at each capitalized contractual-term below to go 
read their definition and cascading-ramification usage in GPLv3 or 
RLEv3.1, so that reading comprehension 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 defined in 
either GPLv3 or RLEv3.1 when those 2 documents are read with my app 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 
defined in either GPLv3 or RLEv3.1 when those 2 documents are read with 
FSF GCC itself in mind (as reading comprehension).
> 
> 1) The G-Source-Code term in GPLv3 initially refers to the source code of FSF GCC as itself licensed under GPLv3.
> 
> 2) But then when my app's source code causes (even indirectly) the invocation 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).

Let's assume a best-case with-the-runtime-exception scenario.

> 3) #2's linkage causes my app's object code to be (dare I say, virally) transformed for the time being into M-Object-Code as the contractual-term defined in GPLv3.

There's no transformation.  It's your code, under your license.  From 
the RLE:

"When you use GCC to compile a program, GCC may combine portions of 
certain GCC header files and runtime libraries with the compiled 
program. The purpose of this Exception is to allow compilation of 
non-GPL (including proprietary) programs to use, in this way, the header 
files and runtime libraries covered by this Exception."

> 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 GPLv3.

No.

<big snip>
Night-shift out.

-- 
sig pending (since 1995)

Re: DragonEgg has been revived

[Dan'l Miller]

On Thursday, May 24, 2018 at 4:59:43 PM UTC-5, Chris M Moore wrote:
> I think condescending is more accurate.  He used the phrase "Dear boy" 
> on me earlier.  For the record Dan'l, I'm 51 and a half.

I did no such thing!  Ever in my life!  I said "Attaboy" in genuine congratulations earlier in this thread.  If "dear boy" ever appeared in one of my postings or comments, it would had to have been autocorrect messing up some other wording.

  Please provide the URL to that c.l.a posting.

Re: DragonEgg has been revived

[Dan'l Miller]

On Thursday, May 24, 2018 at 5:15:05 PM UTC-5, Dan'l Miller wrote:
> On Thursday, May 24, 2018 at 4:59:43 PM UTC-5, Chris M Moore wrote:
> > I think condescending is more accurate.  He used the phrase "Dear boy" 
> > on me earlier.  For the record Dan'l, I'm 51 and a half.
> 
> I did no such thing!  Ever in my life!  I said "Attaboy" in genuine congratulations earlier in this thread.  If "dear boy" ever appeared in one of my postings or comments, it would had to have been autocorrect messing up some other wording.
> 
>   Please provide the URL to that c.l.a posting.

Besides, ‘my dear boy’ would be the British vernacular, as a variant of the older era ‘my dear chap’.  (I am American through & through.)  I think that you have me confused with someone here on c.l.a who is British.  I don't use the word boy to refer to anyone older than about 12 years old, and then not as a form of address.

Re: DragonEgg has been revived

[Dan'l Miller]

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:
> 
> > Oh great.  Now I have convinced myself that there is enough sketchiness/dodginess in this vicinity to question whether Apple's forthcoming App-Store LLVM-bitcode-IR recompiler wouldn't satisfy any one or more required terms of any GPLv3-with-RLEv3.1-licensed compiler (FSF or otherwise) in such as 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 Corresponding Source Code on a “consumer” device that is not-“sufficiently” “industrial”, where that consumer device (e.g., an Apple iDevice) might be a User Product in the terms of GPLv3.
> > 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 runtime) could conceivably be enough for Apple to reject such apps from the App Store, so that Apple need not satisfy #2 above.
> > 
> > https://thenextweb.com/apple/2015/06/17/apples-biggest-developer-news-at-wwdc-that-nobodys-talking-about-bitcode
> > 
> > Apparently Apple is either working on a McSema-esque technology or would require the app to be
> > (also?) provided in the form of LLVM-bitcode-IR (in addition? to ARM-processor machine-code) at the
> > time of submission to the App Store for approval.
> 
> They're not doing anything of the sort. They used to use fat binaries containing both m68k and powerpc,
> then both 32/64 bit x86. For this they'll use LLVM bitcode, which is IR compiled to LLVM's bitcode,
> something that's been in LLVM since it started. One of the major pros about 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 LLVM bitcode IR) when/if Apple ever unifies iOS & MacOS apps, then it seems FSF 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 LLVM bitcode IR as the sole format when submitting an app for App-Store approval, then is seems that compiling an app with FSF GNAT on MacOS would preclude closed-source apps from being submitted to the Mac App Store.

My point of listing conceivable potential futures was that no one can definitively predict what Apple will do.  We can merely list all the conceivable or likely foreseeable possibilities and then we might have a, say, 75% chance of Apple's future decision actually being on that list.

Uncertainty and “all the morass of licensing surrounding” GCC galore.

> We talked about a similar mechanism for a platform neutral binary for AmigaOS 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 analysis of GPLv3 and RLEv3.1 that OSF/1's ANDF (architecture-neutral distribution format) would have also trigged the “notwithstanding” clause of Target Code in RLEv3.1 back in the first half of the 1990s during the era of the so-called ‘UNIX wars’ (which in turn triggers the provide-the-Source-Code demands in the Object Code clauses of GPLv3).

Re: DragonEgg has been revived

[Luke A. Guest]

Chris M Moore <m> wrote:

> 
> I mean who uses "overtly clearly"?
> 

It’s like reading posts from a spambot, isn’t it? My eyes glaze and I just
tl;rcfbb

Re: DragonEgg has been revived

[Dan'l Miller]

On Thursday, May 24, 2018 at 4:59:43 PM UTC-5, Chris M Moore wrote:
> On 24/05/2018 20:26, Dan'l Miller wrote:
> > Specifically where in the set {GPLv3, RLEv3.1, copyright law's body of statutes in USCode, copyright treaties to which the USA is a signatory} does it overtly clearly say anything even remotely in the ballpark of that sentence 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 and parrot what other people say doesn't count; I want original sources and seminal references, such as quotations from members of that set above.)
> 
> I mean who uses "overtly clearly"?

Someone who wants to arrive directly rapidly at the •fully correct• answer within the root/seminal normative reference-documents—as opposed to the alternative:  ‘10 blind men in India feeling different parts of the elephant’, jawboning the same-old same-old parroted partially-correct/cherrypicked hearsay for yet another 10 years.

(Am I the very first person in all these 10 years who publicly posts—in any public forum on the planet—a walk-through step-by-step as I read the plain-language meanings of the license applied to juicy real-world use-cases, detailing precisely how each of the contractual-terms cause the viral license to spread versus to not spread in each of the different scenarios?  If not, post a URL to an analogous step-by-step walk-through of the back-&-forth interplay of Source Code, Object Code, Target Code, Compilation Process, Eligible Compilation Process, and so forth.  The walk-through is little different than a sportscaster calling the plays of a game, really—okay, its a whole lot more boring & esoteric, but still.)

Re: DragonEgg has been revived

[Luke A. Guest]

Dan'l Miller <optikos@verizon.net> wrote:
> On Thursday, May 24, 2018 at 4:59:43 PM UTC-5, Chris M Moore wrote:
>> On 24/05/2018 20:26, Dan'l Miller wrote:
>>> Specifically where in the set {GPLv3, RLEv3.1, copyright law's body of
>>> statutes in USCode, copyright treaties to which the USA is a signatory}
>>> does it overtly clearly say anything even remotely in the ballpark of
>>> that sentence 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 and parrot what other people say doesn't count;
>>> I want original sources and seminal references, such as quotations from
>>> members of that set above.)
>> 
>> I mean who uses "overtly clearly"?
> 
> Someone who wants to arrive directly rapidly at the •fully correct•
> answer within the root/seminal normative reference-documents—as opposed
> to the alternative:  ‘10 blind men in India feeling different parts of
> the elephant’, jawboning the same-old same-old parroted
> partially-correct/cherrypicked hearsay for yet another 10 years.


WTF are you banging on about? That made no sense and had no point and was
soooo long winded.

<stripped out pointless ramblings>

Re: DragonEgg has been revived

[Dan'l Miller]

https://en.m.wikipedia.org/wiki/Blind_men_and_an_elephant#John_Godfrey_Saxe

especially The Moral in the final stanza:
https://en.m.wikisource.org/wiki/The_poems_of_John_Godfrey_Saxe/The_Blind_Men_and_the_Elephant

The Moral:

So, oft in theologic wars
The disputants, I ween,
Rail on in utter ignorance
Of what each other mean,
And prate about an Elephant
Not one of them has seen!

Re: DragonEgg has been revived

[Chris M Moore]

On 24/05/2018 16:38, Dan'l Miller wrote:
> Let us review, where Simon Wright and Chris Moore got off-track in this thread:

<snip>

> Hey, you found one of those “GPL[-based] restrictions on the generated code” 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 “GPL[-based] restrictions on the generated code”.  You found one.  Yea!

<snip>

I mis-remembered.  It wasn't me directly and it wasn't "Dear boy" but 
it's there in sentiment.  I think you have some interesting ideas but I 
would appreciate it more if they were delivered in a more engineer-like 
manner and less as if in virtual combat.

-- 
sig pending (since 1995)

Re: DragonEgg has been revived

[Simon Wright]

Chris M Moore <zmower@ntlworld.com> writes:

> On 24/05/2018 16:38, Dan'l Miller wrote:
>> Let us review, where Simon Wright and Chris Moore got off-track in
>> this thread:
>
> <snip>
>
>> Hey, you found one of those “GPL[-based] restrictions on the
>> generated code” 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
>> “GPL[-based] restrictions on the generated code”.  You found one.
>> Yea!
>
> <snip>
>
> I mis-remembered.  It wasn't me directly and it wasn't "Dear boy" but
> it's there in sentiment.  I think you have some interesting ideas but
> I would appreciate it more if they were delivered in a more
> engineer-like manner and less as if in virtual combat.

Yes.

And for someone who prides himself on only using the clear meaning of
license text, he delights in tangled chains of "reasoning".

Re: DragonEgg has been revived

[Simon Wright]

"Dan'l Miller" <optikos@verizon.net> writes:

>> [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 “GPL[-based] restrictions on the generated
> code” 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 “GPL[-based] restrictions on
> the generated code”.  You found one.  Yea!

I think I originally said "WTF" to this. To expand,

I modify GCC so that it emits some intermediate representation which
might, for example, act as input to an LLVM assembler. My modifications
are released under the GPL.

Explain to me exactly how that, on its own, causes any object code
generated via that compiler to fall under the GPL if the source code was
licensed under e.g. a BSD license.

On second thoughts, don't, since you won't be able to using the plain
words of the GPL but will have to fall back on tangled chains of vague
inferences involving unrelated matters.

Re: DragonEgg has been revived

[Brian Drummond]

On Thu, 24 May 2018 20:38:26 -0700, Dan'l Miller wrote:

> https://en.m.wikipedia.org/wiki/
Blind_men_and_an_elephant#John_Godfrey_Saxe
> 
> especially The Moral in the final stanza:
> https://en.m.wikisource.org/wiki/The_poems_of_John_Godfrey_Saxe/
The_Blind_Men_and_the_Elephant
> 
> The Moral:
> 
> So, oft in theologic wars The disputants, I ween,
> Rail on in utter ignorance Of what each other mean,
> And prate about an Elephant Not one of them has seen!

Or the original (or at least, considerably older) Tittha Sutta.

https://www.accesstoinsight.org/tipitaka/kn/ud/ud.6.04.irel.html

-- Brian

Re: DragonEgg has been revived

[Simon Clubley]

On 2018-05-24, Luke A  Guest <laguest@archeia.com> wrote:
> Chris M Moore <m> wrote:
>
>> 
>> I mean who uses "overtly clearly"?
>> 
>
> It?s like reading posts from a spambot, isn?t it? My eyes glaze and I just
> tl;rcfbb

I think I prefer the Sky59 person. (And no, that's not an invitation
for him to start posting again.)

Since my name is getting thrown around without context, let me make
it clear where my concerns are.

I don't care if the compiler itself is GPL.

I _do_ care if the RTS or anything else is GPL (or even LGPL) and as
a result there are constraints imposed on my binaries or source code
when I use the compiler. I want to be able to compile programs using
the compiler without having to do anything else other than ship the
binary for my program.

This is why I talk about generated code and not the compiler.

The FSF runtime exception is fine for me.

I would like to be able to use Ada in all the places I can currently
use C and C++ code, including bare metal targets.

If I start using Ada in those places, I would be like to sure that
I can still build Ada code for those targets in 2-5 years using the
current toolchains of the day, just like I can with C and C++ code.

It would be nice if it was as easy to port a compiler toolchain to
a new OS or architecture as it is to port a RTOS to a new target.
This would be one answer to the lack of targets for an Ada compiler.

For those of you who have not done RTOS based development, an RTOS is
typically very cleanly divided internally into libraries of generic
code and target specific low level Board Support Packages (BSP) that
implement the required functionality for a specific piece of hardware.

All that it typically takes to port to a new piece of hardware is
to write a new BSP and the interface from the BSP to the rest of
the RTOS is typically very clean and well documented.

It would be nice if an Ada compiler was also that clean internally
and as well documented so that you could easily port it to a new OS
or environment yourself if you needed.

Simon.

-- 
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Microsoft: Bringing you 1980s technology to a 21st century world

Re: DragonEgg has been revived

[Lucretia]

On Friday, 25 May 2018 14:16:55 UTC+1, Simon Clubley  wrote:
> On 2018-05-24, Luke A  Guest <> wrote:
> > Chris M Moore <m> wrote:
> >
> >> 
> >> I mean who uses "overtly clearly"?
> >> 
> >
> > It?s like reading posts from a spambot, isn?t it? My eyes glaze and I just
> > tl;rcfbb
> 
> I think I prefer the Sky59 person. (And no, that's not an invitation
> for him to start posting again.)

Oh god no! ;P
 
> I don't care if the compiler itself is GPL.
> 
> I _do_ care if the RTS or anything else is GPL (or even LGPL) and as
> a result there are constraints imposed on my binaries or source code
> when I use the compiler. I want to be able to compile programs using
> the compiler without having to do anything else other than ship the
> binary for my program.

Major issue I agree with.
 
> This is why I talk about generated code and not the compiler.

Yes, because this is the issue with the GPL and GNAT/GCC as they stand. It is possible to have compilers which are not encumbered in this way. One of the things I want to do is to generate SPIR-V from Ada, that would be cool AF!
 
> The FSF runtime exception is fine for me.

For now.
 
> I would like to be able to use Ada in all the places I can currently
> use C and C++ code, including bare metal targets.

Yes, including mobile.
 
> If I start using Ada in those places, I would be like to sure that
> I can still build Ada code for those targets in 2-5 years using the
> current toolchains of the day, just like I can with C and C++ code.

A clear branching/tagging on the compiler sources where you can grab an earlier version if you need to, then fix up later versions if they fail for some reason.
 
> It would be nice if it was as easy to port a compiler toolchain to
> a new OS or architecture as it is to port a RTOS to a new target.
> This would be one answer to the lack of targets for an Ada compiler.

This has to be a major factor.

My uni thesis was supposed to be a Java compiler, but my "instructor" at the time wanted me to use GCC, I spent so much time just trying to work out GCC I didn't get it done. If I'd just done it with Flex/Bison, it would've been done. GCC is way too big to handle for such a short timeframe, IMO.
 
> For those of you who have not done RTOS based development, an RTOS is

Haven't, intend to.

> typically very cleanly divided internally into libraries of generic
> 
> It would be nice if an Ada compiler was also that clean internally
> and as well documented so that you could easily port it to a new OS
> or environment yourself if you needed.

The documentation needs to be external to the source, so you don't have to go around the sources looking for stuff. This documentation can be generated from the source though.

I agree with everything you said, apart from the sky invite &;P

Luke.

Re: DragonEgg has been revived

[Jeffrey R. Carter]

On 05/25/2018 02:19 AM, Luke A. Guest wrote:
> Chris M Moore <m> wrote:
> 
>>
>> I mean who uses "overtly clearly"?
>>
> 
> It’s like reading posts from a spambot, isn’t it? My eyes glaze and I just
> tl;rcfbb

Don't feed the troll.

-- 
Jeff Carter
"In the frozen land of Nador they were forced to
eat Robin's minstrels, and there was much rejoicing."
Monty Python & the Holy Grail
70

Re: DragonEgg has been revived

[Dan'l Miller]

On Friday, May 25, 2018 at 11:25:26 AM UTC-5, Jeffrey R. Carter wrote:
> Don't feed the troll.

How dare you!  I am not troller-fishing.  I am trying to determine the licensing viability of my aforementioned GELI project to replace DragonEgg.  It is all highly on-topic and pursuant to productive goals in reaction to the reasons that caused the de facto failure of DragonEgg.  So far, I have convinced myself yesterday to delete the nascent GitHub repository that I had previously started to house the GELI project as a fork of GCC, at least until I can figure out how to navigate the licensing with certainty.  In major-contribution replies in this thread, I am not only:

1) laying out the plan for a practical GELI alternative to GIGI so that GELI feeds an LLVM backend in FSF GNAT for "llvm-"-prefixed targets on the GNAT command line (in addition to GIGI feeding GENERIC/GIMPLE-RTL for traditional-GCC targets on the GNAT command line),

but (unless someone can dismantle the sequence of logic using normative references) also, now in later licensing-related replies, I am revealing some likely reasons for:

2) why A# has quietly faded into lack-of-maintenance in recent years (i.e., because Microsoft/Mono CLR doesn't enjoy the same overt mentioning as a permitted IR in RLEv3.1 that JVM does in Target Code's "notwithstanding" clause in RLEv3.1, which in turns forces all generated CLR bytecode be an IR that in turn would be forced to be GPLv3-licensed);

3) why SPIR-V will never be written as a file from FSF GNAT (or if someone builds out that capability, then why the SPIR-V would be forced to be GPLv3-licensed);

4) why LLVM bitcode IR (e.g., to perhaps support Apple's foreseeable App-Store submission requirements) will never be written as a file from FSF GNAT (or if someone builds out that capability, then why the LLVM bitcode IR would be forced to be GPLv3-licensed)

and other related topics of recently-stated concern on c.l.a.  Troller fishermen don't cast nets like that which contain pertinent useful lucidly-presented information.  Actual bona fide contributors do though.

Re: DragonEgg has been revived

[Simon Wright]

Lucretia <laguest9000@googlemail.com> writes:

> On Friday, 25 May 2018 14:16:55 UTC+1, Simon Clubley  wrote:
>> On 2018-05-24, Luke A  Guest <> wrote:

>                                GCC is way too big to handle for
> such a short timeframe, IMO.

Oh yes.

>> It would be nice if an Ada compiler was also that clean internally
>> and as well documented so that you could easily port it to a new OS
>> or environment yourself if you needed.

I believe that there's considerable cross-communication between the
higher (Ada) and lower (GCC internal) stages of the compiler. No proof,
too deep for me!

> The documentation needs to be external to the source, so you don't
> have to go around the sources looking for stuff. This documentation
> can be generated from the source though.

GNAT doesn't have any publicly-visible design documentation that I'm
aware of, or any "user story"-type info. For instance, between GCC7 and
GCC8 the interface between the compiler and the RTS changes so as to
implement the task aspect Secondary_Stack_Size; procedure
System.Tasking.Restricted.Stages.Create_Restricted_Task gets an extra
parameter. I found this out by using the unmodified RTS with the new
compiler, and having confusing error messages (extra confusing because
the call to the RTS is created by generating the corresponding syntax
tree), resolved by compiling with -gnatG to see what the compiler
exepcted to call.

Re: DragonEgg has been revived

[Dan'l Miller]

On Friday, May 25, 2018 at 12:08:39 PM UTC-5, Simon Wright wrote:
> I believe that there's considerable cross-communication between the
> higher (Ada) and lower (GCC internal) stages of the compiler. No proof,
> too deep for me!

I might be factually incorrect, but here is what I think that currently know:

AIUI from my kill-off-DragonEgg investigations pursuant to GELI aforementioned on this thread,
0) GNAT's AST gets constructed during lexing & parsing.

1) The GNAT front-end grinds on _LRM_ semantics very hard via many passes of adorning the nodes of the AST to incrementally become more the full-fledged Ada-IR tree.

1.1) Fascinatingly, slide 4 of the PowerPoint below indicates that GNAT's many passes are organized literally in the chapter-order of the _LRM_.

2) Then the Ada-IR tree has reached its terminus state of being fully semantically adorned.

3) Then and only then walked by an Ada iterator/cursor that feeds snippets to C-language-implemented GIGI.

4) GIGI then authors high GIMPLE as the C-IR tree.  Once that tree-transduction completes,

5) then high GIMPLE begets authoring low GIMPLE,*

6) then low GIMPLE begets RTL,*

7) then RTL begets authoring target hardware-processor machine-code.*

* the same in steps 5, 6, & 7 as it does for C/C++ unbeknownst to which language was in the front end;  Ada adds fewer than 10 treenode-types to high GIMPLE that were lacking in C/C++-world.  I say fewer than because it appears 6 of those 10 somehow never really make it out of GIGI, as if they are temporary, leaving 4 treenode-types leaving GIGI that are peculiar to Ada semantics, not exercised by C/C++ semantics.

> > The documentation needs to be external to the source, so you don't
> > have to go around the sources looking for stuff. This documentation
> > can be generated from the source though.
> 
> GNAT doesn't have any publicly-visible design documentation that I'm
> aware of,

Well, not much more than this 11-slide PowerPoint presentation:
https://www.slideserve.com/reed/the-structure-of-the-gnat-compiler

which is enough to see the GIGI-to-highGIMPLE portion of the architecture on slides 2 & 7.  The fully-semantically-adorned AST/Ada-IR tree that is fed as input into the GIGI tree-transducer via an Ada-language iterator/cursor that walks that Ada-IR tree is described on slides 9, 10, & 11.

Historically, GENERIC, high GIMPLE, low GIMPLE, and RTL are documented at the URL below, whose WWWpage claims to be current for the forthcoming GCC 9.0 era, but portions might be lagging behind one or more major releases of GCC:
https://gcc.gnu.org/onlinedocs/gccint/index.html#Top
in the GENERIC & GIMPLE URLs.

Some people say that GCC's C/C++ compiler authors high GIMPLE directly skipping the older-era GENERIC, whereas this documentation says that high GIMPLE is a subset of GENERIC, so whatever that state of affairs really really means.  (e.g., why does high GIMPLE have a different name than GENERIC then?  I don't know.  I haven't reached full grok yet.)

Re: DragonEgg has been revived

[Dan'l Miller]

On Friday, May 25, 2018 at 3:28:04 AM UTC-5, Simon Wright wrote:
> I modify GCC so that it emits some intermediate representation which
> might, for example, act as input to an LLVM assembler. My modifications
> are released under the GPL.
> 
> Explain to me exactly how that, on its own, causes any object code
> generated via that compiler to fall under the GPL if the source code was
> licensed under e.g. a BSD license.

I already have done that in a reply above, but I will try again, trying to be even more lucid.  Simon Wright, please pay especial attention to steps #B28, #B29, #B33, #B33.1, #B33.2, #B33.3, #B35, and #B36, because those are the points where the communicability of the license virus occurs, which is the communicability of viral license which you claimed did not exist:

> On Wednesday, May 23, 2018 at 2:26:49 AM UTC-5, Simon Wright wrote:
>> Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> writes:
>>
>> > What I would like to see is an Ada compiler that can generate code
>> > for a wide range of targets without any GPL restrictions on the
>> > generated code.
>>
>> Pretty sure that's called GCC. 

The senario B is written to focus on a hypothetical FSF GNAT (that has the IR-file-writing extension that you propose) that is compiling an iOS app to LLVM bitcode IR for submission to the iDevices' iOS App Store.  Clearly, the more that submitting a MacOS app to the Mac App Store resembles this Scenario B, the more that it could conceivably apply to the GNAT for MacOS over time, regarding submitting MacOS apps to the Mac App Store, which might be an intended use-case for the GNAT-for-MacOS builds that you maintain.

Let's walk step by step, but for brevity of writing here (to avoid copy-pasting sentences from the GPLv3 and RLEv3.1), all readers should open up
https://www.gnu.org/licenses/gpl-3.0.en.html
and
https://www.gnu.org/licenses/gcc-exception-3.1.html
in adjacent WWWbrowser tabs/windows right now to read along as each contractual-term is mentioned below.  Please pause your reading below at each capitalized contractual-term below to go read their definition and cascading-ramification usage in GPLv3 or RLEv3.1, so that you untangle the reading-comprehension/logic-puzzle riddle that is cleverly encoded throughout GPLv3 and RLEv3.1.

Note that there exist 3 readings of the GPLv3 and its RLEv3.1 for the case that Simon Wright brings up above, one for each build of software, because it is the build (especially the linking) at which the license can spread virally:
a) once for building GCC-the-compiler-proper pristine as it was prior to b below [henceforce with a G- prefix on the contractual-terms; G mnemonic for GCC] and
b) once for compiling & linking the IR file-writing that Simon Wright proposes [henceforce with a W- prefix on the contractual-terms; W mnemonic for writing or Wright, whichever you prefer] and
c) once for building GCC's runtime [henceforce with a R- prefix on the contractual-terms; R mnemonic for runtime]
d) once for my app [henceforce with an M- prefix on contractual-terms; M mnemonic for my or Miller, whichever you prefer]
so that we can clearly see the R-to-M viral communicability of the licensing virus (and the lack of G-to-M communicability).

Just to be clear M-Contractual-Term is shorthand for Contractual Term as defined in either GPLv3 or RLEv3.1 when those 2 documents are read with my app in mind (called in legalese jargon: reading the license onto my app) when linking with FSF GCC's runtime by FSF GCC.  M-Contractual-Term is for when Contractual Term in either the GPLv3 or RLEv3.1 or both are read onto my app.

Just to be clear R-Contractual-Term is shorthand for Contractual Term as defined in either GPLv3 or RLEv3.1 when those 2 documents are read with GCC's runtime in mind (called in legalese jargon: reading the license onto the GCC runtime) when FSF GCC's runtime is built by FSF GCC.  R-Contractual-Term is for when Contractual Term in either the GPLv3 or RLEv3.1 or both are read onto GCC's runtime.

Just to be clear W-Contractual-Term is shorthand for Contractual Term as defined in either GPLv3 or RLEv3.1 when those 2 documents are read with IR-file-writing extension in mind (called in legalese jargon: reading the license onto IR-file-writing extension) when building FSF GCC-the-compiler-proper with any capable C/C++ compilers.  W-Contractual-Term is for when Contractual Term in either the GPLv3 or RLEv3.1 or both are read onto IR-file-writing extension.

Just to be clear G-Contractual-Term is shorthand for Contractual Term as defined in either GPLv3 or RLEv3.1 when those 2 documents are read with GCC-the-compiler-proper in mind (called in legalese jargon: reading the license onto GCC-the-compiler-proper) when building FSF GCC-the-compiler-proper with any capable C/C++ compilers.  G-Contractual-Term is for when Contractual Term in either the GPLv3 or RLEv3.1 or both are read onto GCC-the-compiler-proper.

Note that what a human being calls, say, target code might or might not be Target Code as a contractual-term.  The capital letters there are a different legalese term that gets overtly defined in the contract, separate from any dictionary meaning(s) (and baggage and ambiguity and preconceptions) that it might have in commonfolk's everyday commonplace life or that it might have in technical jargon known commonly among technical experts.  The virality of the license is communicable via the contractual-terms in initial-capitalized letters, so pay extra special attention to contractual-terms that start with capital letters.

1) The G-Source-Code term in GPLv3 refers to the source code of FSF GCC as itself licensed under GPLv3.   The G-Object-Code term in GPLv3 refers to the object code of FSF GCC as itself licensed under GPLv3.

2) Let's assume that the IR-file-writing extension to GCC has already been imported into the GCC directory tree from some permissive licensed external repository of source code, e.g., UofIllinois/NCSA.  (Btw, to skip a few steps, let's assume that the IR-file-writing extension is not a separately/later compiled plug-in, but rather it is literally in the GCC G-Source-Code tree.)  Copyright applies first & foremost to a document, which for source code is the source-code file (analogous to an individual encyclopedia volume), not the directory tree as a mere compilation (analogous to a set of encyclopedia volumes that just happen to be conceptualized as orderly sitting together on a shelf).  So either the files in that IR-file-writing extension were updated at time of importation to the GCC source-tree to contain a copyright notice evoking GPLv3 or those files still have their copyright notice that evokes the UofIllinois/NCSA license.  Let's assume the more-subtle case:  they still have their UofIllinois/NCSA license notification.

3) As the build of GCC gets around to compiling each source-code file in the IR-file-writing extension, the effective license for the moment of IR-file-writing extension's source code remains UofIllinois/NCSA, as does the license of the derivative-work .o object-file file.  (Hold your fire; see next 2 steps.)

4) The build of GCC gets around to linking the .o files (or library archives thereof) of IR-file-writing extension to at other G-Object-Code from step #1.

5) step #4 causes IR-file-writing extension's object code to be (dare I say, virally) transformed into W-Object-Code as the contractual-term defined in GPLv3.

6) As per the various M-Object-Code clauses in GPLv3, the only right that I have to convey the W-Object-Code is 6.1:

6.1) to comply with the various demands to provide the IR-file-writing extension's source code (which just became W-Source-Code as GPLv3 reads onto the IR-file-writing extension) or

6.1.1) Note what just happened there in 6.1:  despite whatever apparent blah-blah-blah UofIllinois/NCSA GPLv3-compatible license-grant appeared atop W-Source-Code's files, the provide-the-source-code terms of GPLv3' W-Object-Code just eclipsed that UofIllinois/NCSA license-grant.  This is the viral spread of the GPL license that is most widely known, because it dates all the way back to the GPLv1 era circa 1989.  (The RLEv3.1 one in step step #B28 below is not as widely known.)

6.2) Note that because W-Object-Code was linked with G-Object-Code (instead of with R-Object-Code) and because G-Object-Code is licensed with GPLv3 unamended, RLEv3.1 shall not get evoked (even if the IR-file-writing extension were to have invoked at least one subroutine in GCC's runtime).  Because RLEv3.1 doesn't get evoked, RLEv3.1 isn't read onto the IR-file-writing extension, leaving W-Object-Code's demands to provide W-Source-Code standing in GPLv3 unamended.

6.2.1) License analysis of W-Source-Code and W-Object-Code has reached its natural-conclusion terminus.

7) After the build of GCC-the-compiler-proper finishes, that GCC is then utilized to build the GCC runtime.

8) During step #7, GCC runtime's source code is already R-Source-Code because it is licensed via GPLv3-as-amended-by-RLEv3.1 (or GPLv3-with-RLEv3.1 for short).

9) During the compilation of each R-Source-Code file, the object files of GCC's runtime become R-Object-Code as the contractual-term defined in GPLv3.

10) Because of step #9, the only right to convey R-Object-Code is to satisfy GPLv3's provide-the-R-Source-Code demand.

11) Because each file f in R-Source-Code is a file whose prologue atop its source file states that the only right I have to copy this file is via RLEv3.1, f is then deemed R-Runtime-Library as per the definition in RLEv3.1.

12) Because of step #11 and because R-Object-File is a derivative work under copyright law of R-Source-Code, each file f in R-Source-Code fails to satisfy the “not otherwise based on [R-]Runtime[-]Library” clause in the attempted definition of R-Independent-Module.  Hence, R-Independent-Module fails to be defined here.  Where the absence of R-Independent-Module occurs downstream, let's put R-PhthphthphIM downstream so it is clear that R-Independent-Module is absent.

13) In RLEv3.1, R-Grant-of-Additional-Permission needs R-Independent-Module to have been successfully defined.  But instead M-PhthphthphIM is all that came out of step #12.  So now, R-Grant-of-Additional-Permission fails to get defined.

14) In RLEv3.1, R-No-Weakening-of-the-GCC-Copyleft self-evokes itself, even in step #13's absence of R-Grant-of-Additional-Permission (or equivalently in the presence of step #13's M-PhthphthphIM).  This re-affirms R-Object-Code's provide-R-Source-Code demand over in GPLv3, just in case the this-is-an-amendment-of-GPLv3 language in RLEv3.1's preamble left any doubt.

15) Because of steps #13 and #14, RLEv3.1 did not grant any additional permissions beyond the terms of GPLv3, leaving R-Object-Code's demands to provide R-Source-Code standing in GPLv3 unamended.

15.1) License analysis of R-Source-Code and R-Object-Code has reached its natural-conclusion terminus.

16) The GCC compiler that contains both G-Object-Code and W-Object-Code from prior steps then starts compiling my app's source code.

17) But then when my app's source code causes (even indirectly) the invocation of even a single subroutine in R-Source-Code, then my app is linked with R-Object-Code).

18) Step #17's linkage causes my app's object code to be (dare I say, virally) transformed for the time being into M-Object-Code as the contractual-term defined in GPLv3.

19) Step #18 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 GPLv3.

20) 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.1) to comply with the various demands to provide M-Source-Code or

20.2) to comply with the various requisite expectations of good behavior in RLEv3.1 so that M-Object-Code gets recategorized as M-Target-Code via R-Grant-of-Additional-Permission, so that my app gets out of the GPLv3's demands on M-Object-Code.

21) RLEv3.1 is predicated on my app being compiled by an M-Elligible-Compilation-Process.

22) RLEv3.1's M-Elligible-Compilation-Process is predicated on M-Eligible-Compilation-Process being an M-Compilation-Process in the first place.

23) RLEv3.1's M-Compilation-Process is predicated on satisfying the various contractual restrictions on M-Target-Code.

2 hypothetical cases A versus B:

A24) RLEv3.1's M-Target-Code is satisfied if my app is, say, compiled to hardware-processor machine-code (or hardware-processor assembly language thereof) and then merely link-loaded and then merely executed.

A25) The logical-deduction chain of
“if M-Target-Code satisfied”
begets
“if M-Compilation-Process satisfied”
begets
“if M-Eligible-Compilation-Process satisfied”
begets
“if RLEv3.1 satisfied”
then has successfully recategorized (viral) M-Object-Code into mere (nonviral) M-Target-Code, dispensing with any need to provide source code or provide Installation Information or provide Corresponding Source Code over in GPLv3.  GPLv3 and RLEv3.1 reading onto my ap stops at this terminus, ending the GPLv3 and RLEv3.1 license examination for my app.  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 special permissions granted by the RTEv3.1.  Whew!  My app dodged that bullet.

versus

https://thenextweb.com/apple/2015/06/17/apples-biggest-developer-news-at-wwdc-that-nobodys-talking-about-bitcode

B24) 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 if all iOS frameworks become available on MacOS), and perhaps for different eras of ARM processors soldered into iDevices.

B25) Nonjailbroken iDevices are what is called a walled garden, where the only apps (other than development mode, enterprise side-loading, and invitation-only testing) that are permitted to be downloadable to the iDevice are those that have been approved by Apple for conveyance in the App Store.

B26) At some point Apple could require the availability of LLVM bitcode IR for each app to be approved for the App Store.  This could be by overtly requiring LLVM bitcode IR files at time of submission.

B27) For each file in M-Source-Code, the GCC compilation in step #16 writes an IR file that is deemed M-Object-Code by the (anti-)definition of M-Object-Code as being all files output by the compiler that are not M-Source-Code.

B28)  In RLEv3.1, the attempt to define M-Target-Code is comprised of 2 sentences.  Due to step #B27 being an M-Object-File is in fact IR, the “notwithstanding” 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 “notwithstanding” works in legalese:  literally if the 2nd sentence is satisfied, 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 within, literally leaving the attempted definition of M-Target-Code •with• all attempted definitions •not• •standing•** or equivalently literally the attempt to define M-Target-Code in the 1st sentence did •not• •withstand• the nuclear-bomb blast detonated in the 2nd sentence**, because the 1st sentence was blown to smithereens by the dropping of the “notwithstanding” nuclear-bomb regarding IR.

** hence the word: notwithstanding

B29) Oopsies, in step #B28, M-Target-Code failed to get defined, due to the IR nuclear bomb that got dropped.  Where the absence of M-Target-Code occurs downstream, let's put M-PhthphthphTC downstream so it is clear that M-Target-Code is absent.

B30) In RLEv3.1, M-Compilation-Process needs M-Target-Code to have been successfully defined.  But instead M-PhthphthphTC is all that came out of steps #B28/#B29.  So now, M-Compilation-Process fails to get defined.  Where the absence of M-Compilation-Process occurs downstream, let's put M-PhthphthphCP downstream so it is clear that M-Compilation-Process is absent.

B31) In RLEv3.1, M-Eligible-Compilation-Process needs M-Compilation-Process to have been successfully defined.  But instead M-PhthphthphCP is all that came out of step #B30.  Where the absence of M-Eligible-Compilation-Process occurs downstream, let's put M-PhthphthphECP downstream so it is clear that M-Eligible-Compilation-Process is absent.

B32) In RLEv3.1, M-Grant-of-Additional-Permission needs M-Eligible-Compilation-Process to have been successfully defined.  But instead M-PhthphthphECP is all that came out of step #B31.  So now, M-Grant-of-Additional-Permission fails to get defined, eliding all of section 1 of RLEv3.1. 

B33) Regardless of step #B32, in RLEv3.1, R-No-Weakening-of-the-GCC-Copyleft self-evokes itself, even in step #B32's absence of R-Grant-of-Additional-Permission (or equivalently in the presence of step #B32's M-PhthphthphIM).

B33.1) Step #B33 re-affirms M-Object-Code's provide-M-Source-Code demand over in GPLv3.

B33.2) And to the point of the walled-garden on nonjailbroken iDevices, step #B33 re-affirms M-Object-Code's provide-M-Installation-Information demand over in GPLv3.

B33.3) Step #B33 re-affirms M-Object-Code's provide-M-Installation-Information's M-Corresponding-Source-Code demand over in GPLv3.

B33.4) ... just in case the this-is-an-amendment-of-GPLv3 language in RLEv3.1's preamble left any doubt of B33.1, B33.2, and B33.3.

B34) RLEv3.1 would have granted its special magic of M-Target-Code in RLEv3.1 eclipsing M-Object-Code in GPLv3 if and only if M-Grant-of-Additional-Permission would have been successfully defined.  But instead the failed attempt to define M-Grant-of-Additional-Permission caused Section 1 of RLEv3.1 to self-elide itself.  So the RTEv3.1's house-of-cards that RLEv3.1 tries to carefully build up collapses and no special magic occurs:  M-Object-Code stays M-Object-Code; M-ObjectCode's and M-Source-Code's lifetimes live on for my app, over in GPLv3 when reading GPLv3 onto my app.

B35) Now back over in GPLv3, as re-affirmed in step #B33.1, M-Object-Code must provide its M-Source-Code to all possessors of M-Object-Code in one or more GPLv3-specified ways.

B36) Steps #B33.2 and #B33.3 re-affirmed the need for this step #B36's analysis:  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 installed behind not-jail-broken logistical barriers that would require M-Installation-Information and M-Corresponding-Source-Code to be provided.

B37) I don't possess M-Installation-Information and M-Corresponding-Source, but Apple does.

B38) Wouldn't it be wise for Apple to side-step the step #B36's demand for providing M-Installation-Information and M-Corresponding-Source-Code by prohibiting apps built by GPLv3-with-RLEv3.1-licensed compilation processes.

B39) 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-compiled 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).