Unity 4 New EULA Restrictions

My 2c : I wish I have had read the eula or this thread before I have invested $$ in unity assets and time to learn. My mistake.
Btw is it allowed/legal to use the art(models/textures) from bought unity assets in another game engines ?

 

Even that is too vague. This would stop someone from viewing your screen with remote desktop, for example.

I guess this sits wrong with some of us because there's no technical reason for this EULA change, it's all about revenue - and we feel we bought the "unrestricted" version because we paid for Pro.

 

That does not sound like a viable distribution method... not to mention, the guy viewing your screen is not playing the game, so it’s not the same either… and even if it was, it’s not like Unity will prosecute you for a single instance of screen sharing.

Now, if you giving the friend RDP access to a server machine that allows multiple users… that’s a different thing and may fall under the Remote Rendering bit.

I can think of a reason: For the time being things may just work, but eventually these projects will need very specialized support requirements to deal with distributed rendering (note that a big fail for Onlive was the expense that every connected user needed a physical computer for himself, no actual distributed rendering.) Supporting such efforts may require specialized features in the engine plus additional, time consuming support. That may be in the long run enough reason to charge extra to such projects simply to justify the support costs.

As it was explained by David Helgason, this is not yet an industry, but it WILL happen. He didn’t say this, but it can be very costly for the company to promise certain level of support for something that may end up demanding way more than they can afford.

 

So let people contact (and pay) you if they need support. If you have to add features specifically for something, sell a separate license for those features. That's still zero reason to restrict people who don't need or want your help

 

Of course not, and I'm sure Unity isn't evil and all that. But it is the current wording of the EULA, and would also be covered by what you said. So your developer could not RDP over to a QA box and look at it. According to the EULA, that is. All we have to go by is what is in the EULA, not what we wish the EULA meant. And breaking it is breaking it. This is why I want it to be worded better.

Sounds like they would need a support contract at that time.

 

Not necessarily viable. Thing is, if they are forced to implement some additional features in the engine that require some special support in the future of distributed rendering, they may feel they have to charge for the usage of the features to keep supporting them going forward. This is the kind of thing they may be forced to dedicate engineers too, not just "tech support".

But then again, may turn out by the time it becomes "A Thing" that the OS level implementation of OpenGL/DX may be able to take advantage of distributed rendering and the Unity team has nothing to do at that point but let people do it and gather feedback. At least for now, that’s all they are asking: for people to contact them.

I’m not saying I'm crazy in favor for it, but so far I don’t see the reason to bring out the flaming pitchforks.

Then lets be productive and recomend a more clear wording?

"For distribution or use via any service where the user/player is served Remote Rendering, Server Side Rendering or Cloud Rendering use [yada yada] will require special license [yada yada]."

Or perhaps:

"For distribution or use via any service where the user input in a client but rendering is done by Unity Engine in a Remote Server or Cloud Service [yada yada] you will require special license [yada yada]."

 

That's what David was thinking... problem is it's fiction. Streaming will happen as streaming does. There's absolutely no requirement that UT get involved... I think UT might have confirmation bias where because the majority of their time is spent with people who do need help therefore they assume everyone is in that position.

To give everyone an idea of the world *I* live in... I'd note that a while back there was a GPU released with a ethernet output! Integrated Hardware Streaming!

In many ways, Streaming is no different to Steam or Kongregate - at least from a UT deployment model. If anything, it might quite substantially *reduce* their costs. And, as I repeatedly bring up, there's plenty of parallels in other licenses - e.g. the new Ouya Kindle - so a change for streaming would strongly indicate a change for them.

 

If they end up adding additional features to make use of distributed rendering or some other technologies that make the Unity runtime work more efficiently for streaming use, then it makes perfect sense to have a license and charge for that. I would be more than happy with that approach and support it all the way as they are charging for something that has additional features and value, just like they do with say the iOS or Android licenses.

Problem is at the moment they are requiring a license, something that normally has a cost attached to it, in order to do any streaming of interactive Unity content. Unfortunately whilst the act of needing a license means I do have to contact Unity, it does not mean to me 'hey tell us that you are using streaming so we can better determine how to help our community' which is what the supporters appear to be claiming. Even though several UT employees have suggested this is what they want, it is sadly not what is written in the EULA.

