Unity 4 New EULA Restrictions

Unity, /sigh.

 

The only thing UT understands is money . I could see someone steeping up and making one of the various open source engines a bit better . The immediate affect of this would be an embedded manufacturer choosing to NOT use Unity for any projects

 

Unity is one of the few engines that understand indie developers... and actually cares about giving customers a usable product.

 

Just sat down and had a chat with David Helgason, awesome guy!

He's well aware of these issues, and I made sure to recap most of the 'big' issues [e.g. scope, precedence, unintended consequences]. I'd expect to see some sort of response with proposed changes in the next week or two I suspect it'll be based on tightening up the definitions to target very specific markets - which will be an improvement albiet not the repeal I'm hoping for.

With that information introduced - please continue the debate with a focus on ensuring those decisions are
well informed and all avenues are explored!​

For example, I'd prefer UT would ditch the EULA restrictions - potentially losing a little revenue, and make it up by starting community* dialogue on how to make Unity better. I'm going to sleep on it and maybe make a thread tomorrow


*As in forum, UT does a bunch of other work that's to be commended, but I get the feeling it misses out on some obvious stuff.

 

David is a great guy and he loves the community, as we previously stated we are aware of the issues and we are working on it. With David's travelling, Unity's break for the Holidays and the overall complexity of this issue, this is not something that can be handled with a push of a button.

We love our community and have always known the importance of listening to our users, regardless of whether they are Pro or Free. However, we are still a business so actions take time as we still have to go about our daily operations.

 

Yep, spoke with him a week or so before xmas. As you say he's a great guy and I was truly surprised to find a CEO that was willing and able to just have a chat with one of their customers. Its also why I posted a few weeks back that anyone who has a specific issue with the EULA, with specific examples of how it adversely affects them should get in contact with Unity directly or through this thread. The more information they have on how these changes potentially hurt developers, the better the chances of getting this resolved to everyone's benefit.

As you say though, its hard to conceive that UT will repeal the new EULA, but its not impossible, so again the more dev's who can give examples of why the changes negatively effect them the better.


Ideally what I'd love to see next is a dialog with Unity, not them simply coming back and saying 'hey, here are the changes', as that could just lead to repeating the whole thing again. Instead of that perhaps if they had considered several alternatives they could poll the community as to which direction they'd prefer, before making the final decision.

For example I wonder if an 'understanding' that linux would be removed from a near future version of Unity and then charged as an add-on (perhaps on a sliding scale, so it starts off as a nominal fee, rising to that of a standard add-on by Unity 5.0) would be acceptable to the community and UT, if it meant removal of both the the embedded and streaming clause? Perhaps even better, some means of having a linux add-on license that comes into effect specifically for just embedded devices ( terminology to be clarified) or when used when streaming (i.e. allowing devs to still use it for desktop gaming)

That of course is my position, where i'd rather in all three cases of the EULA changes, they be removed and replaced with fair add-on licenses, thus maintaining consistency with other Unity products and licenses as well as keeping it very clear and simple as to everyone's rights of use. Obviously other developers may not share this opinion.

 

It does not make sense to restrict the entire Linux market (which is about as large as the Mac market) so a tiny number consultants can contract to build for embedded devices.

And it makes no sense to effectively kill the Linux market in an attempt to specifically target OnLive.

Just charge those very few people who's job it is to build for embedded devices where the deployment may exceed 50 units or limit it by yearly revenue or let them continue to do it for free. But slashing other parts of the product is the least reasonable thing to do.

 

Well it was just an idea, as the alternative is that we will still end up with something akin to the current restrictions, which for the embedded devices is way to undefined. Undefined to the point where by its actually easy to create a product with Unity and by selling it to 50 different clients (or 5 installs to 10 clients etc), means you exceed the 50 unit limit.

You see thats part of the problem, I don't think there is a single person here who is complaining about the embedded clause that is representing a consultant under contract to build for embedded devices. We are small companies or freelancers developing kiosks and installations, but by the very wording of the EULA we are the ones being affected.

Besides I don't see the difference with linux vs Flash, iOS or Android, if its acceptable to have those as additional add-on licenses, why not linux? Charging for a linux add-on is hardly going to kill the market, it didn't kill any of the others (well maybe Flash, but thats due to a number of issues) and what if it only came into effect with Unity 5.0? That gives dev's plenty of time to adjust and determine if the additional add-on cost is worth it.

