Unity 4 New EULA Restrictions

+1

Unity is like Word or Photoshop - it's a tool that outputs content. That content can even contain propietry data from the tool [e.g. docx or psd IIRC]. However we still own that content and can use it as we wish - we don't have to ask permission to write a movie script in word or use photoshop to make logo's.

 

At the risk of beating a dead horse.....

Yes, my comparison was loose. I was thinking more along the lines of end users vs db admins / software engineers. I realize database apps are gated via system access / permissions rather than not providing the editor. There are some overlapping concepts but I didn't make a perfect analogy.

My understanding is this is their intent so it still seems like a legitimate practice to me.

 

With a DBMS you typically license the use of the DBMS, which is often on a per machine/capacity basis. When you license a tool like Unity you often pay per seat, regardless of how much you use the software or what you do with the produced content - you're confusing two very different licensing models.

 

Woah, too much to respond to, I need to work on making games!

I'll simplify by giving a blanket response.

I don't think Unity is trying nor going to screw us. If they did one of two things would happen:
1. They would piss so many people off that they would be forced to "unscrew" us.
or
2. They would lose a ton of customers. Another engine will sooner or later pick up the slack.

If they don't allow you to create the apps that may fall under the embedded umbrella (after you email with them about this), then sure, be pissed off publicly about it. Until then I think you're pissed off about a theoretical issue, allow them to clarify if your specific scenario is an issue or not.

Of course I don't believe in blindly thinking they will always make the right choice and I should just accept whatever they decide. But I'm not seeing a real threat to us right now. If I'm wrong then this will become obvious and at that point we can get up in arms about it. Until then I'm giving them the benefit of the doubt.

 

Unity have actually gone and made the EULA changes I've discussed. These changes are actively impacting developers today. I'm actively trying to make this an issue so Unity will 'unscrew' us as you say. We're in the process of doing exactly what you are asking us to do!

 

Yes, I need to stress the comparison was very loose. Still Unity may be more comparable to using MS Access rather than Visual Studio which could make it a bit muddy. I don't want to put too much more thought into this, as I said in my previous post, I should be making games, not arguing on the internet.

 

I understand your intent, not seeing the changes as having screwed us. <shrug>

If your specific situation (regarding embedded apps) is an issue with the EULA that would give me pause. But let's see what they say on that.

Actually that's my real point (took me forever to realize it). They are addressing situations with larger companies. If these rules apply to indies I think they will change the rules to allow us to do what we need to do. If I'm wrong then we will kick and scream as usual. But we're mostly arguing over theoretical situations, I'd rather see their reaction to real situations (your embedded app in this case).

 

and what happens when they do something that does 'screw you'? Will there been anyone left to back 'your' cause?

I appreciate its difficult to be vocal about something that doesn't affect you, but just because it doesn't affect you, doesn't mean you should imply it has no effect. None of it affects me directly, yet, but I can easily see how two of the changes might in the near future.

You may be right, but speaking for myself and to recap my surprisingly long replier earlier, if this is the case they've done it using the wrong tool. Through the EULA they have removed options and choice from everyone, not just big companies, further more its not clear, to me at least that they are offering 'value' for the need of additional licenses.

In every case discussed here, if Unity brought something to the table and provided an optional licensee to access these new abilities, features, support, etc, I don't think anyone would be complaining.

 

It should be noted that in every case cited as justification by Unity this is exactly what has occurred - clients have needed special abilities, features, support etc. and Unity has offered their services to help them.

 

Point of clarity, I don't think they are screwing any of us, not "I don't care because I don't need this functionality". If I am wrong then I will be behind you. Still want to see their reaction to the one real scenario presented rather than worry about the theoretical ones. How Unity treats all indies does concern me even if the specifics don't affect me personally.

I understand but feel we're just arguing theory which can get very time consuming and often goes nowhere.

 

1) There is a real scenario - read this.
2) This is a real scenario - we're asking questions to Unity right now [as I said earlier, I've made both public and private contact with Unity].
3) This not just theory - we've got the CEO of Unity participating... this is the 'real deal' as far as discussions go.

 

