Gnat 2021 GPL Community Edition Ada 202x compiler released(adacore.com)
adacore.com
Gnat 2021 GPL Community Edition Ada 202x compiler released
https://www.adacore.com/download
82 comments
Such a shame there is no macOS support for the new '2021 Community Edition', for either x64 or the newer Apple silicon (M1). As ARM is supported for other platforms (even as a cross compiler only) - not sure why the whole Apple community is being missed out in this update, for both x64 and ARM. Guess AdaCore customers don't use Apple products any more, so hence no availability for the Community Edition either..? One of the benefits of using Ada was the great cross platform support for Linux, Window, and previously macOS.
There's an open source distribution of GNAT for macOS here: https://sourceforge.net/projects/gnuada/files/GNAT_GCC%20Mac...
There is cross-platform support - just ada-market specific ( qnx, vxworks, linux, windows, etc) and for all kinds of embedded architectures.
I don't think osx is a target market in any way : their customers are unlikely to use macs in production.
I don't think osx is a target market in any way : their customers are unlikely to use macs in production.
to add to the ada saga, RHEL has dropped providing FSF gnat since redhat 6.
very big loss to not have ada on one of the big linux distributions.
(build your own! yes, it can be done...)
edit. fixed wrong word
very big loss to not have ada on one of the big linux distributions.
(build your own! yes, it can be done...)
edit. fixed wrong word
I'm half-obsessed with C interoperability in a variety of languages. I know Ada (or GNAT) has a C FFI, and I've done a little investigation/experimentation but not much.
Here are a few questions, which probably don't have an answer in the Ada standard but might in specific implementations:
* Is there a way to declare data layouts to have compatibility with C, similar to #[repr(C)] in rust?
* Is there a way to catch C++ exceptions?
* Is there a way to catch C longjmps()?
* Is there a way to have some kind of custom control over ABI issues, e.g. define custom FFIs to langauges with a different ABI? Or anything close to this? For that matter, does any language have something like this or does it not make sense?
Here are a few questions, which probably don't have an answer in the Ada standard but might in specific implementations:
* Is there a way to declare data layouts to have compatibility with C, similar to #[repr(C)] in rust?
* Is there a way to catch C++ exceptions?
* Is there a way to catch C longjmps()?
* Is there a way to have some kind of custom control over ABI issues, e.g. define custom FFIs to langauges with a different ABI? Or anything close to this? For that matter, does any language have something like this or does it not make sense?
* Is there a way to declare data layouts to have compatibility with C, similar to #[repr(C)] in rust?
Yes, and if you have a C header file, gcc can even translate most struct definitions for you. Here's an example of a "thin" binding generated that way: https://github.com/JeremyGrosser/notcursesada/blob/master/sr...
* Is there a way to catch C++ exceptions?
Yes. https://www.adacore.com/gems/gem-114-ada-and-c-exceptions
* Is there a way to catch C longjmps()?
By default, the GNAT runtime uses setjmp/longjmp to implement exceptions. I'm not sure how you'd connect that to a C library's setjmp though.
* Is there a way to have some kind of custom control over ABI issues, e.g. define custom FFIs to langauges with a different ABI? Or anything close to this? For that matter, does any language have something like this or does it not make sense?
ABIs are selected with the Convention aspect. Conventions are implementation defined and would require patches to the compiler to add new ones. GNAT currently supports Assembler, C, CPP, COBOL, and Fortran calling conventions.
Yes, and if you have a C header file, gcc can even translate most struct definitions for you. Here's an example of a "thin" binding generated that way: https://github.com/JeremyGrosser/notcursesada/blob/master/sr...
* Is there a way to catch C++ exceptions?
Yes. https://www.adacore.com/gems/gem-114-ada-and-c-exceptions
* Is there a way to catch C longjmps()?
By default, the GNAT runtime uses setjmp/longjmp to implement exceptions. I'm not sure how you'd connect that to a C library's setjmp though.
* Is there a way to have some kind of custom control over ABI issues, e.g. define custom FFIs to langauges with a different ABI? Or anything close to this? For that matter, does any language have something like this or does it not make sense?
ABIs are selected with the Convention aspect. Conventions are implementation defined and would require patches to the compiler to add new ones. GNAT currently supports Assembler, C, CPP, COBOL, and Fortran calling conventions.
"Conventions are implementation defined and would require patches to the compiler to add new ones."
Is the implementation of a Convention isolated enough that it would make sense to be extensible?
One thing I had in mind is something like Postgres. Some functions in Postgres are called in a specific way that converts arguments into an array first, and handles SQL NULL values. If I were to define this as a new Convention, it would inherit a lot from the "C" Convention, but would do some transformations first.
If it could handle a longjmp() as well, then the new Convention would also do whatever setup (manipulate some global variables and call setjmp()) so that the caller doesn't have to worry about the longjmp().
The challenge with handling longjmp() in rust is that you can't call setjmp() as a normal FFI function (because it can return twice, like fork(), which is not a normal control flow). Also, longjmp()ing into rust code is just not defined behavior, even if it "works" for now. I assume there are similar challenges in Ada.
Is the implementation of a Convention isolated enough that it would make sense to be extensible?
One thing I had in mind is something like Postgres. Some functions in Postgres are called in a specific way that converts arguments into an array first, and handles SQL NULL values. If I were to define this as a new Convention, it would inherit a lot from the "C" Convention, but would do some transformations first.
If it could handle a longjmp() as well, then the new Convention would also do whatever setup (manipulate some global variables and call setjmp()) so that the caller doesn't have to worry about the longjmp().
The challenge with handling longjmp() in rust is that you can't call setjmp() as a normal FFI function (because it can return twice, like fork(), which is not a normal control flow). Also, longjmp()ing into rust code is just not defined behavior, even if it "works" for now. I assume there are similar challenges in Ada.
> Is the implementation of a Convention isolated enough that it would make sense to be extensible?
Conventions are currently implemented in GNAT as a part of the parser/lexer just like any other syntax element, so it's not easily separated from the rest of the compiler. You could change that behavior, but that's not a small task. I don't think new calling conventions come along very often, so it seems unlikely to be worth the effort.
> One thing I had in mind is something like Postgres. Some functions in Postgres are called in a specific way that converts arguments into an array first, and handles SQL NULL values. If I were to define this as a new Convention, it would inherit a lot from the "C" Convention, but would do some transformations first.
I don't know the details of the Postgres implementation, but this sounds to me like the sort of thing that would work well as a generic procedure.
GNAT doesn't use runtime FFI, it dynamically links libraries and maps them into memory the same as any other C program that uses gcc and binutils. I think this makes what you're describing possible, but I'm not familiar enough with how setjmp/longjmp interacts with the stack to be certain without doing more research and testing.
Conventions are currently implemented in GNAT as a part of the parser/lexer just like any other syntax element, so it's not easily separated from the rest of the compiler. You could change that behavior, but that's not a small task. I don't think new calling conventions come along very often, so it seems unlikely to be worth the effort.
> One thing I had in mind is something like Postgres. Some functions in Postgres are called in a specific way that converts arguments into an array first, and handles SQL NULL values. If I were to define this as a new Convention, it would inherit a lot from the "C" Convention, but would do some transformations first.
I don't know the details of the Postgres implementation, but this sounds to me like the sort of thing that would work well as a generic procedure.
GNAT doesn't use runtime FFI, it dynamically links libraries and maps them into memory the same as any other C program that uses gcc and binutils. I think this makes what you're describing possible, but I'm not familiar enough with how setjmp/longjmp interacts with the stack to be certain without doing more research and testing.
The C interoperability of Ada is very good, you can import/export functions and specify whether records (structs) and arrays must have a C convention. I use it often to access libc and Linux kernel functions/syscalls [1][2].
[1] https://github.com/onox/inotify-ada [2] https://github.com/onox/evdev-ada
[1] https://github.com/onox/inotify-ada [2] https://github.com/onox/evdev-ada
Can attest to that. C++ is also OK. You still have to write the 'binding' but the compiler can generate a good part for you. Then you can 'hide' all the C-like things (like 'a pointer is an address', 'an enumerated type is an integer', 'you have to call our free() when you're done'...) behind opaque types, controlled types, etc.
As a simple example you can lookup what the compiler generates as a low-level binding [0] that is wrapped in a higher level API [1].
BTW you can also bind Ada to Java (although support is a bit limited I know places where it's in prod). Don't remember if it's a commercial product or oss.
And for the python people, my company financed a first version of ada-py-bind, inspired by the great pybind11. Still a lot of code to write (or generate) but it works fine.
Thanks onox for those two links!
[0] https://github.com/persan/zeromq-Ada/blob/651ca44cce831c2d71...
[1] https://github.com/persan/zeromq-Ada/blob/651ca44cce831c2d71...
As a simple example you can lookup what the compiler generates as a low-level binding [0] that is wrapped in a higher level API [1].
BTW you can also bind Ada to Java (although support is a bit limited I know places where it's in prod). Don't remember if it's a commercial product or oss.
And for the python people, my company financed a first version of ada-py-bind, inspired by the great pybind11. Still a lot of code to write (or generate) but it works fine.
Thanks onox for those two links!
[0] https://github.com/persan/zeromq-Ada/blob/651ca44cce831c2d71...
[1] https://github.com/persan/zeromq-Ada/blob/651ca44cce831c2d71...
This is more of a general question
With the availability of free languages such as
Rust, Clojure, F#, Go, Typescript, Idris, Raku
You have a solid option that cover ever possible paradigm and style of programming you may fathom
Why would any one invest time or effort in a commercial language such as Ada, Eiffel or even Xojo and LispWorks, that require you to pay for Automated test support and what is considered by most standards now basic libraries
And not only that, the communities are usually tiny and support is probably very limited to the commercial support they provide, and when it comes to languages, languages with big communities, provide infinitely better support than commercial support for proprietary languages or implementations
The cost of AdaCore is not just the compiler license, its the total ecosystem cost
Why would any one invest time or effort in a commercial language such as Ada, Eiffel or even Xojo and LispWorks, that require you to pay for Automated test support and what is considered by most standards now basic libraries
And not only that, the communities are usually tiny and support is probably very limited to the commercial support they provide, and when it comes to languages, languages with big communities, provide infinitely better support than commercial support for proprietary languages or implementations
The cost of AdaCore is not just the compiler license, its the total ecosystem cost
Ada is not a a commercial language. It's free, and the standard is free as well.
Adacore's support is excellent - you're talking directly to gcc/gdb devs. There is no intermediate layer. I've hit a number of nasty technical issues ( compiler bugs mostly), usually fixed within 48h. They then provide you with what they call a 'wavefront' which is essentially a patched version of the compiler which is supported as well.
It is true that the ada community is small, but there is no real other contender in that space ( embedded, formal verification, qualified toolchains, etc).
Edit: nvidia uses spark/ada (from adacore), it's not clear to me what other options they might have given what they want to do (video presentation in the link)
"AdaCore + NVIDIA Partnership | AdaCore" https://www.adacore.com/company/partners/nvidia
Adacore's support is excellent - you're talking directly to gcc/gdb devs. There is no intermediate layer. I've hit a number of nasty technical issues ( compiler bugs mostly), usually fixed within 48h. They then provide you with what they call a 'wavefront' which is essentially a patched version of the compiler which is supported as well.
It is true that the ada community is small, but there is no real other contender in that space ( embedded, formal verification, qualified toolchains, etc).
Edit: nvidia uses spark/ada (from adacore), it's not clear to me what other options they might have given what they want to do (video presentation in the link)
"AdaCore + NVIDIA Partnership | AdaCore" https://www.adacore.com/company/partners/nvidia
And to be clear they also support C on GCC, so our gcc bugs go there too. Also very very happy with AdaCore's tech support. Response within the day, help and patience in reproducing problems, and almost always with a quick workaround. Often citing the reference manual. You also often have an expert jumping in to help, or to answer a question, or to implement some optimization :-)
I still have fond memories of (the sadly late) Robert Dewar answering a ticket of mine 'this is so slow, whyyyyyyy?' with a 'we have implemented a change that should improve the performance of your code' so fast I hadn't had the time to go talk to our local Ada guy for an alternative idea.
They also have world experts in formal methods like Yannick Moy and Claire Dross who will help you prove you jump-start a Spark project and are pushing the state of the art every year (proof of floating point code, pointer/ownership...).
Money well spent.
And to be clear: not from AdaCore, just a customer.
I still have fond memories of (the sadly late) Robert Dewar answering a ticket of mine 'this is so slow, whyyyyyyy?' with a 'we have implemented a change that should improve the performance of your code' so fast I hadn't had the time to go talk to our local Ada guy for an alternative idea.
They also have world experts in formal methods like Yannick Moy and Claire Dross who will help you prove you jump-start a Spark project and are pushing the state of the art every year (proof of floating point code, pointer/ownership...).
Money well spent.
And to be clear: not from AdaCore, just a customer.
Rust is not yet ready for formal verification, along with some ready libraries for that purpose, unlike Ada/SPARK. Hopefully, it will be there, just not yet. It still requires tremendous multi-year effort to finish that.
In addition to lacking formal verification tools, I'm worried about compiler certification with a language that changes as fast as rust, and c++, and even c now do. Yes you cannstick to a version, but the world and bug fixes, and libraries will pass you by. Which brings up another problem with rust for safety critical. The stdlib is so very thin, that doing almost anything requies a dependency tree of a dozen or more crates by different authors. You need to certify all those as well. Its a nightmare of an ecosystem from the safety cert perspective.
Be that as it may, it hasn't stopped certification from being pursued.
Many cases when you want cert will probably be nostd anyway so it is definitely worth pursuing given all the other advantages the language has. I'm just being grumpy because I love the language but I am a fan of batteries included languages. Or at least a thick stdlib and a boost-like thing. That is partly influenced by my primary dev environment being airgapped, and my secondary one being behind nexus/solarcube.
Ada isn't a commercial language, though AdaCore's implementation is. Just like Green Hills compiler implementations cost money, sometimes the commercial implementations offer features/guarantees/support the open source implementations do not.
Correct.
Here is the Ada 2012 standard: http://www.ada-auth.org/standards/rm12_w_tc1/html/RM-TOC.htm...
If you create a programming language that meets all of the Ada standard requirements, you will have your own Ada implementation.
You could use whatever backend suits your needs (or write your own) and license it accordingly.
Here is the Ada 2012 standard: http://www.ada-auth.org/standards/rm12_w_tc1/html/RM-TOC.htm...
If you create a programming language that meets all of the Ada standard requirements, you will have your own Ada implementation.
You could use whatever backend suits your needs (or write your own) and license it accordingly.
By the way, the test suite, ACATS is part of the standard and is freely available. Not enough for an industrial strength compiler, but amazingly detailed already.
> This is more of a general question With the availability of free languages such as Rust, Clojure, F#, Go, Typescript, Idris, Raku You have a solid option that cover ever possible paradigm and style of programming you may fathom
> Why would any one invest time or effort in a commercial language such as Ada,
(1) Ada isn’t a commercial language
(2) What other free language covers the style and paradigm Ada addresses? Rust maybe (I haven't really done a detailed analysis) now subsumes Ada, but has a different focus and a lot of cognitive overhead related to that focus. Haskell or another static functional language with a robust type system might provide an alternative approach to some similar benefits, but not the same style and paradigm.
> Why would any one invest time or effort in a commercial language such as Ada,
(1) Ada isn’t a commercial language
(2) What other free language covers the style and paradigm Ada addresses? Rust maybe (I haven't really done a detailed analysis) now subsumes Ada, but has a different focus and a lot of cognitive overhead related to that focus. Haskell or another static functional language with a robust type system might provide an alternative approach to some similar benefits, but not the same style and paradigm.
Lisp is a good example, instead of Allegro and LispWorks one gets to dabble in SBCL + Emacs.
Qt/Delphi/C++ Builder versus free beer GUI tooling is another.
Or doing RAD Web Applications in Outsystems or doing it all by ourselves.
Certain quality levels are only reachable when people pay for their tools.
Qt/Delphi/C++ Builder versus free beer GUI tooling is another.
Or doing RAD Web Applications in Outsystems or doing it all by ourselves.
Certain quality levels are only reachable when people pay for their tools.
It probably doesn't make a lot of sense for a greenfield project, but for established projects it might make sense to stay with the current technology stack. At my last job we had a team of 10+ domain experts that were expert level at a proprietary language. Replacing years of work to save $10k per developer every year would have been a bad decision.
Perhaps companies and individual with an interest in a permissively licensed Ada ecosystem should step up and create it? Build it on top of LLVM and call it, say, alang.
>> Perhaps companies and individual with an interest in a permissively licensed Ada ecosystem should step up and create it? Build it on top of LLVM and call it, say, alang.
If it is an Ada implementation, why wouldn't they call it Ada rather than alang?
If the language implements the Ada standard (http://www.ada-auth.org/standards/rm12_w_tc1/html/RM-TOC.htm...), it is Ada, regardless of how the particular implementation is licensed.
If it is an Ada implementation, why wouldn't they call it Ada rather than alang?
If the language implements the Ada standard (http://www.ada-auth.org/standards/rm12_w_tc1/html/RM-TOC.htm...), it is Ada, regardless of how the particular implementation is licensed.
> If it is an Ada implementation, why wouldn't they call it Ada rather than alang?
In the same way that "the" C/C++ LLVM frontend is called clang and the Fortran frontend is called flang. So a hypothetical Ada frontend could be called alang.
> If the language implements the Ada standard (http://www.ada-auth.org/standards/rm12_w_tc1/html/RM-TOC.htm...), it is Ada, regardless of how the particular implementation is licensed.
I wasn't arguing against that, but, yes I agree.
In the same way that "the" C/C++ LLVM frontend is called clang and the Fortran frontend is called flang. So a hypothetical Ada frontend could be called alang.
> If the language implements the Ada standard (http://www.ada-auth.org/standards/rm12_w_tc1/html/RM-TOC.htm...), it is Ada, regardless of how the particular implementation is licensed.
I wasn't arguing against that, but, yes I agree.
I understand now.
It would be the alang Ada compiler similar to the clang C compiler.
Thank you for clarifying.
It would be the alang Ada compiler similar to the clang C compiler.
Thank you for clarifying.
> If it is an Ada implementation, why wouldn't they call it Ada rather than alang?
A serious lack of imagination, re clang, flang, etc.
A serious lack of imagination, re clang, flang, etc.
Interestingly there was, in the first days of clang, an Ada 'compiler', through dragonegg. The original author meant to write an Ada compiler on top of llvm and translated (iirc) gcc's gimple to llvm, with some success.
The fun part is that dragonegg became an important part of clang/llvm for years (before it was phased out) to compile fortran (before flang) and to compare clang results and gcc's. I seem to remember other interesting uses but my memory is failing me.
Duncan Sands (the original author I think?) is an outstanding engineer and very fun person to talk to.
The fun part is that dragonegg became an important part of clang/llvm for years (before it was phased out) to compile fortran (before flang) and to compare clang results and gcc's. I seem to remember other interesting uses but my memory is failing me.
Duncan Sands (the original author I think?) is an outstanding engineer and very fun person to talk to.
Well... There's GNATLLVM [0] a project to have the GNAT frontend output LLVM. From... AdaCore. Someone has already beat me to a first wasm example [1] and there's also a first wasm-based Android one [2]...
[0] https://blog.adacore.com/combining-gnat-with-llvm [1] https://blog.adacore.com/use-of-gnat-llvm-to-translate-ada-a... [2] https://blog.adacore.com/android-application-with-ada-and-we...
[0] https://blog.adacore.com/combining-gnat-with-llvm [1] https://blog.adacore.com/use-of-gnat-llvm-to-translate-ada-a... [2] https://blog.adacore.com/android-application-with-ada-and-we...
Anyone know why the linux x86 binary is >3 times the size of the Risc or Arm ones?
Just remember that all software you compile with it will be under the GPL.
The downvotes are utterly ridiculous.
Unlike other parts of GCC, GNAT copyright is held by AdaCore due to some special arrangement with the FSF.
For the compiled CE releases on their website, AdaCore strips the runtime exception:
You are of course free to build the compiler yourself, or use the Ada compiler that comes with your distro.
The sources are available, you just don't get a tag that tells you which exact combination of files AdaCore used to build and verify their binaries.
This is a strategic PITA, and AdaCore have in recent years made some moves to improve the situation, with being active on github and responding to issues in general.
Unlike other parts of GCC, GNAT copyright is held by AdaCore due to some special arrangement with the FSF.
For the compiled CE releases on their website, AdaCore strips the runtime exception:
-- As a special exception under Section 7 of GPL version 3, you are granted --
-- additional permissions described in the GCC Runtime Library Exception, --
-- version 3.1, as published by the Free Software Foundation. --
You are of course free to build the compiler yourself, or use the Ada compiler that comes with your distro.
The sources are available, you just don't get a tag that tells you which exact combination of files AdaCore used to build and verify their binaries.
This is a strategic PITA, and AdaCore have in recent years made some moves to improve the situation, with being active on github and responding to issues in general.
You seem to have various misconceptions; I suggest you consult your legal advisor.
> Unlike other parts of GCC, GNAT copyright is held by AdaCore due to some special arrangement with the FSF.
Adacore holds at least the copyright of their own contributions and therefore can decide whether they want to release their version of GNAT with or without the runtime library exception; the FSF version eventually inherits also the contributions of Adacore, but the Adacore version is more current.
> So yes, binaries compiled with that particular compiler are de-facto under GPLv3, and you have to abide by its terms
This doesn't have anything to do with source or binary version. The reason is that the binaries provided by Adacore are compiled from their (most recent) source version which they publish under GPL without the runtime library exception. For this (and only this) reason you create a "combined work" when you link your code with the Adacore version of the runtime library. This doesn't change in any way if you compile the GNAT version of Adacore by yourself; you still don't have the runtime libary exception which only Adacore can give for their contributions.
> Unlike other parts of GCC, GNAT copyright is held by AdaCore due to some special arrangement with the FSF.
Adacore holds at least the copyright of their own contributions and therefore can decide whether they want to release their version of GNAT with or without the runtime library exception; the FSF version eventually inherits also the contributions of Adacore, but the Adacore version is more current.
> So yes, binaries compiled with that particular compiler are de-facto under GPLv3, and you have to abide by its terms
This doesn't have anything to do with source or binary version. The reason is that the binaries provided by Adacore are compiled from their (most recent) source version which they publish under GPL without the runtime library exception. For this (and only this) reason you create a "combined work" when you link your code with the Adacore version of the runtime library. This doesn't change in any way if you compile the GNAT version of Adacore by yourself; you still don't have the runtime libary exception which only Adacore can give for their contributions.
> I suggest you consult your legal advisor.
So do I.
> Adacore holds at least the copyright of their own contributions and therefore can decide whether they want to release their version of GNAT with or without the runtime library exception.
Indeed.
> the FSF version eventually inherits also the contributions of Adacore, but the Adacore version is more current.
AdaCore contributes to GCC, with some contributions copyright FSF, some copyright AdaCore.
AdaCore retains full rights on the later, limited by whatever private agreement they have with the FSF.
Whether it is more current or not is not relevant to the discussion, and given that GNAT CE has release cycles of 1 year it stands to reason that FSF GNAT gets bugfixes that GNAT CE will only get in 2022.
> This doesn't have anything to do with source or binary version.
I'm now pretty convinced you're reading things that I didn't write.
You seem to be under the impression that dual licensing only works because AdaCore GNAT contains newer files.
However, AdaCore can download stock upstream gcc, remove the linking exception from files they hold copyright over, and distribute this result in source and binary form on their website.
This is due to their unique status with the FSF, something that other companies and private contributors can not do.
Finally, I have never suggested recompiling AdaCore GNAT CE sources will result in a GNAT compiler with runtime exception.
Instead I've pointed out the mechanism of how they achieve this dual licensing: A) unique status as copyright holders alongside the FSF B) strategic inclusion or removal of the runtime exception in each and every file they hold copyright over.
So do I.
> Adacore holds at least the copyright of their own contributions and therefore can decide whether they want to release their version of GNAT with or without the runtime library exception.
Indeed.
> the FSF version eventually inherits also the contributions of Adacore, but the Adacore version is more current.
AdaCore contributes to GCC, with some contributions copyright FSF, some copyright AdaCore.
AdaCore retains full rights on the later, limited by whatever private agreement they have with the FSF.
Whether it is more current or not is not relevant to the discussion, and given that GNAT CE has release cycles of 1 year it stands to reason that FSF GNAT gets bugfixes that GNAT CE will only get in 2022.
> This doesn't have anything to do with source or binary version.
I'm now pretty convinced you're reading things that I didn't write.
You seem to be under the impression that dual licensing only works because AdaCore GNAT contains newer files.
However, AdaCore can download stock upstream gcc, remove the linking exception from files they hold copyright over, and distribute this result in source and binary form on their website.
This is due to their unique status with the FSF, something that other companies and private contributors can not do.
Finally, I have never suggested recompiling AdaCore GNAT CE sources will result in a GNAT compiler with runtime exception.
Instead I've pointed out the mechanism of how they achieve this dual licensing: A) unique status as copyright holders alongside the FSF B) strategic inclusion or removal of the runtime exception in each and every file they hold copyright over.
> So do I.
Thanks, I studied law.
> AdaCore retains full rights on the later, limited by whatever private agreement they have with the FSF.
No "private agreement" is necessary. It's just about whether Adacore grants the runtime library exception for their contributions or not. And they apparently only do that with a delay (a year or so).
Thanks, I studied law.
> AdaCore retains full rights on the later, limited by whatever private agreement they have with the FSF.
No "private agreement" is necessary. It's just about whether Adacore grants the runtime library exception for their contributions or not. And they apparently only do that with a delay (a year or so).
Are you saying if I compile my own GNAT (from source), this exception stays in place and binaries will not be automatically GPL'd?
Watch out! If you compile the Adacore version of GNAT then you're limited by the license they give you for their version which is GPL without runtime library exception. This doesn't change when you compile their code. With some delay (a year or so) Adacore releases their versions of GNAT with runtime library exception so it can be merged with the FSF version of GNAT.
It's crazy how you are downvoted and people who are downright uninformed both about the licensing and the legal issues are upvoted.
Last time I used Ada, around ten years ago, the situation was exactly the same. This goes to show that the licensing issues around GNAT continue to hamper the ecosystem, contrary to what Adacore like to suggest.
Last time I used Ada, around ten years ago, the situation was exactly the same. This goes to show that the licensing issues around GNAT continue to hamper the ecosystem, contrary to what Adacore like to suggest.
Recently, study results were in the press (e.g. https://www.sueddeutsche.de/politik/pisa-studie-lesen-fakten...) according to which the young have more and more trouble distinguishing between facts and opinions. And everyone and their dog seems to have an opinion on everything, whether they understand any of the subject matter or not (people even seem to resent it when you have relevant qualifications and point them out). So it's no surprise that there are random votes.
Yes, that's exactly how it works.
There are multiple distributions under different licenses.
If you compile this source (CE) - yes your code must be GPL. Adacore's distribution is the most up to date.
The FSF distribution has the normal gcc exceptions. The FSF distribution is normally what's shipped with linux distros. It tends to be slightly older.
If you compile this source (CE) - yes your code must be GPL. Adacore's distribution is the most up to date.
The FSF distribution has the normal gcc exceptions. The FSF distribution is normally what's shipped with linux distros. It tends to be slightly older.
> binaries compiled with that particular compiler are de-facto under GPLv3, and you have to abide by its terms (eg. if a customer using these binaries requests the source code)
You'll be violating the terms that allow you to use the compiler if your source code isn't GPL licensed. That doesn't mean your source code is automatically converted to GPL. It just means you don't have a right to use the compiler or to distribute the binaries you've produced with it.
You'll be violating the terms that allow you to use the compiler if your source code isn't GPL licensed. That doesn't mean your source code is automatically converted to GPL. It just means you don't have a right to use the compiler or to distribute the binaries you've produced with it.
I think this is a important point, for what I understand from some old posts, there are basically three versions of Gnat:
- FSF: Is GPL but contains an exception that allows you the create programs which are not GPL (basically the same as e.g. g++)
- AdaCore Community : Also GPL, but no exception. Hence your program is also GPL.
- AdaCore Pro: Commercial and allows you to create programs which are not GPL.
- FSF: Is GPL but contains an exception that allows you the create programs which are not GPL (basically the same as e.g. g++)
- AdaCore Community : Also GPL, but no exception. Hence your program is also GPL.
- AdaCore Pro: Commercial and allows you to create programs which are not GPL.
That's wrong, and this idea has popped up repeatedly on HN lately.
It's true that you may only use GNAT GPL for hobbyist use and GPL software.
But breaking GNAT's license doesn't make the software created GPL. It just makes you liable for damages. And cessation, of course.
It's true that you may only use GNAT GPL for hobbyist use and GPL software.
But breaking GNAT's license doesn't make the software created GPL. It just makes you liable for damages. And cessation, of course.
Using a compiler whose code is under GPL doesn't make your code GPL. But using the GPL runtime library might be an issue. The FSF GNAT version has a runtime library exception which allows you to use the runtime library in non GPL code. The Adacore version has no such exception (at least it didn't when I checked last time).
> But breaking GNAT's license doesn't make the software created GPL
If you do not comply with the terms of the GPL license you're no longer allowed to use the code/software licensed under GPL. Under GPL 2, you can continue to use the code/software after the license violation is removed. Under GPL 3 the copyright holder might terminate your license (see section 8 of GPL 3).
> But breaking GNAT's license doesn't make the software created GPL
If you do not comply with the terms of the GPL license you're no longer allowed to use the code/software licensed under GPL. Under GPL 2, you can continue to use the code/software after the license violation is removed. Under GPL 3 the copyright holder might terminate your license (see section 8 of GPL 3).
Meh, the default behavior of GNAT is to bundle the runtime in the executable anyway...
Even then there can be a question of whether your code is derivative of the runtime, or of the standard. If the latter, then you might escape the licensing quagmire
Your source code may not be a derivative of the runtime, but your object code clearly is.
I don't think you can use Ada without dependency (i.e. making a combined work) of a runtime (maybe someone knows a good way without sacrificing relevant Ada features, I don't).
The basis of derivative work, even when RMS was bullying projects with it, was whether your code was dependant on the GPL implementation, or say, could just as well be built with another vendor's library - even if that one was GPLed too, so long as it wasn't derivative of the first runtime.
Essentially a case of "coding for standard interface offered from multiple sources where the interface itself isn't GPL" vs "Your code requires rework in order to work without this specific GPLed dependency".
This is all grossly simplified, but among other things, it means that separating GPL code to another binary you talk over any form of IPC doesn't necessarily mean you're avoiding GPL.
Essentially a case of "coding for standard interface offered from multiple sources where the interface itself isn't GPL" vs "Your code requires rework in order to work without this specific GPLed dependency".
This is all grossly simplified, but among other things, it means that separating GPL code to another binary you talk over any form of IPC doesn't necessarily mean you're avoiding GPL.
> whether your code was dependant on the GPL implementation
It's rather "whether your work", not only your code. GNAT generates runtime library dependencies even if you are not aware of it. So the result is a "combined work", because the runtime library is linked to your code (otherwise your application wouldn't work).
See e.g. https://www.gnu.org/licenses/gpl-faq.html#GPLStaticVsDynamic
It's rather "whether your work", not only your code. GNAT generates runtime library dependencies even if you are not aware of it. So the result is a "combined work", because the runtime library is linked to your code (otherwise your application wouldn't work).
See e.g. https://www.gnu.org/licenses/gpl-faq.html#GPLStaticVsDynamic
> breaking GNAT's license doesn't make the software created GPL
This is an important distinction.
But it's still true, that using the Ada core GPL Ada compiler, which does not come with lgpl/run-time exception - you can only legally distribute binaries under the GPL (or commercial license).
This does not matter much if you don't distribute code to others (eg: break system of a car - gpl/commercial; build a web server to sell/stream movies - gpl/internal use).
I still think it's probably a mistake to have the fsf and Ada core version be so similar, yet differently licensed (because it is confusing - most are used to gpl compilers comming with lgpl/runtime exception, like gcc).
This is an important distinction.
But it's still true, that using the Ada core GPL Ada compiler, which does not come with lgpl/run-time exception - you can only legally distribute binaries under the GPL (or commercial license).
This does not matter much if you don't distribute code to others (eg: break system of a car - gpl/commercial; build a web server to sell/stream movies - gpl/internal use).
I still think it's probably a mistake to have the fsf and Ada core version be so similar, yet differently licensed (because it is confusing - most are used to gpl compilers comming with lgpl/runtime exception, like gcc).
I am learning SPARK2014 and it is this confusion around the GPL that gives me pause in fully committing to this direction or any other GPL-licensed software, mainly due to not fully understanding how I can use the Gnat Ada 202x compiler. I am learning Zig, and it is MIT (expat) licensed, which I feel more comfortable in accepting. Rust is the same (dual-licensed MIT/Apache V2), and I think given some people comparing Ada to Rust for high-integrity software are going to gravitate to Rust instead of Ada. SPARK2014, a subset of Ada, is an amazing language for these endeavors.
You can build gnat and gnatprove yourself, including runtime exception.
This is a bit painful (intentionally so) but it can be done.
This is a bit painful (intentionally so) but it can be done.
> You can build gnat and gnatprove yourself, including runtime exception.
How does that work? Are the binaries from Ada core (not FSF) intentionally distributed under GPL while the source for standardlib/run-time come with LGPL/run-time exceptions?
It was my understanding that the Ada core distribution is full GPL only, and the FSF one (lagging a few versions) was licensed more like gcc?
How does that work? Are the binaries from Ada core (not FSF) intentionally distributed under GPL while the source for standardlib/run-time come with LGPL/run-time exceptions?
It was my understanding that the Ada core distribution is full GPL only, and the FSF one (lagging a few versions) was licensed more like gcc?
> It was my understanding that the Ada core distribution is full GPL only, and the FSF one (lagging a few versions) was licensed more like gcc?
Yes that's the case.
Yes that's the case.
I am more of an end-user here trying to use SPARK2014 for applications, not doing any unnecessary software engineering or builds outside of using SPARK2014 and a compiler. It is this type of thing that makes it a bad choice for someone like me who doesn't have the time and sometimes the wherewithal to build my own compiler. Sure, a simple build of source without licensing restrictions, maybe, but not much above just using the PL to get a job done. This is why I will never give up C and the tools around it, well, maybe Zig or Rust, which I am playing with, but they are nowhere near SPARK2014/Ada for all that you get with them and the Gnat compiler. I was introduced to SPARK2014 with the book, "Building High Integrity Applications with Spark". I also read a fantastic book, "Analysable Real-Time Systems: Programmed in Ada" that put me on this vector. Great stuff and timely.
SPARK2014 is just a tool (gnatprove), which you don't distribute to others (would be rather pointless). Compiling can be done with gnat from your Linux distro, which usually has the Runtime Library Exception.
Is the compiling part "a bit painful" as @tobiasu comments above? Because that is what I am trying to avoid.
Some source on this?
this is unclear to me, what source do you need?
That if you build ada yourself your binaries later either have the runtime exception or that they do not need it.
Take as an example the gnat.sockets package from upstream gcc:
https://github.com/gcc-mirror/gcc/blob/master/gcc/ada/libgna...
Compare with the same file from the GNAT 2021 CE install:
GNAT/2021/lib/gcc/x86_64-pc-linux-gnu/10.3.1/rts-native/adainclude/g-socket.ads
you will find there are a bunch of blank lines where the runtime exception was.
https://github.com/gcc-mirror/gcc/blob/master/gcc/ada/libgna...
Compare with the same file from the GNAT 2021 CE install:
GNAT/2021/lib/gcc/x86_64-pc-linux-gnu/10.3.1/rts-native/adainclude/g-socket.ads
you will find there are a bunch of blank lines where the runtime exception was.
I might be ignorant, but you actually need the exception, otherwise it would be gpl, isnt it.
But if you're going to use the FSF version, why not use fsf/distro binaries? Getting the source from Ada core still leaves you without the runtime exception? (Ada core is upstream/newer, fsf is downstream, lagging a bit behind Ada core(?)).
This issue has been discussed for decades over and over and there are still people like you claim that I'm wrong.
I am not wrong. The runtime of the Adacore Community edition is under GPL, as are many libraries included in the Adacore edition that are not included in the FSF edition. Your binaries will be under the GPL. (Technically speaking, you could compile executables with this version of GNAT that are not under GPL by writing your own runtime. Practically, this is pretty much impossible and nobody has ever done it.)
The FSF edition allows you to compile executables without license encumbering, because it is licensed under the mGPL.
I am not wrong. The runtime of the Adacore Community edition is under GPL, as are many libraries included in the Adacore edition that are not included in the FSF edition. Your binaries will be under the GPL. (Technically speaking, you could compile executables with this version of GNAT that are not under GPL by writing your own runtime. Practically, this is pretty much impossible and nobody has ever done it.)
The FSF edition allows you to compile executables without license encumbering, because it is licensed under the mGPL.
> Your binaries will be under the GPL
And you've been wrong for decades.
All the things you write are true, except when you claim that the binaries will automatically be GPL.
The author has to make them GPL, in order to comply with the license, that's true. But they don't magically become GPL if the author refuses.
If the author doesn't comply, Adacore can sue them. They can demand that the author stops distributing non-compliant binaries. They can demand that the author pay them money.
They cannot, for example, redistribute the binaries themselves (against the author's wishes), under the theory that they "should be" GPL.
The court probably wouldn't even order the author to put the binaries under GPL, because specific performance is generally not considered by the courts, when paying damages is a workable alternative.
And you've been wrong for decades.
All the things you write are true, except when you claim that the binaries will automatically be GPL.
The author has to make them GPL, in order to comply with the license, that's true. But they don't magically become GPL if the author refuses.
If the author doesn't comply, Adacore can sue them. They can demand that the author stops distributing non-compliant binaries. They can demand that the author pay them money.
They cannot, for example, redistribute the binaries themselves (against the author's wishes), under the theory that they "should be" GPL.
The court probably wouldn't even order the author to put the binaries under GPL, because specific performance is generally not considered by the courts, when paying damages is a workable alternative.
That's probably the worst case of nitpicking I've ever encountered in my life. Yes, you're technically correct. It's not as if you're telling anyone something new, contract law exists for a while already.
I wrote the comment because many people don't know the difference between the FSF version and Adacore's Community Version, hence will involuntarily violate the GPL.
I wrote the comment because many people don't know the difference between the FSF version and Adacore's Community Version, hence will involuntarily violate the GPL.
[deleted]
Are you paid or are you just misinformed?, it is one of the most widespread misconceptions about GPL
I'm neither paid not misinformed. There is no runtime exception for the Adacore Community version, it is under GPL including the runtime, hence every executable produced with it is also under GPLv3.
If you want mGPL (with the runtime exception) you need to wait for the FSF version.
This is well-known in the Ada community, but I thought I'd mention it because occasionally people don't know the license conditions of various GNAT versions very well. Such as you.
If you want mGPL (with the runtime exception) you need to wait for the FSF version.
This is well-known in the Ada community, but I thought I'd mention it because occasionally people don't know the license conditions of various GNAT versions very well. Such as you.
FSF GNAT hasn't been MGPL for years, not even sure which version, but I think it's before 4.9.4. FSF GNAT is GPLv3 with linking exception.
You are right and it is a useful thing to know.
There is a commercial license to help encourage the big well funded customers to pay for the tools they need to compile millions of lines of company confidential ADA.
And a license for only open source software; just in case students or hobbyists want to write their own robust open source rocket guidance system and share it on github.
There is a commercial license to help encourage the big well funded customers to pay for the tools they need to compile millions of lines of company confidential ADA.
And a license for only open source software; just in case students or hobbyists want to write their own robust open source rocket guidance system and share it on github.
My pet theory is that tech people tend to see this as a constraint-solving problem.
"If the resulting software were GPL, all those nasty contradictions would go away. Let's assign GPL to the software and the problem is solved."
Unfortunately, the law doesn't work that way.
"If the resulting software were GPL, all those nasty contradictions would go away. Let's assign GPL to the software and the problem is solved."
Unfortunately, the law doesn't work that way.
There's some nuance here and I don't think this is correct. However, the uncertainty around Ada licensing causes a lot of people to be hesitant to start with Ada.
That is just wrong.
No, it's not. It's the difference between the FSF version and this GNAT 2021 Community Edition by Adacore. The FSF version is under mGPL, this edition is under GPLv3 including the runtime which is included in every binary.
I mentioned it precisely because people get it wrong so often.
I mentioned it precisely because people get it wrong so often.
What’s different?
Debian/Ubuntu: sudo apt install gnat gprbuild
Arch Linux: sudo pacman -S gcc-ada (get gprbuild from the AUR)
NixOS: https://github.com/fluffynukeit/adaspark/
I think it's also available on Fedora IIRC.
And then go to https://learn.adacore.com/ :)