Look i'm not saying it would be popular, but it would at least be consistent with Unity's licensing and avoid having sticky EULA issues. Obviously in an ideal world and certainly my starting point would be that Unity simply drop these changes and we go back to the old EULA. However its also clear that UT need to protect their own revenue streams so how can they achieve that? If we just get an amended EULA there is every chance that many of the issues will remain, the lack of clarity, arbitrary limits on installed units, having to contact Unity to check for licensing for every potential client project you have etc.

But fair enough, what alternative would you propose, assuming you have read the counter-points to the EULA changes and seen just how easily they could destroy revenue streams for current developers?

 

You just can't make everyone happy.

Why does the embedded device developers needs to pay additional license if it just a already supported platform that Unity does no extra effort? Say Windows 8 becomes very popular in future, and we have a project only display our app as main interface. That fits into the definition of embedded device , but it is still windows platform. Why the need to limit 50 and pay more?

Remember the old Eula does not have these restrictions.

Up to now, we don't know what Unity is trying to protect. Perhaps clarifying what Unity problem is, we users can help come with a solution.

 

If I understand correctly, there are some small contractors that build Unity apps for kiosks and the Embed Device Clause, worse than just charging extra, adds complete uncertainty. So maybe just put an annual income cap on it or change the number of deployments from 50 to some larger number.

I don't know what UT's goals are with this clause so it is hard to guess what saves the small contractor while helping UT. But if we suppose that UT wants to start a division to create embed software solutions directly for lage customers and does not want, say Diebold, using UT's own technology to compete with them, then an annual income cap might make everyone happy.

Building for Linux is like building for Mac or Windows. It would be inconsistent to charge for one and not the others. And it would make more business sense to charge extra for a Windows build (with its larger well monetizeable market ) than to charge extra for a Linux build. Yet that would obviously be insane.

The irony of charging extra for Linux alone is that if I want to make a shareware app for Ubuntu, I have to pay more to UT (so it will obviously never happen). But if Diebold builds a multi-million dolar medical app runing on a hundred special built windows boxes they would owe UT nothing. And the total extra income for UT from both sources is zero.

 

Unity *does* charge for windows and mac.

If that's your only metric. Linux support may have a higher per customer cost to support, may have greater value to users etc - all of which impact pricing decisions. From the sounds of it UT have been selling the linux build at 5 and 6 figure points until recently - hence the new EULA.

 

I already paid 1500 for windows, 1500 for IOS Pro, 1500 for Android. So u want linux, yes it can be an add on too. I'm fine with that. But this Eula change is like if you build for windows xp if is fine but if windows 7, you are limited to 50 deploys..Unless windows 7 is a different platform and demand extra more work from Unity to support, there's no excuse. I'm still awaiting to hear the valid reason on this change.

 

So your plan is charge Indie developers extra for Linux solely to subsidize unlimited deployments on embedded devices for companies of unlimited size.

And to justify this, there is an Ad Hoc story of Linux being more like iOS than Windows. And that when paying for Unity with its advertised Linux build, you're not actually paying for Linux builds afterall.
Well, good luck with that.

I'm only on this thread waiting for someone to answer Kaspar Daugaard's 3week old post wherein he says:

"Someone higher up needs to clarify this [Streaming Clause]"

 

In which case wouldn't your alternative be to somehow related embedded and streaming licenses to companies that make above a certain value of sales, e.g. $1 million p.a.? Which in itself I would be 'ok'-ish with, but can't see UT going with that, not least because those companies could presumably sub-contract the development to a smaller studio making < $1m and avoid the xtra cost completely. Which is back to part of the issue being that this type of licensing or the use of the EULA creating endless tricky situations, but a simple add-on license would solve.

Don't see it being ad-hoc in any way since Unity have as much as said that some of the changes to the EULA were brought about due (but not exclusively) to the new ability to build for linux and thus deploy on embedded devices or on servers for streaming. In those terms it would seem to make sense to charge for linux as an add-on, but not necessarily for standalone linux builds. Though splitting it like that again goes back to needing a more comprehensive EULA to specify the exact terms of use.


