Ada on Apple's new procesors

[Jerry]

Apple is beginning its third nightmare transition to a new processor family. What does this mean for Ada on macOS?

Can we hope for a native compiler anytime soon? We will have Rosetta 2 until we don't. (Original Rosetta lasted for two OS generations and then it was taken away.) I could tell you the story of needing to run a small PowerPC program to set up a slightly old Apple WiFi device a couple years ago. Buy Parallels. Call Apple and send $30 to get Snow Leopard Server--that's 10.6. Virtualize Snow Leopard Server on Parallels to run the WiFi set-up program in Rosetta.)

Jerry

[Vadim Godunko]

On Tuesday, June 23, 2020 at 1:53:01 AM UTC+3, Jerry wrote:
> Apple is beginning its third nightmare transition to a new processor family. What does this mean for Ada on macOS?
>
> Can we hope for a native compiler anytime soon?

I suppose native toolchain will be based on LLVM, thus it will allow to use GNATLLVM on new processors.

[Luke A. Guest]

On 22/06/2020 23:53, Jerry wrote:
> Apple is beginning its third nightmare transition to a new processor family.. What does this mean for Ada on macOS?

>
> Can we hope for a native compiler anytime soon? We will have Rosetta 2 until we don't. (Original Rosetta lasted for two OS generations and then it was taken away.) I could tell you the story of needing to run a small PowerPC program to set up a slightly old Apple WiFi device a couple years ago. Buy Parallels. Call Apple and send $30 to get Snow Leopard Server--that's 10.6. Virtualize Snow Leopard Server on Parallels to run the WiFi set-up program in Rosetta.)
>
> Jerry
>

GNAT-LLVM with possibly a custom system-aarch.ads and other runtime parts.

[Optikos]

Without paying a hefty proprietary-licensing fee to AdaCore, isn't GNAT-LLVM distributed only under pure GPLv3 without the Runtime Library Exception (RLE)? Wouldn't that mean that GNAT-LLVM on MacOS (and iOS) can be utilized by software distributed under GPL-compatible licenses, lest that software violate terms of GPLv3?

[Luke A. Guest]

On 23/06/2020 17:16, Optikos wrote:

>> GNAT-LLVM with possibly a custom system-aarch.ads and other runtime parts..

>
> Without paying a hefty proprietary-licensing fee to AdaCore, isn't GNAT-LLVM distributed only under pure GPLv3 without the Runtime Library Exception (RLE)? Wouldn't that mean that GNAT-LLVM on MacOS (and iOS) can be utilized by software distributed under GPL-compatible licenses, lest that software violate terms of GPLv3?
>

Yes that is a problem, but not here.

When you build llvm-gnat, you download the FSF GNAT which comes with the
runtime exception so you can link away all you like without having to
pay for anything :)

Luke.

[Optikos]

Wait, do the FSF GNAT repositories themselves now contain the mods for LLVM instead of obtaining GNAT-LLVM mods from https://github.com/AdaCore/gnat-llvm, which is pure-GPLv3 licensed.

https://github.com/AdaCore/gnat-llvm/blob/master/COPYING3

If mixing FSF GNAT with any 1 or more non-data/non-script (i.e., compiled; linked) source file(s) in https://github.com/AdaCore/gnat-llvm, then RLE evaporates because that 1 or more source file lacks the RLE; hence FSF GNAT-LLVM would become pure GPLv3.

[Luke A. Guest]

On 23/06/2020 21:25, Optikos wrote:

> Wait, do the FSF GNAT repositories themselves now contain the mods for LLVM instead of obtaining GNAT-LLVM mods from https://github.com/AdaCore/gnat-llvm, which is pure-GPLv3 licensed.

There was no change required. GNAT has always had an interface to the
GCC compiler via a glue layer which fits the interface exposed by GNAT.
GNAT-LLVM just implements the same interface. Read the README in the
GNAT-LLVM repo, it tells you to download the FSF GNAT.

> https://github.com/AdaCore/gnat-llvm/blob/master/COPYING3
>
> If mixing FSF GNAT with any 1 or more non-data/non-script (i.e., compiled; linked) source file(s) in https://github.com/AdaCore/gnat-llvm, then RLE evaporates because that 1 or more source file lacks the RLE; hence FSF GNAT-LLVM would become pure GPLv3.
>

The compiler links to GNAT-LLVM, the runtime doesn't.

Pretty sure that the AdaCore people said it won't fall under GPL.

[Optikos]

To cause RLE to elide itself, the Ada runtime does not need to link with the •compiler; it needs the runtime to be linked to the user's •executable•. In my opinion, the RLE requires a greater than 100 IQ and requires that higher intellect to have generous patience to discern topics that are subtle. The RLE grants its exception only under certain strict terms; otherwise the RLE is written to self-destruct/implode legally, reverting the user's executable to pure GPL. One of those strict terms is Eligible Compilation Process. To clearly be an (RLE-)Eligible Compilation Process, the Compilation Process must not write out (any?) intermediate representation. But that is the scot-free way of achieving Eligible Compilation Process; there might be messier ways. GNAT-LLVM seemingly depends on those messier ways.

The “any?” there is what is an unsettled matter legally. See below.

the Narrow legal theory:
When the RLE discusses IR, does it mean semantically-rich IR that represents an Ada (or C or C++) AST, and Java bytecode, LLVM textual IR, and LLVM bitcode IR doesn't count as IR?

the Wide legal theory:
Or when the RLE discusses IR, does it mean what the plain-meaning seems to say: any IR of any technology of any form counts as IR from the point of view of RLE's permission-grant?

This becomes germane regarding the LLVM optimizer, which takes either LLVM textual IR or LLVM bitcode (which is a binary representation of LLVM textual IR) as input and output, perhaps chained zero or more times. (Zero here would be eliding the entire concept of optimization.)

https://www.llvm.org/docs/CommandGuide/opt.html

https://polly.llvm.org

Under the Narrow legal theory above, the user of GNAT-LLVM can optimize to their heart's content (even with hostile-to-GPL optimizer plug-ins, see below) because LLVM IR isn't the kind of IR that RLE is so concerned about, so no harm no foul.

But under the Wide legal theory above, it becomes especially germane if GNAT-LLVM produces LLVM textual IR or LLVM bitcode that is fed into an optimizer plug-in that is (or could be) hostile-to-GPL, such as an optimizer plug-in that has a closed-source license or violates any of the other terms of GPLv3 (e.g., patents). Under the Wide legal theory above, perhaps the legally-safest usage of GNAT-LLVM for the user to have GPL-noncompliant license on the executable is to entirely elide optimization by coaxing the LLVM toolchain to proceed from compilation to linking without optimization.

