Unity 4 New EULA Restrictions

So based on that (flawed logic)
If I made an illegal gambling service using XNA, Microsoft would be in danger of being shutdown?
If I made an illegal gambling service using Java, Sun Microsystems /Oracle Corporation would be in danger of being shutdown?
If I made an illegal gambling service using Flash, Adobe would be in danger of being shutdown?
If I made an illegal gambling service using Pen and paper, the providers of said pen and paper would be in danger of being shutdown?

Its pure nonsense. Unity like all those mentioned above are just tools and they can be misused just like any tool can. If anything the change to the EULA and the requirement of a license would suggest the opposite is now true. That if a flaw was found in Unity and I had their gambling license one would assume they might be liable.

If UT want to develop a gambling based add-on, some accredited version of Unity that full fills the various legal requirements that's fine and they can charge whatever they like for it. The problem is that like it or not, if you use Unity in a gambling app, even if its just as the front end for displaying pretty graphics, you still have to buy their license according to the current EULA.

I really don't understand how people cannot see the fundamental problem here. Its not that developers want the gambling version of Unity for free, or that they deny there are heavy restrictions involved with gambling software, its just that they don't want to be locked into buying into Unity's version if they don't want to. They don't want to have to pay a license for something they don't need or wont be using if they already have an accredited back-end for dealing with the actual gambling aspects.

The same argument goes for embedded and streaming, though overall its the fact that Unity has changed what we are allowed to do with products that we create and build using Unity that is the heart of the matter.

 

It's actually worse than that - I'm very cautious of the word 'indirectly'.

If one was to release a game via Steam, iTunes etc. and then some people install that game in an arcade like set-up*... suddenly one might be liable for such usage. Just an example of how potentially ridiculous this is.

*See Picade as one example.

 

In fact having read the EULA again what I thought constituted embedded systems is actually not what is being discussed there, but could be viewed as exactly the delivery mechanism I use in the majority of my client work as kiosks and installations!

The only reason it doesn't affect me currently is that i've fortunately fallen short of the limit of 50 systems. However there is nothing to say that wouldn't happen in the future, I've had projects running on 10 machines in the past for a large video wall, it is not much of a stretch if a big exhibition came along to tip over the 50 limit.

Furthermore I just realised this isn't 50 devices per an exhibition, but per a project. That's even worse as part of my business is to license out additional installations throughout a company. One of the kinect projects has a request for 5 installations, but that's for a company with only 5 offices. Again no stretch of the imagination to end up with a client who might want it in more than 50 locations.

I've done working the past for companies like Deloitte, creating an exhibition kiosk displaying financial news stories on an interactive world map. They liked it so much it they put it into the foyer of one of the head offices and wanted a version to run as a screensaver on their laptops.

Granted in that case its not the primary interface for the device in question, but its a bit of a grey area since as a screensaver it would be displayed most of the time and according to feedback it was used by many employees. For kiosks it could be argued that it is the primary interface since that is all that is ever displayed to users. So had they installed PC's whose only purpose was to display the interactive worldmap that would fall under this part of the EULA, at least with the current wording.

 

Keen observation, hadn't even considered that.

The more I look into this the more worrisome it becomes. I have no doubt that Unity didn't mean to affect small to mid size developers, at least not in the way they have. Heck i'm basically one guy who works with another occasionally, but even then it seems increasingly likely that one 'good client project' could end up making me fall foul of these new restrictions. Though I seriously doubt that the budget would stretch to covering an 'unknown/non-disclosed' license cost.

I still understand the need for Unity as a business to make money, but this just all seems wrong, targeting the wrong people with undisclosed license costs, closing down potential opportunities, all through a poorly worded and in my opinion (for what its worth) misplaced restrictions in an EULA.

These situations made me chuckle.

A client wants 52 kiosks running Unity as the primary interface to information for an exhibition. I say well thats going to cost extra aas we need an undisclosed cost license, what about just having 50 kiosks/ Client says sure

Depending on how you specifically define 'Licensee Content'.

A client wants 100 kiosks running Unity as the primary interface to information for an exhibition. I create two projects, with subtlety different interfaces, graphics and code. No embedded license needed at least with my interpretation of the EULA

But that's cheating you cry!

