Topic: Initial AGS Engine Source Code release

[qptain Nemo]

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

Well. FSF are being a bit vague and contradictory on it. For instance:
http://www.gnu.org/licenses/gpl-faq.html#FSWithNFLibs
http://www.gnu.org/licenses/gpl-faq.html#GPLIncompatibleLibs

Valve has very little to no documentation of the API as of this writing that is publicly available.

Docs don't equal API itself. The only relevant thing here is the API's own license and whether Valve allow you to expose code that interacts with it or not.
It'd be rather strange if they forbade you specifically that though.

If anyone wants to link to the Steamworks API license and prove me wrong, I wouldn't mind opening the source to AGSteam.

Why does anybody have to check if your claim has any grounds or not? You're simply admitting that it doesn't if you ask that.

[Ogon]

What is the benefit of GPL for anyone? It is just more restrictive. Artistic License 2.0 can do the same, while allowing everyone to do even more, like more permissive closed-source usage which draws some players in (e.g. companies) that would probably not use AGS otherwise and might also contribute something at some point. Shouldn't we all be happy?

Why can't ScummVM sublicense the AGS code parts with Artistic License 2.0 (and keep that licensing in their repository), while still distributing the whole ScummVM under the terms of the GPL? Since the two licenses are compatible, that should be a total non-issue. I don't see the point with all those shouts about AGS -> GPL.

If the merge was done in an intelligent way, pure Artistic License AGS could even stay operative with the old Windows-focussed frontend, and optionally compile/run with the GPL'ed ScummVM.

[monkey0506]

If anyone wants to link to the Steamworks API license and prove me wrong, I wouldn't mind opening the source to AGSteam.

Why does anybody have to check if your claim has any grounds or not? You're simply admitting that it doesn't if you ask that.

My claim is based entirely on the fact that to the best of my knowledge, such an expressly written license for the API specifically does not exist. Nowhere have I been able to find that the API has a separate license from the SDK. Nowhere.

So you can drop the crap and stop trying to make me look like an idiot. If someone who actually has the ability to prove me wrong wants to, I welcome that, but until then you're just being flagrantly inflammatory for the sake of trying to piss me off.

I have specifically referenced the following pages, as well as every single page that they link to.

http://www.steampowered.com/steamworks/FAQ.php
https://partner.steamgames.com/

The Wikipedia entry on Steam indicates the Steamworks API as being "freely available" but that's open to interpretation of the term "free". I didn't pay anything in order to sign the NDA with Valve, so I freely gained access to the Steamworks SDK.

I'm not saying that a license on the Steamworks API (separate from that of the Steamworks SDK) does not exist. I'm saying that I have never seen any form of it, and what I have seen is directly indicative that it does not. Again, I welcome anyone who has found what I overlooked, but you can't discount my claim just because my searches (including Googling!) have utterly and completely failed to yield the results that you are demanding from me. I have documented the background of my claim. If you want to disprove it, the burden now falls to you.

Regarding the GPL, GNU is very explicitly clear that derivative works, especially in the form of plugins that interact with the original software, are required to either be a) licensed under the GPL, or b) an exception must be added to the license of the software, which invalidates the "Free" status of the software. GNU does distinguish that system libraries are an exception to this, specifically meaning those libraries which are part of the operating system or environment. AGS plugins do not remotely fit the definition of system libraries.

If GIMP has an exclusion in their version of the GPL which allows closed-source libraries to be used, then per the GNU definition, it does not meet the requirements to be classified as "Free" software. This isn't just some unbased claim, this is information that is explicitly published by GNU.

[Monsieur OUXX]

ScummVM integration

Licenses issues left aside, I think there should be a completely separate thread about ScummVM, because I've got the feeling that :
1) Not everybody understands what ScummVM is, from a programmer's perspective
2) Not everybody understands  what it can actually do
3) Everybody has a different idea of how AGS should be integrated with it / how AGS games should run on it.

So what do you think? Separate thread? At least to clarify the expectations and abilities?

