Epic and Improbable are taking advantage of Unity with the SpatialOS debacle, seems a little planned
As an update to the ongoing saga between Improbable and Unity in regards to SpatialOS, Epic Games have now jumped in to take advantage of it. To be clear, I don't consider myself biased in any way towards any game engine, especially as I am not a game developer.
As a quick overview of what happened:
- Improbable put out a blog post, claiming Unity overnight blocked SpatialOS and made Unity out to be a real bad company. Improbable then open source their Unity GDK.
- Unity made their own response, mentioning that they told Improbable a year ago about the issues. Let's be real here, revoking the Unity licenses of SpatialOS wouldn't have been a quickly-made decision. Unity have also mentioned repeatedly now about making their TOS (terms of service) a lot clearer.
- Epic Games and Improbable team up to help developers switch game engines.
To assist developers who are left in limbo by the new engine and service incompatibilities that were introduced today, Epic Games and Improbable are together establishing a US $25,000,000 combined fund to help developers transition to more open engines, services, and ecosystems. This funding will come from a variety of sources including Unreal Dev Grants, Improbable developer assistance funds, and Epic Games store funding.
See the full Epic Games blog post here.
I can't help this feeling that Improbable and Epic Games somehow planned this, it feels a little off. To secure a partnership with Epic for rather a lot of money and so quickly, feels like a pretty big PR stunt. Frankly, I feel bad for the folks at Unity as it seems like they've been played here.
Unity does have a lot of issues (especially often on Linux) but this whole situation feels like a made-up farce to make Unity out to be worse than it is. Their terms of service have been pretty poor though, Unity certainly aren't angels and haven't helped themselves.
Again though, this only highlights some of the dangers of using proprietary game engines for your projects. I don't consider myself a zealot in any way towards absolutely preferring open source game engines, especially when closed source alternatives can do a lot of things better, but it should be ringing some alarms bells for developers as a reminder of how they're not really in control.
Article taken from GamingOnLinux.com.
Some you may have missed, popular articles from the last month:
The comments on this article are closed.
I wish I understood more about developing. For now I'm just gonna hate the lot of them, call them all greedy, manipulating goo-balls of avarice, and go play SuperTuxKart.
Last edited by Nanobang on 12 January 2019 at 1:29 pm UTC
Last edited by Nanobang on 12 January 2019 at 1:29 pm UTC
1 Likes, Who?
Quoting: damagQuotefund to help developers transition to more open engines, services, and ecosystems.That's kind of deceitful. Unreal Engine is "source available" proprietary software and Epic could change the terms any time they'd like, just like Unity did. Then again didn't Tim Sweeney also call MS Windows an open ecosystem and then start complaining when he realized it wasn't?
Actually, he just redefined (in his head) what an "open system" is meant to mean. I try to be respectful, always, but I have no time for that guy.
1 Likes, Who?
The IT industry has always been like this. Every participant looks to create a business model that favours themselves, while exploiting the work of others.
When you have a major change in the competitive landscape, such as SaaS, streaming to a thin client, you can expect companies to jockey for positions.
I doubt that many GOL readers will be thrilled with the idea that this is how games will be provided in future, but it almost certainly will be, at least for the companies creating AAA games.
There are upsides to this model:
- everything will be available for Linux.
- DRM becomes meaningless.
- you don't need to spend on constant hardware upgrades.
But, of course, the downside is you then need a subscription/pay as you go/freemium revenue model even for single player games.
It will be interesting to see if any of the big developers stay out of this particular rat-hole, but the frantic activity around developer Web properties, portals and stores suggests not.
When you have a major change in the competitive landscape, such as SaaS, streaming to a thin client, you can expect companies to jockey for positions.
I doubt that many GOL readers will be thrilled with the idea that this is how games will be provided in future, but it almost certainly will be, at least for the companies creating AAA games.
There are upsides to this model:
- everything will be available for Linux.
- DRM becomes meaningless.
- you don't need to spend on constant hardware upgrades.
But, of course, the downside is you then need a subscription/pay as you go/freemium revenue model even for single player games.
It will be interesting to see if any of the big developers stay out of this particular rat-hole, but the frantic activity around developer Web properties, portals and stores suggests not.
0 Likes
salamanderrake Jan 12, 2019
Quoting: ageresSo, Epic Games added SpatialOS to this list: https://twitter.com/flibitijibibo/status/1079575301485723648
Linux did it first. Like the 100s of distros didn't cause that issue, the difference between all of those platforms and Linux, is that they are stable and the developers know what they are working with. When we as a Linux community decide to stop factoring the Linux desktop then maybe developers would jump on the Linux bandwagon.
Quoting: cRaZy-bisCuiTWhats the point? Unity fools their customers with their new licenses. Now someone takes advantage of that... What's the problem?
Maybe I just don't get it because my English sucks...!?
Thats exactly what happened, one company made a grave mistake, another will come in and swoop up as many devs as they can. Epic's actually really friendly with developers, and they would be the same with Linux developers if there were any. But there are none, there are individuals in companies who developer FOR Linux, but as Epic sees it, not ON Linux. I was hoping the community would get their heads out of their whiny asses and jump on the UE4 but everyone is still butt hurt over Unreal 3, and the engine isn't infected with the GPL license.
0 Likes
Quoting: x_wingBy the way, I don't think that an open source engine would have make any difference with the current license situation. From my point of view, even if Unity was open source they could have block the SpatialOS as they did with their license modification.This is the kind of problem that accidental and deliberate blurring of what "open source" is (not to mention Free Software) lead to. Half the people on a Linux site don't know what it is or what it's for.
By definition, an open source engine could not have "the current license situation" because whether something is open source is determined by whether the license gives you rights that don't allow this kind of situation to happen. It's about freedom, not just being able to look at code.
0 Likes
Quoting: GuestYou don't to understand a couple of things about GNU/Linux. First, is that it's truly open, and no forcing one way on everyone. One way might end being used, but it's not forced - don't like it, pick another distro.When I think about games of all things having problems . . . you could bundle all the libraries you need that could remotely plausibly vary meaningfully between distros, and it wouldn't take up as much space as the file for one decent-sized cutscene. So what on earth is the big deal?
But, the second thing to understand is that despite all the distros, it's actually kind of simple to bundle a game to run on the vast, vast, majority...if not all of them.
0 Likes
Quoting: Purple Library GuyBy definition, an open source engine could not have "the current license situation" because whether something is open source is determined by whether the license gives you rights that don't allow this kind of situation to happen. It's about freedom, not just being able to look at code.
It's about freedom, but you can add commercial limitations. Just like Mysql license does.
0 Likes
Quoting: x_wingMy understanding of the MySQL situation is, it's dual licensed. It's available under the GPL, or if you want to do something the GPL does not allow (like, mainly, embed it in a closed source thing and then distribute that thing), you can buy it under a commercial license which is not open source. So there is not one open source license which enforces weird commercial-license-type shenanigans. There is an open source license which works like open source, and there is a commercial license which does not.Quoting: Purple Library GuyBy definition, an open source engine could not have "the current license situation" because whether something is open source is determined by whether the license gives you rights that don't allow this kind of situation to happen. It's about freedom, not just being able to look at code.
It's about freedom, but you can add commercial limitations. Just like Mysql license does.
0 Likes
Quoting: Purple Library GuyQuoting: x_wingMy understanding of the MySQL situation is, it's dual licensed. It's available under the GPL, or if you want to do something the GPL does not allow (like, mainly, embed it in a closed source thing and then distribute that thing), you can buy it under a commercial license which is not open source. So there is not one open source license which enforces weird commercial-license-type shenanigans. There is an open source license which works like open source, and there is a commercial license which does not.Quoting: Purple Library GuyBy definition, an open source engine could not have "the current license situation" because whether something is open source is determined by whether the license gives you rights that don't allow this kind of situation to happen. It's about freedom, not just being able to look at code.
It's about freedom, but you can add commercial limitations. Just like Mysql license does.
That's my point. You can be open source (because your code product is freely available) but you can put limitations on commercial products that were based on your work.
0 Likes
Quoting: x_wingWe're not as far apart as I initially feared, but no. The dividing line is not of commercial or non-commercial use--not for the GPL and, as I recall, not within the open source definition. You can do anything with a commercial product that you can do with one that isn't; if you define your license such that people have to do something differently if they're going to make money from it, that's not open source. It's a matter of redistribution and whether you are granting the same rights as were granted to you. People selling commercial products often happen to want to close down access to code or ability to make changes or further redistribute.Quoting: Purple Library GuyQuoting: x_wingMy understanding of the MySQL situation is, it's dual licensed. It's available under the GPL, or if you want to do something the GPL does not allow (like, mainly, embed it in a closed source thing and then distribute that thing), you can buy it under a commercial license which is not open source. So there is not one open source license which enforces weird commercial-license-type shenanigans. There is an open source license which works like open source, and there is a commercial license which does not.Quoting: Purple Library GuyBy definition, an open source engine could not have "the current license situation" because whether something is open source is determined by whether the license gives you rights that don't allow this kind of situation to happen. It's about freedom, not just being able to look at code.
It's about freedom, but you can add commercial limitations. Just like Mysql license does.
That's my point. You can be open source (because your code product is freely available) but you can put limitations on commercial products that were based on your work.
True, people not selling commercial products are less likely to mind abiding by copyleft terms. But I could have a piece of software which I intended to redistribute for free, but without the code, or without the right to make changes or further redistribute it. If I wanted to embed MySQL in that software, I would not be able to use the GPL. I would have to buy the software from the copyright holder under a different, say "commercial" license, even though my software was not commercial. But I'd be insane to not just abide by the GPL instead.
0 Likes
Patreon
PayPal
See more from me