Messages

If I stripped out the ability to set achievements and stats, then sure, I could use the Open Steamworks API, but AGSteam would be utterly pointless as it wouldn't do anything.

YMMV, but I'd argue that achievements themselves are pointless...

Well, Steam has no obligation to be open source

The whole of Steam wouldn't need to be open. Only the API; the part the communicates with the steam client and server.

and can impose whatever legally valid licensing conditions they want

Sure. And I'm just as free to feel that this is a valid point to not use such systems and to discourage others from using it. As you describe it, Steam, thanks to the restrictive license of the Steamworks API, automatically shuts out GPL (and related) licensed works. I find that highly troubling.

I'd agree that it's troubling that a closed, proprietary distribution system, marketplace, etc. should have such market power, but that's just how it is, and commercial developers need to take it into account.

Call me naive, but I never liked that defeatist attitude of "It's how it is and we can't change it".
I'd argue that an openly communicated boycott because of these restrictions would be anything but a handicap.
Also, like I said, I never got the point of achievements anyway. I play games for the story and occasionally the addictive gameplay; I don't need no flashing "X points of damage dealt" (or even worse "Passed Chapter II of linear game Foobar").


Regardless of all that, like I said, if the plugin instead ship with the game as game data, the point could still be made that they are akin to game scripts and therefore not subject to the engine's GPL license.
Still, I certainly don't like that idea. Apart from my idealogical views, pure-binary plugins are a major damper for portability.

(Just to throw yet another fancy idea into the room: A different plugin system could work similar to a JavaVM, with the plugins being portable compiled bytecode that's interpreted by the engine, with some limited hooks to call platform-dependant libraries for things like the Steamworks API. This would give us the "best" of both worlds, with plugins still portable and yet closed and distributed with the games. Of course, this would add another new language a plugin-author needs to get accustomed to and add to the size of the engine).

According to GNU, plugins are considered derivative works, or part of the same software. Either way, the GPL would require plugins to be GPL.

No, not necessarily. The default lawyer answer to that would be "Maybe". I.e. it depends on the case, the court, etc..
Like I said, I just heard a talk about that on the FOSDEM in Brussels a few days ago, with actual lawyers present. The showcase there was The GIMP, which actually has a plugin system and has an extension in their GPL license to explicitely allow closed / proprietary plugins.

If AGS was to adopt the GPL, closed-source plugins (that interact with the engine) would be a copyright violation.

No, wrong, see The GIMP.

It would be possible to add an exclusion to the license of the AGS to allow closed-source plugins, however it would then negate the identification of AGS as "Free" software, according to GNU. It would make the entire move to the GPL pointless.

No, wrong, see The GIMP. The GIMP is still free software, while still allowing proprietary plugins. I can't say that I myself am too happy about it; I'd rather have all plugins free. I can understand their reasoning though, which is that they don't want to drive away plugin creators that depend on patented and therefore non-free information, because that would only hinder the adoption of The GIMP if you always have to explain to others why a certain function that's common in, say, Photoshop isn't available. The core functionality, that what maybe most people care about, however still remains free software.

If the AGS plugin is based on a closed-source API then it makes sense for the AGS plugin to be closed source. Case in point: AGSteam. The Steamworks API is currently very restrictive in its licensing.

I see that as a (very severly) fault with the Steamworks API, then.
For this particular example, there's also Open Steamworks (with some limitations).

Regardless, if you want to keep them closed, that still doesn't necessarily preclude the GPL for the engine.
The question then is whether the plugin is, like game scripts, mere data; depending on how it's called. The plugin would then ship with the game and not ScummVM (and the game would hopefully have a way to check whether a plugin is available and have a fallback).
Theoretically, there's also apparently the possibility to add an extenting clause to the ScummVM license saying that proprietary (AGS) plugins are allowed. From what I heard in a FOSDEM talk a few days ago, The GIMP did that with their license for their plugins.
I myself am not particularily a fan of that option, though.

[but I am implacably opposed to forcing this upon them]

I'd be happy to see game developers releasing the source code to their games, but I am implacably opposed to forcing this upon them.

This is a completely seperate issue. No one is talking about that.
Making the engine GPL does not have anything to do with the games it runs.
It doesn't have any implications on the experience of an AGS game.
It doesn't have any implications on the marketability or profitability of a commercial AGS game.
In short, this is a non-issue.

Now, if we're talking engine plugins, like the various graphical effects plugins I've seen AGS 2.x games use, they would fall under the GPL. And that's, in my eyes, a very good thing.
Because a) Not being able to run 2.x games when you don't use Windows because the game needs some rain drop effect DLL is insane
and b) This doesn't limit you as a game (and plugin) creator in the slightest, while enriching the community. I.e. you're giving back to the community => everyone wins

And while yes, most "permissive" licenses like MIT allow for closed source forks

That's actually the ideological difference between MIT-style and GPL-compatible licenses: The GPL forces you, when you enhance a project you use, to give back that enhancement to the community; while MIT-style licenses allow you to keep those enhancements to yourself.

Quite frankly, I think the latter is selfish and should be discouraged; therefore I like the GPL.

Interestingly enough, I don't think there's any legal problems with just taking the AL-licensed code CJ released and just re-/dual-licensing it to the GPL. Any enhancements made upon that codebase would then be only GPL-licensed. That's why I for one am quite surprised that CJ chose such a permissive license when he's not that happy about its consequences.
Yet again, IANAL, so I might be talking bullshit here.

Note that again, we are not talking about AGS games.

the GPL does not exactly forbid this either (for internal/private use, for example).

IANAL, but I think I remember reading that the GPL prohibits that too (or rather, says that you have to share any useful enhancements). It's not really enforceable, sure, but as soon as any of it leaks into the wild, you have a problem.
[EDIT: Or apparently, I'm wrong there.]


Now, to extend a bit on what fuzzie said: You are also confusing two mostly different issues:
1) Adding an engine for 3.x+ games to ScummVM
2) Adding an engine to ScummVM that supports legacy 2.x games

Only 1) would theoretically necessitate moving AGS development into ScummVM, since it's, I assume, still actively developed and we really wouldn't like playing catch-up with a complety seperate AGS repo. Doing that would be boring, extremely stupid and a massive time-waster.

As for 2): I've seen the source CJ released, which I assume is 3.x. From what I've seen by digging through it, it's missing stuff to load 2.x games, so the current 3.x branch doesn't run 2.x games anymore, making them already disjunct. At least 2) should be relatively uncontroversial then, no?
Provided, that is, that the 2.x sources get released and there's motivated people working on it. Because quite frankly, the already released sources are horrible and the whole thing would need a completely clean rewrite before it's anywhere near readable and portable.