Using GPL-compatible open-source-licensed optimizer stages on LLVM textual IR or LLVM bitcode under the Wide legal theory above is a grey area because they seem to not meet the Eligible Compilation Process (due to inter-stage visibility of the IR, so: bad) but each stage is GPL-compatible & open-source (so: good to go?). It is left as an exercise to the reader (and their legal counsel) who is interested in this grey area to determine if LLVM opt and poly and any other frequently-utilized LLVM IR manipulator plug-in is GPL-compatible or not (and whether the Narrow or Wide legal theory is operational in the user's jurisdiction).

The rub:
There is a risk that the mere nominal identicality of the term IR utilized in LLVM would be construed (by confusion) as the term IR in the RLE by a judge or jury if this were ever litigated. IR is IR, or so someone relying on identicality of name or acronym might say—leading to the wide legal theory above coming into play. In some audiences, IR from LLVM's perspective perhaps •not• being IR from RLE's perspective might require more IQ points than that audience has or is willing to invest in the matter, resembling such playful mental effort as the now-famous “it depends on what the definition of ‘is’ is”. The Narrow legal theory requires that patience to meticulously think through instead of dismissing the whole mental effort as: IR=IR, or IR here is IR there and everywhere. The lazy person/judge/jury will tend to default to the Wide legal theory, just because IR here has the name techno-term as IR there.

> Pretty sure that the AdaCore people said it won't fall under GPL.

Only an officer of the company or legal counsel would be able to normatively make that promise of estoppel. A mere employee would be only opining their personal opinion.

[Luke A. Guest]

On 24/06/2020 02:02, Optikos wrote:
>> The compiler links to GNAT-LLVM, the runtime doesn't.
>> To cause RLE to elide itself, the Ada runtime does not need to link
with the •compiler; it needs the runtime to be linked to the user's
•executable•. In my opinion, the RLE requires a greater than 100 IQ and
requires that higher intellect to have generous

Don't know what IQ has to do with anything???

> patience to discern topics that are subtle. The RLE grants its exception only under certain strict terms; otherwise the RLE is written to self-destruct/implode legally, reverting the user's executable to pure GPL. One of those strict terms is Eligible Compilation Process. To clearly be an (RLE-)Eligible Compilation Process, the Compilation Process must not write out (any?) intermediate representation. But that is the scot-free way of achieving Eligible Compilation Process; there might be messier ways. GNAT-LLVM seemingly depends on those messier ways.
>
> The “any?” there is what is an unsettled matter legally. See below.
>
> the Narrow legal theory:
> When the RLE discusses IR, does it mean semantically-rich IR that represents an Ada (or C or C++) AST, and Java bytecode, LLVM textual IR, and LLVM bitcode IR doesn't count as IR?

From https://www.gnu.org/licenses/gcc-exception-3.1-faq.en.html

"When you compile those source code files, they usually go through a
series of steps: source code generation, preprocessing, compilation to
low-level code, assembling, and linking. Not all projects follow all
these steps, depending on what language you're using and how it's
written, but they'll always go in this order, and everyone using GCC
will go through the process of compiling high-level code into some
low-level language such as assembly code or Java bytecode. This phase is
when GCC combines or links your own code with code from the GCC
libraries. We call it the “Compilation Process.” The output you get from
it is called “Target Code,” as long as that output is not used as
compiler intermediate representation, or to create such an intermediate
representation."

This is talking about getting access to the compiler's internal
representation on disk after compilation.

"In order to take advantage of this permission, the Compilation Process
that you use to create Target Code has to be “Eligible,” which means
that it does not involve both GCC and GPL-incompatible software."

* GNAT is GPLv3 (with linking exception).
* GNAT-LLVM bindings are GPLv3
* LLVM is Apache 2

All 3 licences are compatible.

"It's important to remember that the Compilation Process starts when you
feed any high-level code to GCC, and ends as soon as it generates
anything that can be considered Target Code. Because of that, as long as
GCC isn't writing out intermediate representation, your Compilation
Process can still be Eligible"

GNAT is linked to the LLVM libraries via the bindings. They generate a
GNAT AST within GNAT, which is then converted via the bindings to an
LLVM IR AST in memory, these are then passed to the code optimising and
codegen functions in LLVM which generates the final binary. There is no
dumping of GCC's IR to disk here, it's all handled in memory. You can
get the LLVM IR from this using a switch, there is no way to access or
dump to disk GCC's IR from GNAT-LLVM.

So, I read the above as being an eligible compilation process.

"even if you use GCC in conjunction with GPL-incompatible assemblers,
linkers, or high-level source generators: those programs aren't involved
in the Compilation Process as it's defined here. The only place you
can't use GPL-incompatible software with GCC is when it's performing the
core compilation work."

So, the options are:

1) AdaCore or FSF legal advise on whether it's legal or not.
2) AdaCore adds the linking exception to GNAT-LLVM, which still might
not clear up any confusion and would require 1.
3) You use a different Ada compiler with a more permissive licence, oh
there aren't any.
4) You buy a licence from AdaCore, too expensive.
5) Write your own Ada compiler.
6) Use another language.
7) Write your own compiler for your own language.

[Optikos]

On Wednesday, June 24, 2020 at 5:49:03 AM UTC-5, Luke A. Guest wrote:
> On 24/06/2020 02:02, Optikos wrote:
> >> The compiler links to GNAT-LLVM, the runtime doesn't.
> >> To cause RLE to elide itself, the Ada runtime does not need to link
> with the •compiler; it needs the runtime to be linked to the user's
> •executable•. In my opinion, the RLE requires a greater than 100 IQ and
> requires that higher intellect to have generous
>
> Don't know what IQ has to do with anything???

As I explained later in that posting, if this were ever litigated, the judge(s) and/or jury would need to be mentally capable of holding the finer points in their head. That is asking too much for at least 50% of the population, either due to lower IQ to begin with or laziness not wanting to exercise the intellect of which they are actually quite capable.

https://kristerw.blogspot.com/2017/08/gcc-low-level-ir-and-basic-code.html

In some regards, RTL is analogous to either LLVM textual IR or LLVM bitcode IR. Dumping out GIMPLE IR from GCC to manipulate it via any GPL-noncompliant tool would certainly make the Compilation Process ineligible to be an Eligible Compilation Process in the RLE. But dumping out RTL IR via -fdump-rtl-all command-line option, then manipulating it via any GPL-noncompliant tool seems very likely to also make the Compilation Process ineligible to be an Eligible Compilation Process in the RLE. If so, then RLE granting its exception to GPLv3 in GNAT-LLVM is highly dependent on each possible plug-in during the optimization phase of LLVM's opt, because legally speaking LLVM textual IR or LLVM bitcode thereof could be construed as directly analogous to RTL.

> So, I read the above as being an eligible compilation process.
>
> "even if you use GCC in conjunction with GPL-incompatible assemblers,

That is the meat of the question: is LLVM textual IR (always) categorized by interpretations of the RLE
1) as mere assembly language (i.e., gets off scot-free)
or
2) an IR due to its name being literally IR (i.e., the user of the Compilation Process must walk a narrow path without missteps)?

> linkers, or high-level source generators: those programs aren't involved
> in the Compilation Process as it's defined here. The only place you
> can't use GPL-incompatible software with GCC is when it's performing the
> core compilation work."
>
> So, the options are:
>
> 1) AdaCore or FSF legal advise on whether it's legal or not.
> 2) AdaCore adds the linking exception to GNAT-LLVM, which still might
> not clear up any confusion and would require 1.
> 3) You use a different Ada compiler with a more permissive licence, oh
> there aren't any.
> 4) You buy a licence from AdaCore, too expensive.
> 5) Write your own Ada compiler.
> 6) Use another language.
> 7) Write your own compiler for your own language.

Yes, that list itemizes the barriers-to-entry that forms AdaCore's business model. A profitable business must establish or inherit at least one barrier to entry, analogous to a military battle taking a hill that is easier to defend downhill than trying to battle uphill.

Plus there is:
8) Consult your legal counsel every time that you modify any of the steps in GNAT-LLVM's back-end Compilation Process to assure that it still remains an •Eligible• Compilation Process.

All that I am saying is: with respect to a GNAT-LLVM-generated executable that links to RLE, legally
a) it is a no-brainer if LLVM textual IR or bitcode thereof is definitively always construed to be an assembly language,
but if it is not, then
b) effort must be expended at each temptation to utilize the LLVM ecosystem's rich feature-set whether the eligibility of the Compilation Process got ruined by a violation of the GPL's or RLE's terms subtly sneaking in during opt's stages, especially plug-ins.

[Luke A. Guest]

On 24/06/2020 16:12, Optikos wrote:
>
> https://kristerw.blogspot.com/2017/08/gcc-low-level-ir-and-basic-code.html
>
> In some regards, RTL is analogous to either LLVM textual IR or LLVM bitcode IR. Dumping out GIMPLE IR from GCC to manipulate it via any GPL-noncompliant tool would certainly make the Compilation Process ineligible to be an Eligible Compilation Process in the RLE. But dumping out RTL IR via -fdump-rtl-all command-line option, then manipulating it via any GPL-noncompliant tool seems very likely to also make the Compilation Process ineligible to be an Eligible Compilation Process in the RLE. If so, then RLE granting its exception to GPLv3 in GNAT-LLVM is highly dependent on each possible plug-in during the optimization phase of LLVM's opt, because legally speaking LLVM textual IR or LLVM bitcode thereof could be construed as directly analogous to RTL.

GNAT-LLVM from what I've grepped doesn't contain any flags that are able
to dump any GCC RTL. You can -dump-ir which calls LLVMDumpModule or
-dump-bc which dumps LLVM's IR.

>> So, the options are:
>>
>> 1) AdaCore or FSF legal advise on whether it's legal or not.
>> 2) AdaCore adds the linking exception to GNAT-LLVM, which still might
>> not clear up any confusion and would require 1.
>> 3) You use a different Ada compiler with a more permissive licence, oh
>> there aren't any.
>> 4) You buy a licence from AdaCore, too expensive.
>> 5) Write your own Ada compiler.
>> 6) Use another language.
>> 7) Write your own compiler for your own language.
>
> Yes, that list itemizes the barriers-to-entry that forms AdaCore's business model. A profitable business must establish or inherit at least one barrier to entry, analogous to a military battle taking a hill that is easier to defend downhill than trying to battle uphill.
>
> Plus there is:
> 8) Consult your legal counsel every time that you modify any of the steps in GNAT-LLVM's back-end Compilation Process to assure that it still remains an •Eligible• Compilation Process.
>
> All that I am saying is: with respect to a GNAT-LLVM-generated executable that links to RLE, legally
> a) it is a no-brainer if LLVM textual IR or bitcode thereof is definitively always construed to be an assembly language,
> but if it is not, then
> b) effort must be expended at each temptation to utilize the LLVM ecosystem's rich feature-set whether the eligibility of the Compilation Process got ruined by a violation of the GPL's or RLE's terms subtly sneaking in during opt's stages, especially plug-ins.
>

