Unity's Terms Change Debacle

Unity announced a series of policy changes, but quickly walked them back after community uproar.

The History

In 2019, Unity, a popular game engine developer, created a PR mess when it changed its Terms of Service to prohibit the use of Improbable OS. After that dustup, Unity announced that retroactive Terms of Service changes should not apply to developers who do not upgrade their projects. To that end, Unity announced that it would host Terms of Service changes on Github to give developers “full transparency about what changes are happening, and when.”

The Recent Changes

On September 12, Unity announced a major fees change. It stated in a blog post that it would start charging a Runtime Fee each time a game is installed. The developer community was quick to criticize the new fee including taking issue with the fact that one user installing a game on multiple devices would incur fees for each install. One of the biggest criticisms was that this fee would be applied to games already released in the market:

Will this fee apply to games using Unity Runtime that are already on the market on January 1, 2024?

Yes, the fee applies to eligible games currently in market that continue to distribute the runtime. We look at a game's lifetime installs to determine eligibility for the runtime fee. Then we bill the runtime fee based on all new installs that occur after January 1, 2024. For more details on when the fee may apply to your game, see When does the Unity Runtime Fee take effect?

(from Unity’s FAQ about the changes, now edited but available from the Internet Archive here). The FAQ additionally stated that while the Fees would start January 1, 2024, the calculations would look back 12 months in time to determine the fees owed.

This stance was … interesting based on previous iterations of the Terms of Service and its own stance on retroactive changes announced in 2019.

Old Terms

For much of Unity’s history, the Terms of Service were governed under the laws of Denmark (see the version updated January 28, 2022, archived here). These terms allowed for any modifications, at any time.

However, the Unity software was also governed by Additional Terms and those terms stated that users could elect to continue using previous versions of the Unity Software and be subject to the terms that were applicable to those previous versions - in line with the philosophy announced in the 2019 blog post:

Unity may update these Unity Software Additional Terms at any time for any reason and without notice (the “Updated Terms”) and those Updated Terms will apply to the most recent current-year version of the Unity Software, provided that, if the Updated Terms adversely impact your rights, you may elect to continue to use any current-year versions of the Unity Software (e.g., 2018.x and 2018.y and any Long Term Supported (LTS)  versions for that current-year release) according to the terms that applied just prior to the Updated Terms (the “Prior Terms”). The Updated Terms will then not apply to your use of those current-year versions unless and until you update to a subsequent year version of the Unity Software (e.g. from 2019.4 to 2020.1). 

We’ll call this the “Modification Clause.” On April 3, 2023, Unity removed the Modification Clause entirely (see this archived version). Additionally, Unity removed the Github repository containing all the previous Terms of Service versions sometime around June or July of 2022. Unity stated they removed the repository because of low views and not in an attempt to obscure previous versions of the Terms of Service (although it just happened to have that effect):

(We’ll get back to this issue later.)

So where does that leave us? Well, it is possible that Unity’s new fees would be allowed under Danish law despite the previous Modification Clause (any Danish legal scholars are welcome to provide insight, we don’t have any familiarity with the laws of Denmark).

However, on or around October 13, 2022, Unity updated its terms to apply the laws of the State of California at least for United States users. The main arguments developers would make against the application of the fees would most likely be that the fee changes are unconscionable and that users of older versions of Unity did not consent to the changes. In California, a contract or provision must be both “procedurally” and “substantively” unconscionable to be unenforceable. The procedural element is often satisfied when the contract is a contract of adhesion. Contracts of adhesion have been described by California courts as:

1) a standardized contract
(2) imposed and drafted by the party of superior bargaining strength
(3) that provides the subscribing party only the opportunity to adhere to the contract or reject it.

On the substantive side, California courts have held that the agreement must be “overly harsh,” “unduly oppressive,” “unreasonably favorable,” or must “shock the conscience.” Here, the application of an entirely new class of fees to older/existing versions of the software could very well be seen as substantively unconscionable, especially when older licenses explicitly allowed for their continued application so long as the developer used those older versions of Unity.

In my opinion, Unity would most likely only be able to apply these fees to new versions of Unity after clear notification and acceptance of these new terms by developers.

The Aftermath

On September 22, Unity issued an apology and revamped its new fee program. Notably, the new fees will only apply to future versions of Unity to be released in 2024. They also stated:

We will make sure that you can stay on the terms applicable for the version of Unity editor you are using – as long as you keep using that version.

Unity also reinstated the Github records of previous versions of the Terms of Service.

The Conclusion

But what does this all mean? Unity has shown on at least two occasions a willingness to introduce massively impactful changes for developers through Terms of Service updates and attempted to apply those changes to all existing Unity users. This most recent incident came just a few years after promising developers flexibility and to not apply new material changes retroactively. Unity has said that they will restore the option for developers to choose which terms apply (though the Terms of Service do not reflect this as of this writing), but can a developer who may be working on a game for years reliably trust that Unity won’t change course again? Time will tell.