1. OK, so according to the article a 'very prominent' gambling company didn't want to pay the license fee. I'd like to see a situation where doing a gambling app doesn't need Unity to get involved (as Unity stated is required in these situations) and Unity still wants the fee. The rest of the article is theoretical.
2. and 3. Yes when it comes to your embedded app it is real.... and, as I've said, we're at the "wait for their next reply" stage of this discussion.....

 

Well for gambling they have, I didn't notice any others, but that wasn't the point of the statement, it was the 'provide an OPTIONAL license' that was the important part. As in if Unity are providing a service, then by all means license it out, but for the cases cited where there are clear alternatives or no real need make sure its optional by not stipulating it in the EULA.

Though I feel I should point out this is just my opinion on the matter. That with the information currently known, this stuff should be licensed by Unity, but not prevented via the EULA, despite how accommodating Unity might be to indie developers (though its nice to hear them say that they can be).

 

Whoa, why do you assume that this company needed Unity's 'special source', or even if they did they needed it to the extent Unity tried to charge them? Isn't it a bit early to rush to conclusions?

Actually we're at the discuss and question phase. Just because we're waiting on answers to some questions doesn't mean we have to sit on our hands.

 

My only real problem with this is the streaming restriction .

I'm not all that great of a coder , so I'm sure theirs a better way to do this , but lets say I made awesome game X . I want people to be able to try Awesome Game X without downloading it . I then run a few cloud VM's , install the game on those and develop( i'd probably buy an off the self solution ) an way for users to access the VM's from a browser .
What, for someone who knows what their doing , would of been a 3 step process , is now a complex legal one .