So, I leave that open to others to answer, I don't know know.

My options are:

1) Write and Ada compiler.
2) Develop my own language without Ada or GNAT's baggage.
3) Find another language.

3 is an issue because there are very few which incorporate certain graet
features from Ada :(

[Simon Wright]

"Luke A. Guest" <lag...@archeia.com> writes:

> My options are:
>
> 1) Write and Ada compiler.
> 2) Develop my own language without Ada or GNAT's baggage.
> 3) Find another language.

Isn't there an option 0, carry on using GCC?

As a side note, the README.md in gnat-llvm says "This is a
work-in-progress research project that’s not meant for and shouldn’t be
used for industrial purposes. It’s meant to show the feasibility of
generating LLVM bitcode for Ada and to open the LLVM ecosystem to Ada,
including tools such as KLEE."

[Luke A. Guest]

On 24/06/2020 17:35, Simon Wright wrote:

> Isn't there an option 0, carry on using GCC?

Not really, as you well know that Apple dumped GCC years ago. Also,
using GCC for iOS is not possible AFAIK.

> As a side note, the README.md in gnat-llvm says "This is a
> work-in-progress research project that’s not meant for and shouldn’t be
> used for industrial purposes. It’s meant to show the feasibility of
> generating LLVM bitcode for Ada and to open the LLVM ecosystem to Ada,
> including tools such as KLEE."
>

Then for Apple stuff, we're all screwed :D

[Stephen Leake]

Until someone pays AdaCore to fully support LLVM. This stuff doesn't happen for free!

[Luke A. Guest]

Neither does creating and supporting open source projects based on the
language.

[Wesley Pan]

On Wednesday, June 24, 2020 at 11:18:58 AM UTC-7, Stephen Leake wrote:
> >
> > Then for Apple stuff, we're all screwed :D
>
> Until someone pays AdaCore to fully support LLVM. This stuff doesn't happen for free!

I would think it is in AdaCore's best interest to complete this effort sooner than later even if it is only with their own funds. LLVM would give them access to various target platforms (new and old), and thus customers, that they wouldn't immediately get with sticking with GCC.

-Wesley

[Optikos]

But if someone pays AdaCore to fully support LLVM, why would AdaCore merge LLVM stuff into FSF? Although RMS is less connected nowadays due to a political-correctness gaffe or two, a shotgun marriage of FSF and LLVM through the Ada backdoor would most certainly ruffle a few feathers at FSF, I would think.

[Optikos]

On Wednesday, June 24, 2020 at 11:35:09 AM UTC-5, Simon Wright wrote:

> "Luke A. Guest" writes:
>
> > My options are:
> >
> > 1) Write and Ada compiler.
> > 2) Develop my own language without Ada or GNAT's baggage.
> > 3) Find another language.
>
> Isn't there an option 0, carry on using GCC?

Yes, option 0 would support only Apple's Intel-based products (and perhaps still support PowerPC-based defunct products), not the new ARM-based Mac, which is the entire point of OP. Without GNAT-LLVM, no Ada compiler from any vendor on the new ARM-based Mac nor on iOS/iPadOS devices. So that is why 2 prior authors omitted option 0: because it is effectively a degenerate inferior not-quite-a-full-option.

> As a side note, the README.md in gnat-llvm says "This is a
> work-in-progress research project that’s not meant for and shouldn’t be
> used for industrial purposes. It’s meant to show the feasibility of
> generating LLVM bitcode for Ada and to open the LLVM ecosystem to Ada,
> including tools such as KLEE."

It is because of this warning, that I cannot place much trust in AdaCore firmly disclaiming the legal matter of generated executables or DLLs (that link to the runtime) ending up pure GPLed under some usages of LLVM opt, especially certain plug-ins, plus perhaps some other complicating Compilation Process that violates a subtle obligatory term in meeting the stricter Elligibile Compilation Process in the RLE.

[Simon Wright]

Optikos <ZUERCHER...@outlook.com> writes:

> Without paying a hefty proprietary-licensing fee to AdaCore, isn't
> GNAT-LLVM distributed only under pure GPLv3 without the Runtime
> Library Exception (RLE)? Wouldn't that mean that GNAT-LLVM on MacOS
> (and iOS) can be utilized by software distributed under GPL-compatible
> licenses, lest that software violate terms of GPLv3?

GCC itself is distributed under pure GPLv3, and the RLE[1] is irrelevant
to that distribution.

The gnat you are straining at is whether a compiler formed by merging
GNAT-LLVM with GCC can be used in an "eligible compilation process". If
so, the RLE will apply:

"You have permission to propagate a work of Target Code formed by
combining the Runtime Library with Independent Modules, even if such
propagation would otherwise violate the terms of GPLv3, provided that
all Target Code was generated by Eligible Compilation Processes. You
may then convey such a combination under terms of your choice,
consistent with the licensing of the Independent Modules."

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

A compilation process is "eligible"

"if it is done using GCC, alone or with other GPL-compatible
software, or if it is done without using any work based on GCC. For
example, using non-GPL-compatible Software to optimize any GCC
intermediate representations would not qualify as an Eligible
Compilation Process."

But!

(a) if you look at the LLVM license[2], you will see at the top that
it's the Apache License v2.0 (with some irrelevant extensions);

(b) in [3] & [4], the Apache License v2.0 is listed as GPLv3-compatible.

So! what's the problem? GNAT-LLVM clearly provides an eligible
compilation process.

[1] https://www.gnu.org/licenses/gcc-exception-3.1.en.html
[2] https://releases.llvm.org/10.0.0/LICENSE.TXT
[3]
http://gplv3.fsf.org/wiki/index.php/Compatible_licenses#GPLv3-compatible_licenses
[4] https://www.gnu.org/licenses/license-list.en.html#GPLCompatibleLicenses

[Simon Wright]

Optikos <ZUERCHER...@outlook.com> writes:

> On Wednesday, June 24, 2020 at 11:35:09 AM UTC-5, Simon Wright wrote:
>> "Luke A. Guest" writes:
>>
>> > My options are:
>> >
>> > 1) Write and Ada compiler.
>> > 2) Develop my own language without Ada or GNAT's baggage.
>> > 3) Find another language.
>>
>> Isn't there an option 0, carry on using GCC?
>
> Yes, option 0 would support only Apple's Intel-based products (and
> perhaps still support PowerPC-based defunct products), not the new
> ARM-based Mac, which is the entire point of OP. Without GNAT-LLVM, no
> Ada compiler from any vendor on the new ARM-based Mac nor on
> iOS/iPadOS devices. So that is why 2 prior authors omitted option 0:
> because it is effectively a degenerate inferior
> not-quite-a-full-option.

Thanks for rubbing my nose in this, you really didn't need to do that
since Luke has had a good go already (sorry, Luke, I'd forgotten that
other Ada users might want to develop for iOS - something they can't do
at the moment ofc, and who knows whether there'll be an apple-arm-darwin
GCC in the future)

>> As a side note, the README.md in gnat-llvm says "This is a
>> work-in-progress research project that’s not meant for and shouldn’t be
>> used for industrial purposes. It’s meant to show the feasibility of
>> generating LLVM bitcode for Ada and to open the LLVM ecosystem to Ada,
>> including tools such as KLEE."
>
> It is because of this warning, that I cannot place much trust in
> AdaCore firmly disclaiming the legal matter of generated executables
> or DLLs (that link to the runtime) ending up pure GPLed under some
> usages of LLVM opt, especially certain plug-ins, plus perhaps some
> other complicating Compilation Process that violates a subtle
> obligatory term in meeting the stricter Elligibile Compilation Process
> in the RLE.

You don't half go in for conspiracy theories! I don't think you can have
actually read that note in order to draw that conclusion from it.

[Luke A. Guest]

On 24/06/2020 19:55, Optikos wrote:
>> Until someone pays AdaCore to fully support LLVM. This stuff doesn't happen for free!
>
> But if someone pays AdaCore to fully support LLVM, why would AdaCore merge LLVM stuff into FSF? Although RMS is less connected nowadays due to a political-correctness gaffe or two, a shotgun marriage of FSF and LLVM through the Ada backdoor would most certainly ruffle a few feathers at FSF, I would think.
>

