Initial AGS Engine Source Code release

[timofonic]

So, the situation is basically like this:

- if AGS engine was supported by ScummVM, AGS games would gain massive multiplatform exposure and zero worries about technical issues. Something this community has been wanting for ages.

Creating a ScummVM-based AGS engine wouldn't lead to "zero technical worries" (cf. other ScummVM engines that are not 100% perfect), although it's true that the ScummVM backend and various platform ports are of high quality and would allow us to piggyback on existing code. But this elides the crucial point that this isn't something that can happen just by saying the word. Someone has to do the work of porting the AGS engine to ScummVM, fixing any resulting bugs, etc. That's a lot of work.

Of course there's no zero worries, that's totally obvious.

OSystem's ScummVM is a framework designed to be quite portable from the practice, and even the coding guidelines in ScummVM are crafted with very high portability in mind.

The work must be done, like it happened with all the available engines in ScummVM. There's not a magical wand to get it. But the same can be said about making AGS portable and having clean code, that's A LOT of work (and maybe recreate the same level of portability can be higher than just reusing stuff like OSystem).

- in turn, ScummVM users would get authoring system that would enable creation of new games. Something that community has been wanting for ages.

Have they? Usually when I see people asking for it on the forums, the devs tend to say it's not something they're interested in. Of course, that's what they used to say about supporting Sierra games, too...

You seem to generalize the opinions of the ScummVM Team, anyway they have a pragmatic thinking. ScummVM is a project consisting of different subprojects, having subteams for each game engine developed. The monolithic thinking that can be applied to a project like AGS can't be applied to the modular ecosystem ScummVM is.

And you agree about Sierra AGI/SCI games. The things changed when people in the project or wanting to join offered their work on those engines. Usually the procedure in FOSS is "release early, release often" and that often means doing experimental forks like the early FreeSCI adaptation to OSystem's ScummVM.

There are people already interested in AGS into ScummVM for different reasons. Some want it for classic games (like DrMcCoy is interested in Yahztee games, for example) to be supported, and that seem something most people in both communities agree to support into ScummVM.

And the only thing preventing this from happening is AGS not being GPLicensed?

No. It's one reason, but not the only one. Probably the biggest reason (as stated from the ScummVM side) is that AGS is intended as an engine under ongoing development, with new features and changes in future versions. The ScummVM devs aren't interested in chasing AGS versions, so the only scenario under which they'd contemplate this is if all AGS development was brought into and taken over by the ScummVM project. Among other things, this would mean adhering to the ScummVM release cycle.

What's the point about ongoing development? That's quite subjective right now, because AGS progress is quite stalled these days...

What's so limiting about the ScummVM release cycle? They are an organized team, they release a new version each six months. I see it a quite standard way like most of the software projects out there, even better than most commercial ones with usually larger release cycles.

How would this affect the development of new features, which might require basic changes in the engine? I don't know, but it's reasonable to think it would complicate it, since you have a backend that must remain compatible against a bunch of other engines too.

I think you are forgeting how FOSS development works these days, using modern computer programming tools like distributed revision control systems  like Git and others like Buildbot.

* Git makes development quite easier, by making operations like forking and merging easier. Forks are a common practice in most complex projects, because they make the development of experimental stuff a lot easier. When the stuff is done to include it into the main branch, you merge the results back.

* Buildbot is a great tool to constantly test if the modified code is able to be built for different platforms, so it's a great way to check the portability and basic bugs in the code.

Each porter gets sure the engines work as intended on the platform, there's testing periods in the project too.

In any case, it's not clear that the AGS community is prepared to hand over ultimate control over the process and the direction of the engine to some outside group of developers, and it's very uncertain how the two communities could work together. Compared to ScummVM, AGS has a more complicated set of interests to align, since it's made for players on one hand and game developers on the other, for people making traditional adventure games as well as people pushing the technical and genre-defining boundaries, for newbies and non-technical artists as well as experienced programmers, and for rank amateurs and newbies through experienced hobbyists to commercial developers. It also has a long-standing community and social aspect, with multiple channels of communication (forums, blogs, IRC, social networks) and regular meets.