Before :
Step one , Install game on cloud VM
Step two , Write client( i'm pretty sure theirs something I can buy for this ) to allow users to do the remote desktop thing in their browser .
Step three , Distribute links to gamers so they can try try the game inside of their browser .

Now
Step zero , Call unity and pray you can afford the liscesning fee , then pray your boss still sees it worth while ,
Step one , Install game on cloud VM
Step two , Write client( i'm pretty sure theirs something I can buy for this ) to allow users to do the remote desktop thing in their browser .
Step three , Distribute links to gamers so they can try try the game inside of their browser .


Although in Unity's defense with the Linux export I could do this from Linux VM's for a very low cost, and I could scale up and down very fast . In fact if it wasn't for the new EULA I would look into developing this solution . Odds are I wont be successful , but at least I would have the option to try .

IF Unity comes out with uber streaming solution and says yo pay us 75k for this streaming solution IF you want to get up and running right now, then that's great . Infact THAT would make more sense then just stopping us from doing something

@Unity staff , is their anyway we can at least get a "hobbyist" exception for this , like if I have an annual gross of less then 100k I can experiment as I want .

 

So I have a question: if Pixar prepare a film and they used 3DStudio Max for creating a character then they have to pay a revenue share of 10% depending of how many watched the movie ?

I already asked to Superpig which said gambling authorities asked for sources: which authorities, links? data on this?

I think U3D wants to have a percentage on revenues... like 1% on 100M$ ... not bad for not adding a single 'quid' into the development phase.... just because the kind of application.
By the way, developing a 3D slot machine using only HTML5 and css animations is not so hard.... bye bye Unity.

 

@npsf3000 Changed title after your request.

 

FYI Pixar uses their own in-house software. And if you think that you're fine without Unity, well then move on. Nobody hinders you.

 

http://www.meetup.com/San-Diego-Tea-Party/messages/boards/thread/28378612

If you can't provide source the authorities will not be able to check your gambling game as required by law,
they will simply have to shut down the machines. so basically you need a source license, even if you don't need
it to actually create your game.

 

Not directly related but, what does a unity source licence cost? (Not for gambling, interested in modifying the engine)

 

X, only discussed under NDA . I'm guessing well into the 6 figures .

 

6 figures sounds pretty high for this but might be, guess i'll contact them directly when the need arise but if it's 6 figures that's definately a big no for me

 

The changes to EULA in embedded systems affects me. What makes UT think that all embedded system uses linux? I can deploy visualization projects on embedded touchscreens that runs windows, and now I can't with U4.

Making Linux build is great, and if there is additional resource/support needed that UT needs to recover that cost, put a separate license on it. In the few recent incidents, UT has destroy all goodwill. Do everyone need new Meciam or DX11? No, we will pay the U4 to get those features and bugfixes, while things like UI are still not fixed. I will be keeping a lookout for another engine to jump ship.

 

We need a clear definition of what streaming is.

if its something like "Game Running and Rendering on machine A and feeding video to Machine B. (potentially accepting input from B for game running on A)" then Streaming appears to fit my understanding of the definition. Although I originally thought that this was complete bologna, I can admit that a potential violation of the previous EULA's intent would be a person licensed solely for OSX serving Windows Operating Systems with a streamed OSX app. A question that is raised however is why is this any different than a Web Player app if Unity's web player is supported by the OS? This particular restriction does not affect me yet. But I have to ask "What are we in for next?".

If it is any way related to headless/non headless server to server communication (other than that listed above), then this is a huge deal! This effectively gimps our network opportunities unless, of course, we pay more money. Also It looks like the way that this section in the EULA is currently worded, this could apply to a server app requesting data from a database and returning the results to a client. That is a big deal. Finally if this is intended to "Only apply if we use a Server OS" that is complete bologna. We paid for OS platform support and Licensing already.

Restricting applications Networking capabilities to a case specific license basis would have been a show stopper for me. I would not have bought the upgrade if properly notified of this change nor would I have bought any previous version if that was clearly stated. The EULA limitations being imposed are against what I have come to believe Unity Stands for. For Unity to tell me what I can and cannot do with the IP that I create with their tools, other than the restrictions to the Generically defined Operating Systems I Licensed, is going to far. The freedom and simplicity of the license is what brought me to Unity in the first place.

I'm struggling to rationalize the decisions being made regarding the restrictions in question. The gambling issue seems to have reasonable arguments in most situations; however the other (NEW) restrictions that have been introduced appear to be creative attempts of increasing revenue while taking away freedom from the developers, unless they pay more. Add to this the method of communication: 1) We were not notified of this before we bought the 4.0 licenses 2) A user had to find out and make this an issue before it became a topic (Would you have ever told us, unless we published something that violated the EULA) 3) I'm reading (Between the Lines) that it's ok to take stuff away from developers (or charge them more for the features) because new revenue opportunities are surfacing that Unity did not notice before [Who helped you get to where you are, who invested time and energy to learn your technologies and improve them, who adds value to your product everyday?]

Please set me straight in my interpretation of where Unity is headed. You have proven to be a creative business in the past. Don't start stepping on your developers to get to the next level.

 

About the gambling concern, if the gaming service require charging player to play, and award the player for certain achievements, but it is not money but some other tangible or intangible form, is it require a separate license?

 

What are you expecting? It clearly has to be more than the price of a normal Unity license.

 

Embedded system means non-desktop environment, excluding mobile platform. I think it is not a good reason because the release of Linux platform.

I believe If you deploy application to something like this you need to talk with Unity, no matter they run on Windows Embedded or Linux.

http://www.acrosser.com/Products/Gaming-Platform/All-in-One-Gaming-Box.html

The EULA can be much easier to read if change to "Application run on non-desktop environment required a separate license and required to work with Unity."

 

Koyima I try to reply you taking your point seriously: the code you write is your source, your scripts, the packages, the commands sent to the engine, like the function calls into the operating system are the source required by any Authority (except Nevada ??) [my assumption].

The fact you are posting a discussion on voting machines (another matter) is showing how weak is the point. Authorities (gambling) ask for source code and for parity check of the software deployed in each machine (to avoid forges) but NOT for the source of a function call to DX11 or OpenGL etc. Why with Unity is different ?

 

Source code of a machine, according with UK:
10.2 Development process.
• Master source code should be held securely (such that the source cannot be tampered
with by unauthorised persons).
• An audit log of all accesses to master source code should be maintained.
• Old versions of source code and the dates they were retired should be retained for 10
years.
• Access to source code by developers should be well controlled and based on a
minimum access required for the job approach.
• Access to platform source code should not be granted to those working only on game
specific development.
• Changes to critical modules must be logged and should be peer reviewed by an
appropriately skilled independent person (who can be from the same company) to
ensure all changes made are appropriate and in line with the change documentation.
Any suspicious or unauthorised changes must be explained.


Where is the operating system source code access? Where is the browser source code access? Where is the audio/video/graphic source code access required?

 

I am not under this NDA so I can tell I've heard of 45k just to start. Of course, is just what I've heard of.

 

This sounds much better than 6 figures already, too high for me but this could change.

 

Thanks for the understanding, these are a new field for many of us and we are trying to balance to enable developers to do fantastic work and keeping the company healthy.

@Bruno: it really varies, from much less than that (in some R&D cases we don't charge) to significantly more. Especially in cases where it's not about games.

@Noisecrime: we're trying to do right by both the community and company here, and in our planning had tried to understand the usecases that we might be blocking. You mention a few like streaming in museums and I'd love to know more. Could you describe what you're doing?

@npsf3000: same here, can you tell me more about what you're trying to do so we can work out a way to enable it?

 

World of Goo, Braid, And Yet it Moves.. these are three indie games available via OnLive. Is it a correct reading of the EULA that any studio that that uses Unity4 to create their game(s) will not be able to make their game(s) available via OnLive? Any potential technical barriers no longer matter, it's now a matter of legal fiat and simply not allowed?

 

Please remember that there's a difference between "not allowed by the EULA" and "not allowed at all". Of course we allow people to submit their games to OnLive, we just want to talk to them first and learn more about this area – so far we've not actually seen this happen at all.

 

The thing is I'm limited since distribution to Onlive or another cloud service might be a late stage decision . Is at your company's discretion to say go ahead and stream your game without paying anything extra , or pay Unity another 20k for something that doesn't actually require any more work on Unity's part .

I think Npfs300's mad since he knows he CAN do many of the things your restricting . For someone like myself, a rookie dev, its not going to make much of a difference right now . But in 2 or 3 years I might be in a situation where I can't use Unity for some new streaming platform or for a specialized tablet that just does one thing .

 

So... If an indie Unity game becomes popular and the dev/publisher manages to start business with OnLive, that means the dev/publisher need to invite Unity to join conversations and as soon as OnLive understands they gonna need to pay UT tons of money they will just say NO to that product...
You sir are very smart person I am sure you know that that situation would enforce the dev to port the game to another engine to simply be able to publish on OnLive, after all such platform would never agree to follow the terms in this Eula; they are the platform, not Unity.
Than that would be a case of UT staying in the way of a client's rights to expand his business, just like you are expanding yours.
How would Unity help the dev/publisher in this case?
Would that dev be forced to share revenue with UT, since OnLive of course would not agree to adapt their ecosystem around a particular product?!
Or would UT just say "-You can't sell your product on OnLive because OnLive don't agree to partner with us."??

If the dev in talk was me, I'd gladly share any fair business to have UT helping me out on having my product on so closed platforms, but I think many devs may see this as a very big problem as we can see in this thread.

 

What's with the aggressive tone and assumptions about evil scheming on our part?

Making your protest heard is cool, but it's possible to be nice and civil at the same time.

It's been outlined a few times, but I think a bit of re-iteration could be useful and bullet points are awesome:

• These EULA changes are intended to be defensive business tools when playing with the big boys.
• Phrasing could definitely be better - I'm sure everyone agrees. It would be awesome if this thread could produce some constructive outlines of cases incorrectly hit by the current phrasing, so that we could more easily rephrase to everyones satisfaction.
• No the EULA is not an ad or whatever other example was given, but in business and legal land, this is how you spell "call me".
• Our products are way more than just the software you download from our website. Especially so with gambling.
• I believe Grahams response to embedded systems was misread. We're not charging extra for bug fixes, but for very custom changes to obscure embedded systems which are likely to see zero re-use.
• Someone mentioned an assumption that we'd be charging people through the nose for using the Ouya? Where the hell did that come from? It's an awesome idea and I'm looking forward to receiving mine soonish. At which point you better believe I'll be playing around with getting my projects on there. It's an android, remember?
• When getting a nice juicy deal with one of the big boys, where do you think that cash goes? To a change of zebra-skin for the seats of all our corporate Ferraris?
  Like we have done with our new features and the pro/free split, it has always been our policy to throw as much income as possible directly at development - that means you get more for the same price. Which I imagine you would approve of.

As mentioned, it is awesome that you protest when something doesn't seem right and we clearly need to clear up our EULA language here. However if through all of this you still believe that we're in this with foul intentions and that we are being two-faced about our mission statement vs. our actions, I am not really sure what more there is to say.

The mission statement is as alive as it has ever been on our end.

 

AngryAnt,
I'm not sure if the alusion of civility issues is global or targeted to the previous poster but i'd like to repeat my own stance:
- I am "not" affected by any of these changes
- I am unhappy to see these changes
- I do not read some hidden evil in these changes
- Yet i do not welcome any form of licencing changes that only positively affects one party (restrictions without additions)
- I am not shocked at licencing costs (and, if the gambling companies need source code anyway, they will call you to purchase it, no need to explcitely refuse them in the EULA)
- I do "not" believe that changing the EULA is the right way to say "call me"
- I feel all of this could have been done with no EULA change because :
1) For gambling it's superfluous, as noted above if companies "need" source code they "will" contact you anyway, no reason to add restrictions there.
2) For embedded the reasoning, even once explained, is very confusing. For exemple removing SSE, is it in all cases (in which case that's bad for everyone except this niche) or in a special build? If it's a special build and the porting effort which you mentioned that took much effort is not available as in in unity, once again, no reason to change unity's eula as nothing changed there, make a separate licence for access to that special build.
3) For streaming as you see everyone minus unity employee seems to agree, we see no diference between sending an EXE to an end customer or sending it to a publisher, also this sounds absolutely unprofitable, sounds to me like streaming is still going to be quite expensive, it's just going to be a big no no if it costs more on top / requires additional licencing legal work (even if the licence was free).

As for the mission statement and the overall "we're not evil", it's important to note that it's not because unity made the barrier to entry low that everyone is here because of that, i'd be here all the same if unity had no free version and costed 5K€ / seat. Yet i still am very unhappy about those changes, and none of the posts adress my concern as most unity posts here are clarifying that there was no bad intent, but it was never the intent that bothered me, it's the change itself. I'm not happy about not being to use my unity produced exe as i wish, and i'm even less happy reading that this is something that sounds reasonable to unity if new technologies emerge, i want to know that if tommorow a lunar projector exists, i can project my game in real time, while it's running on the whole billion dollar microsoft + amazon merged clouds, with alien technology interop being remote controled by the combined thoughts of 10 direct brain inputs!

Licencing should, like anything that leads to good in business relationships, be kept as simple and unambigous as possible. The current text is ambigous and the changing of the text itself at the advantage of a single party is not something that makes me feel safe for the future.

 

Ditto

When I produce a rendered video from Cinema 4D, Maxon doesn't tell me how or where I can publish it, nor charge me additional fees based on such distribution methods.

 

Cool, thanks for your input. We're discussing this issue (though it's a weekend) and looking at this thread (I got the link to it from an internal email thread).