Which sadly does absolutely nothing to resolve my problems with the streaming license or the potential example projects i've outlined previously.

Honestly you first paragraph is the key to this.

If Unity find some means of adding additional value to the Unity runtime, that provides substantial benefits to running it for a streaming /distributed based system, then that becomes the perfect 'add-on' to license. I would be fully in favour of such an endeavour as if I were doing this for gaming it would make so much sense. The possible license cost is likely to be far outweighed by the benefit of running more instances a game for example.

However at the same time they must not restrict my use of the basic Unity runtime to be used for streaming if I want to (which is what the current EULA is doing). This would mean myself and others who want to utilise streaming for simple client projects can do so without issue, whilst Unity can still be create a revenue stream from supporting the 'mass gaming' and heavy use of cloud/streaming/distributed rendering need to accomplish that, in order to offset any losses from lower sales of say the iOS/Android add-ons.

To me that seems like a win-win solution and one that wouldn't need the blanket restrictions we have in the EULA currently and make the whole streaming restriction far easier to write as it would simply act in the same way as the iOS/Android add-on licenses work.

Actually come to think of it, there is one big difference between the current way streaming is used in games vs what I need (currently) for my own potential projects. For gaming you are running many instances of the Unity runtime, one for each player. However for my own concepts I actually just intend to run a single instance, but allow many users to connect and interactive with it.

I wonder if that makes any difference to UT's feeling on the matter in terms of the EULA? Although I guess such a use could be added as an exclusion to the current restrictions, helping out my specific position, i'd much rather see Unity come to the solution above, offering additional features/services for a license cost, which I then have the choice of purchasing, depending upon my needs.

 

Here's one idea:

If the purpose of these restrictions is, as appears to be claimed, basically trying to gain a stake in perceived savings/additional support costs from running on Linux...

Restrict Linux only?

This would be completely consistant with your earlier licensing schemes - e.g. console licenses where it was always a negotiated per project license. You can still allow us to have a basic or free version of Linux that enables us to go on humble bundle etc. Finally, you'll not have taken anything away from us - all existing capabilities would be there, plus some new ones.

It's slightly less than ideal, but I could probably live with that

 

Here's a question for Unity re: "Embedded Devices".

Lets say we make a visualisation for a client, stick it on a PC with a touch screen, and deliver it to a client for use in a showroom or whatever. That's not an "embedded device", I think we'd agree - it's just a PC we've provided with our software on it.

Next step, we put that exact same PC in a box and mount the screen in it. Is that an "embedded device"? It's the same thing, just presented differently. It could even end up looking vaguely like a slot machine depending on the design of the box - ie: a standalone unit with a screen on the front.

Next step, same thing again, but we go one step further and have the OS on the PC automatically load our app on startup - the app can still be closed and the OS is still accessible, but probably not from the interface presented to most end users. Is that an embedded device?

I get the impression that these cases would be fine because, even if the app is all that PC ends up getting used for, it's still not taking the place of the operating system, and the "device" is still a PC that's being presented in a fancy case or box. But the wording could be interpreted to cover this, and it is something that my company is looking at doing in the medium-term future, and with the current wording this could be interpreted either way. Or it could even depend on how the client uses the software - what's the go if anyone's client does exactly the above without the developer intending it? Do we fall under different licenses depending on whether or not our client ends up running other software on the same machine, or if a client ends up buying dedicated machines just for our applications (and perhaps wall-mounting them or putting them in displays)?

I'm not really concerned that Unity will make our lives hard if we get in contact with them, as we'd be happy to do if we were planning a project to go this way. But it'd suck if we have to pass down generic usage restrictions of our own across all projects as a result of our license with Unity - we don't want to complicate things with our clients by having to tell them how they are and are not allowed to present or use the content we develop for them.

 

Under the current EULA that's an embedded device.

While UT staff like talking about exotic hardware, exotic OS's, and 'replacing the UI'... the wording is quite clear:

"...Licensee Content provides the user interface or primary functionality of such electronic device or system..."

If the primary functionality of that PC is to show a visualisation - then it's an 'embedded device'.

Disagree? Read David's examples:

• Game for a slot machine
• Information kiosks for exhibition
• VJing apps

 

That's the thing, though - an "Information Kiosk" is not necessarily an "embedded device" in any practical sense. Hence my wanting to get that one cleared up.

And the "primary functionality" thing is a minefield.

 

I'd point out that's what we've been saying for days now.

 

And I'd point out that I'm still not worried that UT are going to shaft us over this.

They asked us to point out use cases where the current EULA causes issues, which is exactly what I'm doing.

 

I'd be very happy to be unworried - except for the fact that I still haven't seen a straight answer to the question: why? Why do I have to contact Unity to do whatever I want with the app that Unity outputs? All I've seen is that Unity wants to "help" which as far as I can tell means that they want to charge extra for existing features.

For example, if the Unity team has to add extra features to Unity to support OnLive, fine - charge extra to license that *functionality*. But I haven't seen anything about charging for extra functionality - all I see is charging - ahem, I mean, "helping" - with existing functionality. As a Unity Pro/iOS Pro licensee, I'm obviously willing to pay for extra functionality - but being told to pay extra depending on how I use the functionality I've already paid for is kind of insulting.

Again, I'd like to rely on the benevolence of the Unity team, but the lack of a straight honest answer from anyone high up is starting to worry me.

 

That is exactly what I thought initially, then I re-read the EULA and found it so broad that I can conclude that even this, the simplest of cases actually is covered by the EULA, even though it might not be what Unity had intended.

This is exactly why we've been stating our dislike of the current EULA and asking for clarification both of Unity's intent and the definition of what is in the EULA. Thankfully Unity have taken notice, like they always do and i'm sure they will address the whole issue in a way that works for everybody.

Another thing I don't understand and has actually annoyed me is that from my recollection of the posts in this thread no-one who was concerned about the changes in the EULA thought or stated that Unity were evil, that they were out to shaft us. We have only expressed our concern that the end result could be damaging to a section of Unity developers and that it could be seen as more of a 'money grab' in some cases than being constructive.

All the talk of Unity being evil, shafting us or anything else in that regard has come from the supporters, those with the opposing point of view. The only thing that has come close was the use of 'bait and switch', which may have been an unfortunate terms to use, but I don't believe it was ever intended to imply that Unity were out to get us, more about what the end result could effectively become.

Which is only after the fact (EULA changed) and only when it was brought up in this and the previous thread. That's not to say Unity don't want to listen or that they aren't good at listening to their community, there are so many cases that show Unity do listen and will do whats best for their community, infact sometimes I'm surprised at just how far they will go. Its just a shame it wasn't done before the changes to the EULA.

Anyway i'm waiting patiently to see what they come back with, they have acknowledge the issue (quite quickly and even responding over the weekend) and hopefully once they have had time to shift through the information and examples we've given them well get some changes that work for everyone.

I wouldn't worry. There was never going to be an instant 'straight' answer to this, because it wasn't really possible. It seems pretty clear from the early response we did get that the EULA didn't tie together with how they wanted it to operate. Something this big and complex isn't going to be answerable immediately and there is little point in trying to do so until they have had time to address the situation and hopefully come up with solutions that solve the majority of the problems highlighted in the thread.

 

The thread started out with language like "bait and switch" and "scam", and although that has been toned down and/or edited out the tone and attitude from many people is still very negative.

But even that's beside the point. I said I'm not worried because I'm not worried, not because I think you guys think Unity are evil. The point is that if Unity isn't trying to make life hard for us (I do not believe they are), and I have a positive relationship with them (which my company does), and I actually communicate with them as one of my suppliers (which my company does), then it's highly unlikely that the worst case scenarios people are afraid of will come to pass for us.

Exactly. I'd be worried if they hadn't responded, but they have. Getting worried that they haven't solved a far-reaching legal issue which underpins their entire business in a matter of days is a bit unrealistic.

 