[Snarky]

Whether or not GIMP is free software, isn't the point that if we wanted to integrate with ScummVM, we'd have to adopt the GPL as is, without any additional clauses? Is anyone advocating moving to GPL even if we keep the project separate from ScummVM?

As for the whole games-wouldn't-be-affected-by-the-license thing, as I've said I think that depends on details of the implementation, and that the way AGS currently works, they would. I agree that there are ways to implement it where they wouldn't be, though.

I've argued that we should move features out of the core engine and into user-editable modules that are not in principle any different from the script modules for e.g. the LucasArts UI. (So instead of coming with an engine-hardcoded Sierra-like UI, AGS wouldn't have a built-in UI but instead multiple modules you could choose from.) Since these modules would integrate directly with games, they couldn't/shouldn't be GPL. It would take careful consideration to decide what should be an engine feature and what should be part of the module library, particularly if initially implementing it in the engine (and licensed under the GPL) would mean it couldn't later be moved into a module (and licensed under a more permissive license).

[Alan v.Drake]

As far as I know plugins do not have to be GPLed as long as you can prove that the application can run fine without them. Of course if this apply also to the compiled game is unclear to me.


- Alan

[Endres]

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

This would be really an idea beyond the pale. I mean, the concept sounds nice, but the coding effort would be way too high. For this, and many other "problems" I may refer to the PSP port of AGS again. We only need to add the most used plugins by either asking for the source code or rewriting them - look at how the author of the PSP version ported it. This would lead to that we have to implement every possible plugin into the engine (either or not hard coded), but this is not a very huge problem, as most plugins could be rewritten simply using the (I suppose) existing ScummVM functions. Of course this can not be very easily done for every single plugin, thinking about not only SteamWorks. But I think that this is a minor problem we could think about later on, as we firstly need to get plugin-free games working. Use of plugins is explicitly not encouraged for portability, but I think this is also stated in the FAQ. What about just giving the user a popup saying "we can't support this game because the specific plugin can't be executed on this system"?
The application would run fine without plugins, if the game does not need any special plugins. Same for the compiled game. If the engine works usually for every game, but not for one specific, then I don't think that this could be a reason not to develop an implementation which only works with nearly any game. I don't get why this should depend on how to license it.

And the "legacy" 2.x issue doesn't really exist, I suppose, as all games from 2.6 can be played with the PSP port.

Now I think even GPL is not a problem. The engine doesn't have to be open source at all to get a working engine that can use game data and do things with it. It's all about data processing. ScummVM would only take the compiled ac2game data or strip it off the executable and processes it. So the ScummVM part is really independent to the original AGS Engine. Otherwise ScummVM would not be able to support any other engine anyway.

We should not think too much about exceptions. What we need is a development team that would really work on creating such an implementation. If I had more free time, I would think about reading up on ScummVM development.

[qptain Nemo]

Is anyone advocating moving to GPL even if we keep the project separate from ScummVM?

Whether the main fork of AGS is GPLed or not would change very little, but I do believe that in the given circumstances GPL would provide healthier developing atmosphere because any decisions made by the Official Elite Dev Team would have less severe impacts and would be easier to fix in case anything goes awry as well as would reduce the need to struggle forever over doubtful decisions, simplify experimentation, let be closer to the community (which everybody holds in high regard here, right?) and many other things.
And I'm not even talking about all the useful GPLed code that will be available to freely use with AGS, that benefit should be rather obvious.

[RickJ]

The GPL in it's vanillia form is ill suited to the class of applications that are intended to be used to create or run other programs.   The reason for this is it's broad definition of derivative and combined works.  There is a considerable amount controversy and unsettled legal questions surrounding the issue even among copyright attorneys as evidenced by these two articles from the International Free and open Source law Review

• Software Interactions and the GNU General Public License
  
• Working Paper on the Legal Implication of Certain Forms of Software Interactions (a.k.a. linking)
  
  

