What developers can learn from the Unity & Improbable situation
Depending on who you speak to or which publication you read, either Unity are abruptly updating their terms of service to gather more money from a successful platform, Improbable have been knowingly violating the terms of service for many years, or both companies are in the wrong for a complete lack of professional communication. It’s fair to say public opinion is split on who is in the wrong and it’s all a bit of a “he says, she says” situation…
Regardless of the outcome there is a clear lesson to be learned about third-party software and licence agreements.
Last year I wrote a blog post about our proprietary rendering technology that included a section titled “Why not just use Unity?!”. In it I mainly discuss the technical differences between our platform and Unity, demonstrating why we decided to write our own software. However I left out another major reason; we didn’t want to base a large part of our business on third-party software.
Be aware when using third-party software
Whenever you decide to use third-party software, you enter into a legal agreement with the provider of that software. This agreement contains details of what you are legally entitled to do with that software whether that be using it to develop applications, redistributing it or simply hosting it. Most license agreements contain a line to the effect of “[provider name] reserves the right to change these Terms or any Services at any time”. This effectively means that at any time, the provider of the software you are using can change the agreement you have with them, potentially stopping you from using that software temporarily, or even permanently.
Now I am not at all suggesting that developers should never use third-party software, in fact using third-party libraries and software is a major part of writing good quality applications! However developers need to be aware of what rights the license agreement for that software grants them.
There are a couple of basic guidelines that a developer could follow to help determine whether or not they should be using a particular piece of third-party software such as:
Does it have a large custom license? - There are some widely used, simple licenses such as the MIT License, that are designed to be very permissive and encourage free use. Many open-source community projects will use this sort of license and they are generally a very safe choice, although developers should still read them.
However proprietary paid-for software will often have a custom license agreement to go with it, these agreements are generally long documents full of vague legal terminology. Developers and businesses should be very aware of these licenses and it’s often a good idea to have direct contact and support with the software provider in order to receive written answers to any questions one may have.
Is it being used for a core integral part of your application? - Using third-party software to perform a major function in an application is risky. If for any reason you are no longer able to use that software, then you are potentially faced with the task of having to replace/rewrite a large part of the application whilst having to keep it’s functionality the same. This can be very difficult and time consuming, potentially leaving customers in limbo until the work is done.
These are just a couple of very basic guidelines, they don’t cover every situation and it is ultimately the responsibility of the developer to fully understand the potential implications of using any third-party software.
In fact Improbable don’t even use Unity to build their SpatialOS software platform, but simply hosting content on the cloud that has been created with Unity is against their terms of service. Whether you agree with this change to their terms of service or not, Unity are completely within their rights to make the change, which is something all developers should learn from.
Obviously I'm a software developer, not a lawyer, so please do obtain relevant legal advice before entering into a contract.