+1

This is important for two reasons.

Firstly... when is the last time anyone's claimed UT has tried to screw 'em? AFAIK the last thing I mentioned that could be misconstrued was the definition of 'Bait and Switch' - which was meant to be illustrative of precedence - and that was 6 pages ago. This debate has come into existence in a very short amount of time, and there's been a huge progression in a very short amount of time.

Secondly... this has never been about UT being evil. It's always been about UT making perfectly legal business decisions - for apparently valid reasons - that directly and negatively effect us and possibly UT. It's never been based about UT trying to screw us, but UT using this as a guiding principle with negative effects. For example, I don't think UT want to add an additional license fee to Ouya, but it would be *logically inconsistent* for them not to!

 

Sorry to be clear, although my reply quoted your post it was only meant as an example of the language being used to 'brand' those who disliked the changes in the EULA, not to single you or your reply specifically.

As for the negativity, I still don't see how we can discuss what are potentially negative impacts of the EULA without sounding negative But its just weird that apart from the unfortunate use of 'bait and switch', as far as I can tell and remember all the name calling and confrontational language directed towards UT have come from those with counter opinions to ourselves effectively putting words in our mouths.

Sorry I just started to find it annoying a few pages back, though I also have to accept its kind of what happens on an internet forum especially when language barriers come into it and the lack of so many visual/verbal hints as to the context and meaning of what is sometimes said.

But that's so disappointing that you are not living up to your nickname, you need to be angrier

True, but for some of us we need the security in knowing this for definite by clarifying and amending the current EULA. Hopefully Unity will be able to go even further though and come up with methods that fit into the previous business strategy (licensing add-ons) and we can lose these restrictions from the EULA altogether.

 

Let's postulate one last scenario?

You have a great business relationship with UT, and you have your reading of the EULA which assumes that an embedded system is some weird exotic thing that you'd never touch.

Now, you go release a simple game on steam or app-store, or direct downloads, you make a few thousand sales but doesn't go anywhere and you forget about it... it's certainly not big enough to worry about getting a lawyer in to do the EULA. What you don't know is that there's a small arcade chain in Japan that finds your game Hilarious! They read your simple EULA, find no restrictions, and install it on several of their arcade machines. It's so successful that it becomes a niche hit and is installed in a bunch of niche arcades all over Japan. [Edit: Or worse they contact you and you give them explicit permission!]

Now, a big arcade chain sees this and wants in on the action... but the problem is that it has a license with UT that costs them millions a year because arcade systems fall under the embedded clause. Realising that these small arcades aren't being charged, they start shouting at UT asking WTF? UT then contacts the smaller arcades, and find out that you've accidentally licensed them.

Now, here's the end game. Big company is going to pull contracts worth millions a year if UT doesn't charge these smaller arcades their cut. UT can't charge these smaller arcades because you gave them permission. You breached the EULA, and are now in the middle of difficult situation. Sure, you've got a nice relationship with UT but that's not the only concern on UT's mind - you've just given away 6 or 7 figures of their license away and it could cost them 7 or 8 figures in cancelled contracts.

Weird and convoluted yes, possible maybe. Great thing about UT's previous EULA is this scenario was entirely impossible - because you owned those distribution rights.

Lastly, note how no-one was being evil - everyone was acting in complete good faith.

 

I don't think said arcade machine would be an embedded device . Mainly since the game is still running ontop of an existing OS .

The smaller arcade owner can just as easily swap out one game for another one without even rebooting . Theirfore the game DOES NOT provide the primary interface .

 

For starters, my last use case to UT covers that.

But even so, that scenario is based entirely on conjecture, and involves me failing - significantly and repeatedly - to fulfil my own basic responsibilities. It also assumes that whatever the as yet unknown licenses end up entailing, Unity don't manage to solve those problems with them (consider: we're game devs, they'll have lawyers on the job).

 

I've covered this multiple times, in fact I covered it just two hours ago.

 

