Terms of Service clarification - Multiplayer server

I would like to have some clarification on wether the following would be in breach of the license terms specifically clause 2.4 of Unity's terms of service.

Building a Standalone Multiplayer Server for Linux to facilitate our Server-Client networking with Unity and deploying it on Cloud Infrastructure (for example Digital Ocean, etc.).
To be more concrete: Building a standalone headless Linux binary with "Server build" checked, which runs on a cloud server, and acts as our Multiplayer Server.
We are currently using Unity's low-level networking Transport Layer. We might switch to our own networking solution though, since it has been deprecated by Unity.
Obviously our networking code has _not_ been specifally authorized by Unity so:

[...] you may not use [...] source code to be integrated in the Unity Software or Your Project Content incorporating the Unity Runtime (an “SDK Integration”) to install or execute the Unity Runtime on the cloud or a remote server, unless such use of the Managed Service or SDK Integration has been specifically authorized by Unity.

Click to expand...

The wording of this is extremely broad and might include the usecase I described.

Clarification is needed,

or the section should be removed. Here is 2.4 in full:

2.4 Streaming and Cloud Gaming Restrictions.
You may not directly or indirectly distribute the Unity Software, including the runtime portion of the Unity Software (the “Unity Runtime”), or your Project Content (if it incorporates the Unity Runtime) by means of streaming or broadcasting so that any portion of the Unity Software is primarily executed on or simulated by the cloud or a remote server and transmitted over the Internet or other network to end user devices without a separate license or authorization from Unity. Without limiting the foregoing, you may not use a managed service running on cloud infrastructure (a “Managed Service”) or a specific integration of a binary add-on (for example, a plugin or SDK) or source code to be integrated in the Unity Software or Your Project Content incorporating the Unity Runtime (an “SDK Integration”) to install or execute the Unity Runtime on the cloud or a remote server, unless such use of the Managed Service or SDK Integration has been specifically authorized by Unity. Additionally, you may not integrate the Unity Runtime with a Managed Service or SDK Integration and offer that integration to third parties for the purpose of installing or using the Unity Runtime on the cloud or a remote server. For a list of Unity authorized streaming platforms, Managed Services and SDK Integrations, click here.This restriction does not prevent end users from remotely accessing your Project Content from an end user device that is running on another end user device. You may not use a third party to directly or indirectly distribute or make available, stream, broadcast (through simulation or otherwise) any portion of the Unity Software unless that third party is authorized by Unity to provide such services.

Did you read the problem about spatial os? If unity is now blocking all cloud hosted servers, then I am totally disappointed. That looks for sure that unity only wants to sell their own cloud solutions. But this behavior is for me a breach of unitys own philosophy to drive innovations and support developers.
I hope Unity will give an official statement to that and removes this S***ty part of their terms and conditions.

They made an announcement. It appears to be this is a speculation which was made by Improbable, according to Unity's blog post. And dear @Joachim_Ante answered in a forum thread, which clarifies Unity users are not restricted in any case to use a multiplayer service as long as it is a generic cloud service. So there is nothing to worry about, I guess. Just a misunderstanding.

Since the blog post seems to contradict what is _actually_ written in the TOS in every possible way the question remains:
which one is legally binding: that what was stated in the blog post, or the wording of the TOS.

It seems that Unity blocks all of dedicated-server solutions except their own services according to TOS 2.4. Current TOS 2.4 and the blog post are very different so many developer are confusing. What is additional SDK? for generic cloud service, heartbeat routine or packet relaying lib are additional SDK? how about automation? there are too many ambiguous factor.

I like Unity engine and I hope that Unity clalifies this issue as fast as possible.

Since the blog post seems to contradict what is _actually_ written in the TOS in every possible way the question remains:
which one is legally binding: that what was stated in the blog post, or the wording of the TOS.

Click to expand...

I would say its safe to assume the TOS wins, it is the legally binding agreement between you and Unity.

I'm assuming the Blog is meaningless beyond a statement of their intentions. Whether you could use it as an argument in court I have no idea but by that point your odds of winning are probably not good.

Does this kill Amazon game lift dead?

Click to expand...

I am also using Amazong Game Lift. From reading section 2.4 of the TOS it does seem to imply using Amazon GameLift would be in breach of the terms.

It seems that Unity blocks all of dedicated-server solutions except their own services according to TOS 2.4. Current TOS 2.4 and the blog post are very different so many developer are confusing. What is additional SDK?

Click to expand...

This seems to be the core issue. The reference to using a cloud provider with an SDK seems it would apply to almost every scalable hosting solution available. I would hope that this is not their intended affect on developers, just the result of poor wording in the TOS.

I've reached out to Unity regarding GameLift at the email they setup for TOS questions. Hopefully we get some news today regarding this issue.

