Do the sanctions imposed on Russia forbid email communication of an American non-profit entity with Russian volunteers?
No*, at least not in general and most likely not in the specific case that was brought up here.
As a general rule of thumb mere "communication", by email or otherwise, is not forbidden by any sanction by democratic countries I know and I'm quite certain that no North American or European court that deals with constitutional matters would allow for such far-reaching restrictions, that would likely impede the freedoms of a jurisdictions citizens way more than they'd work towards the goal set by sanctions.
However, since the reasons brought up by Linux Foundations are not, as the question implies, "a restriction on email communication with Russian volunteers", let's dive a bit deeper.
Sanctions are measures that target (foreign) adversaries capabilities, especially in the military, financial and infrastructure sector, to name just a few. While directed at said adversaries, sanctions work by legally binding domestic entities into compliance.
This includes NGOs like the Linux Foundation, which is a registered 501(c)(6) non-profit, which is the type of non-profit that is formed by people to work on improving business conditions in their shared field of work, while as an entity not directly engaging in for-profit business.
In regards to the US and Russia, we're speaking about the Russian Harmful Foreign Activities Sanctions Regulations which includes Prohibition on Certain Information Technology and Software Services (section 1(a)(ii) of E.O. 14071), taking effect since September 12th: see here
The exportation, reexportation, sale, or supply, directly or indirectly, from the United
States, or by a United States person, wherever located, of IT consultancy and design
services or of IT support services or cloud-based services for Covered Software to any
person located in the Russian Federation.
Whether or not Linux in its totality falls under that could lead to different answers, because in the realm of Linux of course there exist "cloud-based services for Covered Software...", but since we're speaking about the Linux Kernel here, a quick, non-technical note on what that even is. The Kernel is the set of software that is at the core of Linux or you could say that is all that Linux is. It provides these pieces of code that make hardware (material pieces) work and provides a basic framework that all other software builds upon. The Kernel developed by the Linux Foundation is a non-commercial, open-source project that is not a service in and by itself.
Furthermore, there are notable exceptions to the aforementioned sanctions, such as these here:
(2) Activities to support democracy building in Ukraine or the Russian Federation,
including activities to support rule of law, citizen participation, government accountability and
transparency, human rights and fundamental freedoms, access to information, and civil society
development projects;
(3) Activities to support education in Ukraine or the Russian Federation, including
combating illiteracy, increasing access to education, international exchanges, and assisting
education reform projects;
(4) Activities to support non-commercial development projects directly benefiting the
people of Ukraine or the Russian Federation, including those related to health, food security, and
water and sanitation; and
I would argue that Linux at its core, and thereby the Kernel, falls under such exceptions, because it plays an important role in (at least) these three areas. Certain services that go beyond the mere development of the Kernel would however not be exempt from said sanctions.
As for comparison, GitHub only restricts certain usage in regards to sanctions, namely GitHub Enterprise Server and GitHub CoPilot, meaning they do not offer these services to (among others) Russia. However, they state:
As a result of our advocacy and hard work with U.S. regulators, GitHub has secured a license from the U.S. Treasury Department’s Office of Foreign Assets Control (OFAC) to restore our cloud services to developers in Iran. And we will continue to work with U.S. regulators to secure similar licenses to offer collaboration services to developers in other sanctioned regions, such as Syria and Crimea. We are committed to advocating for the broadest possible developer access, as we believe offering code collaboration services for developers in sanctioned regions makes the global developer community stronger, advances human progress, and supports the enduring U.S. foreign policy of promoting free speech and the free flow of information.
as well as:
Looking ahead, we’ll continue to closely monitor developments in US sanctions laws and will restore access for restricted users as soon as we’re legally able to do so. We’ll continue to speak—to corporations, to individuals, and to governments—about the value of ensuring that humanity can share information and collaborate around the world to produce positive outcomes.
Linux Foundation argues some legal issues that may arise from the collaboration mentioned and while a surface view seems to indicate this not being the case, there may in fact be certain legal measures, that are typically not made public, that could force the foundation (or any other US-based entity) to take such steps. Also known as National Security Letter. This is purely hypothetical and reading the discussion among the Kernel team seems to indicate that there are entirely different reasons.
As to answer the question behind the question: I'd say nothing indicates that there are legal obligations that would indicate expelling those team members.
From here on out, the following is just additional context mixed with some (limited) view points regarding the philosophical debate concerning free software, so take it with a grain of salt or ignore it altogether.
It is important to know, that barring the contributors, does not mean that Linux won't be available to Russian citizens or companies (including companies that produce weapons) any longer, nor does it mean that their previous contributions will be deleted from the Kernel.
The driver code to which the dropped maintainers contributed remains in place.
source
Then, why expel people? One possibility I see is the fear that an adversaries agents (if such were among the expelled developers) may be able to negatively influence capacities that are vital to US (or EU) interests. In other words, if an adversarial agent was able to create some kind of Kernel software vulnerability, they could wreak havoc. Regarding other software, it has happened in the past. There was also mention that the Russian government might try to coerce Russian developers to do such things, which seems at least to be a legitimate fear.
In terms of the Linux Kernel however, I'm not sure how realistic such a scenario is. As far as I know, Linus Torvalds has the last word in all Kernel matters and he's appropriately (and famously) strict when it comes to code quality. Code contributions made by others are not just pushed into production, they're subject to an extensive review process by Torvalds and others. That being said, I can see some reason in taking broad action that doesn't put you in the position to have to wait for sabotage to happen, before you punish it. However, the flaw in that logic is pretty obvious: adversarial agents, tasked with sabotage, may not be the ones working for companies of the countries in question, may not be the ones marking themselves by opposing your stance, may be domestic citizens and may even appear super pro-sanctions and whatever. It doesn't mean that aforementioned steps are wrong per se, just that they could lead to a false sense of security. Whether or not those expelled could do real damage is beyond my understanding of how the Kernel team actually works.
Finally I'd say, there is a strong possibility of this step being neither about public, or non-public legal bindings, but about trust in a common set of values. As you can see in this discussion, this was not about banning Russians, but seemingly Russians that have a position on the war that doesn't align with the view of the majority of the Linux Foundation. So while some argue there were "racist reasons", this seems not to be the case, but rather an issue of "political stance". Notably, among those that were expelled are Russians living in the US and working for Amazon Web Services at the moment, while among those that defend the action taken are Russians living in North America, too.
Whether you agree with the step taken or not, from experience in a whole number of settings I've learned that if fundamental parts of your world view diametrically oppose each other, you'll constantly face a batch of problems that come with a bad atmosphere of distrust and dislike, such as lower productivity, people stopping their contributions altogether and the outright fear of working not together, but against each other. From a managerial point of view, that puts you in a tough spot.
From the perspective of an open-source developer, while I'd like to argue that the idea of "collaboration" should - at least in theory - make it possible to precisely allow for a working together on common goals even when diametrically opposed in terms of opinion or set of values, it is also the case that there is no neutral code. Code is always political and the Linux Kernel is a prime example of that. It is heavily opinionated towards the user controlling the software and not the other way around.
However this does not structurally inscribe for what purpose Linux is used. Yes, this means that somebody could develop a weapon of mass destruction that is powered by the Linux Kernel, but no, this is not specific to the Linux Kernel and maybe more importantly, if you try to inscribe safety measures against such misuse, you're basically using software to control the user, the thing you didn't want to happen in the first place. Even if you have legitimate reasons, the damage you're doing to valid use cases is much higher. In other words, while the Kernel is opinionated by design, on the basis of its own opinionated design it has to be neutral to the use case.
However, does that mean that the people building somewhat neutral infrastructure like a bridge (or a Linux Kernel) do have to be neutral? No. Does an opposing stance make any common bridge-building impossible? No. Would that lead to the conclusion that diametrically opposing stances are always a good way to build something together? Certainly not the case.
I see my hypothesis supported by what Linus Torvalds himself wrote:
As to sending me a revert patch - please use whatever mush you call brains. I'm Finnish. Did you think I'd be supporting Russian aggression? Apparently it's not just lack of real news, it's lack of history knowledge too.
Make of that what you will, but at least to me this seems less of a legal matter and more a matter of trust and assumed world views. Like it, dislike it, from a philosophical stand point I think it means that open source development can't shield itself from the real events that happen in society and those interested in free and open source software may be inspired once again to take a deeper look into the basic workings of everyday systems we all use and ask themselves to what extent does software (or any other tool) needs to be inscribed with opinion, how exactly is that done and from which point onward does it have to be use case neutral or unopinionated?
In regards to law it might inspire a similar debate: to what extent does any exception to sanctions need to be structurally inscribed with "opinion" (meaning here: something considered with overall positive effects that outweigh the goal behind the sanctions) and based on that, where do we reach the point at which further fine-grain control becomes hardly possible and we have to assume a stance of "neutrality" unless specific cases of misuse of exceptions pop up, i.e. where measures other than sanctions will have to be used to counter unwanted usage of exceptions.