Ok how about the reverse. I build a kiosk framework and use it for different exhibitions and different clients, however it all follows the same format, information type, only the media changes, some new photos, new title. The project isn't even updated, it uses the same build for all, just a few assets on disk are imported. Now I can only use this project for 50 exhibitions, before I have to completely rewrite it from scratch in order to guarantee i'm not doing the cheat above.

 

Your signature does.

 

Nope, you need new glasses. If you want to know *why* I used that terminology, this excerpt from wiki may help:

The goal of the bait-and-switch is to persuade buyers to purchase the substitute goods as a means of avoiding disappointment over not getting the bait, or as a way to recover sunk costs expended to try to obtain the bait. It suggests that the seller will not show the original product or service advertised but instead will demonstrate a more expensive product or a similar product with a higher margin.​

 

That's just being disingenuous; you know full well that using the phrase "bait and switch scam" is needlessly inflammatory. Virtually yelling "scammer!" at someone is not exactly the best way to engage in productive dialog.

--Eric

 

npsf3000, I think you're way out of line here. Unity's pretty up front with what you're getting and not luring you into a purchase you didn't set out to get.
They have expanded into new markets and platforms and have updated their EULA accordingly.
As an example to the broadcasting addition: The smart tv's that are running unity would suffer if people were able to work around the technology by setting up 1 unity system in their hotel basement and then just broadcast the generated display to non-smart tvs in the rooms.

 

That's entirely possible, so let's see.

Err what? Please show me, other than the EULA, where Unity have informed their user-base that they are no longer just a tool provider, but are actively controlling the content you output?

I can show you some statements from key Unity staff indicating that if you want to use Unity as you did previously you'll need to get a new license.

Nope, they're taking away existing markets from their own clients by changing the EULA.

And? Where does Unity come into this? They make a tool to help us produce content - they shouldn't be discriminating between which content should be allowed to compete.

 

Rather than re-iterating the same points to which we have already responded and are clearly aware of, could you guys see if there are any additionals we should be aware of when working on our rephrasing?

It would be rather silly if we miss something which then results in another tumble like this. We're of-course doing our best to get the best results out there, but as this thread clearly indicates, we're not perfect in that regard.

Everyone is entitled to their own interpretations and imagination, but continuous speculation / accusation on our malicious intend in this does not only make for depressing reading - it doesn't help solve the issue at hand.

 

Not to be obtuse... but doesn't that depend a lot on how you're trying to rephrase this? The simplest solution would be to ditch the restrictions and operate as you did under the 3.5 EULA - which appears to have worked fine in the past. If you feel the need to continue them, then I strongly suggest you be very deliberate with your wording - right now you're very broad affecting far more than the few examples you've given.

I want to clarify that you've not done anything 'malicious' - at worst this is a bad accident. However, if you exercise some of the rights you've given yourself then from a client perspective... it's a very disconcerting turn of events.

That said I'm in private contact with two of UT's staff and am waiting for them to continue our discussion.

 

For the streaming can we just get an exception if we have no actual plans to make money off it .

Like can I experiment with Unity games running on cloud VM's without trying paying money I don't have for another license .

The way I view it Unity SHOULD offer additional products specialized for the affected areas , but shouldn't place restrictions on those of us who would just want to experiment, or develop without any add from Unity .

For the record , the embedded systems restriction only applies if theirs no other interface for said device . Like I have 60 android tablets set up running a Unity game, even if I disable exiting the game( in a kiosk situation this could just be a plastic barrier over the home button ), the Unity Game IS NOT the primary interface for the device , since the Android OS is still running in the background , and the next day the game might not even be running on the device.... right ?

 

Well, if the "Streaming" clause is destined to be in the EULA, it would be nice to see explicitly that it only restricts Unity from being used for backend rendering (like Onlive and Gaikai).

And that it does not broadly restricts every possible significant use of a dedicated headless server (say, for example, functionality merely on the level of a dedicated Minecraft server)

 

Streaming and Cloud Gaming Restrictions

I think changing Content to audiovisual content would make it very clear, on what is restricted.

 

Exactly!

Either this section is horribly written or the intent is to cover a very broad range of use.

Can someone at Unity chime in on what the official Unity definition of "Streaming" is in english?