However I think this all goes to show it would be so useful if Unity could enter a dialog with its developers, to explain their thinking and needs and for us to explain ours (at the moment its all one way with us explaining are problems and issues). I don't know if that would be possible or even desired from a business point of view, but its the only real way I can see how we can get through this without some fallout somewhere.

I mean I have to accept UT are here to make money, to support their own business, but on the other hand the current EULA closes down avenues and demands way too much interaction with them for my own business/clients. So finding a middle ground is going to be a challenge. However UT have surprised me in the past, perhaps they'll do so again.

 

An extra Linux add-on fee would solve the issue for a few consultants and companies building more than 50 embedded devices. But it would hurt thousands of other developers. And I can not see how this helps UT or "Democratizes game development".

Is there a ground swell of people who want to give up their Linux license to remove the Embedded Device Clause from the eula?

If so then put up a poll asking:
"Would you give up your Linux license if you could remove the Embedded Device Clause from the eula"

Look, I am on your side but the Linux as add-on idea is going to get an army of people against it and UT would be foolish to agree to it. If you three convince eachother it's your best hope and stop looking for other alternatives then you are not helping yourselves.

If you do not believe me, here is the latest thread in Gossip as I type this. Ask there about trading Linux support for unlimited embeded devices.

 

You underestimate the impact of the EULA though - it impacts *every* developer - through both in immediate terms and in uncertainty about future restrictions.

So it'd be 300,000 developers vs 'thousands' of linux devs

 

You seem to keep missing the point that this doesn't just affect a few consultants or companies, it affects everyone, it affects single freelancers like myself due to the ambiguous and wide-ranging wording of the EULA making pretty much anything I do for kiosks fall under the embedded clauses.

Whilst most of the time these are one off kiosks, some are 5 to 10 systems, though often used on a single matrix of monitors. However sometimes clients come back and want to install more kiosks, throughout their company, or we might re-use projects (i.e. a project is a shell for content), that could easily bump up to more than 50 in total for the lifetime of a project. At that point we're suddenly hit with talking/negotiating with Unity for some unknown license for some unknown cost.

So even though I don't think it was ever UT intention to single out the type of work I do by this EULA, (I think most would agree their target was the type of project and companies that you alluded too in your post), ultimately it does affect me and many others. In fact the only people it wouldn't affect are those making standalone apps for desktop users who regularly quit the application, anything else including games could easily be run 24/7 on a system and thus fall foul of the EULA clause.

As I've said before the ideal solution is to remove the new clauses, however if Unity felt the need to add them in the first place I think this is unlikely, regardless of how sympathetic they might be. If they re-word them, then there is always the danger of falling back into the current situation or wording themselves out of getting any additional revenue. Hence looking at some way to deliver a middle ground utilising the well known/understood and relatively well accepted method of add-on licenses.

That is not what I have suggested. I've suggested bringing in a non-retro-active add-on price for linux in future versions of Unity, perhaps on a sliding scale if UT wanted to bring it in before Unity 5 or even afterwards.

Of course no-one who wants to use linux is going to 'want' to give it up now, but then neither have I said that it should be removed for those producing standalone apps run by users. So if that was part of the deal (i.e end user apps excluded) i'd be surprised if any linux developers would be worried as it simply wouldn't affect them. The only developers who would be affected by linux add-on in this case would be those who are created embedded linux content or using it on servers to providing the streaming content, thus the EXACT people UT were trying to license to in the first place.

This situation effects everyone, not just a few companies and not just for embedding but all three of the new clauses (gambling, streaming, embedding). Many of those linux developers will probably end up breaking the EULA without knowing it if they allow their game onto a service like onlive, ignorant in the knowledge that the EULA had changed for Unity 4.0. Lets see how many of them like the situation when UT starts asking them for additional money for licensing 'streaming' for the game they got onto onlive or face having to take it down.


Edit: BTW I appreciate you are only presenting the alternative view on linux costing, and likewise I can see it not being popular unless it is well thought out so as not to affect those who simply want to release a linux version of their game on Steam or what have you.

However I feel its important to re-stipulate the problems with the EULA and my fear that if UT simply amend the EULA we may end up back were we started. Hence why I am trying to expand the discussion into evaluating other possible solutions, since i'm unsure UT are in a position to do it themselves. By which I mean UT may not be able to instantiate such a discussion on a public forum, but they may still take an interest in what the community comes up with

 