Let's see what comes out of it.

I had no intend of targeting any one individual with my request for a nice tone. A few people have been pretty aggressive in here and that's not very cool.

 

No, but I bet if you build a render farm with their software and start making big cash on that, they'll want to have a word with you

 

If you buy enough licences to build a render farm without having a word with them, odds are they'd contact you to know where they can ship champagne to you only

 

Ditto... ronan, you save me a lot of typing

 

Hi AngryAnt,


To give you a quick heads-up on some of the key concerns. Firstly in your attempt to target 'big boys' you've restricted your entire community. If you stuck a $5Mn annual revenue threshold on these limitations *then* you'd have been targeting big boys [though would have still had potential of hurting the small indies].

Secondly, did you listen to the rationale given by David?

According to him he loves Linux, he loves that his customers can now build with it, but due to a slight oversight that enables things that could hurt revenue he's had to restrict all embedded devices [regardless of OS].

Now we know you love Ouya, we know you want us to build for Ouya... but based on this precedent I expect that you're 'suddenly' going to realize that it might cut into your console licensing and therefor restrict it via the EULA. Hmm... Ouya Ouya EULA... I like that

That's not to say that you will do that to Ouya... but you've already done it to two platforms and one game genre so how can I as a Licensee honestly expect you *not* to do so again?


