proposal for a standardised software environment
Version 1.0/4.5.2, 25.04.2026
The fastest and least expensive approach for the EU or a country to seriously increase their level of digital sovereignty might be to
announce that they will demand at a certain future time from their software suppliers (and those of critical enterprises) that their Windows software is guaranteed (officially supported) to run under Wine, too
and make this much easier (or even possible at all) for the ISVs by supporting the creation of a specialised Linux distribution for the use of Wine in an enterprise environment.
European governments (on EU, country and state level) have realised that digital sovereignty is an important goal. This problem has several components, e.g.
software being developed outside the EU
software being available only for Windows or MacOS
software being dependent on other software which is developed outside the EU (e.g. Microsoft Office, Oracle, MS SQL Server).
There may be sufficient political willingness to create legal or market-based demands (through public procurement) which would increase Europe's digital sovereignty. But such demands are politically viable only if they are technically feasible. Technical feasibility is unlikely to emerge without such pressure. So this is a chicken-and-egg problem.
This document only refers to the operating system part. Critical applications from non-EU manufacturers are a very different problem.
Committing to the FermentOS approach follows a principle that also underlies the strength of the European Union: success does not come from finding the best possible version of every regulation, but from standardisation.
Accordingly, FermentOS is not about finding "the best possible version" of Wine, but about defining a single version as the standard platform for everyone who requires long-term guarantees.
For companies which offer Linux software and / or services it should automatically be attractive to enable the migration of Windows environments to Linux as this increases the size of the Linux market. In this case revenue would be shifted from Microsoft licenses to FermentOS services.
It is usually a lot of effort to create a Linux version of a Windows software and not economically attractive to offer both. And which Linux distribution(s) should even be supported? Even more effort.
But getting rid of the Windows dependency does not necessarily mean to have an additional Linux version. This goal may be reachable with a small fraction of the effort necessary for developing a Linux version. If only small changes to the usual Windows development process are required then the smaller group of potential Linux customers might seem attractive enough.
There is very little official support for Wine from ISVs. For most software it would be very easy to make a future version of that software compatible with WINE with very little effort. But until now ISVs have little reason to do that. This is not a technical problem just the lack of demand in the market or legal pressure.
If an ISV wanted to officially support Wine then at least these problems would arise:
Which version of Wine, which Linux distribution, which desktop environment?
Will this version of Wine be reliably available for the lifetime of this version of the ISV product (guarantees similar to those for Windows)?
Will there be (enterprise grade) security fixes?
Will there be changes to Wine which might break the ISV product?
Since 1993 Wine has been offering the possibility to run (certain) Windows software under Linux (and a few other operating systems). Since 2018 the gaming company Valve has been making important contributions to / extensions for WINE (Proton) in order to make more of the games they develop / publish / distribute be able to run under Linux.
Demanding a software which does not require Windows to run is the big step. But for serious digital sovereignty it is not enough to have such requirements for the final product only. The product must be maintained and that possibility in guaranteed only if nothing can block the use of the toolchain (compiler, libraries, IDE) which is used for this version of the product.
This may be a too difficult demand to start with but it should be announced at the start to become effective a reasonable time period later.
The interested parties i.e.
the governments
because this would be a huge step in reducing the dependency on Microsoft / the United States
because this would give them a very concrete approach what to demand from their suppliers
Valve
because they are the biggest contributor to Wine and may see benefits for their approach even though their aims are quite different
FOSS advocacy groups (Free and Open Source Software)
they may see a reduction of the general dependency on Microsoft as a win as this would make it much easier for private, business, and government users to switch to a FOSS operating system
they may hesitate to support this for the radical argument that this might reduce the pressure to switch to full FOSS solutions instead
Linux distributors
because they would want to make sure FermentOS runs under all (or at least their) Linux distribution without either problems or a lot of integration effort
ISVs and other companies in the Linux ecosystem
because they can expect to immediately benefit from a growth of their market (a lot more professional Linux users)
because the Windows ISVs which want to officially support FermentOS might become their customer
business associations of Windows ISVs
they might assume this will become important in the future (due to the government pressure) and would want to be part of this from the beginning and not be the last one to step into a territory completely shaped already by Linux actors
Windows ISVs which mainly sell to governments
because they expect to be the first ones to be forced to support this
companies or government organisations with very high security requirements
might want to use FermentOS not as a replacement for Windows but as a hot stand-by system to which they can switch their application immediately when there is a security problem with Windows for which no fix is available (or not internally validated) yet
maybe even companies which just use Windows software
because they might be the target of legal pressure (because they operate critical infrastructure)
because they are huge and hope for an option to reduce their license costs to Microsoft
could create a long-term NGO which creates a very limited Linux distribution (and maybe a container version) with the sole purpose to provide an ISV-friendly Wine platform i.e. long-term support (10 years) and stability.
They would probably not provide technical input but the data protection officers would support the possibility to run Windows applications without Windows – given the sad data protection history of Windows.
The requirement to offer longer support than usual for Linux may offer positive effects for non-Wine-related LTS versions of Linux distributions.
The list of important details would have to be provided by Wine developers and Windows ISVs but as this is about compatibility the value of this solution would be less in detail decisions and more about having a reference implementation.
In order for this to be able to run anywhere (both in the target Linux environment and on the Windows systems of developers), the provided solution must be a whole virtual machine.
For a safe separation of different applications they may be put into a container environment so that only one VM is necessary for several applications. If the kernel seems not relevant for an application then it could run without a VM as container.
This would be a very small Linux configuration, limited to what is necessary for Wine and the maintenance of the VM.
This approach only works (without problems) if everyone uses the same version. Same source code version or even identical binaries.
Organisations in the FOSS sphere are used to making adjustments to the software they ship. There is an official Linux kernel but it is used virtually nowhere.
But as the whole FermentOS approach is to guarantee a stable platform to Windows developers, those Linux organisations which want to participate in this project or just use the result would have to accept that changes are only allowed around FermentOS (where they are not seen by the Windows applications) but not to the core software. This could be easily achieved by using a trademark. Everyone is allowed to use the software in the usual FOSS sense but is allowed to use the name which the Windows ISVs refer to only if they use the unchanged software.
With the expected wide-spread use of this product, the different desktop environments would provide tools for the comfortable access to applications within the FermentOS VM / container.
The distributions would provide comfortable ways to install this VM / container. There may be some basic standardisation so that the same command name can be used on all distributions with the implementation being distribution-specific.
At suitable time intervals (every 2–5 years) there would be a new version with long term support for which compatibility would be guaranteed as far as that is possible / feasible.
The FermentOS NGO would probably establish a communication platform through which the Windows ISVs can collectively determine which future Wine development is required next.
The preferred long term effect of this approach would be that the Windows ISVs which officially support FermentOS do not even develop primarily for Windows any more but for FermentOS. An application that runs flawlessly under FermentOS should run flawlessly under Windows, too.
There may be advantages (security, containerisation or other) in using FermentOS for certain Windows applications under Windows.
If Wine becomes more relevant for certain Windows ISVs and especially if these ISVs are forced to not only provide a product which is guaranteed to run under WINE but to create it only with software which fulfills the same conditions (which excludes the products by Microsoft) then it would make a lot of sense to help the ISVs achieve WINE compatibility with as little effort as possible by extending Mingw-w64 with options which make it avoid or warn in the case that problematic API calls are used.
FermentOS might be attractive even for organisations which do not want to use it regularly but which have very high security requirements. When there are security problems with Windows then all these organisations can do today is wait for Microsoft to provide a fix. With FermentOS they could have a very different (with regards to the implementation) system on stand-by which would not be vulnerable to the same exploits.
For the same reason one could consider having a BSD version of FermentOS (later) so that in case of severe problems with Linux it would be an option to immediately (just temporarily) switch the Windows apps to the BSD platform. Would be cheaper and maybe organisationally easier than to have Windows systems on stand-by.