You are not seeing the big picture. This Eula is about future uncertainly of developers. You do not know if future gaming device are going to be on cars, watches, or even Ouya 2, which can be running linux. This new Eula will restrict a lot of us, not just a few consultants of kiosk. Again, the analogy is unity is like visual studio. I have paid unity 1500 to run on the platform (windows), and if I can make it run on my watch, that's my issue. Why must there be an additionbal revenue stream for unity on that?

 

First we need to know what Unity concerns are so we can think better. So far, this is one sided, and they decide the license and put it in 4 without informing us. That's not communication.

 

I'm getting more worried that there's still no reply to any of this. Seriously, fix the streaming clause to be less ambiguous or let us know you're not going to fix it so I can start reverting everything to Unity 3.5.

 

Well its kind of understandable what with xmas and key figures from Unity travelling around alot in the last few weeks. I'd rather they took their time to come up with a good solution than a rushed bad one. Obviously a little more feedback would be nice, but they have replied several times in this thread that it is being actively look into, so i'm not sure what more they could say?

However having said that I would love for them to come back to this thread to discuss their current thoughts/aims/objectives and have a bit of a dialog between themselves and the community.

 

We have been talking directly to people from this thread for some time now.

Rather than parsing out all of the, eh, passion of this thread and hoping we get the jist of peoples core concerns and then shipping EULA changes, which could loop us right back where we started, we figured directly ping-ponging would be more productive.

I'm sorry that things seem eerily quiet around here, but it was clear that asking for a calmer tone wasn't working, so we changed our approach.

Rest assured that things will be changed and we are taking peoples strong opinions into consideration. We would just rather that we only need to change them *once* more.

 

Have you?

Ultimately you listened to a few interest groups [e.g. companies already in large contracts for specialised industries] and then implemented some new rules without community consultation/discussion.

Right now you've listened to a few interest groups [which this time include me], and are presumably about to implement some new rules based on it.

At no time have you decided to actually have a wide-scale consultation or discussion - rather you appear to be hoping that you simple get a better sample size this time. While you complain that asking for a 'calmer tone' didn't work [something I'd disagree with] - that's largely due to your decision participate in a substantive and meaningful way.

So while I fully agree you've decided to change the parameters of your 'sampling' - your approach appears to be roughly the same.

 

May I suggest that, along side the eula, it might help to have a FAQ stating explicitly that authoritative game servers and mmogs are not restricted by the eula. Because if you keep keep the streaming clause, whatever the wording, there will likely be some confusion.

May I also suggest applying skepticism to Linux business advice from parties that do not understand the technology or how it is used.

 

When you guys do make the change will you announce it somehow or at least update this thread? I'm not one of the people in the thread who got a response, so I'm still in the dark. For me personally, I just need to know that the streaming clause will change to allow authoritative servers again. But I'd still like to know the outcome of all the rest of it.

 

You should then fire your lawyers for using too broad terms.

 

What about the embedded device clause?

Was that intended to go after people using Unity to make kiosks for interior displays, retail stores or convention displays? Or people who wanted to turn their unity games into physical arcade boxes to sell?

 

I think it was intended for slot machines. It was tied in with the gambling clause, AFAIK.

 

Isn't gambling clause then enough? If not and if Code_Of_Honour has right, embedded clause should be changed to have only impact on gambling devices (slot machines, video poker, etc.).

Also I think solution may be only few days away.

 

Nope, they were thinking more along the lines of large electronics manufacturers etc.

 

I'm worried about the streaming clause. it seems it could fit many different interpretations.
While we wait, xkcd relevant comic:

 

While it's nice to see action here... and you have helped clarify some of what the restrictions are targeting, the fundamental problems still exist.

• You still restrict streaming, for no technical reason, and it's becoming an increasingly viable platform.
• You still ban 'embedded systems' - and the wording still is vauge enough to cross inadvertently, e.g. home arcade machines.
• You still restrict gambling, though IIRC you've not provided a justification for such.
• Ultimately, the precedent still exists vastly increasing risk of any project that uses Unity.

