As always a very nice and elaborate writeup of the changes for Ada 2022. Every feature in Ada feels well-thought-out and fits into place, which leads to a high consistency.
Without specific mentions, big parts of the language community can learn a lot from how AdaCore et. al. do their language development.
Without a permissively licensed compiler, it’s hard to recommend the language. AdaLabs was trying to build an Ada front end for LLVM, but I don’t think they made progress.
If any of your workflow involves distributing the compiler (for example, if you want to create a developer container to allow quick onboarding for a project) then you need to comply with all of the GPLv3 conditions. If you own any patents, for example, then you must carefully audit the code to ensure that no one has snuck in any code that infringes them because otherwise you’ve just accidentally granted everyone a perpetual license. This is why a lot of companies have a no-GPLv3-code policy. In some cases, it’s more liberal (you can use, but not contribute back to or redistribute), but in a modern world using code that you can’t redistribute is painful. You also can’t use the compiler front end in any additional tooling unless you’re willing to release under a GPLv3-compatible license.
I don’t mind having a GPL’d or proprietary compiler as a second source but I wouldn’t want to build a business depending on it.
If any of your workflow involves distributing the compiler
I was going to write a rebuttal, but thinking more about it this is a valid point. However here are a few things that I think weaken it:
Distributing the compiler is a very niche use case that I don’t see many businesses need (and in the case of GNAT, I’d argue that paying AdaCore to do it is a better use of money/engineer time since their business literally is maintaining and distributing GNAT).
A successful stage 3/4 bootstrap from a clean environment (e.g. a VM) is a fairly strong guarantee that you’re not shipping anything you don’t want to leak.
GCC frontends usually are a poor fit for creating new tooling anyway. In the specific case of Ada, you should go with libadalang (soon to be re-licensed under Apache 2.0) instead.
So overall, despite it being correct, I don’t find your argument about finding it hard to recommend Ada due to the main compiler being GPLv3 very convincing :). Still, this was interesting to think about, thanks for sharing your point on view!
Distributing the compiler is a very niche use case that I don’t see many businesses need
I think that absolutely was true a year ago, but it increasingly isn’t. A lot of development is now moving to containers, where you provide a container layer with all of your default tooling so that folks can easily contribute to your project. Even if your project is closed source, you may distribute this to consumers and so on. Similarly, you will distribute it to the folks running any outsourced CI system and so on.
A successful stage 3/4 bootstrap from a clean environment (e.g. a VM) is a fairly strong guarantee that you’re not shipping anything you don’t want to leak.
That doesn’t help. The issue is:
I file a patent on technique A that I don’t want competitors to use.
Someone contributes an infringing patch to GNAT.
I distribute GNAT.
I sue someone else for infringing my patent.
The person points to the implementation of A in GNAT and I discover that I’ve accidentally licensed it.
This is why big companies are incredibly wary about distributing GPLv3 code. A clean-room build doesn’t solve this, only a complete code audit does and that’s too expensive.
The fact that it’s GPLv3 and an FSF project also makes me much more hesitant because the FSF relicensed GCC from a license that was mostly fine to a license that had a bunch of things that made corporate lawyers nervous. I have no idea what GPLv4 will look like and if I have to either fork GCC or migrate to a different compiler when GCC 15 moves to GPLv4, that’s not something I want in my long-term risk planning.
GNAT is both GPL3 and available commercially :). There’s also a bunch of other proprietary compilers, such as Green Hill’s or PTC’s. GNAT is however usually the most up to date one.
It only means that if you ship both in one distribution, the LLVM part is not allowed to be shipped in a way that gives you lesser rights than the GPLv3 part - which essentially means if someone requests the source code to their binary, they need to get it for both components. That’s quite okay.
The LLVM bits will still remain permissibly licensed, it’s not “contaminated”.
The other alternative is shipping the LLVM part as a dynamic library and the frontend separately (e.g. in 2 zip files) for the user to install independently. It’s not uncommon.
Compilers stretch the GPL somewhat because a compiler, intrinsically, embeds some of its code in its output and so can taint the output. GCC has a specific runtime exemption for things like libgcc for this. I’m very grateful to the FSF for doing this. I flagged it as a problem when I started working on clang support for Objective-C in 2008 and realised that I would not be able to use the GCC Objective-C runtime with clang. I ended up writing an MIT-licensed replacement but the GCC project did a fantastic job writing a license exemption that allowed other compilers to use their run-time libraries. I presume all of the relevant bits of GNAT are also covered by this.
I understand this (I used to be in the core team of Rust, among other things dealing with licensing concerns), but that does not change depending on the GNAT frontend running on top of GCC or on top of LLVM.
the LLVM part is not allowed to be shipped in a way that gives you lesser rights than the GPLv3 part
That’s what I meant by “contaminates” :).
The other alternative is shipping the LLVM part as a dynamic library and the frontend separately (e.g. in 2 zip files) for the user to install independently. It’s not uncommon.
Interesting, I didn’t know some entities actually bothered with that. I’m curious to know more, if you’re allowed to share information :).
I‘m not a friend of „contamination“ language. The GPL clause involved in this triggers on distribution, but after that, you can totally go and use both components separately, under their respective licenses.
Interesting, I didn’t know some entities actually bothered with that. I’m curious to know more, if you’re allowed to share information :).
It‘s a common thing for distribution licenses - you go to „some assembly required“ and the user makes the free choice to assemble those things together. E.g. if you use rustc on Windows, you need to either install mingw (gnu/GPL) or Visual Studio CLI (license-encumbered, for pay for commercial applications) for the compiler to actually work. It‘s inconvenient, but keeps the „can we ship these things together“ question neatly outside of the distributors scope.
As always a very nice and elaborate writeup of the changes for Ada 2022. Every feature in Ada feels well-thought-out and fits into place, which leads to a high consistency.
Without specific mentions, big parts of the language community can learn a lot from how AdaCore et. al. do their language development.
Agreed. Wish more people use it for software development
Without a permissively licensed compiler, it’s hard to recommend the language. AdaLabs was trying to build an Ada front end for LLVM, but I don’t think they made progress.
I’m not up to date on my Ada, but what’s the problem with GNAT?
What’s the problem with a GPLv3 compiler? The FSF’s GNAT/GCC license allows linking the runtime with proprietary software.
If any of your workflow involves distributing the compiler (for example, if you want to create a developer container to allow quick onboarding for a project) then you need to comply with all of the GPLv3 conditions. If you own any patents, for example, then you must carefully audit the code to ensure that no one has snuck in any code that infringes them because otherwise you’ve just accidentally granted everyone a perpetual license. This is why a lot of companies have a no-GPLv3-code policy. In some cases, it’s more liberal (you can use, but not contribute back to or redistribute), but in a modern world using code that you can’t redistribute is painful. You also can’t use the compiler front end in any additional tooling unless you’re willing to release under a GPLv3-compatible license.
I don’t mind having a GPL’d or proprietary compiler as a second source but I wouldn’t want to build a business depending on it.
I was going to write a rebuttal, but thinking more about it this is a valid point. However here are a few things that I think weaken it:
So overall, despite it being correct, I don’t find your argument about finding it hard to recommend Ada due to the main compiler being GPLv3 very convincing :). Still, this was interesting to think about, thanks for sharing your point on view!
I think that absolutely was true a year ago, but it increasingly isn’t. A lot of development is now moving to containers, where you provide a container layer with all of your default tooling so that folks can easily contribute to your project. Even if your project is closed source, you may distribute this to consumers and so on. Similarly, you will distribute it to the folks running any outsourced CI system and so on.
That doesn’t help. The issue is:
This is why big companies are incredibly wary about distributing GPLv3 code. A clean-room build doesn’t solve this, only a complete code audit does and that’s too expensive.
The fact that it’s GPLv3 and an FSF project also makes me much more hesitant because the FSF relicensed GCC from a license that was mostly fine to a license that had a bunch of things that made corporate lawyers nervous. I have no idea what GPLv4 will look like and if I have to either fork GCC or migrate to a different compiler when GCC 15 moves to GPLv4, that’s not something I want in my long-term risk planning.
What is the importance of a permissively licensed compiler?
Is there a commercial option? I’m allergic to GPL3, but commercial is OK.
GNAT is both GPL3 and available commercially :). There’s also a bunch of other proprietary compilers, such as Green Hill’s or PTC’s. GNAT is however usually the most up to date one.
Recently they have changed that
https://blog.adacore.com/a-new-era-for-ada-spark-open-source-community
I think LLVM one is available through alire
GNAT-LLVM uses GNAT’s frontend, which is GPLv3 and thus contaminates LLVM, if I’m not mistaken.
It only means that if you ship both in one distribution, the LLVM part is not allowed to be shipped in a way that gives you lesser rights than the GPLv3 part - which essentially means if someone requests the source code to their binary, they need to get it for both components. That’s quite okay.
The LLVM bits will still remain permissibly licensed, it’s not “contaminated”.
The other alternative is shipping the LLVM part as a dynamic library and the frontend separately (e.g. in 2 zip files) for the user to install independently. It’s not uncommon.
Compilers stretch the GPL somewhat because a compiler, intrinsically, embeds some of its code in its output and so can taint the output. GCC has a specific runtime exemption for things like libgcc for this. I’m very grateful to the FSF for doing this. I flagged it as a problem when I started working on clang support for Objective-C in 2008 and realised that I would not be able to use the GCC Objective-C runtime with clang. I ended up writing an MIT-licensed replacement but the GCC project did a fantastic job writing a license exemption that allowed other compilers to use their run-time libraries. I presume all of the relevant bits of GNAT are also covered by this.
I understand this (I used to be in the core team of Rust, among other things dealing with licensing concerns), but that does not change depending on the GNAT frontend running on top of GCC or on top of LLVM.
That’s what I meant by “contaminates” :).
Interesting, I didn’t know some entities actually bothered with that. I’m curious to know more, if you’re allowed to share information :).
I‘m not a friend of „contamination“ language. The GPL clause involved in this triggers on distribution, but after that, you can totally go and use both components separately, under their respective licenses.
It‘s a common thing for distribution licenses - you go to „some assembly required“ and the user makes the free choice to assemble those things together. E.g. if you use rustc on Windows, you need to either install mingw (gnu/GPL) or Visual Studio CLI (license-encumbered, for pay for commercial applications) for the compiler to actually work. It‘s inconvenient, but keeps the „can we ship these things together“ question neatly outside of the distributors scope.
The same mechanism can be used here.
It would be nice if more languages took such care when adding new features!