There's the real point! The feeling of property about a project and a community...

Contrary to what it seems to certain people, that's very relaxed in FOSS due to the Copyleft philosophy of collaboration and meritocracy. That's something not well understood to most people outside FOSS. Sense of ownership is considerated as ridiculous for true FOSS developers, because anyone can fork a project to take a different direction.

About experienced developers in AGS, I disagree. I see there are very few developers on this community, but very experienced ones in ScummVM.  Computer programming must be quite organized to get proper results and certain ideas that can be amazing to a graphics artist can be totally and ridiculous nonsense to a proper computer programmer because of solid and objective technical reasons.

ScummVM isn't a monolithic project as explained before, but a bunch of projects on a common ecosystem (using a framework named OSystem) and with a common interest in adventure game engines.

Let's go to speculate a bit about how AGS would live inside ScummVM, here's my ideas:

- AGS would have it's own set of developers, the AGS subteam. Those are developers focused on the progress of the AGS runtime, cooperating with the developers of the AGS authoring tools (the real deal of the AGS community, in my opinion).

- ScummVM would integrate the stable versions of the AGS runtime in each 1.x version, having experimental ones in separated forks that can be built automatically by using Buildbot.

- Forums  would stay the same, having a link on the ScummVM forums redirecting to the AGS ones.

- At least the information related to the technical part of the AGS runtime would be merged into the Wiki.

Another big issue is the work involved. Converting the AGS engine to ScummVM would involve almost a top-to-bottom rewrite, and you wouldn't have a feature-complete engine until you were done. No one who's competent to do that has volunteered. The alternatives offer a less daunting path forward, since you can fix problems and refactor parts of the code bit by bit and have a fully functioning engine every step of the way. So if we decide to go with ScummVM, we have to hope that someone with the necessary skills materializes and hope they keep working on it until it's ready.

Well, ScummVM developers managed to do difficult efforts like merging tons of engines plus rewriting ones. Some examples are AGI, SCI and Tinsel. But I agree new developers are needed to take this great effort, with volunteer work to get it done.

Refactoring with AGS alone can look easier because of a more progressive way, but the rest of the effort could be less friendly in this environment. There would be needed to prepare the project with high portability in mind if AGS wants to stay relevant in these days, with lots of available platforms in the market.

Anyway, the source code of the AGS runtime is quite rusty and needs a proper refactoring. It's one of the very common mistakes of one-man projects, they lack of coding standards because that person already understands the whole codebase (but that fails in a bigger group, where someone focus more on certain parts of of the projects than others).