https://gcc.gnu.org/pipermail/gcc-patches/2020-June/547370.html

[Luke A. Guest]

On 24/06/2020 20:06, Optikos wrote:
> On Wednesday, June 24, 2020 at 11:35:09 AM UTC-5, Simon Wright wrote:
>> "Luke A. Guest" writes:
>>
>>> My options are:
>>>
>>> 1) Write and Ada compiler.
>>> 2) Develop my own language without Ada or GNAT's baggage.
>>> 3) Find another language.
>>
>> Isn't there an option 0, carry on using GCC?
>
> Yes, option 0 would support only Apple's Intel-based products (and perhaps still support PowerPC-based defunct products), not the new ARM-based Mac, which is the entire point of OP. Without GNAT-LLVM, no Ada compiler from any vendor on the new ARM-based Mac nor on iOS/iPadOS devices. So that is why 2 prior authors omitted option 0: because it is effectively a degenerate inferior not-quite-a-full-option.

It wouldn't support Apple's Intel stuff, they stopped developing GCC
around v4 IIRC, I know Simon has done porting work, I don't know how
much. But when I looked GCC always seemed to be missing flags for the
most recent OSes.

Apple also don't support PPC anymore, haven't for a number of years.

[Luke A. Guest]

On 24/06/2020 20:26, Simon Wright wrote:
>> Yes, option 0 would support only Apple's Intel-based products (and
>> perhaps still support PowerPC-based defunct products), not the new
>> ARM-based Mac, which is the entire point of OP. Without GNAT-LLVM, no
>> Ada compiler from any vendor on the new ARM-based Mac nor on
>> iOS/iPadOS devices. So that is why 2 prior authors omitted option 0:
>> because it is effectively a degenerate inferior
>> not-quite-a-full-option.
>
> Thanks for rubbing my nose in this, you really didn't need to do that
> since Luke has had a good go already (sorry, Luke, I'd forgotten that

Did I?

> other Ada users might want to develop for iOS - something they can't do
> at the moment ofc, and who knows whether there'll be an apple-arm-darwin
> GCC in the future)

Are you doing that?

[Luke A. Guest]

On 24/06/2020 20:18, Simon Wright wrote:
> Optikos <ZUERCHER...@outlook.com> writes:
>
>> Without paying a hefty proprietary-licensing fee to AdaCore, isn't
>> GNAT-LLVM distributed only under pure GPLv3 without the Runtime
>> Library Exception (RLE)? Wouldn't that mean that GNAT-LLVM on MacOS
>> (and iOS) can be utilized by software distributed under GPL-compatible
>> licenses, lest that software violate terms of GPLv3?
>
> GCC itself is distributed under pure GPLv3, and the RLE[1] is irrelevant
> to that distribution.

FSF GNAT is GPLv3 with linking exception. CE GNAT is pure GPLv3.

> But!
>
> (a) if you look at the LLVM license[2], you will see at the top that
> it's the Apache License v2.0 (with some irrelevant extensions);
>
> (b) in [3] & [4], the Apache License v2.0 is listed as GPLv3-compatible.

This is what I was getting at, but I don't really know what would happen
re licences if GPLv3 LE FSF GNAT is linked to the GPLv3 GNAT-LLVM
binding and I've always have not been sure, I've mentioned this before
on a number of platforms.

[Luke A. Guest]

On 24/06/2020 21:06, Luke A. Guest wrote:
>
> This is what I was getting at, but I don't really know what would happen
> re licences if GPLv3 LE FSF GNAT is linked to the GPLv3 GNAT-LLVM
> binding and I've always have not been sure, I've mentioned this before
> on a number of platforms.
>

It is their insistence on the pure GPLv3 that pissed us all off back
when they switched and is one of the reasons I've seriously considered
writing a new Ada compiler. But more recently, I'm looking into
developing a new language with Ada-like features, but smaller.

[Optikos]

On Wednesday, June 24, 2020 at 2:18:11 PM UTC-5, Simon Wright wrote:

Despite your focus exclusively on garden-variety unadorned LLVM itself, clearly the garden-variety unadorned LLVM is •not• the entirety of the back-end of OP's tool-chain to release a GNAT-LLVM-compiled app to Apple's Mac or iPhone or iPad app store(s), which is customary on nonjailbroken Apple devices. When submitting an Universal 2 app to the App Store, the developer submits LLVM IR (bitcode only, not textual, AKAIK). Reportedly,* Apple reserves the right to perform any closed-source proprietary transformations on that IR that it so pleases, including of course translating to machine code (but perhaps other proprietary closed-source optimizations too, such as peculiar to improved multiprocessor scheduling and/or battery-life). Apple's Rosetta 2 is closed source, hence violating the RLE's exception grant, precluding the Compilation Process from achieving the desired Eligible Compilation Process. Hence, the RLE's exception grant implodes, reverting the app to pure GPLv3, but since Apple's final steps of the Compilation Process are closed-source, the app is in violation of GPLv3 so GPLv3's license grant implodes, hence no right to copy the derivative-work executable whatsoever via the Apple App Store.

* The Apple Developer Agreement is reportedly protected by NDA. Any observations about the Apple Developer Agreement are from public media postings on 3rd-party websites. Btw, this NDA itself might be problematic for achieving GPLv3's terms, but that is left as an exercise for the interested reader.

In prior postings along this thread, I was actually trying to be politely circumspect and not be the messenger of the Draconian outcome above (that I knew already), but you directly challenged me for a revelatory analysis. At some level, I am sorry to be the bearer of bad news, because I would love to cheer GNAT-LLVM onward.

Disclaimer 1: This posting uses my aforementioned Wide legal theory of LLVM's IR is in fact an IR in RLE's terms, instead of the Narrow legal theory's LLVM textual IR being recategorized as mere assembly language. Presumably under the Narrow legal theory, Simon Wright's analysis stands, because the RLE and GPLv3 do not regulate what Apple does downstream with assembly language.

Disclaimer 2: I am not a lawyer who has passed a bar in any jurisdiction. This posting is merely my personal notes to myself of my own understanding for my own future reference. You and your legal counsel would need to perform your own analysis, using the legal system in your jurisdiction.

[cha...@adacore.com]

That's correct, there is no issue here. The GNAT LLVM compiler is a tool and is licensed under GPLv3, which is just fine and the proper license for a tool. The runtime which is linked with your executable comes from the gcc.gnu.org repository and contains the GCC RunTime exception license.

[Luke A. Guest]

On 25/06/2020 08:21, cha...@adacore.com wrote:

> That's correct, there is no issue here. The GNAT LLVM compiler is a tool and is licensed under GPLv3, which is just fine and the proper license for a tool. The runtime which is linked with your executable comes from the gcc.gnu.org repository and contains the GCC RunTime exception license.
>

Can you confirm that using FSF GNAT with GNAT-LLVM (GPLv3) does or does
not enable the IR clause in the GPLv3?

[cha...@adacore.com]

> > That's correct, there is no issue here. The GNAT LLVM compiler is a tool and is licensed under GPLv3, which is just fine and the proper license for a tool. The runtime which is linked with your executable comes from the gcc.gnu.org repository and contains the GCC RunTime exception license.
> >
>
> Can you confirm that using FSF GNAT with GNAT-LLVM (GPLv3) does or does
> not enable the IR clause in the GPLv3?

It does not and in any case, invoking this clause is a red herring since as explained in the license, the concern and what's not allowed is using an intermediate representation and feed it to a proprietary (non-GPL-compatible)
software to e.g. optimize it or further process it.
LLVM is a GPL-compatible Software, so this is irrelevant.

Arno

[Simon Wright]

"Luke A. Guest" <lag...@archeia.com> writes:

> On 24/06/2020 20:26, Simon Wright wrote:
>>> Yes, option 0 would support only Apple's Intel-based products (and
>>> perhaps still support PowerPC-based defunct products), not the new
>>> ARM-based Mac, which is the entire point of OP. Without GNAT-LLVM,
>>> no Ada compiler from any vendor on the new ARM-based Mac nor on
>>> iOS/iPadOS devices. So that is why 2 prior authors omitted option
>>> 0: because it is effectively a degenerate inferior
>>> not-quite-a-full-option.
>>
>> Thanks for rubbing my nose in this, you really didn't need to do that
>> since Luke has had a good go already (sorry, Luke, I'd forgotten that
>
> Did I?

Apologies! I certainly thought _someone_ had -- but now I can't even
find that. Must have been feeling guilty about something.

>> other Ada users might want to develop for iOS - something they can't
>> do at the moment ofc, and who knows whether there'll be an
>> apple-arm-darwin GCC in the future)
>
> Are you doing that?

