It is technically open source, yes, but it still rubs me the wrong way. As open-source as the games are, it's still at the end of the day promoting a closed platform that is decidedly non-open...
It is technically open source, yes, but it still rubs me the wrong way. As open-source as the games are, it's still at the end of the day promoting a closed platform that is decidedly non-open source and requires real world money for several important features. They've effectively open-washing; it would not matter to them much in the long run if their OSS games fail. It's window dressing.
Unity has several major issues that are slowly bubbling up. As they are already widely known and adopted within the indie community, they don't really have any incentive to fix them. While many more techy users are well aware of possible alternatives (including real OSS like Godot), the more artisty types on Twitter seem to be largely in the dark - they just use Unity since it's the standard, and their friends use it. As these engines aren't well known, many of them can't develop a userbase to justify using them anyway, creating a Catch-22.
Giving Unity Technlogies free attention and users gives them an incentive to sidestep these problems, by creating a loyal base of contibutors which are shackled to their propietary engine regardless of its continual usability.
I'd say so, yeah. An open source application that uses WinUI is still open source, even if it uses a proprietary GUI framework. And if you want to take it to the extreme, it's virtually impossible...
I'd say so, yeah. An open source application that uses WinUI is still open source, even if it uses a proprietary GUI framework.
And if you want to take it to the extreme, it's virtually impossible to write software that is all open source all the way down the stack with consumer products. At the very least you're going to run into proprietary drivers, propertiary ISCs, proprietary architectures, probably booting from a proprietary BIOS, and so forth.
If the code that is under the purview of the project, in this case the game, is open source, then, while Stallman would disagree, I would say that it's generally agreed it's open source, even if it's tightly integrated with a proprietary engine.
Proprietary drivers etc are all related to the user's hardware in which the user could theoretically at least opt for hardware with open software. None of these games will work without the...
Proprietary drivers etc are all related to the user's hardware in which the user could theoretically at least opt for hardware with open software.
None of these games will work without the proprietary game engine leaving no way for the user to opt out of using proprietary software.
Similarly, I'd argue that a open source windows app that relies on a proprietary windows API is still open source because there's no way you could make a more open source app for that OS. It...
Similarly, I'd argue that a open source windows app that relies on a proprietary windows API is still open source because there's no way you could make a more open source app for that OS. It depends on windows no matter what.
A game that relies on unity is a different matter. You could easily use one of the FOSS engines and have an actual FOSS game.
Now, if unity was to make all their libraries open source and keep the developer tools closed source, I'd change my mind here. As it is though, this has a good amount of "do as I say, not as I do" to it.
By sharing the code and licensing what you can under a permissible license, you make it possible for people to replicate your software in a new engine, which I'd say is the basis for open source...
By sharing the code and licensing what you can under a permissible license, you make it possible for people to replicate your software in a new engine, which I'd say is the basis for open source software, and leads directly into free software.
From there, somebody could potentially liberate it from the proprietary engine. AFAIK (which is very little, honestly), Unity doesn't do anything a very skilled person, or group, couldn't do with the right libraries and enough time for a given game, and it would take less with similar FOSS engines that already exist.
Depending on the engine, you'll get some very tight coupling with the engine though. Sure, you could argue that one could just build a open source reimplementation of unity, but such a thing does...
Depending on the engine, you'll get some very tight coupling with the engine though. Sure, you could argue that one could just build a open source reimplementation of unity, but such a thing does not exist. And just ripping out the unity bits and putting in godot is, from my experience, somewhere between a complete write-off (i.e. porting the game is more costly than scrapping it for parts (assets) and rewriting it from scratch) and a costly affair.
Someone in the comments there raises a good question - Is it open source if the engine is proprietary?
It is technically open source, yes, but it still rubs me the wrong way. As open-source as the games are, it's still at the end of the day promoting a closed platform that is decidedly non-open source and requires real world money for several important features. They've effectively open-washing; it would not matter to them much in the long run if their OSS games fail. It's window dressing.
Unity has several major issues that are slowly bubbling up. As they are already widely known and adopted within the indie community, they don't really have any incentive to fix them. While many more techy users are well aware of possible alternatives (including real OSS like Godot), the more artisty types on Twitter seem to be largely in the dark - they just use Unity since it's the standard, and their friends use it. As these engines aren't well known, many of them can't develop a userbase to justify using them anyway, creating a Catch-22.
Giving Unity Technlogies free attention and users gives them an incentive to sidestep these problems, by creating a loyal base of contibutors which are shackled to their propietary engine regardless of its continual usability.
I'd say so, yeah. An open source application that uses WinUI is still open source, even if it uses a proprietary GUI framework.
And if you want to take it to the extreme, it's virtually impossible to write software that is all open source all the way down the stack with consumer products. At the very least you're going to run into proprietary drivers, propertiary ISCs, proprietary architectures, probably booting from a proprietary BIOS, and so forth.
If the code that is under the purview of the project, in this case the game, is open source, then, while Stallman would disagree, I would say that it's generally agreed it's open source, even if it's tightly integrated with a proprietary engine.
Proprietary drivers etc are all related to the user's hardware in which the user could theoretically at least opt for hardware with open software.
None of these games will work without the proprietary game engine leaving no way for the user to opt out of using proprietary software.
Similarly, I'd argue that a open source windows app that relies on a proprietary windows API is still open source because there's no way you could make a more open source app for that OS. It depends on windows no matter what.
A game that relies on unity is a different matter. You could easily use one of the FOSS engines and have an actual FOSS game.
Now, if unity was to make all their libraries open source and keep the developer tools closed source, I'd change my mind here. As it is though, this has a good amount of "do as I say, not as I do" to it.
By sharing the code and licensing what you can under a permissible license, you make it possible for people to replicate your software in a new engine, which I'd say is the basis for open source software, and leads directly into free software.
From there, somebody could potentially liberate it from the proprietary engine. AFAIK (which is very little, honestly), Unity doesn't do anything a very skilled person, or group, couldn't do with the right libraries and enough time for a given game, and it would take less with similar FOSS engines that already exist.
Depending on the engine, you'll get some very tight coupling with the engine though. Sure, you could argue that one could just build a open source reimplementation of unity, but such a thing does not exist. And just ripping out the unity bits and putting in godot is, from my experience, somewhere between a complete write-off (i.e. porting the game is more costly than scrapping it for parts (assets) and rewriting it from scratch) and a costly affair.