And while you have brought up the point of these restrictions allowing you to 'reinvest more into Unity'... I can't exactly say that I'm impressed with your investment to date.

Be interesting to see how others view this.

 

Thanks for posting, but I have to say i'm bitterly disappointed. Other than clarification (of my worst fears) and increasing the embedded device limit, nothing has actually changed. Many of my concerns are still relevant.

Its impossible for me to stream Unity content to say mobile devices from say a museum kiosk/installation and allow two way user interaction, without needing to approach Unity and possibly require an undisclosed licensed both in terms and cost.

For embedded device the limit is raised so I 'probably' wont hit it, but i'm still going to have to pass this restriction onto clients to cover my own back and i'm still going to have to contact Unity for every potential project I get that approaches the limit, to 'discover' the license agreement for it. Yet there are still instances where by projects I create may inadvertently end up breaking the EULA.

Gambling - well it never affected me, but there doesn't seem to be any change there either.

The really sad point is that for two of these (streaming and embedded), even if i get a license it would appear that Unity offers nothing extra in return for the cost and pain. I really dislike being forced to obtain these licenses, despite Unity not providing or myself actually needing anything extra from them in these cases. I could understand for example with streaming, if Unity had developed a special build to make use of nVidia's new Geforce Grid, though I would still rather get that via a paid add-on.

So I guess that's it then. Can't see Unity making any more changes, many of us have presented our cases and concerns, most of which has been ignored. Even if Unity offer these licenses for free on a per project basis, the appearance is one of changing the rules, stepping away from the add-on method that has served everyone so well in the past.

 

To be fair, how exactly where you thinking of setting this up? The new EULA now has the clarification: "...over the open Internet...", which should allow you to produce a LAN based system - something I'd suggest doing for bandwidth reasons anyway.

I disagree. Firstly, we should let people respond so UT can gauge the response. Secondly, if UT decide that this is satisfactory then it's up to us to decide what steps are to take next. For example, we could try additional discussions, seek legal assistance [how much of this is enforceable?] and/or create a competitor.

 

Doing LAN would defeat the purpose

It would be WLAN and in terms of bandwidth I was thinking of reducing the framerate. This wouldn't be for a fast paced game or even fast paced interactive, it could even be very slow ( even 1 fps) updates. We all ready have one-way communication from a browser on a mobile device to a Unity kiosk, this would just be the next step. Being able to stream the Unity content to a visitors mobile device would mean they no longer have to stand infront of a monitor.

Whilst i'm happy to continue discussions, I just don't see any other changes happening? What's left to discuss? I'll add my voice should I feel or see the need, but just can't see anything new coming up.

As for the rest I have no interested in seeking legal avenues or threatening switching to competitors, what happens will happen. I'm sure i'll continue to happily use Unity for many years to come for standalones, web, iOS and Android, but will have to consider very carefully any investment into streaming or embedded solutions that clients ask for. Though I will be checking any new EULA's much more rigorously and have a very real concern about the future based on these changes.

 

Nope, LAN is just 'local area network' and can consist of many components such as wireless and wires

Give it a day or two, let's see what comes up.

 

This new Eula is the same, only raising the limit from 50 devices to 1000 devices. What additional work does Unity have to do for my app to run on 1000 devices vs 50? If there is real work, then I would gladly pay more for an addon or extra. If there isn't, we go back to the Photoshop/Visual Studio comparison again.

For streaming/broadcast, I've in discussion to develop games for TV stations, which will broadcast the games live while audience is playing. I use Windows XP and deploy. So Unity wants me to contact them? Why? Microsoft does not do that where I deploy my compiled .exe or even where I install Win XP.

I hate to do this, maybe its time to revive torque

http://www.garagegames.com/community/blogs/view/22107

 

This is getting ridiculous. This "clarafication" has done nothing at all.

 

That won’t be a problem because the viewer of the stream is not returning any input to the game.

Be assured: if you offer a virtualization Windows service, MS does want you to contact them about every single license.

 

They never said they changed their mind on their changes, only thing they said from the start was that they agree the wording was too vague in some areas, but they very clearly stuck to their guns on the goal of the clauses.

I think it would be a bit hard for anyone to deploy more than 1000 home arcade devices. Heck, even if Arcades are covered, you can make one insanely large Arcade business and not have enough floor space to host more than 1000 arcades (unless you become an international franchise.)

 