Works with your existing engine and workflows
Whether you use a AAA engine like Unity, Unreal, Lumberyard or a homegrown C++ solution, the Amazon GameLift SDK easily integrates to get your servers up and running in the cloud. ​

Can Unity please clarify why SpatialOS is in violation of the ToS, but GameLift is not?

Both services are effectively providing the same thing -- an SDK to enable hosting and management of headless dedicated Unity server instances running in the cloud. In both cases, the developer is uploading headless server builds of their Unity app (the builds are generated normally by the developer with their own hardware, Unity Editor, and Unity license) and then the cloud service handles deployment, load-scaling, and execution of the app. One difference between the two seems to be that SpatialOS also provides advanced techniques to divide up and split shared simulation state across multiple Unity server instances (or sever instances written with any other engine technology, for that matter). But that feature does not seem relevant to the ToS issue here though. The underlying services provided by SpatialOS and GameLift are essentially the same, so why is the enforcement of the ToS not the same as well?

Since the blog post seems to contradict what is _actually_ written in the TOS in every possible way the question remains:
which one is legally binding: that what was stated in the blog post, or the wording of the TOS.

Click to expand...

The ToS technically wins, but Unity's blog post makes it clear how they will be enforcing it. With them choosing to not enforce the ToS against even SpacialOS users with existing games either shipped or in development, it is clear that they intend to be very selective about what entities this is enforced against, namely the most extreme violators.

When I say the ToS technically wins it is because what is written in the ToS doesn't actually matter compared to how Unity chooses to enforce the ToS. How they enforce it is what matters, and if they say the ToS wording is not intended to go after your dedicated server game, or whatever server setup you use that is not what someone would consider broadcasting or streaming, that should be all you need to know.

Why is the technical wording of the ToS not very important? Because Unity, like virtually every software company ever in the history of ever, includes a clause in their ToS that they can change the ToS at any time. So if for some reason they later wanted to ban all servers other than their own, they can just change the ToS at that time to do so. They can literally tomorrow add to the ToS that all servers are banned besides theirs, and the wording of the ToS yesterday when you wrote your game wouldn't matter in the slightest. Unreal could do that, or any other engine too.

So what really matters is the intent of Unity, really the only thing that matters, and I've seen nothing regarding their intent to do anything like that even ignoring their blog post stated that flat out. Their track record doesn't say that either, given that they have had a networking service (Unity Multiplayer Service) for years yet made no attempt to strong arm the community into using it.

If you don't like that situation, your only choice is to entirely write your own game engine from scratch without any code licensed from anyone. No 3rd party physics engine, no 3rd party networking, etc, so you can avoid agreeing to any ToS in the process, since whatever ToS you agree to will undoubtedly state that they can change it at any time.

I don't think Amazon basing the safety, upkeep and development of a service like Game Lift on a blog post is going to cut it.

The ToS change by Unity is beyond irresponsible and they need to deal with the problem internally, followed by issuing an apology to the community for their lack of clarity and insight. Changes need to be made to how their legal team operates and the ToS altered to reflect objectivity.

Big companies cannot take a single step forwards without a legal team being involved and the ToS is where it starts and ends.

To say they've angered people would be to woefully understate the gravity of this situation.

Regarding everyone comparing GameLift and SpatialOS. Did everyone miss the fact that cloud platforms are not banned, but has to be approved? Or am I missing something?

From blogpost:

"However, if a third party service wants to run the Unity Runtime in the cloud with their additional SDK, we consider this a platform. In these cases, we require the service to be an approved Unity platform partner. These partnerships enable broad and robust platform support so developers can be successful. We enter into these partnerships all the time. This kind of partnership is what we have continuously worked towards with Improbable."

Regarding everyone comparing GameLift and SpatialOS. Did everyone miss the fact that cloud platforms are not banned, but has to be approved? Or am I missing something?

From blogpost:

"However, if a third party service wants to run the Unity Runtime in the cloud with their additional SDK, we consider this a platform. In these cases, we require the service to be an approved Unity platform partner. These partnerships enable broad and robust platform support so developers can be successful. We enter into these partnerships all the time. This kind of partnership is what we have continuously worked towards with Improbable."

Click to expand...

I'm not sure I agree with their stated philosophy on this but I still can't seem to find much documented regarding their currently approved cloud partners.

The terms of service for section 2.4 points to this page and the regular partners page is located here. Seems there is a lack of cloud providers included that could potentially be impacted. AWS, PlayFab, Multiplay etc. I'm not sure where else this would be documented. Perhaps they will provide an updated list?

Oops...

"Unity", Unity logos, and other Unity trademarks are trademarks or registered trademarks of Unity Technologies or its affiliates in the U.S. and elsewhere (more info here). Other names or brands are trademarks of their respective owners.