Author Topic: Initial AGS Engine Source Code release  (Read 86709 times)

sev

  • ScummVM Team Leader
Re: Initial AGS Engine Source Code release
« Reply #240 on: 10 Feb 2012, 20:41 »
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.


Eugene

Re: Initial AGS Engine Source Code release
« Reply #241 on: 11 Feb 2012, 08:50 »
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.

Would it be possible to have an open-source *plugin*, but have the actual low-level Steam API be handled by code which didn't communicate by anything other than a very simple interface (ideally something which could thereotically done by communicating simple strings etc)? It looks like that would be sufficient for AGSteam, and that would mean that in the worst case, someone could come up with something like a proprietary wrapper which runs ScummVM and then talks to it via a pipe to do the Steam communication.

And are there other plugins which are essential and yet can't be open-sourced or reimplemented? I think trying to come up with a relicensable ScummVM subset would serve mostly to drive everyone mad.

Other than the license issues, AGS doesn't look *too* painful to refactor/rewrite into a ScummVM engine, after having dug through the code for half a day and started an experimental attempt.

However, ScummVM doesn't expose hardware graphics acceleration to engines right now, since it's not available reliably on a lot of platforms. We can probably fix that, but can anyone summarise how important it is and give an idea of which games might be good testing candidates? I couldn't find a good summary.