Unity Updates to our Terms of Service and New Package Guidelines

Wow, what an absolutely terrible decision, good way to kill the package manager.

And the reasons are laughable.

 

I am so incredibly angry that Unity has ruined UPM experience for Google packages. I pulled down the latest commit of our project today as I am working from home only to be met with package resolution errors because Google had to shut down their scoped repository.

Thanks.

Thanks so much.

 

Idk what the point was of soliciting concerns if the overwhelming chorus of "this sucks and is braindead stupid, please revert" is ignored.

Unity is wrong here, and I'm sure they don't appreciate my frustrated tone but I don't care, they're still wrong.

I hope every asset developer goes the route of Odin Inspector offering direct purchase/subscriptions.

If we're going back to using .unitypackage or workarounds like private git/verdaccio access then at least devs can finally self host older versions, etc, and provide an even better experience than we have now via the crappy antiquated insufficient Asset Store.

I know UPM is unavoidable for Unity internal packages and workarounds going forward but, those aside, I don't want to touch the Asset Store or any "Unity authorized channels" ever again for anything developed by a third party.

There is no reason for wrapping UPM in legalese, period. Even kids using Roblox Studio have access to multiple, unrestricted package manager solutions..........

 

Inb4 thread is locked and legitimate complaints are labeled as derailment in corporate-speak lol

 

"I am so incredibly angry that Unity has ruined UPM experience for Google packages" - 999% agree.

Unity PLEASE reconsider this decision, the developers beg you (as you can see). Managing (primarily Google) packages/dependencies was finally a breeze and now you destroyed it.

...or introduce "Trusted Partners" which doesn't have to fully comply with the new terms of services?

 

Honestly even if Unity reverts this decision the damage has been done already, do you really think Google will risk money coming back to using this?

What was one of the best features Unity created recently was essentially killed because anyone who would use it will not risk anymore dev time using something they might just break on a whim.

It's unbelievable.

We're back to adding massive amounts of plugin trash inside our assets folder, manually having to manage updating plugins, having to go to multiple websites to check for updates and download the terrible .unitypackage files.

 

I was so looking forward to a time where I could integrate every SDK via the package manager. The Google Scoped Repository was a nice glimpse into the future.

 

I think trusted partners would be the opposite partners who are in full compliance with Unity's whims, and any exceptions that might come with that. Probably more for marketing reasons or to re-assure people for whatever it's worth.

Personally I don't care at all about a trusted partners program.

I want full flexibility and freedom by default, like we had before and in every other mature package manager.

 

I don't actually care how they solve it, I just want @LeonhardP to take this feedback back to Unity and do something about this!

 

Unity team, give us your feedback, please! Don't ignore these asks. It's very important for all of us.

 

My google packages are no longer working because Unity changed their TOS. Fix it!

 

It is not being fixed. Rather than compete on a level playing field, Unity has tilted it in their favour by making it that much harder to obtain competing products. I can see no other reason for this change.

We'll be stripping Unity Analytics out of our project soon in favour of Flurry regardless of how hard Unity makes it to use competing products.

 

I had a feeling that once they went IPO they'd sell out to the developers that helped build and create the foundations on which they stand on.

Unfortunately depending on how the Apple VS Epic lawsuit goes we'll know better how this will all play out.

Don't get me wrong, I think Unity is entitled to some financial compensation for the editor and their IP, but it needs to be done in a fair and honest way. I can see some Anti-Trust suits over this in the near term.

Maybe it is finally time to make the switch to Unreal after 15 years...

 

But the Package Guidelines only apply to packages and only those that are distributed via the standard channels anyway as I understand it?

So if I were to write an external script (such as openupm does it) that does not fall under the package guidelines. Or does using the Unity Editors Package resolution features (i.e. the downloading of packages that are entered in manifest.json) count as distribution?

I'd like some clarification on that point as it seems to me that according to these guidelines the following two scenarios are still possible:

1.

A standalone application that does not leverage the Unity Editor but just modifies the manifest.json file leaving the Unity Editor to resolve packages, since these packages are not distributed through the Unity official channels they do not have to conform to the Package Guidelines right?. (this is what openupm-cli does already, so I'm assuming this is still ok?)

2.

A standalone application that performs the complete package resolution process outside of the Unity Editor and puts the resulting packages either directly in Assets/Packages or leverages manifest.json again pointing it at a local folder using file:// as the version string (this would then completely cut out the Unity Editor from the distribution portion as it is not even leveraged as a downloading mechanism in this case)

 

Not a lawyer, but if you're a company building a standalone application to distribute files to users that may or may not be unity related, I don't think you would need to accept the terms of service in the first place. Otherwise, every CI or source control software would be violating Unity's terms of service.

 

On the matter of CI systems: They need a valid license in order to work.

I would concur somewhat, though there might be legal issues for the users of said software. The whole issue is that its entirely unclear what is and is not allowed when it comes to using the package manager for package resolution but feeding it from outside the editor.

I get that its not allowed anymore to write editor extensions that allow any sort of package discoverability. The question is whether such extension would somehow be allowed if distributed outside of the editor in the first place. From my point of view building an editor extension is just leveraging the interfaces exposed by Unity, since it does not include any code from unity itself the license could be whatever. I am not sure if the TOS can actually apply to things that are distributed outside the editor in the first place unless they include actual unity source files (in which case the companion license applies). All the compilation and linking of the code happens within the editor of the user USING the code. It might be that they somehow breach the TOS by importing such a package, however as far as I understand it you can still do whatever you want with your editor as long as you don't distribute it.

The fact that google decided to withdraw their scoped registry appears to me to imply that their lawyers thought it was not a risk worth taking however.

 

The term "Package" is so generic and could apply to any collection of files, not just .unitypackage's

I could be missing something here, but It sounds to me like Unity banned the use of CI, because given a strict interpretation of the text of the guidelines, that is exactly what it does.

 

That's pretty much why I said:

A lot of Unity's new terms are wishful thinking and largely unenforceable from a practical POV (and in some cases from a legal POV as well, depending on the jurisdiction)

Ignoring that this was the path of least resistance for them (no major changes needed to the SDK as long as it's repackaged in an antiquated format going forward) I think Google simply has no incentive to fight this out, and even if they did, imo it wouldn't make sense to do it under the official Google banner and affect overall relationship with Unity.

There is no need to formally burn bridges since a technical workaround to move around UPM can come from anywhere, and Unity is entirely powerless to stop it.

 

Yes please. Somebody needs to make an Independent Package Manager For Unity

 

But then that would be in violation of the terms and conditions. Although Unity has said this move was about quality control somehow, I think the real reason for these guidelines is exactly to prevent independent package managers and Asset Store competitors, so they can protect that lucrative revenue stream.

 

That's why I said Cydia type. I think it's a logical end to predict in this scenario. Every major "package manager"-like thing I can think of that was restricted ended up with a workaround.

Although it doesn't even have to be Cydia style. There are a lot of scenarios here where Unity couldn't do much from a legal POV.

They can write whatever they want in their Terms, it doesn't mean it's enforceable or legally extends to the scope of other people's work.

For example if an indie in Russia, who doesn't use Unity, shared an independent package manager tomorrow, for free, what could Unity really do?

Threaten their host to take it down?
Revoke the indie's non-existent licenses?
Revoke the licenses of everyone who ever used it?
Kill off UPM with more DRM hell that ends up being worked around anyway?
Hunt down the dev and try to litigate them into submission?

Maybe that's something they're enthusiastic about and would see as a win, idk.

Personally, I wish they would come to their senses. If this was really financially motivated then I don't see how this helps in the short or long term, but ok. This attempt to create a moat is already backfiring, so...

I hope someone puts this to the test:

 

I just want Google packages available via package manager and the ability to use CI and version control without violating the letter of the package guidelines. Is that too much to ask?

 

@LeonhardP can we get a response regarding this?

 

I'm already seeing few companies providing downloadable .unitypackage that have auto-updaters. They can download whatever they want to a project. Yikes, doesn't safe very safe.

 

Is using NuGet for Unity a violation of the Package Guidelines and Unity terms of service?

 

I would assume that since it doesn't use the package manager for resolution it isn't in scope of these rules.

 

Definitely. Really just highlights that this is not a security-minded change, but just a move to thwart competition to the Asset Store. Sad, considering the package manager was one of the best new features Unity implemented in the editor.
We've come a long way since "democratizing game development". Expected when they decided to list the company, but sad.

 

Such a shame. I'm sure the Devs working hard at unity agree and must be frustrated about this. Seems like someone at some level has decided that this is the way it'll be and perhaps even told the team to ignore complaints until people inevitably learn to live with it and move on. What an absolute waste.

 

Because of:

• I want my library to be immutable so I want to export my package as tarballs.
• My package has a dependency on some open source library which can also be exported as tarball.
  
• Unity 2018 doesn't have the UI for importing the tarballs and even with UI users would have to import each dependency by hand.

I would like to export tarballs with custom script as .unitypackage.
After importing .unitypackage the script would prompt the user if he wants to import/update "x and y" packages to his project.

Am I allowed to do this? @LeonhardP

 

Can we conclude that you actually don't allow the creation of nugetforunity ?

 

I'm sorry but this is entirely not clear. He's not talking about a marketplace. He's talking about importing a .unitypackage that performs changes based on user input to the package manifest.

If this alone is not allowed (which I thought it was as long as you aren't "advertising") then how is openupm still legal? Because its not "in" the editor? Would distributing a bunch of scripts that modify manifest.json then be legal as openupm is?

You've also quoted Nuget for Unity as well which is a completely different beast that doesn't even use the Package Manager but just adds a different form of Package Manager into Unity. How is this covered by these guidelines at all?

How is "Internal Usage" fine but "Sharing for Others" not especially when it comes to Nuget for Unity (https://github.com/GlitchEnzo/NuGetForUnity) which has been around for quite some time and is not some sort of internal development by anyone.

The problem is that we are all VERY unclear about what constitutes a "platform" at this point. The practice of having autoupdaters bundled as editor scripts delivered via unitypackages seems to exist for a long time and as far as I can tell this is NOT illegal per these rules, it would just be illegal if the updates were delivered via Package Manager? But then again Package Manager is fine to use if you add the dependencies yourself instead of having it done via a script?

Please make some clear examples of what sort of distribution mechanism are still available to people wanting to provide packages to their users via scoped registries. Examples that don't just quote the rules but that actually add real value to understanding this extremely strange situation you've put us in.

As it stands right now it seems like ANY sort of distribution of packages that leverages ANY part of inbuilt Unity Editor functionality is illegal especially if it provides search features or anything similar (see Nuget for Unity).

 

I think its entirely unclear what we can conclude from that answer, see my reply just above. Also its entirely unclear _who_ is actually breaking any Terms of Service here. Apparently if its for internal studio use its ok? But then what else is it for? Can I advertise on my webpage that you can just install Nuget for Unity to install my package? Is that not ok then? What if someone just publishes their package on Nuget and I happen to install it from there? May I myself only install packages from Nuget that I have pushed there? Its a total mess of rules.

 

Even a git client violates those guidelines since it "programmatically modifies installed packages" when you pull an updated packages.json file, so nuget for Unity seems to be in complete in violation, as would be any script or tool which can download anything from anywhere inside the Unity editor, unless you write that tool yourself and never distribute it outside of your company.

 

As I said its very unclear right now. The official Terms state the following:

So according to this, its actually the people that create the packages that are liable? But I don't really have any control how my packages are made available especially if they are openly available. They could be packaged as upm packages or nuget packages or whatever, so who is actually liable for anything here?

The current wording and examples are conflicting and an absolute nightmare from a legal perspective.

Actually taking the wording as is, .unitypackage distribution is also off the table as that means its making packages available within the Unity Editor?

Edit: Well ok the package guidelines themselves say that they don't apply to you if you host the packages on your own website, unless you (again) leverage the Unity Editor as a marketing or distribution platform. Which is a very vague term as has been stated before.

I think a very thorough explanation of what is actually the intended use case that isn't filled with legalese and that summarizes the questions here and adds examples of allowed/disallowed behaviour would help a lot. The examples so far have been very unsatisfying.

Edit 2:

Thinking once again about this. I think the real problem is the part:

where I and I think pretty much everyone else. Has no clue what that means. A lot of the package guidelines don't apply if you host it yourself or on github etc. but always with the caveat that you may not leverage the Unity Editor as a marketing or distribution platform.

Nuget for Unity is probably a distribution platform? As it Git for Unity Packages and some other things.

These terms are not defined anywhere in the legalese as far as I can tell, so we are stuck with the explanations in this thread which sometimes contradict themselves and which are unclear about external package managers that just modify manifest.json but aren't part of the Editor UI. Unclear because @LeonhardP has stated on the first page of this thread that they are not allowed, but then again HOW can the Unity Terms of Service affect a third party software that changes a .json file in the Package folder? I don't think that this is even legally possible but IANAL.

It might also be that @LeonhardP has misinterpreted that rule about modifying through scripts. I think what the legal text might refer to is: Modify via scripts in the editor without leveraging the Editor UI. Not scripts outside of Unity (which is what an external package manager would be).

@Favo-Yang did you actually make any progress with your discussions with Unity? It might be interesting to hear how openupm is being handled as a case?

 

I cannot deliver my package thru the git URL - My package is private, delivered only to selected users with appropriate permissions. Even if I would set up a private repository my users would have to create an account, then setup the SSH or other authorization system on each machine that has to open the project with my package. I cannot expect my client to do that.
I cannot deliver my package with a private scoped registry - this requires even more steps for the client.
To utilize UPM features and keep my package private I can only use tarballs. But because of the reasons I previously mentioned I have to create a installation script for that.

So in the end it looks like I cannot even do that. This way entire Package Manager just lost me here. To deliver my package I still have to use .unitypakcage, my code and assets are mutable and users dependencies are hard to find. Also, I will keep telling my user that they have to delete the previous version of the package from their project before the import because that's all I can do.
Everyone has a bad experience.

 

Actually not though, because the term only apply if it utilize unity editor to do something. Git client mostly don't do anything with unity editor itself

But as far as I see. nugetforunity, that utilize unity ui to discover package, is not allow in this term. Also the same to any and every package resolution and management system that try to generally help us in anyway inside unity itself is not allow. Everyone must reinvent their own wheel to used in their project or organization

That what I can conclude from the term. That it don't even allow nugetforunity unless nugetforunity would officially become under unity (surely, this term don't applied for antthing unity owned by themselves)

 

Or use Unity's solutions and not their competitors ones, but I'm sure that's just a coincidence.

 

There is another side of this coin:

Unity is preventing a situation when this all is going out of hand.
- you want Google's packages? You only can access it through Google's package manager, extra account, extra marketing crap.
- you want Microsoft's packages? You only can access it through Microsoft's package manager, extra account, extra marketing crap.
- you want prodigga's packages? You only can access it through prodigga's package manager, extra account, extra marketing crap.
- you see where it is going

Obviously they are protecting their interests, but at the same time they are trying to prevent the same insane BS happened on the Play Store, for example, with Amazon. You want amazon's apps? Too bad, first you have to install Amazon's BS-store.

Oh and you do whatever you see fit for yourself and your contracted companies/people. You are only not allowed to provide package managers and in-editor marketing crap for other/general Unity users.

 

Actually the most simple way for you is to deliver the tarball, tell your clients to extract it to a PackageExternal folder that is a sibling of the Assets folder and add an entry into their manifest.json referencing it via file: using a relative instead of an absolute path. That works very well and should solve your issues. In general the experience with a private scoped registry that users get access tokens to is not as bad as you make it out to be. Its just that even for those packages its completely unclear what "marketing or distribution platform" means.

 

Except they aren't really preventing this situation at all. They are creating it. The thing is, Googles packages were available via a scoped registry before this change, now they are only available as .unitypackages once more. Meaning comfort was lost to users.

The playstore is a very special situation that not everyone is a fan of either (see the current issues around that and the apple app store as well).

The idea of saying: "Hey, you may not write plugins to the Unity Editor that introduce any sort of marketing or distribution features" may sound good on paper, what it really does however is introduce a whole slurry of uncertainity around what that actually means. As soon as you start restricting the usage of something with arbitrary terms it becomes much more of a hassle for people to know whether they are still being "compliant" or not.

Also its entirely unclear to me how I, as someone that writes an open source editor extension that anyone can install if they so choose, could possibly be liable if people decide to install it. Unity claims that the pure act of making it infringes on the TOS somehow (which I guess legally speaking it might since it might be a derivative work? Welcome to legal hell).

So this means that whenever I create something (open-source or not) that makes the Unity Editor better in some way that Unity does not want, I am forbidden from doing that. That sounds like a very bad situation indeed. Its also questionable that something that doesn't actually hook into the Editor classes themselves might be in any way a derivative work (read: external scripts).

 

Yes, you can sell anything for Unity users outside of the editor. That's the point.

Exactly.

Like it or not, Unity is a business. It is not open source product, they control what you can do inside of it. There are open source alternatives if you want that kind of freedom where everyone does whatever they see fit. But again, you can distribute your packages through your website and can install from there.

I don't see any legal hell anywhere.

 

Except you can only do that as long as you don't leverage the Unity Editor as a marketing or distribution platform.

Which is a term so woefully undefined that its unclear to me what it means.

The right to make packages available comes from this part of the Additional Terms:

Where it now states "including via the Package Manager". To me this does not exclude that the Package Guidelines also apply to .unitypackages and reading LeonhardP's answer above it seems to me that they do, even if that was always taken as something that is out of scope.

The package guidelines become further vague as they start to use the (to me) dreaded "marketing or distribution platform" terminology. Especially since it is prefixed sometimes with "directly or indirectly".

I think what really ticks me off here is the vagueness of the wording. It seems to me, and most likely that's the reason why, a lawyer wrote this so they would have the most leeway to shut down whatever they didn't like. This to me is not just unfriendly to users, but a slap into the face of anyone that wants Unity to become a better platform.

I do get that it isn't open source software, but they have provided us with ways to extend the Editor in the past, and now suddenly put a bunch of vague statements out there that say: "Some changes are not allowed but we are going to be very vague about them"

Its strangling a budding package ecosystem, and uncertainty for everyone that wishes to make Unity better as an Editor, which is my biggest concern here.

 

Yes, the outside portion of my sentence covers it precisely.

 

I think that my understand of what marketing or distribution platform means might be different from yours, which makes my whole point. From my understanding:

If I offer a .unitypackage outside the Editor, that when installed shows a little Window saying: "Click here to buy this if you like" or "This is where you can find our other interesting packages" or "Installs a Package Manager such as Nuget for Unity" or "Provides AutoUpdate functionality inside the Editor".

I am somehow breaking the TOS even though I'm not installing anything but just providing a bunch of files? That doesn't sound right. Especially since I might be operating under an old version of the TOS that did not include those terms to begin with.

What's unclear to me is whether having a .unitypackage that installs a Package into manifest.json is then leveraging the Editor as a distribution platform and what exactly the difference is to having the User enter it into manifest.json. The pure act of providing a package that the Unity Editor somehow understands can't be illegal as pretty much any npm package fits that bill. Also it was stated somewhere that selling your package on your page and then using manifest.json to download updates is still fine.

 

Maybe we can get some clarity in this situation if @LeonhardP answers a bunch of scenarios with a simple: Yes/No to whether they are allowed maybe with a short explanation of why and which part of the Terms forbid this if No

Of the top of my hat I can think of the following scenarios that would be interesting to know the answer to, sometimes with multiple subparts as I think there are subtle differences:

• Creating an open source project that extends the editor in ways prohibited by the package guidelines

1. Purely creating it (Putting it on github or something similar so its public)
2. Creating a package.json for it (Maybe the same, maybe a different user)
3. Making it resolvable by packaging it as an upm package and putting it into a scoped registry (Maybe the creator or via openupm)
4. Making it available only via .unitypackage downloads

• Creating a private project that extends the editor in ways prohibited by the package guidelines

1. Purely creating it (for in house usage)
2. Creating a package.json for it
3. Distributing it inhouse via a scoped registry
   
4. Opening it up to other users that have to register for it (payed or not payed) but without putting it out into the general public
5. Opening it up to others users without the need for registration
   
6. Making it available only via .unitypackage downloads (registered or unregistered)

• Creating a project/program that does not extend the Editor itself but provides functionality outside of the Editor that changes manifest.json (openupm-cli for example)
• Creating a project/program that does not extend the Editor itself but downloads and extracts code/packages to the Assets folder

And also the question whether:

• Creating an Editor Extension that downloads arbitrary data into the Assets folder (e.g. autoupdater for .unitypackages, Nuget for Unity, etc.)

is against any TOS and why.

My personal understanding gives the answers as follows:

1. Yes
2. Maybe
3. Maybe? Leaning to No
4. Unclear

1. Yes
2. Yes
3. Yes
4. Yes (Designated Users)
5. Maybe? Leaning to No
6. Unclear

Yes (I see no way that external programs could be regulated in any way by Unity TOS even if they change files in a project)

Yes (same reason)

Unclear (Especially as to who is actually breaking TOS here)

If anyone wishes to contribute some more questions or their take on what the answers are from their understanding feel free.

 

Sounds like something like Photon even displaying a link to their website inside the editor could violate the guidelines, because it indirectly allows users to purchase their services.

This sounds far too much like Apple's terrible anti-steering rules. Except Apple can actually enforce their rules by booting your app from their store. What can Unity realistically do about random scripts hosted on GitHub and whatnot? Sue the authors?

 

Sorry but you have no idea how bad those solutions are in the context of a product that you are trying to sell and maintain. Your clients will message you at each step of the import if it is more complex than importing ".unitypackage". Many people are also not reading documentation so this is also not a complete solution. Private scoped registry/repository? Each time someone will try to share a project with another unauthorized system they will run into problems that will have to be addressed either by their sysadmin or my tech assistance. I know that for us adding two lines into manifest.json and coping tarballs into some folder is not complex, but Google itself offers .tgz files only if you open their archive page for a reason.

 

Like it or not, we and unity live in capitalism, which anti monopoly and encourage competition is another practice to uphold in business

You do business by making your product better and allow competitive to go on, at least if you can't do better job then you could buy the one that do better job than you. But this point on they are destroying the competition and put a legal terms barrier and fog (it is a fog because it's very vague) to stop the innovation on the thing they can't do it right. Allow me to repeat myself, especially when the unity package manager itself is one of the most defected feature of unity editor. That's also the fuel that people are frustrating with this term in particular. It is very ugly. If the unity package manager was perfect from the start there would not be many people made their package manager system to compete with them and this terms would not have annoyed many people