I'm very worried about what the intent is regarding this section. Do you plan on new licensing structures for headless servers and/or authoritative servers that are not run on a clients machine?

Am I going to be charged an additional fee if my client requests data from a unity based server that in turn gets data from a SQL database? Perhaps I do not want my clients going directly to my SQL database. Is this going to apply only if I'm running on a specific OS? Do I now have to use another technology for the server just to avoid additional fees? How does this benefit the growth of the Unity product?

The next huge concern is that the Unity representatives Responses to our questions leads me to believe that you intend to start breaking down OS's into "Server" and "Non-Server" versions. Eluding to a potential extra cost if our app is running on a Server in specific situations. Is this a total misinterpretation of where Unity is headed?

I think Unity can clear all of this up if Unity can comprehensively and clearly define the intent of these EULA sections in English. The legalese (i'm sure by design) is written in a way that blankets so many situations, that we cannot help but feel constrained and violated given the precedence of the previous EULA. Once we understand the exact intent, I think the community can then help with wording that makes us all feel better.

I'm feeling like i have invested and dedicated a very large amount of my time over the years into a technology and company that is about to change the way they do business in a very significant way. This puts me in a very uncomfortable position.

 

The streaming restriction in the v4 EULA is clear in intent and requires little imagination. It forbids use of Unity based games in deployments like OnLive and Gaikai (or any other new cloud gaming initiative from anyone) without a separate license from UT. Details of said separate license are naturally not provided in the EULA, hence why a company would have to contact UT for additional details.

When I licensed UnityPro v3 over a year ago for Win/Mac is was so I could create and sell games that would run on those platforms. Starting in v4, the Windows license now comes with an explicit exclusion that does not allow the windows OS running the game to be a server that streams interactive content over the internet. If I want to make any Unity4+ developed game (or demo of that game) available via any streaming technology or service I now have to bring UT into the discussion with a presently unknown agenda.

So, if you want me to go away and get back to work, simply remove this restriction. That's in my best interest since it preserves the most options for me as a licensee.

If you can't do that, then a very honest statement of why this restriction was added might help sooth your PR problems.

As a final note and to bring my input to a close, I'd encourage you to consider whether this streaming restriction / separate license clause will actually accomplish your intended goals.

 

Although I don't disagree with your point, it is not exclusively 'games' but far broader, as in any Licensee Content. That may be a little pedantic of me, but since we are also discussing the specific details and wording of the EULA, I think its important to highlight there is currently no distinction. Though such a distinction might make the restriction easier for me to work with (as half my work could not be considered as games), I'd still rather there were no restrictions.

 

An additional "only applies to companies with over 50 employees" would cool everybody down.

 

Wow... seriously. This thread actually made me to post my first reply on the forum, I mainly just read technical stuff, and I'm also sort of a newcomer to Unity. But wow!
As I see, the starter of the thread finally managed to talk to UT staff about his problems. This should've been done IN THE FIRST PLACE.
Instead, he tried to make everyone here go crazy about the changes, and "evilify" Unity Technologies UPFRONT in front of everyone who read the thread BEFORE even a non-lawyer member of the staff could've reacted to the endless rambling that was going on.
Considering how important Unity is to many users of the engine here, and how involved many people get with it, and how much they LOVE the product (hence the great community), and how much they paid or not for it, one would find the harsh voice from some community members acceptable, although I personally think that the opposite is the case here, so I do not think that this was necessary and/or Unity deserved it.
And of course after the actual CEO of UT posted a perfectly nice reply (which fact in itself implicitly guarantees that "we will surely look into it"), the rambling didn't stop.

Somehow I must have found the thread greatly enertaining to read through the most of it, but it triggered multitudes of "ShutTheF*ckUpAlready" events in my brain, and I think not just in mine, I even had to apply a BeerHandler to them.

I'd like to see how this goes, and if they change the EULA. My personal opinion is that
- if they change it, they won't just revert it back to the previous version, because they are professionals, and the decisions that led to the changes are products of cognitive reasoning
- if they change it, it will not be because of rambling on a forum thread about how evil they are, but because of reasoning (again, because they are professionals)

To wrap this up, if we are professionals, we should always try to initiate meaningful conversations about our concerns.
Live long and prosper.

 

No If Unity changed the EULA in our back, we should know about it (and don't tell me I should read the big EULA ecah time I make an update, no one read it..).
And Unity should give a public answer.

 

Actually no. I'm in contact with two of UT's staff... but not yet had any meaningful responses. That said, why shouldn't the community be informed about EULA changes that affect everybody?

The CEO of UT raised even *more* questions about the EULA and Unity's business strategy. As I stated back then, his words indicate that products like uLink are using Unity in a way that he'd like to charge extra for.

 

How does it imply anything about products like uLink? uLink is a networking library, not a streaming library.

 

Because one of uLink's key selling points is the ability to run the Unity authored content on the server - to provide an authoritative game with physics. For example, the 1000 player FPS they demo'ed a while back used 8 instances of the Unity Authored Game on a single server IIRC. uLink have been putting a lot of time and effort porting their systems over to Linux.

And as I stated here:

Already David Helgason - CEO of Unity has stated that:
"Most software has limitations and a different pricing model when it comes to being run on servers ... And to add to that, Unity's Linux support allows these companies to save substantial money licensing Windows, so also here the Linux support comes up."
​

Now I've talked to MuchDifferent about this and they've got a solution in the works that would bypass any new restrictions RE Unity Servers - however that solution could still potentially be banned via EULA.

Now for careful viewers, I'm not claiming Unity is *evil* or * scheming* - but I am pointing out some of the implications of their actions and words.

 

I start to think this whole restriction for Unity4+ is part of the new deal with gambling industry...
The whys UT started to think about such restrictions just now makes no sense, but makes perfect sense when you think about these gambling big boys trying to avoid small/localised competitors. Probably they weren't even thinking about OnLive/Gaikai, just want to close the door for those who may want to illegally build gambling machines based on streaming or whatever... Doing so wouldn't really affect UT, but since Unity's technology necessary to do it is open for all its users, that could simply destroy local markets for UT's new 'partners'; So, yeah, I liked UT more before all this gambling stuff.

 

"Running a game server" is not the same as "streaming a game".

In the context of OnLive and similar services, "streaming" means that the game is being run entirely on one computer but played entirely on another, ie: the client sends input to the server, the server updates the game state, renders the scene, appends the image and some audio to an output stream and sends it back to be displayed on the client. In other words, all the client is doing is playing a (streamed) video and sending input packets to the server, which is where the game is actually being processed, rendered, and so on.

That is very different to a multiplayer game, where each client does its own input, rendering, audio, etc., sends its own game state updates to a server, and receives everyone else's game state updates from that server to be included in its own next frame cycle. In this context, the server's role is to implement the game mechanics where multiple client machines need to agree on something, and to keep all client machine game states relatively synchronised.

Yes, in both cases there is a "stream" of information from a server to one or more clients, but it is a very different architecture and a very different use case, and I believe you're getting mixed up between the two.

 

How am I getting confused?

• We have a change in the EULA saying that all streaming is restricted [which is understood as onlive like technologies, but has ambiguous wording].
• We have the CEO of UT saying that any content produced in Unity and runs on a server is something they're looking into restricting.

With regards to uLink, I'm concerned about the precedent of the first, and the stated intent of the second.

 

I just explained how I *think* you're getting confused. You're assuming that a multiplayer game server will be treated like a game streaming server, even though the two are very different.

 

I think a game running on a server will be treated as a game running on a server. UT have made it clear they think that they now have some sort of 'ownership' and the right to exact revenue in this scenario.

Remember, in neither of these scenario's is Unity providing anything new - they're merely restricting functionality that already existed.

 

To me the main one is clearing up any potential ambiguity around "streaming". It seems pretty clear to me that the intention here is solely related to systems where the game is played on one machine and displayed/controlled on another, but that doesn't seem to be clear in general if so many others are concerned about the impact on multiplayer games. So, is that intended to impact multiplayer game servers, or is it solely intended to control usage in streamed gaming environments such as those provided by OnLive and similar services?

It'd also be good if Unity could clarify their position on the latter sooner rather than later. The concern that Unity is holding all of the cards should one of our games go large and attract interest from an OnLive-style service is a perfectly reasonable one. While I personally don't expect Unity to be unreasonable, the situation in general would still earn a mention as "high risk" in any project or opportunity planning I were to do, simply because it's such a big unknown at this stage. This isn't a short term problem for me, though, and I'm sure it's on your radar to be addressed anyway.

 

Strange... I though there is a LOT of new features in Unity 4; didn't know I could build for Linux, use Mecanim, have easy realtime shadows on mobile and etc already on Unity 3.
UT, money back please?

 

But can you not see that there are big differences between the two scenarios I presented? And can you not see that both the license and David Helgason's comments seem very much to be about the first and not the second?

And he's perfectly right that software licensing for software run on servers (ie: 'in the cloud') are handled, licensed and priced very differently to software licensed to be run directly on client machines. Think Google Docs as opposed to Microsoft Office, or BitBucket as opposed to Stash, or Jira hosted as opposed to Jira standalone. Last I saw nobody was upset over the restrictions and different licensing for one as opposed to the other.

 

And which one of those enabled streaming games? Which one of those enabled embedded systems? Which one of those...

Please keep in context - Unity4 has improvements over Unity3 and they charge for it.

Food for thought - where in the EULA does Unity prevent me from publishing to iOS even if I do not have an iOS license? Please think before responding.

 

No. I can see how the license is limited to streaming - I've always been very clear on that. However when looking at David's comments he talks far more generally than just streaming IMO.

Completely correct.

And when Unity want to license their software on a cloud/streaming platform I'll be giving them my thumbs up. However, that's not what's at issue here. What's happening here is Unity is trying to license *our* content for these platforms. WE are the ones that should bde deciding how to license for these platforms, not UT.

 

I still fail to see where they controlling, or dictating us what content we produce.

 

So you think that if I wanted to have my product installed on 100 'embedded devices'... I don't have to ask UT's permission?

 

Exactly how are they trying to do that?

All they are saying is that some other license will apply to that usage of their software, much like the vendors in each of the three examples I gave. The only difference is that they haven't developed that license yet. But based on prior performance and behaviour I feel it's unlikely that they're suddenly going to turn around and shaft their users with it - not only would it be out of character, it'd be kind of silly.

 

I think you should ask and see what they say before you get upset about it.

A lot of business is about relationship management, not just contract management. Forming a positive relationship in the first place is likely to get you on a much better footing in the long run than getting upset about perceived issues with the license.

 

Because they are not apply these restrictions to their software, but to our:

You may not directly or indirectly distribute interactive Licensee Content...
You may not directly or indirectly distribute Licensee Content...
You may not distribute or publish any Licensee Content...

This is UT trying to control *our* product, not UT trying to restricting the license of their software [which, fyi, is the editor].

So... Unity restricting our rights of our content in a way that they've not done before is entirely in character and we shouldn't be concerned?

 

That are two completely different things. You still can produce what ever you want. UT's EULA applies when you want to install your product on a lots of embedded devices, which is (a) understandable from a business point of view and (b) does not affect the majority of Unity devs.

 

Firstly that's purely incorrect. UT have that gambling clause which for better or worse prevents you from distributing gambling content regardless of how you install it baring a new license. They are controlling both the content you produce and how you distribute it.

Secondly, the embedded clause as stands *could* affect virtually every developer - unless you specifically remove the rights of all your customers to use your content on an 'embedded device'.

 

That doesn't answer the question. That's what you think they're restricting, I asked how exactly they are doing that.

Sorry, but that bolded bit simply isn't true - their product is not just the Editor. It's also a bunch of other things, such as the runtime that our content executes within, the framework/API in which we write our scripts, the environment and structures in which we create our interactive scenes, and so on and so forth.

You keep throwing the word "restricting" around, but how do you know they're restricting it? All we know for sure is that it will be covered by a license agreement which is yet to be written. And again, I call back to my examples of cloud vs. standalone versions of various pieces of software - each of them are covered by different licenses depending on the version in use, each of which have their own set of "restrictions" relevant to the software and the context in which it is used.

Where does the assumption that Unity will behave radically differently to these examples and to the detriment of their user base come from?

To put this into context, these are license additons which we have been made aware of in large, plain English text at the start of the agreement (so it was never hidden from us), which staff have been more than willing to discuss and elicit feedback on in public, who has set out to - and largely succeeded in - making game development more accessible. Why would they suddenly turn around on all of that now?

 

Where does that come from? I'm pretty sure David (or one of the other staff) made it clear that the clause in question applied only if the software was the "primary user interface" for the device. If you're user can install your software then that pretty much rules that out.

 

No, now that is incorrect. It's clear through most of this you basically want them to remove the stuff they have added in the EULA that will not likely affect 99.9% of developer using Unity for whatever reason. The arguments you are using don't match the EULA in a number of cases.

Argument 1: Unity is preventing all developers from producing content for embedded devices.

In brief, why this is false: Generally speaking, if you are developing the primary interface for a device, eg I am not writing a GPS program in Unity to run a GPS device, your fine. Publishing an iPhone game / application is fine. Your not replacing the interface.

You may not directly or indirectly distribute Licensee Content installed on more than 50 electronic devices or systems if such Licensee Content provides the user interface or primary functionality of such electronic device or system without a separate license from Unity.

Doesn't mean you can't do it, just means you have to talk to them about it. Exactly the same way as an XBox license works. It doesn't sop you for developing for Windows Mobile devices (slates etc), only if you are trying to use Unity to replace Windows Mobile on a device.

Argument 2: Unity's gambling clause prevents me from distributing my own content now

For starters, this only applies if you are writing an application that falls under "Gambling Activities" which they clarify:

“Gambling Activities” means any gambling product or service offered in any market or application that is regulated by any local, state or national authority and requires a gambling license.

If your application requires a gambling license, which for the most part are expensive and have heaps of legislation around the appropriate use and reporting of transactions, you are going to need to provide a lot of detail around the inner workings of whatever software you are using. UT will need to provide this to meet legislative requirements. This would affect the 0.001% of developers that actually have a gambling license anyway, with or without the EULA, and the developers would need to get UT to provide the information so putting it in the EULA should flag the issue BEFORE a developer spends resources on an application. UT potentially saving me time and resources ensuring I have met all requirements before publishing my 3D sports betting application ?!? How "evil". It would be interesting to see how many developers actually have a gambling license.

Argument 3: Unity's streaming and cloud gaming service clause prevents me from distributing my own content or running multi-player server games

The actual wording of the EULA is:

You may not directly or indirectly distribute interactive Licensee Content by means of streaming or broadcasting such Licensee Content that is primarily executed on a server and transmitted over the Internet or other network to end user devices without a separate license from Unity. 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.

IE If the user has a version of the Unity client to Interact with your application your fine. This effectively means the following cases are also fine:

- A user running the Web Player plugin version of your software to play it
- You run a headless server to control a multiplayer game. The user opens the local game application connects to the server and plays. The user is still interacting with your content by using the required Unity application
- You stream gameplay of users playing your game to the internet through Twitch TV or similar service. Again, this is fine as they are not interacting with your content.
- A user connects to their virtual PC that is running "in the cloud" with the Unity client and your content installed and interacts with your content. Again fine as you are effectively running the content on an end user device (cloud based VM) from another end user device.

The only case it affects if you somehow set up an interactive application outside of unity that accepts inputs from the user which then sends it to a server somewhere for the Unity program to process and stream the video and audio result back to you. Again, it would be interesting to see if any developer is pushing for a case where they are not installing the web client, Phone app, Windows App, OSX App or Linux Application for the client to access your content.

When you buy Unity3D, it is made (I though anyway) very clear that you are publishing the client to Windows/OSX/Web/Linux and that Unity3D would let you publish to iOS / Android if you paid a nominal amount for a separate license. They would also let you publish to XBox if you contact them. No where have I ever seen them every say they let you publish to embedded devices or to some funky cloud platform, so what is it again are they taking away from you ?!?!? From what I have seen they are effectively saying through the EULA and their store / site "We allow you to publish to Windows/OSX/Web/Linux through the basic software, to iOS/Android through additional licenses, and to XBox/Embedded Devices/Cloud Streaming Services if you talk to us". From the way your banging on it's like UT have charged you for software, come and kicked your dog and told you you can't publish anything.

 

I'm not sure what you're looking for anymore, could you elaborate?

I should clarify - we've always licensed the 'editor product' - you know, thats the software you download off of Unity. Beyond that, Unity have never before restricted what we do with the produced content*, to use an similar set-up when one uses photoshop one owns the finished product - even if that product might contain some proprietary information [e.g. the psd format]. Photoshop [to my knowledge anyway] have never said that you couldn't use those images for gambling, or distribute them via the internet.

More importantly than any other product, this is the relationship we've always had with Unity. Again I'll ask:

Food for thought - where in the EULA does Unity prevent me from publishing to iOS even if I do not have an iOS license? Please read the EULA before responding.

*barring minor technicalities like reverse engineering or displaying trademarks.

Because the EULA restricts it. It's really as simple as that... what more do you want?

From their actions to date. Feel free to think otherwise, but I'd be doing my interests and my clients interests if I was to turn a blind eye and just *assume* everything is going to be fine and dandy.

I'm sorry, making fundamental changes to a product/service and then saying 'but it was in the EULA' does not count as properly informing your market. If you disagree, go and ask 10 random users and ask 'em if they new about the changes.

Nope. I suggest you reread the EULA, reread what David had to say, and reread the various scenario's both I and others have come up with that violate the EULA.

 

From the EULA, second paragraph says:

If you are accepting the terms of this Agreement on behalf of a Legal Entity for use of Unity Free

meaning you are accepting the EULA to use the Free version of Unity as detailed in the definitions:

“Unity Free” means the full featured version of the Unity software.

And where the restrictions for free and basic add-on's are clearly defined in the relevant sections with the definitions of the Add-on's:

“Unity Basic Add-On Products” means the reduced feature versions of the add-on Software products such as those for the iOS, Android and Flash platforms that contain less functionality than the “Pro” versions.

“Unity Pro Add-On Products” means the full featured versions of the add-on Software products such as those for the iOS, Android and Flash platforms.

 

For half of that I'll just refer to crispie's post above your own. As for the rest, I really don't feel like going around in circles.

 

Okay, let's go though them.

False. The EULA does not say you have to 'replace the interface'. The EULA says:

...if such Licensee Content provides the user interface or primary functionality...

Now, what is the primary functionality? Hint - it depends entirely what it done with it. As I've said earlier, I can build systems based on Android, iOS, Windows, Mac etc. that all have plenty of non-Unity functionality UI, but if devices are set up to be used primarily for the functionality within Unity authored content then I've fallen foul of the EULA. And it's not just be with this interpretation:

Examples include "...the game for a slot machine..." - David Helgason.

Which is the concern I'm bringing up in this thread...

Evidence? This question has been asked repeatedly by multiple people but the answer is not forthcoming.

Exactly. The problem is when I signed up to be a dev on Unity I was under the impression that Unity licensed the use of some tools services and that was it. Now the assumption is Unity can at any time restrict any content. So suddenly I've got a huge investment of time learning developing applications in Unity that can at any time be held hostage. Furthermore I now have to explain to my clients that there are considerable future risks to their applications...

Sure, they may be able to do this completely legally - doesn't mean we should be happy about it though.

When did I say it prevented you from running multi-player servers? Please don't misrepresent my arguments.

After that exhaustive analysis... where do you actually refute my argument?

And yet now Unity is saying that you may not be able to run your content on these above platforms.

That's great. Since I've never been explicitly licensed to run 'embedded devices' Unity should be allowed to take that away. While we are at it, where does Unity explicitly allow us to publish to the App store? To Steam? To any other distribution method?

Actually that's wrong, Unity never gave you permission to publish to those platforms. [Hint: Read the EULA].

 

Exactly.

Now answer my question. Where does that prohibit or allow you to publish [or more accurately run] your content on the iOS platform. Read what you quoted carefully.

 

@npsf3000 Could you please explain what your concerns are with the new EULA agreements? I read the EULA and it doesn't sound so bad.

 

The most succinct answer is my first one: http://forum.unity3d.com/threads/16...Restrictions?p=1105980&viewfull=1#post1105980

I've explained these basic concerns in more detail several times - but the essence is basically the same as that post.

If you have any more questions I'll be happy to answer [I think I've gotten a new angle to explain it].