So, if I want to make WoW in Unity (I know that I most likely wouldn't be able to, since it requires best artists, designers, etc. but for sake of this example let we say I can do it alone), I won't be able to without paying license due to "streaming" part?

Here I want to use help of my friend who is working at Blizzard on WoW server software development, so he is pretty knowledgeable on the subject. According to him, most of the work is done by server (computing experience, managing players' and mobs positions, managing their inventory) to avoid cheating. To the WoW client only computed data is transmitted - WoW devs even make it so that server receives actual input from the user (e.g. user has pressed 'move forward' key) and then calculating new player positions, if player has hit a mob in case key pressed was attack key and calculating damage then sending that data back to client.

I don't know how much (if any) info of that is correct as this was shared with me by third-party (my Blizzard friend), I am just mentioning it here.

So with current license I cannot do game working like that, even if it is on less scale, not necessarily MMORPG, but let say game starring bottles which uses same server-side logic (e.g. not computing anything of importance client-side, client is only receiver of data sent by the server)? That's nuts.

For gambling and embedded part I couldn't care less. I've bought Unity in order to make games, not another 3DNA Desktop or slot machine.

It's streaming bit that really worries me. If it'll get reworded to limit to specifically services like OnLive, it'll concern me as much as gambling and embedded thing, as I don't see this as viable platform now. Maybe in 10-15 years, but certainly not now.

 

I just disagree with you interuptation of it . I think as long as the device can still be used for purposes aside from the Unity game your fine .

 

While the current EULA is very vague, it's generally accepted they meant to refer to OnLive like technologies - and I'd be very surprised if they don't clarify that in the updated EULA they are working on.

Surprised you say that, since it's up and running today. The biggest issues is simply for them to ramp up users to a profitable level... but that could happen almost overnight. Heck, there are already useful streaming examples with Unity in existence today - that don't rely on scale!

 

I think there are two ways Unity could go. There's the "development tool" route, where Unity thinks of itself as a tool like Visual Studio or Photoshop, and says that the user has the rights to whatever he creates. That's the way it's been in the past. Or it could go the way of Daz3D where it thinks of itself as a "service provider" or "content provider", where the user doesn't actually have rights to what he creates, and is only licensing the ability to redistribute his creations according to the company's EULA.

Personally, I hate the Daz3D model and part of why I chose Unity was because it seemed to use the development tool model. I think Unity is now trying to have the best of both worlds but this has a high chance of backfiring. Microsoft and Adobe surely know that they could suddenly change the Visual Studio or Photoshop license to say that you have to give them a cut of anything you sell, but they haven't done that. Why? Because they know that despite gaining some short-term profit from the people who they "caught", it would result in most people eventually jumping ship as soon as they could. They'd move to competing products that let the users have full rights to their creations. Daz's model has sort of kept Daz afloat, but it doesn't seem to bring in nearly as much profit as Max or Maya, who let the users have full rights.

 

Show me where it says that in the EULA?

If that was the actual license, then none of the quoted examples David gave would be an 'embedded device'.

Remember - plenty of 'embedded devices' e.g. Signs, ATMs, PoS, Exhibitions, Arcade Games, Slot machines etc. run on Windows - how do we know? Cause they blue screen every so often.

 

Out of curiosity. Is this your full time job now to monitor and answer that thread npsf3000?

 

But strictly speaking we are not trying to interpret it, we are taking exactly at face value the wording of the EULA. Which says absolutely nothing about whether the device has an OS on it or not. The OS is never mentioned and is therefore irrelevant. The only relevant parts are whether the Unity content 'provides the user interface or primary functionality'. So if you have your game or interactive media on the device 24/7 that must surely constitute the 'user interface or be its primary functionality', just because you can close it down and access a different layer does not in any way negate the restriction.

If it worked as you interpret, then actually nothing would be covered by this restriction, since AFAIK Unity cannot be run on anything without an OS of some description and conversely almost everything runs with some form of OS or kernel these days.

No he's just my <strike>lackey</strike> idol, to take up the slack when I don't have time to reply

 

I'd rather waste a hundred posts on this issue... then have to learn another engine that scripts with C++ or Lua... yuck

Sorry, the term 'lackey' is only available to pro-subscribers as per my EULA. Terms available of the free license include hero, god, idol, superhero, emperor.

 

Lol

I'm quite sure that you don't need to learn another engine eventually

 

That's basically how all complex embedded devices work. Anything able to run Unity would have to have some kind of OS and graphics layer underneath it. Can you give an example of a device running Unity that you would consider "embedded"?

 

Say you make your own Oyua and the dashboard itself is a Unity game . Basically without rebooting your stuck in Unity .
Most Embedded devices have the application running 24/7 and unless you want to go into the code you can't exit the application . I'm guessing as long as you can exit the Unity application and fall back to the background OS you should be fine .

Etherway , Unity needs to be clearer on this

 

So to go back to your statement an hour ago:

I don't think said arcade machine would be an embedded device . Mainly since the game is still running ontop of an existing OS .

Do you still think arcade machines aren't embedded? After all I've never encountered one with a [publicly visible] 'back to OS' button.

 

Like npsf said, that is how arcade games work. You can't alt+tab out of Steet Fighter to play Solitaire.

 

IANAL, but the Unity EULA may end up being unenforceable due to lack of the exact legal of definition of "streaming" and "embedded" and perhaps other terms in the EULA and the lack of a definition within the industry.

 

Well even that aside, the question of EULA enforcability isn't quite setled (i don't mean unity's eula, i mean generally)

 

I beg you not to put more restrictions or costs on Linux deployments than on Windows, that would surely be absolute PR suicide.

 

So they put limits on windows, mac, Linux, flash, webplayer, android, iOS... No/low PR problems. They limit Linux only and then there is a problem?

Sad world.

 

Restricting linux more wouldn't be pr suicide as their user base isn't linux it's a new market for them.
I think most unity devs don't care at all about linux and see it as a gimmick. Before this thread i had no clue why they even bothered with that port

 

Sad or not, singling out for extra change an operating system that was built without pay by legions of smart people and is distributed free and rightly loved by a large sophisticated community would be very unwise.

Better not to have ported to Linux in the first palce than do that.

 

Disagree, would have no effect, the target market doesn't seem to be those who care for it being a free os anyway it seems, so what they'd lose isn't what they're targeting

 

If the case is a Kiosk is connect to a network, running a web browser and use Unity web player to run the app host on the web server, is that not classify as embedded device?

 

There are so many ways to disable alt-tab, ctrl-esc, ctrl-alt-delete, windows key, etc.

http://lmgtfy.com/?q=disable+ctrl-esc+alt-tab+ctrl-alt-delete+on+windows

Or use 3rd-party software

http://shop.inteset.com/Products/9-lock-down-windows-7-with-inteset-secure-lockdown.aspx

 

And if I leave the home button active ?

This is going to depend on what the courts decide , as is its really ify what Unity means by embedded .

What would I have to do to make the arcade machine a NON embedded device

 

Then the set-up won't function correctly.

Here's a suggestion. Stop thinking about embedded devices - the EULA does not ban them. The EULA has a clause titled 'embedded devices' that outlines a description of what is banned. Waiting for courts to decide is relatively stupid... when we have the opportunity here and now for UT to make their intentions and restrictions crystal clear.

 

Hmm what about this thing? An Android TV stick with HDMI output, plug in the HDTV, running Unity game on it, is that TV+Android TV box combo classify as embedded device?

http://www.amazon.com/MK808-Android-Rockchip-RK3066-Cortex-A9/dp/B009OX22B4

 

Under the current EULA the following from that description is irrelevant:

• Android
• TV
• HDMI
• HDTV
• combo

What matters is:

"...if such Licensee Content provides the user interface or primary functionality of such electronic device or system..."

 

It depends , I could just have the home button fall back to extremely stripped down OS that only launches other games . Their-fore bypassing the EULA restrictions .

Here's what I think Unity meant
For Embedded you can't make a Unity Phone that ONLY has the Unity Game on it , and theirs no fall back OS to exit too .

Or it the simplest terms when the Unity game crashes is their ANYWAY to exit and restart it aside from rebooting the entire device . If yes you do not have an Embedded device . If no you have an embedded device .