Unity 4 New EULA Restrictions

Yep. It was an IT class and the IT teacher needed to install software... so he did. Not to say there isn't a lot of needless bureaucracy that hindered things - but sometimes there are 'gaps' in idiocy if one knows the system.

Another thing to note was that the Unity web-player installed without a hitch in that environment... so the story could have been exactly the same but without a 'installation' they would have been visiting a webpage [hosted on the web or locally or intranet] - which would be applicable for any department without special skillz.

Fundamentally this is the mistake UT make - they see one side but ignored the vast quantities of alternatives. As a developer I pride myself on attempting to see as many work-arounds as possible - 'out of the box' thinking.

 

Because Ureal 3 has very clear terms. No royalites until 50K is passed.

http://arstechnica.com/gaming/2011/02/no-royalties-on-unreal-development-kit-until-5000-in-sales/

So if I develop for embedded devices, which I do as a contract fee (which is usually much lesser than 50k), I don't have the restriction of 50 deployments. And I don't have to pay for engine license, unlike Unity which costs $6500 (all pro) per seat, which I have to upgrade every 2 years.

 

UDK licensing is not the same as direct UE3 licensing, and Unreal has been around a lot longer than UDK.

 

I'd refer you to my question:

Linux and Windows are both operating systems... but that doesn't mean that they share the same licensing logic nor that people would be happy to swap between licenses.

 

I doubt that UDK is an option for the people who complain here (freelancing programmers working for bigger companies). Which brings up an interesting question.
Are there any acceptable alternatives to Unity? Torque, Shiva, C4, BGE? Some of these have nice features, even better than Unity. But as a whole package, Unity is most balanced and easy to use. At least from my artist point of view.

 

Fully half the threads in the "Multiplayer Networking" forum seem to violate the letter of the Streaming Clause. It's hard to think they are all expected to spontaneously email UT for permission to continue.

Indeed, far from being warned or deleted, threads are actively encouraged.

So if UT were not fixing the Streaming Clause, they would be actively encouraging teams to violate the EULA only to surprise them with an extra undisclosed charge when their product ships.

I am absolutely certain this is _not_ their intent and that they are fixing the EULA.

 

Can we get some Feedback Unity?

How are you progressing on this issue?

Can you provide any clarity to any of the issues raised at this point in time?

Is there a rough ETA on when we can get this resolved?

 

When one of the Unity developers has to answer for legal, you know something's not right.

 

I just realized something.

Unity and pretty much any and all content creation applications are probably going to have to put in an 'anti-streaming clause'.

This isn't to prevent you from putting content you created onto OnLive, but RATHER it is to prevent some company from buying any given content creation app, then streaming that app to other end users to allow them to create things. If you bought Unity, then put it on a server, and then set up a streaming service for people to remotely use Unity on your server for some subscription fee, well I think thats just about 1 step away from commercial piracy.

If this is what the Unity Anti-Stream clause is supposed to be defining, and I hope it is, then I think it's pretty obvious such a clause will become standard on everything.

BUT Unity does define 'Licensee Content' as “games, applications, software or other content that you develop with the Software", Licensee content being the thing you can't stream.

So I hope there use of the word "Licensee Content" was wrong, and the streaming clause applies to the actual Unity editor.

 

Unless there's some bizarre legal loophole no one's discovered yet, Unity and most apps already have that covered. Unity's license specifically says it's for one user only; you can't share it between two people whether they're physically sharing the same computer or streaming it.

It doesn't; they've already specifically said it's because they want to make money from streaming game sales and are worried that other game engines (Unreal for example) will find out a way to cash in on the streaming revolution, so they're defensively lawyering up early to make sure they can compete in the streaming game marketplace somehow. The problem is that none of these other game engines have done anything like that yet; I don't think anyone is going to make money just by arbitrarily banning certain methods of sales. If a game engine company wants to cash in on streaming, they should be making an engine that is designed to run streamed games.

 

That's good to know; thanks for giving us an update, Kaspar.

 

I can't imagine the time of year helps, either. Many people will have their end of year crunch or be on holidays.

 

Anyone who creates a Game needs to write an 'End-user license agreement', so reading this thread is useful. It demonstrates the pitfalls of placing restrictions on software.

 

