Sev, thanks for acknowledging the issues and offering a practical solution. Putting this in a FAQ is
a little weak. Perhaps, in addition, there could be a separate "GPL Compliance" text file that would/could accompany any distributions. It could include similar to the above statements and others as well as the offer of source code and the relevant URLs.
In fact it is business of the game authors. They have to provide accompanying licenses as part of their distributions. To comply with GPL, they have to provide ScummVM license, and next to it they should put a license which explicitly deals with their game assets. This should make everything clear in every instance. Putting it now on the ScummVM site would be pointless. Consider the freeware game distributions available from scummvm.org website. All of them contain separate license.
Up until recently AGS did produce a separate game file in addition to the combined executable and a separate game file isn't a technical problem at all or a foreign concept to AGSers. However, at times the combined exe is convenient and useful. Perhaps the licensing issues could be sorted out in the above mentioned compliance document and the remaining technical issues addressed by a "Project options/configurations" in the editor where the user could setup multiple compile/build targets. It would then be possible to specify which files are to be produced for each target.
Again, you cannot combine executables with the data in a portable fashion with current approaches, e.g. the data is generated by AGS compiler and then glued together with the interpreter. There are technical possibilities to it, such as generating inline data in form of .cpp files and then recompiling the engine, but stop thinking in Windows terms if you are gearing towards the portability.
It was previously said on the ScummVM forum that nobody would be interested to do this and that nothing from ScummVM. not even the API, could be used in AGS/APL. So I welcome this proposal as I suspect most (if not all) in the AGS community do.
If you are basing your assumptions on post by da1writer
, I have no clue who he is, where he is coming from, and why on earth he has guts to speak in behalf of our team. Nothing like this was expressed by ScummVM team members. Please correct me if I'm wrong.
Also, I would highly recommend monkey_05_06 as a sort of technical liaison between the two groups.
That's good to know.
With a few exceptions, most of the plugins written for AGS ended up being closed source likely because nobody ever thought to make them open source or suggested that plugin authors consider making them open source.
Is the plugin system something that could live in an APLish AGS?
This subsytem is already in place, and since it is platform-dependent, it lives in backends part of our code. This would not help to have it as part of the engine, since it will have to rely on our code. What needs to be done, is that this interface extended a bit, relevant .h files dual licensed under APL, and then the proprietary plugins can use it and will be picked up by the engine and linked run-time. GPL license issues, e.g. no static linking is allowed are avoided. And after all, it is ScummVM team who potentially can sue people violating our rights, so everything could be arranged beforehand. In an unlikely case when our current plugin headers cannot be dual licensed because some developer who was involved in writing parts of it is not available anymore, the relevant comparatively small code could be rewritten from the scratch and dual licensed on purpose.