Unity 4 New EULA Restrictions

You mean developers building servers for Linux using Unity? Does such a market exist? Not to be too blunt but just because it runs on Linux doesn't make it a server. Unity is absolutely fantastic tool in a million ways but in the end, most of the interesting parts of a build aren't even thread safe. So I suggest there are not actually any developers (over the age of 12) planning to make WOW servers using Unity.

Are we to suppose that Streaming Cloud Gaming stuff is only viable on Linux servers but not windows? I humbly submit that the server OS is not what's stopping that business model.

If on the other hand, it was done for end users running Ubuntu buying the humble indie bundle or to entice interest and positive comments and attention from the Linux community, then they very much care. Whoever installs Linux on their personal PC except on principle?

 

No one's really been talking about linux for server here, unity's been saying embeded linux was a target, personally i really don't see much of a market either way, low level embeded won't run unity and wether it's linux or windows i really don't see why embeded is any diferent than regular distribution.

Their best bet would've been to make the changes on a per contract basis, having the customers pay upfront for the changes they need for embeded, and then to add this as an add on if they want to rake more.

 

As far as I'm concerned having a 'stripped down OS' is fairly irrelevant - in theory there a small chance it'll help ['pends on your definition of primary]. But you do catch on to an interesting point - if there are two sets of 'licensee content' on the said device [e.g. an arcade that plays two games] then how could either of them be considered 'primary'.

If true then it should be easy for them to fix, no?

 

While this is off topic I just have to say I agree 100%.

It's not like there are successful MMO's using Unity for the server, nor is it like there was a public demonstration of a 1000 player FPS using Unity.

 

Had there been an official response to this yet?

 

Only that they are working on it. The goal being a "win/win" outcome.

 

UT staff have made various statements, most significantly from David Helgason on page 4. These mostly revolve around how those staff members interpret the EULA or justifications/rationale for it. Useful for understanding their POV, but not a resolution.

All we've been promised is that they take this very seriously, and will be releasing some sort of solution as soon as they figure it out.

However we have little to no idea *what* that solution will be - they've not indicated anything at this time.

 

They need lawyers to do this. And the lawyers need to write stuff that deals with Casinos.

I humbly submit that the more time they spend on this, the better off everyone is going to be.

 

For the people who thinks this does not concern them,think long term. This isn't about Unity 4, it's about Unity 5, 6 ,7 etc. Linux opens some new possibilities for Unity games like in airplanes and possibly cars (near future). The future of games may not be deployed a PC or a mobile only. I've brainstorming with TV stations about broadcast interactive games real time with audience. Unless these depolyment need additional work on Unity, I can't see why the Eula exist.

It's like buying a car, and then when you want to use it for grocery shopping, the manufacturers tells you. "Sorry, you can't, please call us to ask if u can use it". If I want to use the car to carry a canoe, I will buy additional parts to make sure it holds. We are fine with that. The whole point that gets people upset is the Eula was silently changed. It should be make known easily. Is Unity evil? No, they need to address biz concerns. Are they allowed to change the Eula? Yes of course. Can they make the Eula vague? Sure. Will it piss laywers off? Of course.

While this Eula may not affect you in near future, it's change will shape how Unity becomes in future.

 

The current EULA effectively changes the way Unity does business with us. Consequently this has the potential to change the way we use Unity.

After pondering each party's interests for the past few days, the best case scenario I can see is that we can go back to the arrangement we had with 3.X due to it's simplicity and freedom to developers. Constraints are not conducive to creative solutions. Creative solutions built on Unity helps Unity and it's Developers.

I have a few ideas for the restricted items added to the new EULA, please consider them.

[Embedded]
I would like to see embedded applications, licensed under an embedded platform add-on license perhaps these are treated more similarly to XBOX or PS2 licenses. This keeps things clean for the rest of us. I'm assuming the definition will resemble intent provided by Graham Dunnett on page 4 of this thread.

[Gambling]
Paid service and support. People should be only impacted by this if they need the service you provide. If the regulating agency requires source code, then the dev should have to pay for it, etc. If he also needs support for an implementation, he should be willing to pay for it as long as it's clear that this is paid support.

[Streaming and Cloud]
Some note in a EULA addressing the following:
If a technology allows the unity engine to stream to a platform that requires a paid add-on license then that license must be purchased by the developer. It does not matter what type of client is consuming the streamed content. If you are developing a product and knowingly streaming to a platform that requires a paid license for an add-on platform that you don't have (i.e. iPhone app receives a stream of an app running on a windows machine and the developer has not purchased an IOS license) then shame on you. You should understand why you should pay for the IOS license and willingly do so.

[Server Licensing] -
(I only mention this because David Helgason eluded to this on page 4 of this thread)
It appears that there is some consideration for charging additional fees for our products running on servers. This item is in dire need of clarification of precisely what this means? If it is what i think it is, please don't go there. The runtime provides a very small part of the logic for the servers that are written by us. The developers should decide the constraints imposed on our applications. If my interpretation of David's post is way off base, please accept my apologies.

 

Why? Merely to protect a revenue stream? If there is No technical reason - no other platform to write code for, no extra support costs, etc - then where is the justification beyond "we can so we will"? If someone wrote a mac emulator, and could run Unity games for mac right on their ipad 4, do you feel Unity should then charge that developer more? And if so, why? I feel the previous model is better - We pay for the features we want, and then are free to distribute as we need. If Unity is hurting for money, then they can charge us more money up front.

 

I think it comes down to intent of license. If you want to have your app run on IPAD. You should be willing to pay for it. If you turn around and write some code to work around the intent of the licensing model so you can save yourself some money. How is that any different from stealing from the company you depend on?

If you will benefit financially from the platform why shouldn't Unity get the licensing revenue they are due.

Another thing to note about your example. If you write a Mac emulator for iPad, then you own a Mac License already.

 

Maybe you should consider to set up an entire streaming system to an Ipad would cost more in time and effort then to just buy the Ipad license .

Plus theirs other ways to do this , restrict touch controls for users who lack an Ipad or Android license .

See for streaming some games might work better as a stream( say its a 3 gb game , not many users want that on their Ipad) . No dev in their right mind is going to set up a streaming system to save money !

 

All that I am trying to say is that If I want my unity content delivered to IOS, I should expect to pay for that feature. Just because I write a input translator with another tool that feeds my IOS input to another machine to then be processed by a unity runtime and fed back doesn't mean I should now be exempt from the intent of unity's license model. Perhaps we are talking more ethics here; however you may have some liability in court with a scenario like this.

I suspect that there is a concern about the future impact of cloud gaming / Streaming on the current license model. I was suggesting some sort of clarification to insure unity's interests are covered while keeping the EULA simple and straight forward.

 

The intent of the license is... ahem *was* clear. UT license some tools and you can do whatever you wanted with the outputted content.

As stated before, UT has not restricted or enabled a platform via the EULA before - because *all* UT has ever tried to sell to us has been tools services. Read the thread for more detailed examples, got to run.

That was a very happy relationship, one that got UT as far as it has.

 

If Unity was afraid of that they could make a separate clause saying you need to buy an IOS license to run content in any form on an IOS device .

As is it cost X
X can be nothing , X can be 100k ...

 

For anyone who thinks that streaming is hypothetical, 10-15 years away, or about individual devs making their own systems for some odd reason, just read this for an overview.
http://www.engadget.com/2012/12/12/playcast-cloud-gaming-service-hands-on/

Streaming in the coming few years won't just be all about a few AAA titles, or some rare scenarios that won't affect you. It's about a revenue channel for game publishers from big studios to indie game makers.

 

This is why the new streaming clause is in the EULA. No code changes necessary. While I didn't see this article mention IOS, it does say there is an Android app, and others state there is an IOS player. Now if we could just get them to pay a small royalty instead of us paying six figures, I'd go for that.

 

But there's still no reason for them to add it other than "We want some of that money". Unity before these changes were a tool you buy to make a game, and then you can do whatever you want with that game: sell it on steam, sell it for $10 million, burn it to a cd and hide it under your bed, put it on a big screen tv and let a hundred people play it, give it away for free, use it as a screensaver to distract your cat, whatever. We pay for the tool to make the game, just like you buy Photoshop to make photos or 3DSMax to make models. When Flickr became popular, Adobe didn't suddenly change their EULA to say that if you put any photos that have been edited in Photoshop on Flickr, you have to pay Adobe more money. Because Adobe isn't a photo publisher; they didn't do anything to help you get your photo on Flickr; they're not paying for the costs of hosting it; they're not helping you market it if you're selling it, etc. Unity is in the same position: if I put my game on OnLive, they didn't help me put it there, they aren't paying for the hosting costs, they didn't add any technology to make it streamable, they didn't help me market it - they didn't do anything at all, but they want to cut into my profits because "streaming is different". Who cares if it's different... if I put my game on a spaceship and launched it at the moon, that would be different; it doesn't mean Unity deserves extra money just because I decided to do that.

Let me put it another way: if you think it makes sense for Unity to charge extra for the right to put your game on OnLive, then should Microsoft also charge me extra to sell on OnLive if I used Visual Studio and Windows to make the game? Should Adobe charge me extra for selling on OnLive because I edited my textures with it? Should Notepad++ get a cut since I edited some text files with it? I don't think it makes sense for any of those companies to somehow claim that me selling my game on OnLive is so different from selling it on Steam that they somehow deserve extra money.

 

I wanted to add one more thing though: I don't think the intention of their Cloud clause is to stop us from selling on OnLive. Like I mentioned earlier, I think it's more likely that it was a clause added by a paranoid sales team who are worried that "The Cloud" was somehow going to turn the entire game ecosystem on its head and open a black hole that would swallow up all money in the universe, since I've seen a lot of sales people in software companies turn white when you say the word "cloud" at them. I'm hoping it's mostly just paranoid cloud insurance, to give their lawyers an out if somehow someone figures out how to use the dark power of the cloud to let everyone in the world use Unity Pro by paying for only one license or something like that.

 

lol, I enjoyed this thread and totally agree with what you said. I'm looking forward to getting all of this sorted out, since all of the new restrictions can apply to me.

 

The embedded software restriction is of high concern to me, and would like a response from someone at UT about this because this may impact my companies involvement with Unity.

To quote the EULA:

My company does retail store design. We design the interiors of retail stores, design the furniture, put together and make the furniture, and install everything in the spaces. Something that is becoming more and more in demand is in-store digital kiosks. We have already used Unity to make some in-store retail Kiosks. This basically involves us making a Unity application of some sort, then putting together a small PC, with a big touch screen, then installing the touch screen, running the Unity application, into the store somewhere for customers to interact with.

Does this constitute embedded software? By License are we then only allowed to create 50 kiosks with a standard Unity license? There are going to be instances where we may create a Unity application for an in-store kiosk, and then the client will want to purchase 100 kiosks to install in their stores all around the globe. Are we going to need to get an additional license to do this? How much is that going to cost?

Also, on another, but related, note. A personal interest of mine is to make and sell arcade game boxes. Whenever I make a good enough game to justify the cost of doing this, I was going to build an arcade box, with a PC in it, a monitor, some joystick or physical control system mounted on it, to then be a physical arcade version of my game. I was then planning to potentially solicit these arcade boxes to various local arcades. Maybe try to sell them internationally on the web if I got any notoriety. Would this embedded software license issue basically restrict me from being able to build and sell arcade boxes running my Unity game?

I'd like to note that the kiosks and arcade boxes would be running windows, or linux, while running a unity application on top that the user couldn't exit out of. Does this qualify it as an embedded system?

Could someone at UT please answer these questions? I don't want to have to email you guys about this, because I am sure everyone here would like to know the answer as well.

 

Obviously not from UT but:

Yes, IMO as it is written those are both 'embedded devices'. Yes, UT are aware of these concerns [and through this thread and private we continually elaborate]. And yes, they are working on some sort of 'solution' - though what that is nobodies really sure ATM.

 

The thing about this though, is there such an easy loophole around this.

A company hires us to build them Kiosk or Arcade boxes, with a PC in them running linux. Unity is in no way involved in this process.

A company then hires us to create a Unity application that can run on the specs of those kiosks and arcade boxes.

Said company then runs the same unity application on all the kiosk's we built them.

We didn't sell them embedded systems. We just sold them kiosk boxes, and then they contracted us to build an Unity application.


But even with that, what if at some point I actually want to sell an arcade box that runs some game I make as a single product? I would like to know if this would cost me more money to do. And I really don't think UT deserves anymore money for this. Whether I sell my game on the iOS app store for $10, or I sell it in a complete arcade box as an integrated system running on top of linux for $1000 should really be the same thing to unity. Just because I want to build a box to house my game doesn't mean unity should now get a percentage of sales on that box.

I can sort of understand this embedded systems thing if some company basically wants to start mass manufacturing and selling something like tamagachis that use unity to build the application the device runs. But still even then, I think that is out of line.

Whether or not a company makes a unity app and sells 2 millions copies in the iOS app store, or they sell 2 million copies of that app through the selling of their own proprietary piece of hardware that runs the app as it's primary front, that really shouldn't make any difference to unity.

The only thing I can think of as being the reason for this embedded device clause is UT might be assuming a company that can mass manufacture an embedded device probably has more money to spend on licenses. But this distinction is really not valid. Lets say some company gets $5 million from investors to develop and release a children's toy and it uses unity to run some graphical front end on a screen, vs some company that gets $5 million from investors to build a game for release on the web or PC or iOS. Why is there a distinction there? There shouldn't be.

I actually think that with mobile GPU's becoming cheaper, smaller, easier to integrate, we may actually begin to see certain children's toys or other on the shelf products that run some 3D graphical frontend, and potentially some companies may start reaching out to game engine developers to develop software for use on these products. Are we then going to have to contact Unity and charge the client some chunk of money, or percentage of sales, to use unity to make that software? Again, whether or not a million copies of our unity application is being sold through an App store, or it's selling a million copies through being on a piece of proprietary hardware, I don't see the rational in unity thinking they now get an additional chunk of that money.

To me this seems like unity is trying to sneak in royalties in the areas where it wouldn't completely destroy their reputation as 'royalty free'.

If UT wanted to get more money for dealing with embedded systems, or the potential of unity apps being the front of toys or other on the shelf products. Then unity should develop a special version of the engine, deeply embedded with either a stripped down version of android or a stripped down linux, that acts like the unity application is the whole entire OS. This should be offered as a separate license, and an additional build option, which when you built it would basically produce a linux .iso that would install a whole operating system, with the unity app acting like the entire OS. Maybe add some nice built-in functionality so the end-user could deal with certain OS tasks more easily without breaking the experience of it being an 'embedded system' and not just a unity app running over linux. That would actually be pretty cool. If I ever got the cash flow from building Kiosks or arcade boxes I would spend another $1500 for that build option.

 

Nope, the EULA includes the word 'Indirectly'. We've postulated that if your content is put on a embedded device - e.g. a home made arcade - you could still be liable even though you have no knowledge or intention that this should occur.

Beyond that, I agree with pretty much everything

 

This is another 'loose end', I take it to be 50 installs of a specific Unity project, (i.e Licensee Content), but I guess at a push you could interpret the EULA to mean 50 installs of Unity developed content.

However the more worrying aspect is if you developed a framework Unity Project that you can use for kiosks across 50 clients, where by it imports a few different graphics (e.g photos) and some different text to display. My feeling under the current EULA is as its still the same Unity Project or even Unity build that is being used on 50 or more different client kiosks that would infringe the restriction.

I also postulated would a cheeky workaround then be to make several builds of the framework, changing project the name, some graphics, layout, buttons etc. Would this mean that they are no longer the same 'Licensee Content'. In which case for your 100 kiosk example for the same client you can just make two slightly different builds and not infringe the restriction.

I'm not suggesting you do this, but trying to illustrate the ambiguity of the current restrictions in both directions.

Yep I think this seems to be the most sensible and agreeable solution for all three of the restricted clauses i added to the EULA as it is consistent with the licenses we currently have. Unity offers something of value, you buy a license to use it, but you are no required to and if you don't then you don't get the added value features.

 

I cannot agree with you more.

 

And it's not even that I think Unity wanting to get certain royalties for certain things not previously defined is terribly bad. It's a bit disappointing that Unity is potentially changing their philosophy on this subject half way through the game, after they already attracted so many people for their initial philosophy on the subject. The worst thing is that this whole alteration of the EULA seems a bit sneaky. Users shouldn't learn about these things from other users making threads in the forum and having to speculate about what exactly it means.

Which I'm not directly accusing people at UT of trying to be intentionally sneaky and brush things under the rug, I'm just saying, thats what it feels like on this end.

 

At least now there's some warning. The first user who encountered this [that we know of] found out because UT quoted his client 6 figures...

 

No they shouldn't, but that can't honestly be pinned on Unity. If you're buying software which you intend to use for business and not even skimming the license agreement then you can't blame anyone else.

Quoting that without context is more than a little unfair, though. We have no idea what "6 figures" actually was, and we have no idea what they were actually being quoted for. For all we know it was $100k for a source license and tech support, which would actually be pretty cheap.

 

True, but it might not of been... so that's why I didn't put hypothetical context in there.

 

I'm not a lawyer, but the way I think it works is like this:

You have a legal obligation to tell the person buying your product that he is not allowed to install it in a kiosk. Legally, you should probably be giving him a EULA which includes the provisions from the Unity EULA. If you don't tell him, you can be held responsible and sued by Unity. If you do tell him, and give him a EULA saying not to put it in a kiosk, and he breaks the EULA and does it anyway, you are still held responsible and can be sued by Unity, but you now can counter-sue the guy that broke your EULA to try and get him to pay equal damages to you that you are forced to pay to Unity. Isn't the legal system great?

 

Well, to be fair, apparently almost all of us failed to realize the EULA got updated. In my case, I actually did read through the Unity 3.5 EULA when I started using it, but it didn't occur to me that there would be such a different one when I updated to Unity 4. Still totally my fault, but it's understandable that pretty much everyone else just assumed the EULA was more or less the same.

I think it would have been better for Unity to put an "Important: License changes" announcement on the site like some companies do, especially if it turns out that this new license does mean we're not allowed to have servers or sell on certain marketplaces anymore.

 

Don't you get asked to agree with the EULA as a part of the purchasing process?

 

I don't recall; I'm sure it did pop up in front of me somewhere along the line, but I assumed it would have been more or less the same as the 3.5 license. I agree it's my fault, but I think people click past EULA's even more than they usually do when they're upgrading something they already read the EULA for. I might have just been damaged by WoW, which would make you re-click the EULA every time they changed any little thing despite it always being the same EULA for the 400th time.

 

Well, I think we can all agree that licenses used for business purposes probably deserve a somewhat higher level of diligence than the one used for your WoW subscription.

 

Clearly you've never had a strict guild leader. That guy would have burned my house down if I missed raid night.

 

Can someone from Unity give us a rough ETA on getting an answer on the questions in this thread?

I've been going through my EULA's on the misc. installers from Time Machine and am growing more concerned. I don't like having to go through all this trouble to fill in the gaps when we could just get the feedback from the "Horses Mouth".

I'm starting to get the impression that Streaming and Cloud Gaming was an afterthought that was slipped in and this area concerns me the most. I can also see the valid concerns in the other areas discussed by community members in this thread.

Perhaps you are waiting to quantify the impact depending on how many people express their concerns? I'm in the assumed .01 percent negatively impacted by these changes. I hope you can see the problem is bigger than the few who took the time to respond.

I'm not saying you won't do the right thing; however the delay in response is really starting to worry me. If you do not provide feedback to us, we will fill in the gaps. Given the circumstances, this will likely be negative.

I cannot proceed with my network projects until I understand your official Position on this.

I don't want to jump to conclusions; however any hope of a win/win outcome is appearing deteriorate day by day.

 

If we are on WoW subject... Can anyone from Unity Team (legal/sales or dev) answer to my post posted somewhat earlier?

 

You should all be shocked and repelled by this new Eula. It is just a blatant attempt by Unity to grab more income. Unity3d is essentially an editor like visual studio, a tool to create content. There should be no restriction on where you can use that content. Can you imagine the uproar if Microsoft tried a stunt like this with visual studio or c sharp or .net? The gambling restriction has nothing to do with gambling laws and protecting unity, i have been in nearly all legal gambling jurisdictions for 25 years. The middleware you use might have to be approved but not normally. Gambling laws and commissions don't care what editor you use to create the content, they just care what your Random number gen code looks like. And what the hell has it got to do with unity if you want to put it on an embedded platform?

Unity is suffering big company bloat syndrome, over the last year or two the have massively increased their costs through over employing etc, and now need to generate more revenue, the cant get it from us indies as we don't have it. Personally I would prefer unity to cut back its internal expansion and return to its core values and not being so greedy.

 

I love this engagement. Unity revoltionised and democritized gaming and now they experience the lashback when Unity is trying to turn away from the idea they sold everyone in to.

 

Folks, I understand some of your concerns regarding the EULA but let's not act like it's December 21th so I suggest for everybody to calm down If you are seriously concerned about this do yourself a favor and email UT with your specific questions/case.

 

I would much rather see it answered publicly since I think most of us have the same questions... does it really mean we can no longer make client/server games, are we banned from OnLive, are we banned from arcades, etc.

Also, after my earlier post about the limitations carrying through to a EULA, it occurred to me that that everyone making games with Unity 4 now has to include a EULA carrying the new limitations on use. Could Unity distribute a simple document saying what we all have to put in our own EULA's? For example, I assume we need to say that the user can't play our game over a streamed connection like Remote Desktop, he can't install it on an embedded device, etc.

Edit: I reread the network clause, and apparently users can stream; only the developer is barred from streaming. I'd still like to see what of that needs to be inserted into our own EULA's though. For example, I assume we can't treat OnLive as an "end user" streaming from their servers.

 

Did you get my email Thomas?

 

No, everyone's banned from streaming where streaming is defined as from 'server to end user device' not 'end user device to end user device'.

 

But I could run a Unity powered game on my own computer and stream it to my TV or phone?

 

This , and you shouldn't be telling each person something different . It makes Unity as whole unstable to work with .

 

Under the current wording you should be fine.

"This restriction does not prevent end users from remotely accessing Licensee Content from an end user device that is running on another end user device."

 

Well said arkon. Of course they can do what they like but we don't have to agree with it and the beauty of forums is that we can let them know. The important thing is that we can see clearly what is occurring. Back to Basics Unity.

 

It's not that easy to go back to the basics once you've grown that big. UT is now a complex business with a lot dependences, worldwide offices and hundreds of full time employees. Some companies invested millions of dollars into UT.

To be honest, I find the lack of official responses and a clear statement worrying now.