This company has significantly more developers than legal people.

The legal people can't come to the phone right now, they're juggling legalese.

As described quite a few times already in this thread, we're not trying to cheat or ruin anyone. What we are trying to do is to continue to build and maintain a healthy company which can continue to invest in product development feeding into our free and cheap licenses.

Part of this effort went into the EULA changes which have been mentioned once or twice in this thread. As stated a few times earlier, those changes were too open to interpretation.

While we coordinate flying ninjas and legalese, it is our hope that this thread can turn into a constructive source of suggestions for improvements and outlines of previously undiscussed troublesome areas.

Merry christmas on this the 24th page.

 

My main suggestions would be:

- If the "streaming" clause is only meant to stop us from selling on services like OnLive, and not stop all online games in general, change the wording from "broadcasting such Licensee Content that is primarily executed on a server and transmitted over the Internet" to "broadcasting such Licensee Content that is primarily RENDERED on a server and transmitted over the Internet AS A VIDEO STREAM". Or something like that. Being unable to broadcast any content from a server is way too strict.

- Allow some sort of exception for arcade games in the embedded clause.

Of course my real preference would be to remove those sections entirely, and let devs continue to own the rights to their own games like we did with 3.5. The streaming clause is especially annoying in this regard, especially after the explanation we got, which was basically "We think services like OnLive might get popular in the future, so we want to preemptively hold your games for ransom to see how much extra we can charge you before we let you sell there". Instead of seeing new distributors as a way to milk your devs, you could perhaps instead encourage your devs to take advantage of new distributors. If OnLive does become popular, and indie devs see that they can use any game engine except Unity to sell games on it, that's likely to hurt Unity much more than the money you get from any backroom deals with individual devs whose games you're holding hostage would help. Currently, Unity is the only middleware company anywhere that I've heard of who are actively trying to block users from selling games on OnLive. It just seems like a terrible idea, like deciding ten years ago to try and block anyone from selling on Steam because you were trying to figure out how you could charge extra. I don't think anyone today would use any middleware that stopped you from being able to sell on Steam, so if OnLive does become popular like you guys fear, I don't think you have much to gain by being the only middleware that stops its users from selling on OnLive.

 

Makeshiftwings, those ideas are pretty much what I'd like to EULA to be changed to (about streaming and arcade games). Of course it'd be the best if they'd return to previous license, but that rocket ship probably not gonna fly.

 

My suggestion too is to return to the 3.5 EULA, we invested a lot of time and money that was the promise of unity, only to suddenly get restictions placed on us that didnt exist before. This is very unfair. It doesnt help that unity is so secretive about the new licence extensions cost. Tell us how much money these new extensions would be. Currently with no price known you are left with the sour feeling of you doing it on a case by case basis which just leaves you feeling like you will try and take whatever you can get away with.

 

UT staff have given similar suggestions before. The problem is UT staff haven't given us any indication of how they intend to proceed, so everything we say is completely speculative... and oddly enough UT staff find some of our speculations troubling. Which is odd, given that these speculations are wide ranging:

We've speculated that UT will add more restrictions. We've speculated that UT will remove some/all restrictions. We've speculated that UT will narrow the definitions of the restrictions. The only possibility I can think that we haven't speculated is that UT will decide to widen the restrictions.

At the end of the day, the most constructive opinion was the initial opinion - get rid of the EULA restrictions as a whole - with the possible exception of gambling if you can prove a real and significant legal risk. If you want even more constructive opinion it is this:

Communicate with your users.

UT have hundreds of staff... yet I see so few of them actively posting in the forums. At the end of the day, if you want to make more money one of the easiest things to do is to ask us what we want to buy.

 

Shiva3D is worth a look... well done UT! You are opening my mind.

 

2 weeks and still pending.
UT is fast growing but should realize there are competitors engines out there, some way cheaper, and "talk to us" eulas will benefit them.

I can't start a 6 months+ project without knowing if I need a 1$ or a 1 billion$ add-on to sell the application to a client or publish it.

Free lancers and small studios have to provide clients costs estimate before even starting, I won't ask them details on their business to pass it to UT to let them press their "random additional costs" button.

Also since I don't beg to get things, I'm sure someone else would get a better deal and I don't like it at all: clear rules for all thanks.

 

