Thank you, Valve! But...

Posted Jan 24, 2014 12:30 UTC (Fri) by njwhite (guest, #51848)
In reply to: Thank you, Valve! But... by debacle
Parent article: McGovern: Valve games for Debian Developers

> Maybe it would be more helpful, if Valve shows their gratitude to Debian and other free software projects by other means. E.g. they might sponsor meetings of free games or multimedia developers or support the development of free video card drivers.

Well, from what I've read it sounds like they are doing a great deal to improve free video card drivers, so that should be applauded.

But yes, another nice contribution to the community would be to release the engines to some of their games as free software. It may impact their revenue, I'm not sure if they have licensing said engines as a business model at present.

On the same subject, actually, I don't see why the steam client couldn't be free software. Or does it have some sort of obscurity-requiring DRM built in?

Thank you, Valve! But...

Posted Jan 24, 2014 14:22 UTC (Fri) by mpr22 (subscriber, #60784) [Link] (1 responses)

It may impact their revenue, I'm not sure if they have licensing said engines as a business model at present.

They do. The Source engine (the basis, apparently in incrementally developed incarnations without useful version numbers, for all of their in-house games since Half-Life 2) is gratis for purely-gratis projects, while non-gratis projects require a commercial licensing agreement.

Thank you, Valve! But...

Posted Jan 24, 2014 16:43 UTC (Fri) by mathstuf (subscriber, #69389) [Link]

Sounds like a Qt-style GPL+exceptions with CLA could work for the Source engine (the exceptions would be for game assets and any scripts associated with them at least).

Thank you, Valve! But...

Posted Jan 24, 2014 14:54 UTC (Fri) by Cyberax (✭ supporter ✭, #52523) [Link] (4 responses)

Steam client simply doesn't need to be OpenSource. It's pretty clear that Valve would want to retain full control of its development anyway, so there are no advantages in opening its source.

Thank you, Valve! But...

Posted Jan 24, 2014 16:36 UTC (Fri) by deepfire (guest, #26138) [Link] (2 responses)

There are. People do not like running binary blobs on their computers.

Then, there's the white-box security model -- we trust Steam to handle our personal, even financial, information.

Thank you, Valve! But...

Posted Jan 24, 2014 16:42 UTC (Fri) by Cyberax (✭ supporter ✭, #52523) [Link] (1 responses)

I very much like running binary blobs on my computer, if they are classified as 'games'.

Steam is going to be used to run binary-only software, maybe with a light DRM. One more blob simply makes no difference.

As for credit card numbers, they are used by online merchants that are complete 'black boxes'. And I don't think that Steam client actually stores any financial information locally.

Thank you, Valve! But...

Posted Jan 24, 2014 16:57 UTC (Fri) by deepfire (guest, #26138) [Link]

Steam provides more than running blobs[1]:

1. Steam cloud
2. The community thing:
- IM/conferencing -- I'd use open-source Steam communication over Skype any day
- the rest (blogging, reviews)
3. Big Picture -- I can see it transformed into something more than a blob launcher

--
1. Some of the blobs could be trusted (signed) builds of open-source code, btw; I'd actually love to be able to find open-source games through a simple category search

Thank you, Valve! But...

Posted Jan 24, 2014 17:03 UTC (Fri) by deepfire (guest, #26138) [Link]

I thought a bit, and there's more to that story.

Some people find Steam UI glitchy, and/or clunky in places -- certainly, sometimes I feel the same way. I guess Valve would accept patches : -)

I'm not sure if there would be many instances of a situation where it's easier to patch the code to your heart's desire, than it would be to go through the write-bug-report-communicate-iterate low-pass filter -- and I'm sure the threshold is different for everybody. It's not something to dismiss, still.

Thank you, Valve! But...

Posted Jan 27, 2014 4:13 UTC (Mon) by imunsie (guest, #68550) [Link]

I have a vested interest in Steam (in that I have ~500 games in Steam, ~140 of which run on Linux), and would be quite interested in contributing from time to time if they did decide to open source the client - I've already written some third party tools to work with Steam games (in my junk code on github).

They do have DRM, but I don't see it as being a significant problem for open sourcing the client - it only affects Windows games (not Linux, I don't know about Mac) and works by the server wrapping the game's executable to tie it to the particular Steam installation the user is running on (the wrapped executable does not need to be online to verify the environment is what it expects). If their environment changes or they log in elsewhere the server simply generates a new executable for them to download - no install limits and no always online requirements. The point is, the client has very little to do with the DRM they employ.

Steam has always been designed with the philosophy that users should be able to play the games they own as easily as possible (as opposed to other DRM platforms who's philosophy seems to be that customers are nasty buggers and should be prevented at all costs from using the products they may or may not have paid for if there is even the slightest doubt they don't own them - a subtle but rather significant difference), so their DRM has been designed to keep out of the way as much as possible.

When it has bitten me, is when a publisher requires keys for their games and they underestimated how many copies they were going to sell in a weekend sale (they did resolve it early on the Monday when they could get more keys from the publisher, but there were a lot of people who couldn't play Burnout Paradise that weekend).

One thing I can see as being a concern for them if they did open source the client, is people creating fake/proxy steam libraries that lie about what licenses the user has - a lot of games ship DLC files with the main game (for multiplayer games it is often not a choice since they need the art assets to render DLC that other players are using), and Steam has an API that the game can query to find out which DLC the player actually owns. In an open source client it would be trivial to alter the library to tell the game that the user owns whatever DLC they want. Being closed source doesn't prevent this kind of thing from happening, but it does raise the bar quite a bit.