I just can't find any single sentence in the license text covering SaaS.
SaaS is covered by the following fragment (emphasized by me below) which was added since version 1.1 to the last paragraph of Article 1:
- ‘Distribution’ or ‘Communication’: any act of selling, giving, lending, renting, distributing, communicating, transmitting, or otherwise making available, online or offline, copies of the Work
or providing access to its essential functionalitiesat the disposal of any other natural or legal person.
regarding the compatible licenses, they say the other one wins.
If you combine the original work (licensed EUPL) with another work (licensed under weaker terms, but only applicable to one of the explicitly listed licenses), and there's a conflict of obligations for the combined result, the terms of the lesser license prevail.
If there's no conflict or the other license is silent, the stronger terms prevail (EUPL).
The original work always remains under the stronger terms (EUPL).
Hope this clears it up.
PS: I think maybe I understand the confusion. In the earlier comment I was talking about cross-licensing. That means making the software available under two licenses. That's something that can only be done by the copyright holder.
What you're describing is not cross-licensing. If someone takes EUPL software and combines it with code under one of the other listed licenses, the distribution alone of the mixed result can be done under the terms of the other license (if the obligations conflict etc. etc.)
It's fairly safe as long as you add a strong enough form of access control. For example if you put it behind a VPN, or a SSH tunnel, or require mTLS. Even a key in a custom HTTP header or Basic HTTP auth can be good enough if the key is strong enough.
You can further decrease the probability of drive-by bots reaching a publicly exposed service by merely scanning IPs and ports if you use a reverse proxy and hide your service FQDNs and IP.
You can do this by using TLS certs on wildcard domains rather than explicit domains, using explicit CNAMEs for the service subdomains rather than a wildcard domain, and keeping the A/AAAA records on an obfuscated subdomain rather than the base domain. If the bots can't figure out a FQDN they're not getting past the reverse proxy even if they find the IP and port.
This is obfuscation not real security but it cuts down tremendously on bot hits.