+1 in "Unity is a tool like Photoshop or 3DStudio", they don't ask more money to freelancers if they are working for a big publisher, why UT should?

@David Helgason "Most software has limitations and a different pricing model when it comes to being run on servers"

True, but Unity can't replace Photon server, the OnLive is a terminal, like Citrix Metaframe, to use it you need a normal Windows client license (Unity) and a Citrix Metaframe server license (OnLive)

 

I have been overlooking this thread but suddenly I see that it will affect me in a strange way.

My current contracts involve projects that have to do with historical/arhaeological reconstructions/presentaions.

The customer will install this application on several custom made (windows based) touch screen "devices" where the only application that will run is this app I made. As I understand until now Unity believes that this is an embeded device.

Ok. Let's say that the customer will install the app on more then 50 touch-screen devices. Who will have to contact unity? Me or the customer?

I say it is confusing an unproductive.

 

Well I have a lot of questions and the UT answers could affect the projects scheduled for 2013-14.
So I hope they provide some details soon after Christmas.
Bad timing of the year to discover this, I don't want to halt forward momentum of work.
I am sure UT will come up with a resolution.
Happy Holidays everyone!

 

Yes, with the holiday period here potential Indie developers will be looking at the available Game Engines and if they are serious, a look at the current Unity EULA will quickly help them decide which way to go.

 

I've been working on my own client / server project for the last 3 weeks in pure c#. I've been fiddling around with OpenTK and my own rolled geometry classes as well. Looks like there may be opportunity with using Bullet with C# for the physics Engine but I have not got far enough to start playing around with it.

I'm not saying this is an easy undertaking; however the uncertainty that Unity has inserted into the development pipeline makes it worth the effort.

If Unity's business model is going to change toward the direction that is insinuated by this thread. I'll work slowly toward removing the Unity dependency altogether in time. Rolling my own Engine is looking more and more achievable.

I have to ask the one glaring question in my mind: "Why did Unity develop their own engine in the first place?". Was it to avoid the very same situation we are being put in today? To many constraints will push people away. Requiring people to consult you to see if a project is feasible is bad form.

I will not be playing the "Run your project by us to see if you need additional licensing" game with any vendor. I feel like i'm being put into the situation of providing information to a vendor so that they can creatively find ways of charging more money. If they cannot make a clear definitive EULA that lets me know what I can and cannot do with absolute clarity, then I have to jump off the ship.

My trust in Unity is deteriorating while our questions remain unanswered. These questions are a BIG deal to me. I would think they would be a BIG deal to Unity as these decisions will likely dictate their long term outlook.

I take my customers very seriously and do what i have to do to address their concerns regardless of Holidays or Vacation. I expect the same from my vendors.

My mac OSX installation for 4.0.0b11 included the EULA for 3.5. The Streaming clause was introduced late (looks like an after thought or a response to the negative feedback around the gambling clause). This has been a changing product for the last several months via the EULA changes. All of this has been going on after my purchase of the product. I will not be agreeing to the 4.0 EULA in it's current form. If this is not resolved to my satisfaction I would like to pursue getting my money back. The product I thought I purchased appears to be changing into something else.

I know Unity representatives are offended by the term "Bait and Switch" but how else is this to be perceived?

At the very least the law analysis here: http://lawiki.org/lawwiki/Shrink-wrapped_licence_agreements:_the_UK_legal_position my apply.

This whole mess was handled horribly and is maintaining the same course. The end users are still in limbo. The silence on this matter leaves me deeply concerned.

Unity you had a great product and great customer support. What happened?

 

Well I've been using the holiday and Unity silence on the issue as an opportunity to download and try out Torque3d now that it's open source and see how much effort would be needed to convert my games. From a rendering and cross platform point of view it certainly seems like it could be a candidate. There is even talk of the iTorque going open source too.

 