No

[Luke A. Guest]

On 25/06/2020 11:25, Simon Wright wrote:
> "Luke A. Guest" <lag...@archeia.com> writes:
>
>>> Thanks for rubbing my nose in this, you really didn't need to do that
>>> since Luke has had a good go already (sorry, Luke, I'd forgotten that
>>
>> Did I?
>
> Apologies! I certainly thought _someone_ had -- but now I can't even
> find that. Must have been feeling guilty about something.

I'm not saying that IU haven't wanted iOS support, I have, as have others.

>>> other Ada users might want to develop for iOS - something they can't
>>> do at the moment ofc, and who knows whether there'll be an
>>> apple-arm-darwin GCC in the future)
>>
>> Are you doing that?
>
> No

Why not?

[Simon Wright]

Optikos has (at last) made clear his concerns about this: if it is
indeed the case that Apple require App Store developers to deliver
bitcode for further proprietary optimizations then there might be an
issue.

Depends on whether LLVM IR (which I understand is logically equivalent
to bitcode) can count as target code? I've seen it described as LLVM
assembler ...

[Simon Wright]

If you mean develop for iOS, I'm more into tools than apps.

If you mean an apple-arm-darwin GCC, that would be several bridges too
far for me.

[Luke A. Guest]

On 25/06/2020 12:03, Simon Wright wrote:

>> It does not and in any case, invoking this clause is a red herring
>> since as explained in the license, the concern and what's not allowed
>> is using an intermediate representation and feed it to a proprietary
>> (non-GPL-compatible) software to e.g. optimize it or further process
>> it.
>
> Optikos has (at last) made clear his concerns about this: if it is
> indeed the case that Apple require App Store developers to deliver
> bitcode for further proprietary optimizations then there might be an
> issue.
>
> Depends on whether LLVM IR (which I understand is logically equivalent
> to bitcode) can count as target code? I've seen it described as LLVM
> assembler ...
>

Indeed. The only thing I've found so far is this:

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

Quote from near the top:

'This means that apps can automatically “take advantage of new processor
capabilities we might be adding in the future, without you re-submitting
to the store.”'

From the apple docs it links to at the top:

"Bitcode is an intermediate representation of a compiled program. Apps
you upload to App Store Connect that contain bitcode will be compiled
and linked on the App Store. Including bitcode will allow Apple to
re-optimize your app binary in the future without the need to submit a
new version of your app to the App Store. "

So, looks like he's right.

[Luke A. Guest]

On 25/06/2020 12:25, Luke A. Guest wrote:

> Indeed. The only thing I've found so far is this:
>
> https://thenextweb.com/apple/2015/06/17/apples-biggest-developer-news-at-wwdc-that-nobodys-talking-about-bitcode/
>
> Quote from near the top:
>
> 'This means that apps can automatically “take advantage of new processor
> capabilities we might be adding in the future, without you re-submitting
> to the store.”'
>
> From the apple docs it links to at the top:
>
> "Bitcode is an intermediate representation of a compiled program. Apps
> you upload to App Store Connect that contain bitcode will be compiled
> and linked on the App Store. Including bitcode will allow Apple to
> re-optimize your app binary in the future without the need to submit a
> new version of your app to the App Store. "
>
> So, looks like he's right.
>

Just to add, this is just another nail in Ada's coffin for me.

[Optikos]

Arno, are you aware that garden-variety unadorned LLVM straight from llvm.org seems to be cleary •not• on-topic for OP's Apple-centric question along this entire thread? Submitting LLVM IR bitcode to the App Store for publication/distribution permits Apple to perform any proprietary closed-source manipulation of that bitcode IR that Apple desires. Unless LLVM bitcode IR is recategorized in all legal jurisdictions worldwide as mere assembly language (which might be the valid & proper case or might be on thin ice, perhaps varying by legal-system jurisdiction, or worse by each judge), this later closed-source processing of the app by Apple for nonjailbroken ARM-based Macs and iDevices to distribute via the App Store seems to violate terms of at least the RLE if not GPLv3 too.

Clearly, compiling with GNAT-LLVM & linking the runtime to an app's executable via garden-variety unadorned LLVM straight from llvm.org for distribution to jailbroken ARM-based iDevices and Macs would conform to your analysis, but Jerry in OP is likely not referring to that niche subset of Apple-world, so perhaps it is your analysis instead that is the red herring.

[Luke A. Guest]

On 25/06/2020 13:50, Luke A. Guest wrote:

>> From the apple docs it links to at the top:
>>
>> "Bitcode is an intermediate representation of a compiled program. Apps
>> you upload to App Store Connect that contain bitcode will be compiled
>> and linked on the App Store. Including bitcode will allow Apple to
>> re-optimize your app binary in the future without the need to submit a
>> new version of your app to the App Store. "
>>
>> So, looks like he's right.
>>
>
> Just to add, this is just another nail in Ada's coffin for me.
>

I think AdaCore's silence on this situation is deafening.

[Fabien Chouteau]

On Thursday, June 25, 2020 at 6:15:47 PM UTC+2, Optikos wrote:
> this later closed-source processing of the app by Apple for nonjailbroken ARM-based Macs and iDevices to distribute via the App Store seems to violate terms of at least the RLE if not GPLv3 too.

The Apple app store is incompatible with the GPL since long ago: https://www.fsf.org/blogs/licensing/more-about-the-app-store-gpl-enforcement

I don't see anything new here.

[Optikos]

On Tuesday, June 30, 2020 at 6:16:40 AM UTC-5, Fabien Chouteau wrote:
> On Thursday, June 25, 2020 at 6:15:47 PM UTC+2, Optikos wrote:
> > this later closed-source processing of the app by Apple for nonjailbroken ARM-based Macs and iDevices to distribute via the App Store seems to violate terms of at least the RLE if not GPLv3 too.
>
> The Apple app store is incompatible with the GPL since long ago: https://www.fsf.org/blogs/licensing/more

> about-the-app-store-gpl-enforcement

Yes, when the developer's app is GPLed, the App Store's terms and the GPL's terms are mutually incompatible. Historically, GPLing an app would have been by developer choice (unless somehow violating the RLE which was rare in practice because using garden-variety unmodified IR-unadorned GNAT, GCC, and so forth resulted in an Eligible Compilation Process in RLE).

> I don't see anything new here.

What is new here is that there appear to be well-reasoned ways (e.g., the Wide legal theory along this thread) that GNAT-LLVM could •force• a developer's app to GPLed against the developer's will by easy-to-enact-in-GNAT-LLVM violations of the RLE's terms that cause the Compilation Process to not achieve the stricter Eligible Compilation Process definition, due to Apple's closed-source manipulations of LLVM IR bitcode.

Perhaps the work-around is that GNAT-LLVM-based developers of apps should •never• submit LLVM IR bitcode to Apple's App Store's app-intake procedure. In the past as far back as 2015, submitting bitcode instead of machine code was optional. It is unclear with the new ARM-based Macs, whether that optionality will continue in the future, or whether that optionality has already been curtailed.

(Conversely, under the Narrow legal theory along this thread, your claim is correct, nothing has changed: if an app-developer doesn't want to suffer the mutual incompatibility of the GPL and Apple App Store, then don't choose GPL as the license for the app, because despite its name LLVM IR bitcode is merely assembly language which is unregulated by RLE.)

[Luke A. Guest]

That is for uploading of GPL'd software to the app store, that is not
what we are talking about here. This is a completely different matter.

What we are talking about is whether the GNAT-LLVM backend violates the
GPL IR clause, enacting it in the final binary.

We need clarification on whether the translation from GCC's IR to LLVM's
IR invokes this clause. I'm not sure if GNAT final IR before the
GNAT-LLVM backend is GENERIC or GIMPLE.

I've had a quick look in GNAT-LLVM and I cannot see any flags enabling
the output of GCC's IR, only LLVM's IR.

[Luke A. Guest]

On 30/06/2020 13:28, Optikos wrote:

>> I don't see anything new here.
>
> What is new here is that there appear to be well-reasoned ways (e.g., the Wide legal theory along this thread) that GNAT-LLVM could •force• a developer's app to GPLed against the developer's will by easy-to-enact-in-GNAT-LLVM violations of the RLE's terms that cause the Compilation Process to not achieve the stricter Eligible Compilation Process definition, due to Apple's closed-source manipulations of LLVM IR bitcode.
>
> Perhaps the work-around is that GNAT-LLVM-based developers of apps should •never• submit LLVM IR bitcode to Apple's App Store's app-intake procedure. In the past as far back as 2015, submitting bitcode instead of machine code was optional. It is unclear with the new ARM-based Macs, whether that optionality will continue in the future, or whether that optionality has already been curtailed.