Thanks,


NPSF3000

 

AngryAnt, you are not seeing this. People here love Unity, they depend on it, invested time and resources learning , and make a living on it. People are Angry (no pun intended) because the way the situation is being handled. If UT came out saying, hey 1.5K for Pro is too low, we need to raise prices to sustain, I think we can understand. After all we don't want UT to go bankrupt. The whole affair of handling this, is a major part of what caused people to be angry.

Regarding non desktop deployment, what does it actually mean? If there's a windows build like Windows RT that run .exe fine like Windows XP, again that changes what we can deploy to.

 

The problem is, how they know the render farm making big cash?

 

A point of clarity as I see it:

- I would imagine that UT isn't bothered by the remoteness of cloud gaming. It is the platform abstraction that would be a threat to the current revenue model. Imagine a world not too far from now where you only need target one or two platforms as a publisher, yet your games can be played on various devices and consoles. That's great for developers and potentially bad for UT. No more high end platform licenses, just one flat PC/Linux license. That is, till this was covered by a firewall statement in the v4 EULA.

In this light, I can easily see where the firewall rule preventing cloud streaming came from. But, I'd also like to respectfully state how it affects my company. In short, it introduces an additional liability in the use of Unity4+. I don't know how/if cloud gaming will evolve in the coming years, but if it does evolve I don't want to be potentially locked out of those markets with a title I publish today. Being locked out could be because the 'cloud store' simply refuses to allow Unity authored titles because of complications with licensing. Or, it could be financial because UT won't provide an exclusion to the cloud streaming firewall EULA rule without some financial payment or royalty. In any case, this cloud gaming market uncertainty combined with the clear certainty of what the v4 EULA says today translates into a liability for licensees of Unity. In a sense, UT has moved this liability from themselves to the licensees. This streaming restriction allows them to retain the ability to intercept any development in cloud gaming that could lead to future revenue loss. But it introduces uncertainty for licensees.