Again, I'm not a lawyer, so I could be wrong, but I believe what you need to do is include your own EULA in the app your making that says the purchaser is not allowed to install it on any embedded devices if doing so would bring the grand total of embedded devices in the world to over 50. For an app you plan to sell to a lot of people, there's no way for the user to know how many other copies are live in the world, so your EULA would probably just have to say that they can't install it on an embedded device at all. If it was a specific app only for a specific client, you could have the license say they can't install to over 50, and then it's your responsibility not to sell a license to anyone else or to install it on your own. If the purchaser then breaks the terms of your license, Unity will still take you to court, not your client, but now you can counter-sue your client for breaking your own EULA, hopefully to cover damages incurred by you being sued by Unity for breaking their EULA. Of course, this all assumes that you can even convince someone to buy an embedded app after you tell them they have to ensure it is never installed on more than 50 machines.

 

the vision of Unity how many other companies is make money, but now exist better options for the indie game developers.

 

Well, we see how confusing all this can be!

 

I say change streaming clause so it'll say that streamed content can be only accessed by client written in Unity. That should fix the problem. It will be MMO-safe and at the same time will limit OnLive/Gaikai which seems to be UT intention (from what they said in their posts).

 

That's better but still not great... it would mean you can't have any tools built outside of Unity interact with the executable on the server. I think they should just limit it to not being able to stream video rendered by Unity from server directly to client. Phrased so as not to block youtube vids and such.

 

How about "streaming interactive video stream where user can directly control remote Unity application"? It will still lock OnLive and such and would not block YT vids or twitch streams.

 

You say that like blocking OnLive [and other streaming technologies] is a good thing...

 

From UT point of view it is. It's just another "platform", like PS3/X360/Android/etc. They need to secure their revenue stream or they'll go bankrupt. And we wouldn't want it to happen, would we?

 

They don't make revenue off the client now - and the platforms you mention all require work on the UT side. Onlive and others require nothing. Seems like they make revenue by selling us the development environment. I'm assuming the fear here is that this sort of streaming technology might bite into Console license sales. Since it can't conceivably affect mobile sales for the next few years due to lack of data rate, and data plan limits would make it completely unfeasible.

 

But that's flawed, it's only 'another platform' in the sense of direct downloads, steam, origin, physical copies etc. are 'different platforms'. Right now UT are supporting Ouya which is a 'new platform' yet they haven't [yet] created a new license for it.

The truth of the matter is UT have never before restricted what platforms one could publish on - the Android/iOS licenses never granted you the right to publish to those platforms - it merely granted you the right to use some additional tools that made such publishing easier. Should UT develop tools that make streaming easier then they are entitled to license them as they see fit, but restricting existing tools is out of character.

Lastly the argument of money is distraction - nobody here want's UT not to make money. However UT's royalty free model is one of its historical selling points and has worked excellently so far - and from all available evidence the decision to move away from that wasn't particularly well thought out.

 

How do OnLive and Gaikai run there games? can they just run an EXE or other platform Unity supports or is it a different file?

 

Just a .exe I assume, but more importantly read the EULA - it says nothing about generating new output.

 

Well this news is rather disappointing. We are developing StarForge for the PC, and we already purchased the upgrades here for Unity4, but I am a bit hesitant to switch.

After all, my previous title was ported to Onlive in their early days, and I do understand why the EULA has changed from a business perspective. Cloud gaming through the T.V may indeed bleed consoles dry in the coming years, and it is fine for you guys to want an extra revenue stream.

But since you do not offer a turn key solution to port to Onlive or Gaikai, all the cost is then put on the company doing the porting and not on Unity. Hence why the community would deem it as a money grab or the such. But I do think you guys are a fair company and are indeed putting this in the EULA under the intention that you will develop a more turn-key solution for whatever cloud gaming everyone is doing in the next 2-5 years and then charge to license that solution. After all, you should be payed for your R&D.

But I think you should be upfront to the costs as you already are with the Iphone and Android. Considering cloud gaming is going to be such a mainstream effort, and it will include the indie community. I think everyone would be fine if you just put up a cost saying you pay this to get a "cloud" license. If you can't predict the cost of it, then just take it out of the EULA for Unity4 and then re-introduce it when you have a published price.

Otherwise independent developers like ourselves will shy away from Unity4 for future projects. It puts small studios in the position of - "Well, what if everything becomes the cloud and we don't have the money Unity3D requires to port? What happens to our X years of work? We could email Unity3D about the cost right now, but what if they change it after we spent years developing?". These are the Q's that will float in the heads of independent developers.

I believe that a important license without a published cost is a good recipe for fear, stagnation, and may cause the "forward thinking" developers to not choose this engine entirely.