We in the AGS community have expressed our concerns and have enumerated at least three specific concerns we would have distributing our games with a ScummVM binary.  In stead of our concerns being addressed in a serious manner we are told that we don't get copyleft and that if we just adopted GPL everything would be just fine.  

You need to get this straight in your heads:  The Artistic License was chosen by CJ who listened to our needs and working slavishly of over the past 15 years to satisfy those needs.  We are extremely loyal and grateful to him. The particular license he chose may not protect the AGS source code as well as some other license could but it does seem to satisfy the needs of the people who use AGS to make their games.  Everybody here respects this decision and support it's continued use.  Further, nobody here would benefit from a GPL'd Ags.

Further, you on the one hand say "Well game files are clearly not derivative works".  But on the other hand you won't say so on the license, thus reserving the right to file future lawsuits over the issue.  

You also say on the one hand, "Well it would be all right with us if people downloaded source from the ScummVM website and so game develpers wouldn't have to supply source" but on the other hand you again refuse to say so on the license.  Again preserving the right to file future lawsuits.

You keep reassuring us that your license already addresses these issues and that we don't have to worry.  But then you say you can't add a clarification clause to the license that explicitly makes the very same assertions because that would change the meaning of the license.  Which is it?

You also say that you don't know who all the contributors are or how to contact them and that's why you can't add clarification to the license.  However, if the clause that is added does not change the meaning of the license as you have said above then it wouldn't be necessary to contact everyone, Right?.   It ought to be a no brainer!  

Unless of course you have reason to believe that some contributors may have a different interpretation of the license than you do.  In this case any of the known or unknown contributors could surface at any time and file a lawsuit over these issues.  

So what you are really doing is encouraging people to engage in behavior that you have reason to believe would be understood by one or more ScummVM contributors to violate the ScummVM license and htier copyright.  Isn't that correct?

IMHO, this position is intellectually dishonest and morally reprehensible.  

Realistically, a ScummVM port of AGS runtime(s) would be of limited benefit to AGS game designers if it couldn't be confidently and easily distributed with their games.  

I'm out of this Cheese Shop!  Cheers...

[wjp]

Hi all,

Let me try to summarize ScummVM's license viewpoint.

ScummVM is licensed under the (unmodified) GPL, and has to stay that way,
simply because it is infeasible to contact all right holders and their
estates/heirs for a license change.

Many people have agreed to release their code under the specific text of the
GPL, and we can't just change that text retroactively, even if we personally
feel it is only a clarification and not a change with any legal effect.

We're more than willing to clarify our personal viewpoints on any issues you
raise in our FAQ, and in fact have a first draft about one such issue on our
development mailing list already.

However, ultimately of course the choice to distribute ScummVM is up to any
individual who wants to do so. If you or they feel uncomfortable with our
license, then so be it. If you feel you need clarification on legal issues, I
suggest contacting a lawyer, or possibly the Software Freedom Law Center may be
able to assist. Several commercial game releases include ScummVM however, and
their publishers have likely done their legal due diligence.

If you wish to twist our reasoning, that is also your choice, but I do not much
appreciate being called intellectually dishonest and morally reprehensible.

We would still potentially be interested in AGS support in ScummVM, but would prefer
discussions about this to be civil and constructive. The current directionless
bickering here seems to be neither.


Sincerely,
Willem Jan, ScummVM core developer

[bicilotti]

I will dive in this 12 pages topic to say that the discussion is getting out of our hand.
Artistic License 2.0 and GPLv2+ are compatible and I am sure that there is a technical solution to offer AGS games via SCUMMVM without having them open sourced (I will use the layman term 'repackaging' even if the question is slightly more complex).