I already linked in a previous message proof that you do have to upload
the output from LLVM as bitcode to the appstore so Apple can optimise
based on intended target device.

[cha...@adacore.com]

> That is for uploading of GPL'd software to the app store, that is not
> what we are talking about here. This is a completely different matter.
>
> What we are talking about is whether the GNAT-LLVM backend violates the
> GPL IR clause, enacting it in the final binary.
>
> We need clarification on whether the translation from GCC's IR to LLVM's
> IR invokes this clause. I'm not sure if GNAT final IR before the
> GNAT-LLVM backend is GENERIC or GIMPLE.

GNAT LLVM doesn't use nor depend on GCC at all: it goes directly from the GNAT
tree to LLVM bitcode, there is never any GENERIC nor GIMPLE in sight by design
and never can be (unlike with the old DraggonEgg FWIW).

> I've had a quick look in GNAT-LLVM and I cannot see any flags enabling
> the output of GCC's IR, only LLVM's IR.

See above.

By the way the reason I haven't answered other messages is mainly because I am not familiar with Apple's specific constraints here, so I'd rather not make any statement about them rather than making wrong statements and you shouldn't draw any conclusion from the fact that I haven't replied to some of the messages in this thread.

Arno

[Luke A. Guest]

On 30/06/2020 15:35, cha...@adacore.com wrote:

>> We need clarification on whether the translation from GCC's IR to LLVM's
>> IR invokes this clause. I'm not sure if GNAT final IR before the
>> GNAT-LLVM backend is GENERIC or GIMPLE.
>
> GNAT LLVM doesn't use nor depend on GCC at all: it goes directly from the GNAT

Ok, makes sense.

> tree to LLVM bitcode, there is never any GENERIC nor GIMPLE in sight by design
> and never can be (unlike with the old DraggonEgg FWIW).

But, GNAT is 1 part of GCC and the GPLv3 mentions IR, what constitutes
the IR? Surely it covers the Ada AST IR?

Does the GPL infect across the different IR boundaries?

>> I've had a quick look in GNAT-LLVM and I cannot see any flags enabling
>> the output of GCC's IR, only LLVM's IR.
>
> See above.
>
> By the way the reason I haven't answered other messages is mainly because I am not familiar with Apple's specific constraints here, so I'd rather not make any statement about them rather than making wrong statements and you shouldn't draw any conclusion from the fact that I haven't replied to some of the messages in this thread.

Fine, but surely AdaCore has access to a legal department?

[cha...@adacore.com]

> > By the way the reason I haven't answered other messages is mainly because I am not familiar with Apple's specific constraints here, so I'd rather not make any statement about them rather than making wrong statements and you shouldn't draw any conclusion from the fact that I haven't replied to some of the messages in this thread.
>
> Fine, but surely AdaCore has access to a legal department?

Yes, and this legal department is busy processing customer requests, it can't process requests coming from e.g. c.l.a

Arno

[Luke A. Guest]

And this is why this issue will persist and will drive people away from
using Ada. Because they won't be able to use it the way they want to.

[Optikos]

Then perhaps this thread's Narrow versus Wide 2 legal theories should be transcribed into a GitHub issue at https://github.com/AdaCore/gnat-llvm/issues so that when/if GNAT-LLVM is to ever leave its current “experimental” state of being “a work-in-progress research project that's not meant for and shouldn't be used for industrial purposes [that i]s meant to show the feasibility of generating LLVM •bitcode• for Ada” (emphasis added, as quoted from GNAT-LLVM repository's main page at GitHub). At the point that GNAT-LLVM is no longer to be deemed experimental, there should have been a long-standing open (!) (not closed!) issue that reminds AdaCore's legal department to tie up this loose end, even if that is years from now. By that point, there should be a strong track record of technical knowledge regarding Apple's bitcode submission policies to the App Store to relay to the attorneys so that they can simply turn the legal crank to make a decision/adjustments of whether/how GNAT-LLVM is to transition out of experimental status. Also by that point, (despite RMS's own distance nowadays) there might even be more legal precedent/statement from at least one member of the set {FSF, Software Freedom Conservancy, Software Freedom Law Center} regarding the RLE's true meaning of IR vis a vis assembly-language-esque IR that could be applicable to GNAT-LLVM's emission of LLVM IR, textual or bitcode (and perhaps to JVM bytecode and perhaps to Microsoft CIL). It seems that it would be the executives at AdaCore and/or FSF in consultation with their legal teams at that time (i.e., when this proposed GitHub issue gets worked) who would make that final wise/well-informed decision and/or those wise/well-informed adjustments—not engineers or mid-level managers who might post to c.l.a.

Is there a green light to submit such an issue at https://github.com/AdaCore/gnat-llvm/issues as described above?

[Luke A. Guest]

On 30/06/2020 21:15, Simon Wright wrote:
> Optikos <ZUERCHER...@outlook.com> writes:
>

>> By that point, there should be a strong track record of technical
>> knowledge regarding Apple's bitcode submission policies to the App
>> Store to relay to the attorneys so that they can simply turn the legal
>> crank to make a decision/adjustments of whether/how GNAT-LLVM is to
>> transition out of experimental status.
>

> I'd have thought that AdaCore's response to this idea would be to ask
> where you got the idea that iOS & the App Store would feature as a
> candidate target.
>

I'm developing SDLAda, there are mobile targets. I don't see why Ada
shouldn't. Jesus, even COBOL can compile to mobile according to an
article I read a while ago. If AdaCore and Ada users want people not
thinking that Ada is an ancient language, then it needs to wake up,
smell the coffee and get on mobile.

[Wesley Pan]

On Tuesday, June 30, 2020 at 1:52:25 PM UTC-7, Luke A. Guest wrote:
>
> I'm developing SDLAda, there are mobile targets. I don't see why Ada
> shouldn't. Jesus, even COBOL can compile to mobile according to an
> article I read a while ago. If AdaCore and Ada users want people not
> thinking that Ada is an ancient language, then it needs to wake up,
> smell the coffee and get on mobile.

I COMPLETELY agree with Luke! We need Ada to expand to things like mobile, gaming, and other "more exciting" markets to help attract the new generations of software engineers and to stay relevant in the public's eyes. The gaming industry alone rivals that of Hollywood. By end of 2019, GTA 5 sold more than 100 million copies worldwide, earning its publisher more than $6 billion on a $265 million development budget. That's not chump change. How can members of the Ada community ever really jump into such industries if the same issues like the license keep coming up as road blocks?!

I'm not in any way suggesting the Ada community give up its focus on the safety and reliability angle. Those are very important too. But, if you were to have affordable/free Ada tools for mobile/gaming on one side, and expensive tools for the next-gen Mars rover on the other side, which do you think would attract more end users?

BTW, even the new "cool" Rust language is being used to develop apps for mobile. Ada apps....?

[Simon Wright]

"Luke A. Guest" <lag...@archeia.com> writes:

> On 30/06/2020 21:01, Simon Wright wrote:
>
>> There just might be a way round this: write your own clean-room RTS and
>> licence it however you please! If you didn't need tasking or most of the
>> Annexes, it wouldn't be that bad.
>>
>
> Wrong. There's still the issue of "what constitutes IR" as I've spelt
> out numerous times. GNAT AST IR -> LLVM IR and the conversion process
> and whether the IR clause is activated.

No.

The RTS released with GNAT CE has had the runtime exception removed, so
it's pure GPL. The RTS released to customers is 99.99% the same, but it
hasn't had the runtime exception removed. Likewise the FSF GCC RTS. So
*as far as the licensing is concerned* an FSF user is in the same
position as a supported user; but supported users get support!

The only reason that the GPL and the runtime exception are involved at
all is because the RTS is released under those terms. If I write my own
(clean-room) runtime under say the MIT license then the fact that a
developer uses the GCC compiler (or GNAT-LLVM) has no effect on how they
propagate the product; and since the GPL and the runtime exception aren't
involved in the first place, using LLVM IR can't make any difference.

[Luke A. Guest]

[Simon Wright]

Optikos <ZUERCHER...@outlook.com> writes:

> By that point, there should be a strong track record of technical
> knowledge regarding Apple's bitcode submission policies to the App
> Store to relay to the attorneys so that they can simply turn the legal
> crank to make a decision/adjustments of whether/how GNAT-LLVM is to
> transition out of experimental status.

[Simon Wright]

cha...@adacore.com writes:

>> That is for uploading of GPL'd software to the app store, that is not
>> what we are talking about here. This is a completely different
>> matter.
>>
>> What we are talking about is whether the GNAT-LLVM backend violates
>> the GPL IR clause, enacting it in the final binary.
>>
>> We need clarification on whether the translation from GCC's IR to
>> LLVM's IR invokes this clause. I'm not sure if GNAT final IR before
>> the GNAT-LLVM backend is GENERIC or GIMPLE.
>
> GNAT LLVM doesn't use nor depend on GCC at all: it goes directly from
> the GNAT tree to LLVM bitcode, there is never any GENERIC nor GIMPLE
> in sight by design and never can be (unlike with the old DraggonEgg
> FWIW).

It seems to me that there's a lot of argument about things which can't
or won't be changed.

AdaCore have produced GNAT-LLVM as a proof of concept, aimed really at
targets not supported by GCC but of interest to AdaCore's customers.

GNAT-LLVM code itself is (C) AdaCore, and is GPLv3. The gcc/ada code is
(C) FSF, and is GPLv3.

No change there.

The current build takes the RTS from FSF GCC, though clearly it could
take it from elsewhere (e.g. some bare metal RTS).

That RTS is (C) FSF, GPLv3 + runtime exception.

Some here have thought, Aha! LLVM, RTS with runtime exception, people
could produce apps for iOS!!!!

Then, cold reality strikes: it looks as though there's a conflict
between the actual terms of the runtime exception and Apple's
requirements for code to be submitted to the App Store (it needs to be
in LLVM IR or equivalent); the code would very likely lose the
protection of the runtime license umbrella.

Now, guys, given that there's Apple on one side standing on a mountain
of money and a prickly attitude to what they'll accept for their app
store, and on the other side a very much smaller developer community,
who's going to risk going to court to put a GNAT app on to the App
Store?

Whether you could make such an app and run it on iPhones privately,
without going through Apple & the App Store, I don't know. I'm sure the
NSA can.

================================

[Luke A. Guest]

On 30/06/2020 23:07, Wesley Pan wrote:
> On Tuesday, June 30, 2020 at 1:52:25 PM UTC-7, Luke A. Guest wrote:
>>
>> I'm developing SDLAda, there are mobile targets. I don't see why Ada
>> shouldn't. Jesus, even COBOL can compile to mobile according to an
>> article I read a while ago. If AdaCore and Ada users want people not
>> thinking that Ada is an ancient language, then it needs to wake up,
>> smell the coffee and get on mobile.
>
> I COMPLETELY agree with Luke! We need Ada to expand to things like mobile, gaming, and other "more exciting" markets to help

Thanks :)