Why is AGS not GPL (now that it's already open source)?

Because CJ released it under the Artistic License 2.0, and requested that it be kept under a permissive license. Since it's CJ's work and he spent more than ten years making it, I'd argue that we should respect his wishes.

OK, so you are recognizing the reasons are not pragmatical at all, but dogmatical ones. I agree on this.

But a proper community must follow it's own path, and not get into a religion.

What prevents AGS from being GPL?

Only the choices of AGS developers and contributors, who will presumably be guided by the wishes of CJ and the community.

I agree about the first part, but in the rest you are talking like a preacher.

And what are the benefits and/or limitations of AGS being GPL?

The benefits are that we could integrate GPL components, such as ScummVM or certain libraries. Some also believe that under the GPL license the project would attract more contributors, under the theory that talented open-source programmers prefer strict copyleft licenses over permissive licenses.

The limitation is that GPL imposes a number of restrictions on what you can do (or have to do) with the software, and once you switch to GPL you can't change it to something else (without the permission of every individual contributor, which is usually impossible). It only allows the integration with other GPL (or GPL-compatible) software, and this excludes anyone who isn't prepared to adhere to the GPL licensing restrictions. This can be an obstacle not just for commercial developers, but also for other open-source projects (as the ScummVM-AGS issue demonstrates).

I agree about the first paragraph, there's lot of projects under GPL and that's something objetively verificable. It's quite common open source programmers prefer Copyleft over BSD/MIT style licenses, because it makes their code to be always available and not closed sourced by other individual or company/corporation (like Microsoft and Apple does most of the time, for example).

It hasn't been an obstacle to many commercial developers and publishers already using ScummVM. So what's the problem?

Even ID Software releases their games as GPL too, but the game data still being propietary and need to be bought.

Does GPL prevent commercial usage of software? Would it require open sourcing the scripts in every AGS game?

It doesn't technically prevent commercial use, but the licensing requirements are such that you'd have to provide the source code and allow people to distribute it and compile it freely, so you can't stop people from giving it away. There are business models that work under these conditions, but probably not for commercial adventure games.

Excuse me, but what's wrong with giving back the code to the community? You receive it, then give something back!

Nobody can stop giving away an unauthorized copy, even by using samizdat-like laws like SOPA and ACTA or by an extreme evolved Big Brother approach from the wet dreams of british/american/chinese/iran governments. That relies on the personal ethic of the individual, not on the software license itself.

I believe that the way AGS works now, where the engine and game logic/data are compiled together into one binary, the GPL would technically require the scripts to be open-sourced. ScummVM doesn't work that way: the engine is distributed separately from the game logic/data, so there's no question of its license covering them.

It would be possible to change the way AGS is built so that the engine code and game code are kept in completely separate files, and this would probably address the concern. Though in most cases you would probably still want to distribute the engine along with the game and have it launch the game directly on startup with a single click. In spite of what RickJ says about the absurdity of what a "binary file" is, I think the distinction matters. And I also think an expansive reading of GPL could mean that e.g. distributing an AGS game with the engine as an executable installer could require open-sourcing the game (or at least the installer), though probably no one would be likely to press this interpretation.

I'm sorry, but you and others are misinterpreting the virality of GPL. This has been talked ages and it's just theoric speculation, because commercial game development companies like ID Software already release their games as GPL and we all agree they have a lot of lawyers to check this kind of things.

It's quite possible to extract the games of the already available games from the AGS bundle, that's not a problem at all.

About using an installed or bundler, that's quite possible to do without breaking the GPL. It has been done with other projects.

What I think would be a more realistic concern would be that a game developer couldn't make changes to the engine that relied on closed-source APIs. For example, I don't think the Steam plugin that monkey and Dave made for the Blackwell games could be integrated into a GPL version of AGS. (And I believe I remember that the ScummVM team was unwilling to create a plugin API for the engine to link to separate DLLs, partly, I guess, because it's platform-dependent.)

That's something that need to be discussed, as Steam is closed source and having a strict license. I would like to know the opinion of other people on this matter, it looks a quite interesting situation to know for me.

[Sslaxx]

Can we stop with the open source zealotry, please, Timfonic. You are not helping. CJ has explicitly set a license and that should be honoured. With all the complications that could be thrown up by adopting the GPL or LGPL, we should either stick with the Artistic License v2, or adopt a MIT/ZLib/PNG license.

[timofonic]

Can we stop with the open source zealotry, please, Timfonic. You are not helping. CJ has explicitly set a license and that should be honoured. With all the complications that could be thrown up by adopting the GPL or LGPL, we should either stick with the Artistic License v2, or adopt a MIT/ZLib/PNG license.

You are not helping with your attitude too. Please avoid insults or negativity under certain point of views.

[Sslaxx]

Everything has a time and place.

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. You will scare off potential commercial developers from using AGS if this were so, and whilst AGS is primarily hobbyist those commercial developers should not be ignored.

Regardless of CJ's dogma (or not) with wanting more "permissive" licenses than the (L)GPL used, it is a pragmatic move to do so. As has been noted in other threads, the use of the GPL/LGPL can cause problems with other software libraries (primarily commercial ones). And while yes, most "permissive" licenses like MIT allow for closed source forks, the GPL does not exactly forbid this either (for internal/private use, for example).

[Snarky]

Sooo much tedious! timofonic, 90% of what you write could be condensed to "GPL rules!!111" We all know your stance by now, and each post is just wearing down more and more of our patience.

Why is AGS not GPL (now that it's already open source)?

Because CJ released it under the Artistic License 2.0, and requested that it be kept under a permissive license. Since it's CJ's work and he spent more than ten years making it, I'd argue that we should respect his wishes.

OK, so you are recognizing the reasons are not pragmatical at all, but dogmatical ones. I agree on this.

But a proper community must follow it's own path, and not get into a religion.

Being pragmatic means recognizing the situation as it is. Would it be good for AGS to fork off the project into a GPL branch, going against CJ's express wish and potentially splitting the community? Even if one were to prefer GPL in principle, I think the pragmatic answer would have to be a clear no.

Incidentally, the ScummVM devs also seem inclined to defer to the wishes of the creator and developer of AGS in this matter, even if the license would technically allow them to ignore him.

I'm sorry, but you and others are misinterpreting the virality of GPL. This has been talked ages and it's just theoric speculation, because commercial game development companies like ID Software already release their games as GPL and we all agree they have a lot of lawyers to check this kind of things.

Releasing your own code as GPL is completely different from relying on GPL-licensed code by others. You can do whatever you like with your own work (for instance, ID could use the game code they released under GPL in other projects without releasing the source for those derived works), but once you use someone else's code under the GPL license, you are subject to all its terms.

[monkey0506]

timofonic's posts are becoming more and more derogatory, more and more patronizing, and more and more flagrantly inflammatory. Whether or not he's doing it on purpose, he is constantly spewing the same information, adding new bits here and there. His responses are not generating useful discussion that are in any way relevant to this thread (this is the thread about the release of the source code, arguments over what the GPL is are completely irrelevant).

I think that people are beginning to realize where my frustration was coming from, and reaching the same conclusions themselves. We have usefully discussed all that timofonic has presently brought up for discussion, and until he brings something new to the table, there isn't much point chasing him around in circles.

[Alan v.Drake]

You guys are so verbose. If you used even only half the energy you pour into these threads to clean the source code, we'd be already done.

- Alan

[Snarky]

Hah! You haven't reckoned with how slow of a coder I am.

Honestly, even if I devoted all forum time to improving the AGS code, I'd probably still be reading the current version of the source, and possibly looking into various libraries we could build on top of.

[doimus]

Regardless of CJ's dogma (or not) with wanting more "permissive" licenses than the (L)GPL used, it is a pragmatic move to do so. As has been noted in other threads, the use of the GPL/LGPL can cause problems with other software libraries (primarily commercial ones). And while yes, most "permissive" licenses like MIT allow for closed source forks, the GPL does not exactly forbid this either (for internal/private use, for example).

Thanks for this clarification. That's one pretty serious limitation of GPL-ing the code, IMO.

[fuzzie]

Being pragmatic means recognizing the situation as it is. Would it be good for AGS to fork off the project into a GPL branch, going against CJ's express wish and potentially splitting the community? Even if one were to prefer GPL in principle, I think the pragmatic answer would have to be a clear no.

Incidentally, the ScummVM devs also seem inclined to defer to the wishes of the creator and developer of AGS in this matter, even if the license would technically allow them to ignore him.

This whole thread is a bit confusing to us ScummVM devs - to be clear, we'd love to support the existing AGS games in ScummVM. That has been a very common request from many, many users for a long time. If there had been a code release which supported all the older AGS games we'd have *jumped* on it. Perhaps at some point we'll take a look at the ports which added support for older games and see if we can't make something of that code ourselves.

But it seems clear from this thread that *ongoing* development of AGS within ScummVM is probably not what many AGS devs want - even ignoring the licensing worries, our priorities are compatibility with old games, portability (i.e. games should run on all platforms), longer-term release cycles to make sure all the platforms stay in sync, etc. Obviously things like new features for engines would always be less important to us, because that's not what our project is about. (And bundling the game data into a single platform-specific binary along with ScummVM is probably not something we'd be spectacularly happy about either, because of portability concerns - again ignoring any licensing issues.)

(And about the licensing: There are commercial releases of games bundled with ScummVM on things like the iOS app store. Their game data hasn't magically become GPLed. But we can't add clauses to our license without the permission of (long-gone) contributors, even if we wanted to. Some clarification in our FAQ is obviously an option if our general view is unclear to people, as already suggested long ago in the ScummVM forums.)

[DrMcCoy]

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.

[monkey0506]

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.
...
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

False. 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. To release an open-source AGSteam plugin would be to either break the license of the Steamworks API (and thereby infringe on the copyright of Valve), or to strip out the references to the Steamworks API, leaving the plugin source in a useless state. Every single user-exposed function of the AGSteam plugin relies in some degree on the Steamworks API.

Requiring AGS plugins to be licensed under the GPL or a compatible license would be, as you say, "insane".

[DrMcCoy]

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.

[monkey0506]

Regarding Open Steamworks, "some limitations" includes:

Furthermore, you do not get access to the Steamworks backend. You cannot create achievements, register a game, or do other backend related activities.

That entirely negates the purpose and usefulness of the AGSteam plugin. The entire existence of said plugin is to provide an intermediate API between the closed Steamworks API and AGS itself. The AGSteam API is proprietary of MonkeyMoto Productions, Inc. and is freely available, and as a separate work does not fall under any of the licensing terms of the Steamworks API. The AGSteam plugin itself however, does directly utilize the Steamworks API, and out of necessity is therefore closed-source.

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. I'm not saying that Open Steamworks itself is incapable of doing anything, but presently achievements and stats are the stated purpose of AGSteam.

[qptain Nemo]

The Steamworks API is currently very restrictive in its licensing. To release an open-source AGSteam plugin would be to either break the license of the Steamworks API (and thereby infringe on the copyright of Valve)

Would you kindly link to the aforementioned license?

[Snarky]

I see that as a (very severly) fault with the Steamworks API, then.

Well, Steam has no obligation to be open source, and can impose whatever legally valid licensing conditions they want, just as GPL can. If the two sets of conditions are incompatible, the fault is equally on each side.

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. If using AGS means they can't take advantage of basic Steam features like achievements, that's obviously a major handicap.

[qptain Nemo]

Btw even if what you say about Steamworks licensing is true, isn't it strikingly obvious that GPL programs can dynamically link to any proprietary dlls so if AGS was under GPL there'd be no problem at all with that a closed source ags plugin would exist that provides the necessary steam interactions?

[timofonic]

I see that as a (very severly) fault with the Steamworks API, then.

Well, Steam has no obligation to be open source, and can impose whatever legally valid licensing conditions they want, just as GPL can. If the two sets of conditions are incompatible, the fault is equally on each side.

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. If using AGS means they can't take advantage of basic Steam features like achievements, that's obviously a major handicap.

Well, could you please provide a link of the Steamworks API license[u/] or whatever that forbids that from Valve? Dosbox is used by many games distributed by Steam and Dosbox is GPL itself, like id Software games.

http://games.slashdot.org/story/07/08/05/1951243/id-and-valve-may-be-violating-gpl
http://www.eurogamer.net/articles/id-sorts-gpl-steam-issue

Anyway, aren't there other alternatives besides making AGS to access the Steamworks API? Like writing the relevant information to a file and a watchdog wrapper looking at it to send it by using the Steamworks API, for example. This can be a more generic solution that would require less specific code added to the game engine to maintain, too.

[monkey0506]

Tim, your "watchdog wrapper" would be a derivative work, and therefore need to be licensed under GPL.

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

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

When I was saying "Steamworks API" I was specifically referring to the exposed methods of the Steamworks SDK. Just because they're exposed though doesn't mean that they're publicly available. Valve has very little to no documentation of the API as of this writing that is publicly available. If you want access to the full API documentation, you have to get access to the SDK. That means you have to sign a Non-Disclosure Agreement and a Source Code Addendum. Physically sign it.

If anyone wants to link to the Steamworks API license and prove me wrong, I wouldn't mind opening the source to AGSteam. Everything I have seen and read though prevents me from doing so, under obligation of the aforementioned NDA.

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. So, even if AGS moved to the GPL, it would have to do so in such a fashion as to defeat the entire purpose of why we did so; or else closed-source plugins would forever be banned from legal (public) usage with AGS.

[DrMcCoy]

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.