Lastly, if I'm anywhere even close to right, I understand the business motivation behind the new EULA restriction on cloud gaming. I get it and I'm not trying to be disrespectful in the slightest in this or other posts. That said, the cloud gaming restriction devalues Unity today in my eyes because of the added liability and uncertainty it introduces for licensees.

 

Thanks for taking the time to reply to the thread.

Well there are two aspects to this, the first is that in my line of work I pretty much deal with new clients on a constant basis and rarely end up doing the same types of projects. So it is perfectly feasible in my mind for an existing or new client to come to me wanting to create a project that relies on streaming Unity content or even on an 'embedded' device.

Several times in the last year i've been asked about creating a similar project to that of the Lynx- Fallen Angels AR promotion and actually suggested that not only could it be done locally but also streamed with two way interaction. I.e. streamed in a webpage using browser based communications to pass data back and forth, no need for a Unity plugin (sorry).

Now although I don't have any specific projects like that on at the moment doesn't mean I wont. A year ago I had no projects using Unity with Kinect, in the last six months i've done three (each markedly different to the others) and was working on a framework off and on for six months before that. If this required an additional license I can tell you now those projects would not have gone ahead, there just isn't the budget to accommodate it.

For a more concrete example I have been working with a colleague on a system that would link Unity content (or actually any content) to visitors mobile devices for use in museums or exhibitions. Enabling them to control the content, without the need for touchscreen or other input devices. This has been developed to a working prototype and being offered to clients. Its nothing ground breaking, but it is a potentially exciting use of technology that may attract new clients.