> attract the new generations of software engineers and to stay relevant in the public's eyes. The gaming industry alone rivals that of Hollywood. By end of 2019, GTA 5 sold more than 100 million copies worldwide, earning its publisher more than $6 billion on a $265 million development budget. That's not chump change. How can members of the Ada community ever really jump into such industries if the same issues like the license keep coming up as road blocks?!

I came out of the game industry 15 years ago and automatically went
straight to Ada because I thought it was a good fit.

> I'm not in any way suggesting the Ada community give up its focus on the safety and reliability angle. Those are very important too. But, if you were to have affordable/free Ada tools for mobile/gaming on one side, and expensive tools for the next-gen Mars rover on the other side, which do you think would attract more end users?
>
> BTW, even the new "cool" Rust language is being used to develop apps for mobile. Ada apps....?
>

Exactly.

[Luke A. Guest]

On 30/06/2020 22:57, Simon Wright wrote:
> No.

No.

> The RTS released with GNAT CE has had the runtime exception removed, so

I don't care about GNAT CE, I don't use it, never have because it has
the LE removed.

> it's pure GPL. The RTS released to customers is 99.99% the same, but it
> hasn't had the runtime exception removed. Likewise the FSF GCC RTS. So

Nope. The FSF GCC has the LE in the COPYING.RUNTIME file.

> *as far as the licensing is concerned* an FSF user is in the same
> position as a supported user; but supported users get support!
>
> The only reason that the GPL and the runtime exception are involved at
> all is because the RTS is released under those terms. If I write my own
> (clean-room) runtime under say the MIT license then the fact that a
> developer uses the GCC compiler (or GNAT-LLVM) has no effect on how they
> propagate the product; and since the GPL and the runtime exception aren't
> involved in the first place, using LLVM IR can't make any difference.
>

Again, you're missing the whole point of this thread, it's the IR not
the runtime, that's the issue.

[Optikos]

On Tuesday, June 30, 2020 at 5:40:13 PM UTC-5, Simon Wright wrote:

Gee, either
a) we all concurrently pulled it out of thin air via overactive imagination as you imply,
or
b) the following extant events & facts transpired:

At least an engineer at AdaCore (if not AdaCore speaking as an organization) wrote the following on the GNAT-LLVM repository's README.md:

“[GNAT-LLVM] is a work-in-progress research project that's not meant for and shouldn't be used for industrial purposes. It's meant to show the feasibility of generating LLVM ••bitcode•• for Ada.” (emphasis added)

LLVM.org did not organically produce bitcode out of their own volition. Bitcode was Apple's idea, Apple's design, contributed by Apple to benefit primarily Apple as a strategic technology to facilitate Apple's OS-optimization & processor-switcheroo goals without Apple begging all app developers to resubmit a plethora of minor-variation apps every time Apple has a bright idea or Big New Thing. So when GNAT-LLVM's README.md is explicitly calling out bitcode emission as the A#1 top-priority reason for GNAT-LLVM to exist, by using that very term bitcode, it is quite clear that the intended reading of README.md is referring to the Apple-Apple-Appleness of bitcode since bitcode was announced at Apple's Worldwide Developer Conference in June 2015 as a key technology related to App Store submission and downstream proprietary processing by Apple post-submission:

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

[Fabien Chouteau]

On Wednesday, July 1, 2020 at 6:46:48 AM UTC+2, Optikos wrote:
> On Tuesday, June 30, 2020 at 5:40:13 PM UTC-5, Simon Wright wrote:
> > Optikos writes:
> >
> Gee, either
> a) we all concurrently pulled it out of thin air via overactive imagination as you imply,
> or
> b) the following extant events & facts transpired:

The answer is a).

> it is quite clear that the intended reading of README.md is referring to the Apple-Apple-Appleness of bitcode since bitcode was announced at Apple's Worldwide Developer Conference in June 2015 as a key technology related to App Store submission and downstream proprietary processing by Apple post-submission:
>

It seems like you focus too much on details of a simple README. LLVM bitcode is sometimes used to talk about the general LLVM IR.

The example use case mentioned by the README are bringing more tooling to the Ada ecosystem, for instance with KLEE, or "connecting the GNAT front-end to the LLVM code generator".

It took time and effort to publish GNAT-LLVM on GitHub, and AdaCore had absolutely no obligation to do so. To be honest, I am personally a bit disappointed to see such a long discussion on what is allegedly not possible to do with GNAT-LLVM (and was absolutely not possible before anyway), rather than all the possibilities that GNAT-LLVM opens.

[Simon Wright]

Fabien Chouteau <fabien....@gmail.com> writes:

> It took time and effort to publish GNAT-LLVM on GitHub, and AdaCore
> had absolutely no obligation to do so. To be honest, I am personally a
> bit disappointed to see such a long discussion on what is allegedly
> not possible to do with GNAT-LLVM (and was absolutely not possible
> before anyway), rather than all the possibilities that GNAT-LLVM
> opens.

Personally, I thank AdaCore for making such an interesting project
available.

A couple of postings down Jeffrey Carter quoted this, which seems apt in
the current context:

"Propose to an Englishman any principle, or any instrument, however
admirable, and you will observe that the whole effort of the English
mind is directed to find a difficulty, a defect, or an impossibility
in it. If you speak to him of a machine for peeling a potato, he will
pronounce it impossible: if you peel a potato with it before his
eyes, he will declare it useless, because it will not slice a
pineapple."

Charles Babbage

[Simon Wright]

"Luke A. Guest" <lag...@archeia.com> writes:

> On 30/06/2020 22:57, Simon Wright wrote:

>> The RTS released to customers is 99.99% the same, but it
>> hasn't had the runtime exception removed. Likewise the FSF GCC RTS. So
>
> Nope. The FSF GCC has the LE in the COPYING.RUNTIME file.

I don't understand your point.The preamble in COPYING.RUNTIME says

This GCC Runtime Library Exception ("Exception") is an additional
permission under section 7 of the GNU General Public License, version
3 ("GPLv3"). It applies to a given file (the "Runtime Library") that
bears a notice placed by the copyright holder of the file stating
that the file is governed by GPLv3 along with this Exception.

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.