The clarification gets rid of my concerns about the embedded clause and how it might affect kiosk or home arcade game makers. Theres more changed than just a device limit increase.

"This restriction does not prevent you from distributing Licensee Content pre-installed on personal computers and consumer electronic devices such as mobile phones, tablets, televisions or set top boxes as long as such Licensee Content does not provide the user interface or primary functionality of such device."

Basically that means it is ok to sell a box, or device, with your Unity game on it, just as long as the end user has to double click 'Launch Game' shortcut on the desktop, or type something into the console.

Which is pretty much what was going to be happening anyways.

So I don't think it affects kiosks or home arcade boxes.

 

This is very discouraging. I think this is where I draw the line. Imagine your balls are squeezed by someone. That's how I feel. Basically the new term imposes on our creative freedom. Sure, you can create anything you want, but you can't put it there, or there or there. Oh, over there, that's a no no. Come talk to us first and see where we permit you to put your games.
I hate the fact that one company or platform controls the future of my creations. I think 2013 will be the year that I look for and support an alternative. It's not really freedom when one party controls everything.

I'll be looking for alternatives platforms for my future projects. I'm done with Unity as my main platform. Torque is looking very attractive since it's MIT Open Source license now.

" Democratize game development and enable everyone to create rich interactive 3D content where we see fit"

"Don't sale me bullshit and tell me it's chocolate. I'm not buying it. " not sure where I heard this one.

Just my 2 cents.

 

I just wonder, in the streaming clause, who will have to deal with the streaming license and how?

Will the game developer themselves have to contact Unity if he wishes to give his game to a streaming service? Or will the streaming service themselves have to contact Unity upon reception of any Unity title?

Will the streaming service have to pay extra for each Unity title or will it just be like a single license that permits a service to stream as many titles as they want? I worry if the streaming service has to pay extra for each Unity title then such services may become more discriminatory to Unity titles.

 

Here is my guess: If you make a game, you sell it, and without any change OnLive starts buying licenses from you and installing them on their virtual machines... that's not your responsability (cant be!)

However, should you do a special edition to accomodate APIs from said service, or to work in a special way for that service, then it is your project and you are the one that needs to comunicate with Unity.

The thing here is, with case A, how would OnLive realize they are dealing with a Unity game and not a run-off-the-mill game?

 

I'm thinking now that the addition of the streaming clause might have something to do with Unity's philosophy of "another $1500 per platform". And Unity is viewing any potential new streaming service as a new platform, and should thus need an additional license for that.

I mean lets say there becomes some new streaming game service available on tablets. Then everyone just exports their title to PC using unity free and then all the games stream to your iPad or Android device completely bypassing Unity's iOS and Android licensing? Then further than that, Unity's old EULA is somewhat ambiguous as to what power Unity could hold over such a system. Given that one would no longer be selling games as executables but, just streaming video of other executables, maybe people could legally avoid streaming the Unity Splash screen on the Free version. There is no prior stipulation on the streaming of Unity games, which means that people could end up doing whatever with Unity content, breaking limitations that were imposed by the previous platform licenses.

Given that, what Unity has done isn't exactly out of line.

I just wish it was clearly stated who, what, where, when, why in specific terms ideally with examples. Broad all encompassing legal terminology is far too intimidating to small solo developers that could never hire a lawyer to deal with any issues that arise.

 

Agreed, Unity are in danger of driving people away. They seem to be entrenched in the complexities of large Company paranoid craziness. Where I live there is a saying.. 'keep it simple stupid'. I guess this is a lesson of what happens when a small business becomes a big business.

 

Who said anyone would deploy 1000+ home arcade machines?

I'm talking about ~1000 fans of the game each putting together a home arcade for the fun of it.

Unless every single UT project you release specifically bans Embedded Devices via EULA, you could unknowingly break the EULA at any moment in time.

Nope, IIRC that was there before the change.

Depends on your definition of 'Primary Functionality'.

It does and always has targeted kiosks and arcades - read through earlier clarifications to read UT's intent. The only thing they've tried to change is the scale of operation needed before contacting them.

 

I'm pretty sure that doesn't fall under the definition of an "embedded device."