Improbable said they were going to open-source part of their system under the MIT license:

"Improbable says it has set up an emergency fund to assist partners facing financial challenges as a result of Unity's enforcement action and has pledged to make its GDK open-source under an MIT license."

Now that's a big deal. They removed the old "Improbable" license and switched to the MIT license.

Someone can now make an open source compatible back-end and not use the Improbable/Google servers at all. Like OpenSim did to Second Life. A simple single-server compatible back end would be useful; it wouldn't scale, but you could develop. Then a multithread back end, to run on a big AWS instance. That would probably get you to a few thousand users.

15 minutes ago, Septopus said:

Nope..  The GDK that they have/will MIT'd isn't going to help anybody build their own back end.  It's just Improbable's Unity editor code that makes it easier for you use their SDK..  ..Yet another misleading PR spin.

Probably right. I glanced at the source, and it's mostly glue code. No code that actually does much. But at least the API is open.

What are the alternatives to Spatial OS for big shared world back-ends? For something like Second Life or OpenSim. Those scale, but with difficulty. They have problems with region crossings and choke if too many players visit a single region.

Now that somebody has done this, it should go like physics engines - first it was super hard and took an army of PhDs, and the startups that figured it out had grand ambitions and were way overvalued. Then the startups (Mathengine, Havok), went bust or had a down round and downsized. Now there are several good open source physics engines and it's no big deal.

How good is Spatial OS's performance, anyway? If 1000 players get into a melee, will it hold up? Anybody tried?

The way middle part of 2.4 sounds right now open sourcing the GDK or having others provide SpatialOS-like cloud doesn't help since it's still integrating something into your project that lets you manage deployment.

Quote

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.

This whole thing is like a pro-FOSS PSA.

They fail to define the term "Unity Runtime", "Managed Service" and "SDK Integration", though they call them out as 'defined terms' as they are capitalised where used.

I'm going to assume that the undefined "Unity Runtime" means the Unity Editor and all its dependent executables, for example, unity.exe, unityhelper.exe, etc. This assumption is based on the defintion of "Unity Software" from the 8.13 (“Unity Software” means all versions and updates of all the downloadable Unity Pro, Unity Plus and Unity Personal software products identified on Unity’s website.)

With this in mind, I read this all as being:

A) You cant run the Unity Editor tool through a cloud service provider, or on a remote server via technologies such as citrix.

(this would be to avoid licensing issues)

B) You cant create inventive ways to make use of the Unity Editor through SDK/GDK or other Middleware that you supply to customers.

(this would be to avoid people making use of a service they thought was not unity, but in the end was unity - without licensing)

C) You cant supply an emulation of the Unity Editor to deliver via cloud services.

(this would prevent what Amazon just did with MongoDB)

I love legalese long run on sentences.

"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. "

I'm guessing the intent of the above is to say you cant do a "Twitch plays" unity development. Basically you have to be local to the editor to be using it.

"Without limiting the foregoing, you may not use a managed service running on cloud infrastructure[..] 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[..] 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. "

I'm again guessing the intent of the above specifies you cant use a whole range of things to install or execute the unity runtime on the cloud... the use of the "Your project content" in this appears to limit that you cant code into your project a way to install to a cloud location, IE, no button press deployment of the unity editor to the cloud.

The above bolded by me are the conditions, the italicised is the action.

"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. "

Again, intent seems to be that you can have your "Project Content" (Defined as: “Your Project Content” means games, applications, software or other content that you develop with the Unity Software.) accessible from an end user device from a different end user device.

@Hodgman Exactly. And Unity is actually more restrictive than GNU in that regard. Let that sink in.

Edit: And by that I mean bison, GCC and other tools from GNU that all have an exception (out of pragmatism to not scare people away) to let you make non-GPL or even proprietary software despite GNU project being philosophically very against it.

14 hours ago, Irusan, son of Arusan said:

People need to be more careful in distinguishing between "forbids" and "requires an agreement with Unity". These are not interchangeable concepts.

They amount to the same thing. Terms of service are just a part of a licence agreement, and Unity have the right to give you any particular licence they want - including one essentially identical to the existing licence and ToS with 1 or more clauses redacted or amended. - but practically the only way that will happen is if you reach an agreement with them (usually financial).

(What they don't necessarily have is the right to change a previously-awarded licence to your detriment without warning. They're making very clear that they gave Improbable warning in this case, so arguably this doesn't apply.)

The whole line at the start of 2.4 is probably the root of the problem:

"You may not directly or indirectly distribute the Unity Software, including the runtime portion of the Unity Software (the “Unity Runtime”) "

"Unity Software" is already a defined term, that from this point in the document we will also refer to as "the Unity Runtime" - because thats clearer, obviously. I think this was a goof by probably an intern or legal aide who isnt overly comfortable with the concept that "Runtime" actually means something to the industry... particularly as Unity Runtime is not defined at all in section 8.

I'm still keen to see how Unity digs up from this one tho.