If GNAT CE was inadvertently released with COPYING.RUNTIME there would
be no effect because none of the RTS files "bears a notice placed by the
copyright holder of the file stating that the file is governed by GPLv3
along with this Exception".

>> The only reason that the GPL and the runtime exception are involved
>> at all is because the RTS is released under those terms. If I write
>> my own (clean-room) runtime under say the MIT license then the fact
>> that a developer uses the GCC compiler (or GNAT-LLVM) has no effect
>> on how they propagate the product; and since the GPL and the runtime
>> exception aren't involved in the first place, using LLVM IR can't
>> make any difference.
>
> Again, you're missing the whole point of this thread, it's the IR not
> the runtime, that's the issue.

If you want to use the FSF Ada RTS, you run up against this in the LE:

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

One would expect you'll have a difficult time persuading anyone that
something called "LLVM Intermediate Representation" isn't an
intermediate representation.

[1] says "The LLVM code representation is designed to be used in three
different forms: as an in-memory compiler IR, as an on-disk bitcode
representation (suitable for fast loading by a Just-In-Time compiler),
and as a human readable assembly language representation", which to me
precisely matches "data in any format that is used as a compiler
intermediate representation, or used for producing a compiler
intermediate representation".

[1] https://llvm.org/docs/LangRef.html#introduction

[Optikos]

On Wednesday, July 1, 2020 at 4:23:30 AM UTC-5, Fabien Chouteau wrote:
> On Wednesday, July 1, 2020 at 6:46:48 AM UTC+2, Optikos wrote:
> > On Tuesday, June 30, 2020 at 5:40:13 PM UTC-5, Simon Wright wrote:
> > > Optikos writes:
> > >
> > Gee, either
> > a) we all concurrently pulled it out of thin air via overactive imagination as you imply,
> > or
> > b) the following extant events & facts transpired:
>
> The answer is a).
>
> > it is quite clear that the intended reading of README.md is referring to the Apple-Apple-Appleness of bitcode since bitcode was announced at Apple's Worldwide Developer Conference in June 2015 as a key technology related to App Store submission and downstream proprietary processing by Apple post-submission:
> >
>
> It seems like you focus too much on details of a simple README.

In the desert, the only remaining single drop of water in the water-bottle is all that there is to drink.

> LLVM bitcode is sometimes used to talk about the general LLVM IR.
>
> The example use case mentioned by the README are bringing more tooling to the Ada ecosystem, for
> instance with KLEE, or "connecting the GNAT front-end to the LLVM code generator".
>
> It took time and effort to publish GNAT-LLVM on GitHub, and AdaCore had absolutely no obligation to do
> so. To be honest, I am personally a bit disappointed to see such a long discussion on what is allegedly
> not possible to do with GNAT-LLVM (and was absolutely not possible before anyway), rather than all the
> possibilities that GNAT-LLVM opens.

The reason for the long discussion is that there are 2 valid legal theories in play, detailed in prior postings along this thread:
1) the Narrow legal theory (i.e., LLVM IR is merely RLE's assembly language.) which permits the RLE's exception grant to proceed for the app, permitting the app's license vast freedom to not be GPLv3
versus
2) the Wide legal theory (i.e., LLVM IR is RLE's IR due to both names literally being IR.) which causes RLE's exception grant to be elided, reverting the license of the app to pure GPLv3.

If all members of the set {AdaCore, FSF, SFC, SFLC} were over the years to have unanimously sided with just 1 of those 2 legal theories in a history of public statements, then this entire thread would have been quite short (or perhaps OP would never have been posted at all). Again people who are walking in the desert diligently try to discern where water sources might or might not be before walking that direction only to find the perceived shimmering pool of water a mirage. Better to expend a few words on c.l.a than to expend a few years in ill-fated software development on GNAT-LLVM-based app development to learn the hard way if the Wide legal theory eventually prevails.

[Simon Wright]

Simon Wright <si...@pushface.org> writes:

> "The LLVM code representation is designed to be used in three
> different forms: as an in-memory compiler IR, as an on-disk bitcode
> representation (suitable for fast loading by a Just-In-Time compiler),
> and as a human readable assembly language representation", which to me
> precisely matches "data in any format that is used as a compiler
> intermediate representation, or used for producing a compiler
> intermediate representation".

On thinking about this further, can't help wondering whether this is
deliberate.

[Optikos]

On Thursday, July 2, 2020 at 4:54:29 AM UTC-5, Simon Wright wrote:

By whom? For what purpose?

[Wesley Pan]

On Wednesday, July 1, 2020 at 2:23:30 AM UTC-7, Fabien Chouteau wrote:
> It took time and effort to publish GNAT-LLVM on GitHub, and AdaCore had absolutely no obligation to do so. To be honest, I am personally a bit disappointed to see such a long discussion on what is allegedly not possible to do with GNAT-LLVM (and was absolutely not possible before anyway), rather than all the possibilities that GNAT-LLVM opens.

Hi Fabien,

That's a fair point. As with any compiler related development (and software in general), I'm sure the amount of time and effort it took to create GNAT-LLVM was significant. Aside from the licensing issue/debate, it is a really great contribution to the Ada community and I hope it becomes production quality in the very near future.

AdaCore is the main (if not only) company that continues to make innovative and very helpful tools related to Ada (e.g. libadalang and LearnAda). As you pointed out, AdaCore was not obligated to make such contributions. GNAT-LLVM could very well have been kept in closed doors to only further AdaCore's internal development.

When news about GNAT-LLVM first came out, I for one thought it would finally allow people to create IOS apps in Ada and to further the adoption of the language. Sadly, not sure that will ever happen now...

-Wesley

[gautier...@hotmail.com]

On Wednesday, July 1, 2020 at 11:23:30 AM UTC+2, Fabien Chouteau wrote:

> It took time and effort to publish GNAT-LLVM on GitHub, and AdaCore had absolutely no obligation to do so. To be honest, I am personally a bit disappointed to see such a long discussion on what is allegedly not possible to do with GNAT-LLVM (and was absolutely not possible before anyway), rather than all the possibilities that GNAT-LLVM opens.

There is a bias here: the people discussing on comp.lang.ada tend to be busy... discussing on comp.lang.ada - and less busy doing actual programming. Chatting and programming are incompatible activities IMHO. At least you cannot do both at exactly the same time...

[anti...@math.uni.wroc.pl]

Why doubt? FSF clearly did not want what Apple is doing now.
Apple understood this well, left GCC developement and started
promoting LLVM. FSF lawyers formulated appropriate licencing
language. So the remaing question is if they did good job.
Basically folks here are searching for loophole. Loopholes happen,
but FSF was careful, so do not bet on this.

--
Waldek Hebisch

[Optikos]

On Friday, July 3, 2020 at 12:18:42 PM UTC-5, anti...@math.uni.wroc.pl wrote:
> Simon Wright wrote:

These have been my exact concurring conclusions as well for over 2 years now, when I back then ceased coding up my own variant resembling what is now known as GNAT-LLVM. Some of my design/coding work was hinted at in multiple of my postings here on c.l.a. back then. I figured out these ••chilling effects•• on my own over 2 years ago.

[Jerry]

On Monday, June 22, 2020 at 3:53:01 PM UTC-7, Jerry wrote:
> Apple is beginning its third nightmare transition to a new processor family. What does this mean for Ada on macOS?
>
> Jerry
OP here. Did this thread ever give a simple answer? From my perspective it sort of ran off into the weeds. I use GNAT for my personal research projects on my Mac. I don't sell the software.
Jerry

[Luke A. Guest]

As long as you don't want to put anything up on the appstore, you'll be
fine. Just need a port of the compiler, use gnat-llvm, although I've not
built it on macos, yet.

[Simon Wright]

"Luke A. Guest" <lag...@archeia.com> writes:

I last built it (on macOS, ofc) on 24 June.

Interestingly, it fails in a similar way to the bug I just filed:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99020

[Brian Drummond]

Third?

6502
68000 family
Power PC
Intel x86(_64)
ARM

-- Brian

[Andreas ZEURCHER]

The 6502 was on the Apple I and Apple II so non sequitur as much as Apple's Z-80 CP/M plug-in board also for the Apple II. The 680X0 was the initial ISA on the 1st Mac. So Jerry is correct: 3 transitions 1) 680X0-to-POWER, 2) POWER-to-x86, 3) x86-to-ARM. The only way to get to more than 3 processor transitions on Mac is to consider POWER-to-x86-32 and then x86-32-to-x86-64 as 2 full-fledged transitions, which they sort of were but sort of weren't.