An obvious extension of this is to then be able to stream the unity content so that the visitors don't even have to remain in front of the screen, though we have not pursued that, yet. I say obvious as we've done many kiosks in the past that link users to content, from sending email to print outs. As the barrier to entry for streaming content comes down and as our clients become more technologically up to date streaming would seem to be a natural progression.

Just for clarification, in none of these cases am I talking about the technical level of streaming that would be required for that of gaming. Bandwidth, latency, unlimited connections none of those would have much of a priority as long as the end result is usable. These projects aren't trying to create 'onLive' they are just using an old technology that is rapidly becoming more and more feasible.


Here is where we have the issue and why i'm being so vocal about how Unity has 'apparently' locked down the ability for us to even pursue this due to the new EULA. Whilst clients might be able to afford something along the lines i've described an additional expensive/unknown license cost, especially for something like streaming where Unity to my knowledge is not providing anything would kill it dead.


I realise that you are walking a line between business and community support and I really appreciate your offer to developers for getting in touch if the changes to the EULA affect them and that UT will probably be happy to work something out. Unfortunately whilst very supportive, such statements clearly conflict with the EULA, more so when you say

. To my mind this just gives even more weight that the current approach in the EULA is a really bad fit and seems to be helping no-one and frankly its the EULA that developers will work to, meaning in my case i'll probably just end up moth balling or not pursuing projects that might fall foul of it, instead of taking the chance that UT would turn around and say 'thats fine' or ask for a small acceptable fee.

I'll say it again. What I dislike here here is that 'choice' over what we can produce/deploy with Unity has been taken away from us. That in some of the cases (e.g. streaming) Unity does not appear to provide any additional resources, assets or features to justify additional licence costs (with the exception of perhaps a linux server license which would be fine, see my previous replies). That the EULA has blanket clauses that prevent uses which really shouldn't be any of UT's business.

Sigh, I really hate this, I have grown to love Unity and respect UT and its hard working developers, but these changes to the EULA concern me greatly.

 

I'd just like to say I completely support Unity's EULA.

UT is a private company and they can set any restrictions on the software.

The streaming issue is to cover their bases in the future. I have not tried to become an OnLive developer nor do I know exactly how their mobile streaming works, but If you can play a PC version of a game through the mobile app then why would any developer need to purchase a unity android/iOS license? They could just create a PC version of the game and push it to a streaming service.

Gambling is heavily restricted and enforced in the United States. I wouldn't be surprised if a company develops an illegal gambling service using Unity and the US tries to go after UT for allowing those games to be created using their software.
http://www.vendingtimes.com/ME2/dirmod.asp?sid=&nm=Vending+Features&type=Publishing&mod=Publications%3A%3AArticle&mid=8F3A7027421841978F18BE895F87F791&tier=4&id=7E90D799B50F4AF0A6B9932E79A811B7
Slightly different situation, but that article still shows a possible problem with this.

Finally, IF there was some evil mind conspiring to enact harsh restrictions on Unity devs then why wouldn't they just delete this thread and ban all users complaining about it?

In closing, - If it doesn't work, you must be holding it wrong -

 

And what are we? Sheep that should do whatever UT says? No, we are businesses in our own right, and UT has fundamentally changed our relationship behind our back. Is it unreasonable for us to try and have a discussion about said changes, with the aim of reverting or altering the EULA?

Firstly, that's not whats happened here - Unity has not said 'no streaming to mobile platforms without a mobile license'. Secondly, Unity has made a business decision to support additional platforms - if/when those platforms die then Unity's investment in that area will end. If UT's business model has to change to raise more revenue, there's plenty of options available that don't involve arbitrarily removing rights from its users.

Do you have any evidence to think this could occur? Remembering I could go and make a game tomorrow that breaches dozens of laws without touching any gambling regs. If anything, and I'm not a lawyer, one could argue that these changes make UT more liable.

Strawman much? Who's saying there's an 'evil mind conspiring'?