Linked by boldingd on Tue 29th Jan 2013 23:12 UTC
Games It seems to have so far escaped OSNews' notice (if the top few hits for a site-search for 'Steam' is any indication) that Steam for Linux is now in Open Beta; you can get the Linux steam client from steampowered.com. So far, they appear to only be making an Ubuntu .deb available, and the client will require closed-source GPU drivers in order to work.
Thread beginning with comment 550819
To view parent comment, click here.
To read all comments associated with this story, please click here.
RE[2]: Comment by Wafflez
by robco74 on Wed 30th Jan 2013 02:57 UTC in reply to "RE: Comment by Wafflez"
robco74
Member since:
2009-10-22

If I understand correctly, game developers could release the game source code, but keep the creative aspects (art, music, story, etc) proprietary. So you could build your own game using the source code, but would need to provide your own creative elements. I would imagine there's more concern over the Steam DRM.

Reply Parent Score: 2

RE[3]: Comment by Wafflez
by Valhalla on Wed 30th Jan 2013 03:12 in reply to "RE[2]: Comment by Wafflez"
Valhalla Member since:
2006-01-24

Yes this is pretty much the way that it's done with all commercial games which has later been open sourced.

The code is released under GPLv2/GPLv3, meanwhile (non-copyleft) copyright is retained on the game 'assets'.

This means that you can port the game to just about any platform and run it there, but you need to 'own' a copy of the graphics/sound/etc data, which in practical terms mean that you need to own the original game if you want to play the game as 'intended'.

Obviously releasing the source code opens up lots of possibilities for 'modding' and other ventures which doesn't rely on the original game data.

Reply Parent Score: 4

RE[3]: Comment by Wafflez
by ssokolow on Wed 30th Jan 2013 03:18 in reply to "RE[2]: Comment by Wafflez"
ssokolow Member since:
2010-01-21

If I understand correctly, game developers could release the game source code, but keep the creative aspects (art, music, story, etc) proprietary. So you could build your own game using the source code, but would need to provide your own creative elements. I would imagine there's more concern over the Steam DRM.


Yeah. It's a common way for companies to open-source the engines for games like DOOM and Arx Fatalis.

It's also how free games like Sauerbraten and Frogatto and Friends are done. The engines are open-source and you're encouraged to reuse them but the default assets bundle is merely freely redistributable with no derivatives allowed.

(Frogatto and Friends was actually written specifically to encourage more 2D indie platformers by providing a good free engine and an example of what it can do and how it's used)

The inverse is also popular with indie games. (Using things like music and art assets under licenses like CC-BY-SA)

GPLed code doesn't affect assets unless they're compiled right into the executable binary because there's no code linking going on and Creative Commons assets don't affect code for the same reason.

(Copyleft licenses cover derivation, not aggregation)

Reply Parent Score: 3

RE[3]: Comment by Wafflez
by Ravyne on Wed 30th Jan 2013 03:38 in reply to "RE[2]: Comment by Wafflez"
Ravyne Member since:
2006-01-08

That's the way things go when people (i.e. iD) go down that route, however there are other issues with releasing the source to AAA games.

Firstly, the industry competes fiercely on technology, and licenses their engines and tooling for 10s of thousands, or even millions of dollars.

Secondly, any major AAA game engine also supports consoles, and there's a legal liability if they expose any portion of the SDK. They could do a lot of work factoring out and removing #ifdef XBOX's, maybe even treating the cleaned source code as another build target, but that's rather a lot of work for little gain. More so to retrofit it. You might have to not include any version-control history either, lest comments reveal secrets.

Then there's the overhead of accepting upstream patches, and telling contributors that, no, we can't take your patch because it doesn't work well with the secret stuff we can't disclose to you, and we can't provide any more than the vaguest of hints to redirect you, because you could then infer super-secret stuff we can't tell you and Legal will have our asses.

Honestly, a better approach is to go the other way around -- begin the project entirely open source, and then treat yourselves as a third party using the code-base. However, you still have problems forcing the codebase to be console-friendly without maintaining a whole lot of private code replacing things whole-cloth, or just branching entirely.

Really, the whole thing idea falls apart when you touch closed platforms (which is not a rebuke of consoles, just an observation.)

You can't even really point to iD's releases as a model, as iD itself isn't really actively looking to FOSS contributors to provide iD with upstream patches. Their source code releases are essentially gifts to the community and insurance that their games will remain playable into the future.

Reply Parent Score: 1

RE[4]: Comment by Wafflez
by WereCatf on Wed 30th Jan 2013 05:45 in reply to "RE[3]: Comment by Wafflez"
WereCatf Member since:
2006-02-15

Then there's the overhead of accepting upstream patches


The engine can be open-source even without the developers accepting any upstream patches at all. Accepting such is not a requirement.

Really, the whole thing idea falls apart when you touch closed platforms (which is not a rebuke of consoles, just an observation.)


You could always place the console-specific portions in separate header - and code - files and use ifdefs, and as such, that's not really as big of an issue as you would seem to believe. It is some extra work, but not much -- especially so if you plan the code-base accordingly from the get-go.

Reply Parent Score: 5

RE[4]: Comment by Wafflez
by tidux on Fri 1st Feb 2013 17:46 in reply to "RE[3]: Comment by Wafflez"
tidux Member since:
2011-08-13

> Secondly, any major AAA game engine also supports consoles, and there's a legal liability if they expose any portion of the SDK.

Why do console OEMs do this? Do they think that restricting access to the SDK will provide MORE good games?

Reply Parent Score: 2