Alas Rick, ScummVMers cannot change the license (because that would mean tracking down every single contributor and ask for her/his permission. You can't add words or clauses because you feel they are just clarifying a license, you just can't. it would be a legal abomination and in first place adding more 'restrictions' (again, layman term) is forbidden by the license itself.

The question raised by Monkey is interesting and requires attention (still the Gordian knot which would only mean such tainted games would not run on ScummVM, saving both parties from being tainted by the other).

The point of this post is: we can play the lawyers that we are not or discuss how technical could help us to be better prepared to solve those problems (whichever license will be chosen).

[sev]

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

[Sslaxx]

Do we have a formal spec anywhere for the AGS VM and datafile formats? If so, someone could put together a small (PD-licensed?) reference application to show how it goes together and the ScummVM team could work from that. As no AGS code would be used in that case, license (in)compatibility would not be a concern, although it'd naturally take longer to get a working implementation together.

[sev]

Do we have a formal spec anywhere for the AGS VM and datafile formats? If so, someone could put together a small (PD-licensed?) reference application to show how it goes together and the ScummVM team could work from that. As no AGS code would be used in that case, license (in)compatibility would not be a concern, although it'd naturally take longer to get a working implementation together.

This will not work. Nobody would work from the specs, it will give no benefit to anyone. Developing whole engine basing on the documentation is an enormous project and will definitely bring pain and incompatibilities.

As I've mentioned, APL code could be brought to GPL since GPL is more restrictive than APL is. We would rather base our work on the released code.


Eugene

[Calin Leafshade]

@ScummVM guys

Thank you so much for your input, it's very nice to know that you are interested in clarifying your position. I'm sure everyone appreciates that.

You should be aware than no one in this thread (Except CJ at this point) represents AGS and the negative comments of RickJ and whoever else should be considered their own opinion.

Since you guys are unarguably more experienced than any of us in running a large project would you care to share your opinion of what we should do next? How would you go about creating a system in which AGS can move forward in both compatibility and its feature set?

Am I to understand that you recommend making AGS *require* the ScummVM binaries? And then game developers distribute ScummVM with their game? If that were the case wouldnt the engine need to be *entirely* rewritten to conform with ScummVMs system? How would engine development continue? Would it need to be controlled by the ScummVM team or would development still rest with us?

I apologise if my questions appear overly obtuse but we, as a community, are not familiar with large sprawling projects like ScummVM and we really require some guidance from someone who is despite what people here would have you believe.

[fuzzie]

Am I to understand that you recommend making AGS *require* the ScummVM binaries? And then game developers distribute ScummVM with their game? If that were the case wouldnt the engine need to be *entirely* rewritten to conform with ScummVMs system? How would engine development continue? Would it need to be controlled by the ScummVM team or would development still rest with us?

Well, not sure we *recommend* that - we recommend the community chooses what would be best for them.

The suggestion of using ScummVM's framework is a technical one - we feel it's a lot easier to work with ScummVM's code, which we've spent a long time making highly portable etc, and it would help with refactoring/rewriting. Plus, you'd get a lot of development help/support from the ScummVM team.

However, if the GPL is a problem due to things like Steam plugins, then someone would have to reimplement a new (non-GPL) version of the ScummVM framework code in order to distribute a non-GPLed AGS runtime, which would probably be a lot of work. Something only the AGS community could decide.

My personal preference (as a ScummVM dev) would be for us to just write a new AGS engine from scratch, as part of ScummVM, using the existing code as a reference, for the purpose of running the older existing games. Obviously if there's some way we could help out with the AGS community's development goals, that would be preferable over simply duplicating all the effort.

[Calin Leafshade]

However, if the GPL is a problem due to things like Steam plugins, then someone would have to reimplement a new (non-GPL) version of the ScummVM framework code in order to distribute a non-GPLed AGS runtime, which would probably be a lot of work. Something only the AGS community could decide.

Is that really an issue? Surely if scripting code within a games data files is not subject to the GPL then neither are plugins bundled with a game. There's no in-kind difference between the two.

[fuzzie]

Is that really an issue? Surely if scripting code within a games data files is not subject to the GPL then neither are plugins bundled with a game. There's no in-kind difference between the two.

I would summarise as "the definition of derivative works is hideously complicated, and you'd need a few weeks of time from a lawyer". The GPL FAQ says "If the program dynamically links plug-ins, and they make function calls to each other and share data structures, we believe they form a single program, which must be treated as an extension of both the main program and the plug-ins", and (as someone unfamiliar with AGS) it looks like a plugin using a ScummVM version of IAGSEngine would definitely be included in that category - as opposed to the far more 'hands-off' use by the scripting code, which is more of an 'interpreter' situation.

[sev]

Am I to understand that you recommend making AGS *require* the ScummVM binaries? And then game developers distribute ScummVM with their game? If that were the case wouldnt the engine need to be *entirely* rewritten to conform with ScummVMs system? How would engine development continue? Would it need to be controlled by the ScummVM team or would development still rest with us?

AGS badly requires maintainability. Working with 29k+ lines of code ac.cpp file is hardly possible. Thus,  it has to be refactored/rewritten, whatever.

Another area what AGS needs to clear is portability.

ScummVM offers you both things, i.e. we have developed standards for maintainability, and portability. Follow our standards, use our framework and you will reach these goals.

Of course, you may decide to learn from us and go your own path, but implementing support for 30+ platforms took 10 years for us. You can save tons of time.

As of whether rewrite or not. Current code needs heavy refactoring. That is, take the individual function code, and put it into classes, rethink the architecture. fuzzie calls it 'from the scratch,' but I know she implies 'reuse 40-60% of the code.' Rewriting it completely from the scratch would result in huge amount of bugs which is a motivation killer.

We have experience with porting engines to our infrastructure, most recent cases be FreeSCI and Sołtys. These usually undergo exactly the same process of refactoring and cleaning up. So I do not see this as a big problem, just a challenge.

The development may go as it is now. After all you do not want to break compatibility with previous versions of the engine. Our current release schedule is 6 months, which IMHO is enough to roll out stable version of an engine. Of course there are daily builds for those who like to be on the cutting edge. This developed release management will let you test your code better. Again, it is used to be a one man project, which did not require any integration testing. Once there will be 2 developers working on the same code, the issues will rise. Besides, six months releases are for the major versions. Minor versions aka bugfix releases are usually go 1-2 months after the main release. These are intended for hotfixes.

In essence, only release cycle will be governed by ScummVM, but trust me, you will have hard time with making more frequent releases. It is a volunteer project. Of course, you will have no blind freedom of touching other parts of our infrastructure, and will be forced to go the route everyone else goes, i.e. plan and discuss beforehand changes to the core code, since it affects all of the ports, 65 developers and 1.3 million lines of code. But again, this is exactly what makes ScummVM rock and stable.


Eugene

[RickJ]

Eugene thank you so much for listening and for your thoughtful post.

[quote autor=fuzzie]
I would summarise as "the definition of derivative works is hideously complicated, ...
[/quote]
Fuzzie, I couldn't agree with you more on this point.  Lawyers can't even figure out what it actually means.  In the two documents I linked in my previous post they conclude that it depends on the jurisdiction, on what the copyright holders think it means, and a hos t of other things. 

That's why I said there needs to be clarification.  IMHO, the license is the best place.  But since it appears that this is not possible in practice then unequivocal statements similar to Sev 's post (see below) will have to suffice.

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.

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.

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.

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.   

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.

Something like this has been in my mind also but based on what everyone was saying it just didn't seem possible or worth the mention.  Thanks for bringing sanity into the discussion. 

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.

I think everyone is in agreement on this point.  There are recent discusions here about the need to refactor and how to proceed.   

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

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. 

Also, I would highly recommend monkey_05_06 as a sort of technical liaison between the two groups.  I have no idea if he would be interested in such a role however he does possess excellent deep diving skills and is extremely tenacious when it comes to understanding, in great detail, how things work.   He and I often disagree in our technical discussions but I can say that he always makes good points and usually tells me things I didn't know or hadn't thought about.    He also seems quite interested in the re-factoring of the engine.

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.

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?   

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,  again many thanks for the generous helping of sanity.  I look forward to future discussions.