This was not really fun thread to read, nevertheless I would like to step in and clarify some questions.
First thing I would like to talk about is that there were some unwise and not supported accusations and even insults on expressed in this thread. Let me make it straight. We would love to see AGS engine as part of ScummVM. However, if the AGS community does not want to
develop their engine in our tree, we would prefer to concentrate on legacy, i.e. 2.x code, because otherwise we would have to continue constantly synchronising two codebases.
We as a team were never intended to ignore or insult anyone from AGS community, however in that thread on our forums as well as here you can see some wrong statements posted by non-team members. All ScummVM team members have relevant badges on our forum, so it should be easy to identify who is who. We are not moderating people's messages besides obvious spam or warez promotions, so even negative things will stay as they are.
Now on the licenses.
Game assets are not bound by the executable license. Putting several assets with separate licenses into a single archive or on same media does not affect their licenses. GPL governs only software source code which is linked (in terms of object linker, used by compilers) to it statically. I.e. your GPLed Linux libraries could be dynamically linked with your proprietary executable without it being affected by GPL. If you have to link statically, there is LGPL license, specifically for that purpose.
If an AGS game will be using ScummVM, it will have links to our site as well as relevant copyright statements in the About dialog. Since our site contains full source, that is enough for complying to the license. Again, this is valid only for the cases when there are no modifications to ScummVM source code.
Now, considering that currently AGS is embedding the compiled game scripts into a single game executable, this is a bit problematic. You still can consider this as a blob under different license, but purist communities like Debian require source code for everything which is in the executables. Nevertheless splitting out game data from executable is not a technical problem at all, not to mention, that keeping them together
is a technical problem since it is not portable at all.
ScummVM is GPL, but some parts of it are dual-licensed. So could be the AGS engine, i.e. it could stay as GPL/APL, but outside of ScummVM framework somebody has to implement all required APIs.
Current AGS code is of low level quality, and is practically impossible to maintain and develop by any team beyond single person, which was admitted by Chris himself, and has obvious reasons to be such. It was Chris' sole project for nobody else to see. Thus, if/when somebody decide to do development work on the engine, it will require heavy refactoring. Porting the engine to a new platform like PSP is quite straightforward task and differs a lot from extending its functionality.
Thus, if some team is arranged on either side, e.g. AGS for developing 3.x or ScummVM for porting the engine, it must be refactored. Then, depending on the consensus we either will have 2 incompatible code bases, or still single one shared by both communities.
The proposed solution.
My suggestion is that since you're looking towards portability, you are welcome to use our code infrastructure since it is proven in 10 years of the project history as reliable and comfortable to work with. You keep AGS engine under APL, which is forward-compatible with GPL, i.e. it could be published under APL as separate entity, and under GPL as part of ScummVM distribution. You are getting nice framework with tons of convenient and portable utility classes, and most probably also number of ScummVM developers, interested in developing the engine.
The games produced with this engine could be sold, charged, closed, wiped, nuked, or printed out and burn, without game scripts being affected by GPL. As of the proprietary plugins, we already have plugin subsytem with dynamic linking, so as soon as those plugins are not using our code, they could be closed source. Of course, this subsystem has to be extended a bit since these days it supports loading of whole engines, not some parts of them.
I welcome everyone to start our discussion from this very message. Alternatively the moderators could consider splitting it out from this thread and starting from the scratch.
Eugene Sandulenko
ScummVM Team Leader
http://scummvm.org