Now I really respect this engine, and the work that has gone in it. And I do feel bad that there is such uncertainty as to what medium will deliver games in the future and where engine and end user play roles in this. It is never easy running a business, especially in uncertain times.

Perhaps you can publish a license in your store now and even if it is grossly under-cost, you can always increase the cost to license for cloud gaming in the future. At least it enables those who want to invest early in the "potential" of cloud gaming to do so and feel their project is future proof and safe, making a better product and a happy developer.

 

Well thought out post.

 

They don't want to charge you for cloud. They want to charge OnLive.

 

Reading the EULA change brought gambling restrictions, this caught my attention.

http://unity3d.com/company/jobs/?jvi=oz3XWfwf,job&title=Field Engineer - Gambling

Coincidence?

 

shhhh npsf3000l is still fighting the argument it doesn't cost them anything more and people shouldn't be forced to go to them

 

Not that it affects me personally but I can imagine this is a turndown for people who had specific ideas. UT seems serious on this matter.

 

and people still seem to not be reading or understanding the counter-point.

Why should someone be forced into having a Unity gambling license if Unity is only used as a front end? There should be no need for any accreditation, source code or anything else from UT in this case, but with the current EULA it no longer matters, you want to make a gambling application, you have to apply for their undisclosed license.

Yet even more telling is if you take the time to read the posted job description there is not one requirement for existing knowledge or experience within the gambling market, not one! Doesn't that strike you as a bit weird or even worrying? If I were to employ someone to write code for a gambling app then i'd be looking for 3-5 years direct experience, precisely because of the restrictions in place.

Even more interesting is that job description is not actually just for gambling, from my reading of it, it covers all three of the aspects being discussed in the EULA.

. Yet most of the job description reads to me as for someone to liaise with clients and help code specific solutions. I have no problem with that, but it just reinforces my opinion that these EULA changes should not be there and instead should be offered as additional optional licensing add-ons. I.e. where you have the option to buy additional Unity support.

A good example of this might have been for embedded systems, if Unity were to support mini-PC's like the Raspberry PI, with a new add-on license for a Linux-ARM distribution. Now I'm unsure the relative power of these devices, but if they could power the type of client project's I do (kiosks, installations) that would definitely be appealing due to the potential drop in cost of hardware required and physical space needed. Although the add-on license cost would be more expensive at first, it would quickly be offset against the hardware savings over several projects.

 

Yeah, this job is probably a RESULT of their new EULA..

 

Um no, they want us to email them, therefore there is a desired agreement between us and them to which OnLive is not a party. But if you were right, I would have no power whatsoever over whether my app could appear on OnLive at any price. That, incredibly, would be even worse.

It does everyone (and UT most of all) a huge disservice to dismiss wsworin comment so casually.

At any rate, the OnLive issue is compartively tivial. While the streaming clause definitely restricts "OnLive", its wording is unworkably ambiguous. Just search these forums for the word "streaming" and see in what percentage the content is "primarily" executed on the server.

Since UT says they are working on it, that means they too know there is a problem.

 

When I read many of their old posts I swear I could remember them mentioning they only want to charge the service providers. Iwon't be going through the thread again to find it though. Maybe someone remembers what they said?

 

Nope, it's been well established that UT now have a team of experienced engineers to help people who seek UT's help with regards to gambling accreditation development. This is not a problem - it's good to see UT taking the initiative and providing services that it customers need.

And? How does this affect my argument in the slightest?

Legal contract > Some idea somebody may have once said.

EULA does not mention charging a service provider. Furthermore charging a service provider is still affecting my royalty free license. Lastly, who's to say that there is a 'service provider' ala Onlive? That's just one example of how streaming can work.

Just for clarification here, why is streaming considered a dangerous console killer... when pretty much every other platform has the theoretical capacity to damage other markets?

Streaming may affect say Xbox360... but not iOS, Android [esp. Ouya], Flash, Web, PC, Mac, Linux, Wii, PS3?

Could you imagine how weird it would be if UT tried to enforce this ideology? You can use the web-player... but not on a flash games site. Mobile licensing costs will be $3000 - split between Android and iOS based on their current marketshare as to avoid assisting one in dominating the other etc.