AGS Is Going Open-Source!

[CJ-AGS]

aryah, I'm not sure why you claim this is "negative".

I've said that, should the ScummVM team want to, they are welcome to go ahead and implement support for running AGS games into ScummVM.

All I'm saying is that, at the current time, I don't want future AGS development to be controlled within ScummVM. Also, the GPL is too restrictive for my tastes and I wouldn't want AGS to be bound by that.

The idea of using ScummVM to run old (AGS 2.x) games is an interesting one, and something I would support -- as Barky says, this would be getting ScummVM to do what it's best at -- running old unsupported games on modern platforms.

[DrMcCoy]

I've said that, should the ScummVM team want to, they are welcome to go ahead and implement support for running AGS games into ScummVM.

Well, that would work for 2.x, which I understand is fixed and not further developed anymore (correct me if I'm wrong), this is all fine and dandy.
But for the still in active development and very much in flux 3.x version (again, correct me if needed), playing catch-up is no fun. I'd consider it torture.
I also don't think that would work. At all.

All I'm saying is that, at the current time, I don't want future AGS development to be controlled within ScummVM.

Which I for one consider to be a bit sad. We're a fun and (in general) happy little family. Merging with an lively community like the AGS one is something I'd see as a good thing, for both sides. Then again, I am an "inclusionist", and opinions might differ (on both sides).

Also, the GPL is too restrictive for my tastes and I wouldn't want AGS to be bound by that.

IANAL, but I think you can still (dual-?)license your part of the code, the AGS engine, under a compatible license, like the Artistic License.

Also, if you excuse a moment of snide remarks (that are my own alone, since I can't speak for other ScummVM devs):
That's a bit funny, considering that you've in that past rejected open source in general in favour of going closed source (even more restrictive than the Artistic License)...
Sorry, but I for one still feel a bit...sore about that, since I think that was a really stupid, damaging and sad move on your part. If you look through the comment history about AGS on this forums, you're probably going to find such comments from me I made in the past, so I thought I best lay it open, in the sense of honest discussion.
I am, of course, very happy and giddy that you've now opened the AGS source. I always liked the idea of AGS, loved many games using it (Yahtzee's games especially), and even though I loath Allegro, I was always happy that at least a limited Linux port existed. You're in part responsible for many happy hours I had.

The idea of using ScummVM to run old (AGS 2.x) games is an interesting one, and something I would support -- as Barky says, this would be getting ScummVM to do what it's best at -- running old unsupported games on modern platforms.

Agreed.
This would probably be less "controversial" among the ScummVM team too, I guess.

[fingolfin]

Hi Chris! Nice that you are here and participating in the discussion, I appreciate that .

aryah, I'm not sure why you claim this is "negative".

I can't speak for aryah, of course, but I interpreted the "negative" as simply the converse of "affirmative", without a judgmental connotation. Of course that's just my take... Anyway, let's not get hung up on how some people phrase certain things .

I've said that, should the ScummVM team want to, they are welcome to go ahead and implement support for running AGS games into ScummVM.

That's a clear word, thanks. In the past, one of the major reasons I always opposed any work on AGS support was that my impression (which of course was subjective and possibly wrong) was that you didn't want us to do that, and we don't like adding support for games against the will of their creator(s).

That said, I am not sure if anybody on or off the team is interested in working on AGS support, but if anybody is, then it's good to know for them that this fundamental blocker is gone.

All I'm saying is that, at the current time, I don't want future AGS development to be controlled within ScummVM. Also, the GPL is too restrictive for my tastes and I wouldn't want AGS to be bound by that.

I think I understand where you are coming from, and I respect it, even though I may not quite agree -- but as I said, AGS is your baby, and it's your decision.

Note that the ScummVM team is not interested as such in "controlling AGS". Nor in making games, or in taking away AGS from you.

However, if the code is not GPL (which would allow us to "share" control) then this also means that the full power of the ScummVM team won't be able to help with AGS development either. Which in my (admittedly very much biased!) view is a kind of sad thing: We have an excellent track record at taking engines in source form, refactoring them cleanly, making them highly portable, even melding multiple engine versions together, to get one uber-engine that runs all games supported by previous incarnations of the engine, across a wide range on devices.

Looking at the existing AGS source, it definitely could stand a major overhaul -- of course retaining full backwards compatibility would have to be a central goal, too.

Now, I assume you with the help of the AGS community you already planned some things here. But if we, the ScummVM team, took AGS and implemented, say, 2.x compatibility, then we'd be doing all that refactoring on our fork of the code, while you would be doing completely different changes on your official / primary fork of AGS. The result would be two divergent lines of the code, which would then be more difficult to unify later on, if that would ever be desirable. In particular, a lot of changes would probably have to be done twice; or worse, one version of the code would get a fix / cleanup applied, while another wouldn't. That's unfortunate, although of course not with precedence throughout the history if adventure engine development (the original LucasArts SCUMM engine had such moments in its development, too .

The idea of using ScummVM to run old (AGS 2.x) games is an interesting one, and something I would support -- as Barky says, this would be getting ScummVM to do what it's best at -- running old unsupported games on modern platforms.

Actually, "running old unsupported games on modern platforms" is a somewhat oversimplified summary of what we excel at, I dare say . Typically and IMHO, engines leave our hands in a much better state than they came in . Bug fixes, cleaning up code messes, refactoring unwieldy code to become readable again, melding multiple versions of an engine together into one, etc. are what we do, too.

Anyway, if AGS 2.x is not changing anymore, then yeah, maybe it would be OK if people wanted to work on a ScummVM engine for that. Depending on how different AGS 3.x is from AGS 2.x, that might be best anyway. I can't tell myself, though, as I only saw the AGS 3.x code in your SVN repository, and don't know how AGS 2.x looks or where to find it.

Oh, and then there is the issue of plugins... I am told that many AGS adventures rely on (possibly closed source) plugins, which of course also impedes portability, as we well as the ability to support these games in ScummVM... Maybe that is a serious problem, too? Again, I don't know enough about AGS and its games to really judge, but hopefully others can fill in the holes.

[aryah]

Hi Chris! Nice that you are here and participating in the discussion, I appreciate that .

aryah, I'm not sure why you claim this is "negative".

I can't speak for aryah, of course, but I interpreted the "negative" as simply the converse of "affirmative", without a judgmental connotation. Of course that's just my take... Anyway, let's not get hung up on how some people phrase certain things .

Oh, yes that's what I meant - simply the opposite of saying 'yes'. BTW nice to see CJ's detailed position actually isn't incompatible (as I initially assumed) with running older AGS games in ScummVM, so I can still hope it happens!

(AGS includes HQ3X, btw.)

oh; my bad - need to find that option, then; I only recently tried using it (in wine, 'journey down'), it left my screen in some incredibly tiny resolution after exiting (I'll play w it further)

[Barky]

Which I for one consider to be a bit sad. We're a fun and (in general) happy little family. Merging with an lively community like the AGS one is something I'd see as a good thing, for both sides. Then again, I am an "inclusionist", and opinions might differ (on both sides).

I'm not sure what CJ's reasons are, but I think the "community" issue is one of the main argument against fully merging. AGS has an established social fabric, and I guess ScummVM does too, which you risk disrupting by combining the communities. The two cultures are not going to be 100% compatible on all issues. (For example, would ScummVM even welcome an influx of a whole bunch of people who have no interest in Open Source or engine development, with lots of talk about their homemade adventure game projects that may or may not ever be completed?)

I made this point on the AGS forums: I think if we do find that there's a benefit to working together, the best thing would be a collaboration where the communities maintain autonomy, contributing to a shared codebase but still having separate names, websites and forums.

IANAL, but I think you can still (dual-?)license your part of the code, the AGS engine, under a compatible license, like the Artistic License.

Is this feasible? Could (and would) ScummVM contributors work on dual-licensed code, or would any contributions from the ScummVM side be GPL-only? Since:

However, if the code is not GPL (which would allow us to "share" control) then this also means that the full power of the ScummVM team won't be able to help with AGS development either.

(I assume that a game made in AGS distributed with a hypothetical ScummVM backend would not have to go GPL, as long as it acknowledged and pointed to the source of the engine.)

But if we, the ScummVM team, took AGS and implemented, say, 2.x compatibility, then we'd be doing all that refactoring on our fork of the code, while you would be doing completely different changes on your official / primary fork of AGS. The result would be two divergent lines of the code, which would then be more difficult to unify later on, if that would ever be desirable. In particular, a lot of changes would probably have to be done twice; or worse, one version of the code would get a fix / cleanup applied, while another wouldn't. That's unfortunate, although of course not with precedence throughout the history if adventure engine development (the original LucasArts SCUMM engine had such moments in its development, too .

Here's one idea:

If AGS-ScummVM could be developed under dual license, then engine devs from both sides could work on refactoring and fixing up the current state of the code, and the AGS people could have a dev branch for new versions of the engine that would not be "controlled by" ScummVM (i.e. it'd have its own release process and schedule). The ScummVM team could then decide when to merge the stable versions of that branch back into ScummVM. As long as there's some overlap among the developers and some understanding of the conventions and architecture of the ScummVM framework among the AGS devs, merging their changes should not be too difficult.

My hope is that this would realize the positive potential of a merger, achieving a high-quality, highly portable code base for AGS and extending the compatibility of ScummVM to a huge new library of games, while avoiding the downsides by reducing the "moving target" problem for ScummVM while giving AGS the freedom to continue to enhance the engine at its own pace.

[fingolfin]

DISCLAIMER: I am not really arguing for or against including AGS into ScummVM, merging the projects, etc., etc. -- I just want to reply to some questions, clarify some points, explain what I think is possible and what not. So, just because I say something is difficult does not mean it is impossible; just because I say something is easily doable does not mean I want it to be done.
Moreover, these are my personal views, I am not the dictator of the ScummVM project.

Which I for one consider to be a bit sad. We're a fun and (in general) happy little family. Merging with an lively community like the AGS one is something I'd see as a good thing, for both sides. Then again, I am an "inclusionist", and opinions might differ (on both sides).

I'm not sure what CJ's reasons are, but I think the "community" issue is one of the main argument against fully merging. AGS has an established social fabric, and I guess ScummVM does too, which you risk disrupting by combining the communities. The two cultures are not going to be 100% compatible on all issues. (For example, would ScummVM even welcome an influx of a whole bunch of people who have no interest in Open Source or engine development, with lots of talk about their homemade adventure game projects that may or may not ever be completed?)

I made this point on the AGS forums: I think if we do find that there's a benefit to working together, the best thing would be a collaboration where the communities maintain autonomy, contributing to a shared codebase but still having separate names, websites and forums.

I actually don't see a problem with people discussing development of AGS games in an AGS subforum of this forum (or a set of multiple such subforums). However, I also don't see a need to abandon your existing forums and infrastructure for that.

After all, the people who are working on the engine usually only have a small overlap with the people who are using the engines. Of course, they need to talk to each other -- but this can happen in both forums *and* mailing lists *and* private email etc. What would be important, though, is that all people who would actually be working on the AGS (engines) have a common place where they can discuss and plan things. This place could be here, there, a new mailing list, an existing mailing list, whatever... I actually don't perceive a problem here.

IANAL, but I think you can still (dual-?)license your part of the code, the AGS engine, under a compatible license, like the Artistic License.

Is this feasible? Could (and would) ScummVM contributors work on dual-licensed code, or would any contributions from the ScummVM side be GPL-only? Since:

However, if the code is not GPL (which would allow us to "share" control) then this also means that the full power of the ScummVM team won't be able to help with AGS development either.

(I assume that a game made in AGS distributed with a hypothetical ScummVM backend would not have to go GPL, as long as it acknowledged and pointed to the source of the engine.)

Depends on what you mean with "the game". The source code of the *engine*, if it contained *any* of ScummVM's GPL-only code, would have to be completely released to the public, licensed under the GPL *in addition to whatever other license you like to put on it*. On the other hand, the game scripts of course don't have to be open sourced. At least in our interpretation of the GPL, the Debian folks might disagree, but frankly that's their problem.

Having a dual-license AGS engine inside ScummVM is a difficult issue. In theory, it would be possible. Let's assume the ScummVM team members agree. We could then mark all code in the hypothetical engines/ags/ directory as being dual-licensed under GPL and artistic license. And we could set it up in such a way that changes made there are also automatically covered by the dual license. And so in theory, somebody else (say the "AGS Team") could take any of the changes they like in there, and merge it into their version of the code, which could be "artistic license" only.

However, I have strong doubts of the real-world usefulness of this. You see, if the engine was to be integrated inside ScummVM, then it would have to be converted to use our infrastructure code. It would use our OSystem backend interface. It would make use of our audio, graphics, video and gui code -- anything else wouldn't make sense.

Thus, quite some of the changes we would make would be completely useless without somebody also making a clean-room re-implementation of our infrastructure code, licensed under the Artistic license. Which would be a *major* undertaking, and a quite unrewarding one.

Of course we'd also make ton of refactoring changes that could benefit the regular AGS version, but these would necessarily be intertwined with changes necessary to make AGS use the ScummVM frameworks, and untangling those likely would be too much work to pay off.

In addition, the fact that AGS uses Subversion for version control makes cross-repository cooperation much more difficult. If AGS was using git (or mercurial, bazaar), then it would at least be relatively easy to cherry pick individual changes from each other and so keep two separate but cooperating repositories. But doing that manually with SVN is quite painful. Alas, that's just a minor technical problem, considering the much bigger issues I just sketched.

So, as long as AGS insists on wanting a completely Artistic licensed source code version, there is no real potential for close cooperation in my eyes.

That said, I don't understand the desire for a non-GPL, artistic-only licensed version of the engine anyway. As alluded to above, the hope that this could be used to implement copy protection is IMHO completely unrealistic. And it is not necessary to keep people from cheating at in-game puzzles either, because you could still keep the script code of your games secret / closed. Lastly, if there is a closed source version diverging from the open source version, that greatly hampers the portability goal.

But if we, the ScummVM team, took AGS and implemented, say, 2.x compatibility, then we'd be doing all that refactoring on our fork of the code, while you would be doing completely different changes on your official / primary fork of AGS. The result would be two divergent lines of the code, which would then be more difficult to unify later on, if that would ever be desirable. In particular, a lot of changes would probably have to be done twice; or worse, one version of the code would get a fix / cleanup applied, while another wouldn't. That's unfortunate, although of course not with precedence throughout the history if adventure engine development (the original LucasArts SCUMM engine had such moments in its development, too .

Here's one idea:

If AGS-ScummVM could be developed under dual license, then engine devs from both sides could work on refactoring and fixing up the current state of the code, and the AGS people could have a dev branch for new versions of the engine that would not be "controlled by" ScummVM (i.e. it'd have its own release process and schedule). The ScummVM team could then decide when to merge the stable versions of that branch back into ScummVM. As long as there's some overlap among the developers and some understanding of the conventions and architecture of the ScummVM framework among the AGS devs, merging their changes should not be too difficult.

My hope is that this would realize the positive potential of a merger, achieving a high-quality, highly portable code base for AGS and extending the compatibility of ScummVM to a huge new library of games, while avoiding the downsides by reducing the "moving target" problem for ScummVM while giving AGS the freedom to continue to enhance the engine at its own pace.

I actually don't think that the pace of the engine change is a problem for ScummVM; it would only be a problem if we had one version of AGS and the AGS folks another version, and we would have to track the latter. *That* would be crazyiness. If the engine development teams were identical, or at least shared some overlap and were working on two closely related versions of the engine (both GPL, both in their own git repositories, with regular cross merges), however, then the speed of advancement of the engine wouldn't be a problem...

By the way, the ScummVM team has relatively strict requirements on code quality and things like keeping backward compatibility, keeping your code portable etc. This is actually another limiting factor with merging the teams: AFAIK, only Chris Jones has major contributions in the AGS engine, and as such could qualify for full developer membership in the ScummVM team (assuming his modern code is nicer than the original AGS code *grin*). But we don't just hand out repository write access to arbitrary people without a track record.

That's actually yet another reason why development using git (or mercurial, bazaar) instead of SVN is so much nicer and more open: We don't *have* to hand out write acces to anybody. People can just fork our repository, make their changes, and then submit them back (on github.com, this is super easy using their web interface). We can then merge their code, and it's almost as good as having direct write access, only you get code review atop (and sometimes may have to redo your changes because issues with it are pointed out to you).

[LordHoto]

IANAL, but I think you can still (dual-?)license your part of the code, the AGS engine, under a compatible license, like the Artistic License.

Is this feasible? Could (and would) ScummVM contributors work on dual-licensed code, or would any contributions from the ScummVM side be GPL-only? Since:

I can only speak for myself I would not work on something dual licensed under the Artistic License and GPL. Then again that wouldn't be too bad since that just would rule out me working on the possible AGS engine.

However, if the code is not GPL (which would allow us to "share" control) then this also means that the full power of the ScummVM team won't be able to help with AGS development either.

(I assume that a game made in AGS distributed with a hypothetical ScummVM backend would not have to go GPL, as long as it acknowledged and pointed to the source of the engine.)

As Fingolfin explained already if you would distribute a binary utilising ScummVM code and your AGS engine in it it would have to be GPL. There is nothing that can be done about that, even when you just link against ScummVM's backend your code needs to be GPL.

Also relicensing ScummVM's common "framework" code under Artistic License is out of the question here. There is code from people who contributed, who might not be fine with it, like I would for one never ever accept that for my code in ScummVM.

Moreover, these are my personal views, I am not the dictator of the ScummVM project.

Damn, you are not? Why didn't one tell me that earlier... :-P


EDIT: Don't get me wrong, I have no problems with an AGS engine inside ScummVM, just merely saying that the licensing will probably be an issue here.

[Barky]

Depends on what you mean with "the game". The source code of the *engine*, if it contained *any* of ScummVM's GPL-only code, would have to be completely released to the public, licensed under the GPL *in addition to whatever other license you like to put on it*. On the other hand, the game scripts of course don't have to be open sourced. At least in our interpretation of the GPL, the Debian folks might disagree, but frankly that's their problem.

I was thinking about the fact that AGS games are typically distributed with the engine bundled in the same EXE. If they did this with an AGS version that would use (GPL-licensed) ScummVM as a backend, I don't think it would be acceptable if that required them to GPL the game scripts.

To make it a little more complicated, some devs, e.g. The Journey Down team, are talking about tweaking the engine (to add support for widescreen resolutions) for their games. I can imagine in some situations it would be hard to separate the "game script" from the "engine code," if custom engine features are closely tied to the particular game.

However, I have strong doubts of the real-world usefulness of this. You see, if the engine was to be integrated inside ScummVM, then it would have to be converted to use our infrastructure code. It would use our OSystem backend interface. It would make use of our audio, graphics, video and gui code -- anything else wouldn't make sense.

Thus, quite some of the changes we would make would be completely useless without somebody also making a clean-room re-implementation of our infrastructure code, licensed under the Artistic license. Which would be a *major* undertaking, and a quite unrewarding one.

What I was vaguely imagining was that the current AGS engine would be refactored/rewritten to match the ScummVM OSystem API, so there'd be a non-ScummVM backend that did not rely on GPL'd code.

Admittedly, I have no idea whether that is at all feasible given the codebase, and even if it was doable I can see that everyone might not be happy about it.

So, as long as AGS insists on wanting a completely Artistic licensed source code version, there is no real potential for close cooperation in my eyes.

Yeah, it's not looking so promising. Maybe it's best to leave it for now and see how AGS comes along as an open source project. The situation might look different once the code is cleaned up, more developers are familiar with the engine, and the whole thing is genuinely a team product.

Of course, in the mean time ScummVM team members are welcome to contribute to AGS as well.

[fingolfin]

Depends on what you mean with "the game". The source code of the *engine*, if it contained *any* of ScummVM's GPL-only code, would have to be completely released to the public, licensed under the GPL *in addition to whatever other license you like to put on it*. On the other hand, the game scripts of course don't have to be open sourced. At least in our interpretation of the GPL, the Debian folks might disagree, but frankly that's their problem.

I was thinking about the fact that AGS games are typically distributed with the engine bundled in the same EXE. If they did this with an AGS version that would use (GPL-licensed) ScummVM as a backend, I don't think it would be acceptable if that required them to GPL the game scripts.

Simple solution: Distribute the game in two files, one for the engines, and one for the data file.

To make it a little more complicated, some devs, e.g. The Journey Down team, are talking about tweaking the engine (to add support for widescreen resolutions) for their games. I can imagine in some situations it would be hard to separate the "game script" from the "engine code," if custom engine features are closely tied to the particular game.

Actually, I cannot imagine any such situation, unless I assume that the authors either do something very wrong, or that they are very selfish and do not want to release their engine improvements to the public. But of course just because *I* cannot imagine such a scenario doesn't mean it could exist .

For the example you give, I propose this simple solution: Make the widescreen resolution support open source, too, keep your game scripts closed source. This would be fitting the community spirit, wouldn't it? They benefit from the AGS engine, and give back their improvements to the community, while still being able to write their own unique game.

By the way, I would strongly suggest this approach regardless of GPL or Artistic License, and regardless of whether AGS becomes part of ScummVM. The primary difference is that the GPL enforces that people are not selfish and share their improvements to the engine, while the Artistic license allows anybody to take AGS, improve it greatly, and then share the improvements with nobody. All they have to do is changes the name AGS to something else.

Once more, though, this also boils down to a matter of world views and what the community considers just and fair. I for one wouldn't want my code to be abused so; and many other ScummVM team members feel alike. I wonder if some AGS community people might feel the same... ?

In fact I was very surprised when I saw that Chris Jones chose this license. Given his past statement about open source and how he was "burned" by it... To me it seems that the Artistic license is just *perfect* for anybody who wants to "burn" you. It allows a company to take AGS, call it AGSPro, offer licenses for money (*any* license they like), and keep the source closed otherwise. So, with Artistic, it is *trivial* and even *legal* to burn Mr. Jones. The GPL on the other hand he rejected in the past because for it to protect his rights, he'd have to sue anyhow. Well, truth is, if somebody steals your code (and this *has* happend to ScummVM, by the way), then in the end you may have to sue regardless of everything else, sad as it is. But at least with GPL you have something to sue over, plus this has been well-tested and proven in court.
With Artistic, though, Chris Jones explicitly allows these people to sell his baby under their own name. I just don't understand it...

However, I have strong doubts of the real-world usefulness of this. You see, if the engine was to be integrated inside ScummVM, then it would have to be converted to use our infrastructure code. It would use our OSystem backend interface. It would make use of our audio, graphics, video and gui code -- anything else wouldn't make sense.

Thus, quite some of the changes we would make would be completely useless without somebody also making a clean-room re-implementation of our infrastructure code, licensed under the Artistic license. Which would be a *major* undertaking, and a quite unrewarding one.

What I was vaguely imagining was that the current AGS engine would be refactored/rewritten to match the ScummVM OSystem API, so there'd be a non-ScummVM backend that did not rely on GPL'd code.

Admittedly, I have no idea whether that is at all feasible given the codebase, and even if it was doable I can see that everyone might not be happy about it.

It's not about whether it is feasible -- rather, it completely misses the point .

First off, the ScummVM OSystem API *itself* is licensed under the GPL. Secondly, the backends (one for each system we run on) are under the GPL; even if you could write a non-GPL backend (which you can't), then you'd have to do that for every single system ScummVM runs on, at which point there is no reason to use ScummVM / OSystem at all anymore.

Lastly, any frontend (=engine, such as AGS would be) contained inside ScummVM must make use of GPL'd stuff, such as OSystem, and ideally also our infrastructure code. Otherwise, there wold be tons of code duplication, which we don't like, for many good reasons (duplicated code means more maintenance work, means duplicated bugs, means increased code size and ram usage, means incoherent program behavior, and many other bad things).

This is why I stated earlier that I don't believe that a dual-licensed version of the AGS engine would help much. It would only work if we could cleanly separate the parts that interface with ScummVM from the rest. This might be possible, but I'd need to evaluate the code more closely to know for sure; but I have my doubts whether this would a beneficial avenue. All that work put into making such a separation would be much better spent on cleaning up the engine overall. That in turn then would make future improvements to the engine so much easier...


So, to sum up, as long as AGS is under the Artistic License, I don't perceive a great chance for much collaboration. Our world views and goals are too different. That said, maybe it would indeed make sense for us to work on AGS 2.x support, but then as far as I know, that version of AGS has not been open sourced. Sad .

[maximus]

...
So, to sum up, as long as AGS is under the Artistic License, I don't perceive a great chance for much collaboration. Our world views and goals are too different. That said, maybe it would indeed make sense for us to work on AGS 2.x support, but then as far as I know, that version of AGS has not been open sourced. Sad .

I PM'd Chris a couple days ago about the possibility of getting the 2.7.x code as well. I agree that it would probably make more sense to try to implement that first, then see about implementing features from the stable branches as they are released.

[Barky]

Simple solution: Distribute the game in two files, one for the engines, and one for the data file.

Right. Yeah, that sounds like it would do the trick. LordHoto's reply made it sound like all games distributed with a ScummVM-based engine would have to be fully open-sourced.

For the example you give, I propose this simple solution: Make the widescreen resolution support open source, too, keep your game scripts closed source. This would be fitting the community spirit, wouldn't it? They benefit from the AGS engine, and give back their improvements to the community, while still being able to write their own unique game.

I think that's what the JD guys plan to do. I was just citing them as an example of game developers tweaking the engine.

I'm gonna skip the FOSS license discussion, since it's besides the point. Personally I'd not mind if AGS went GPL (given that it's completely clear that games distributed with the engine would not need to be open source), but since CJ is against it I respect that, and so I've been trying to come up with a way that would allow us to have a working build of AGS under the Artistic License while also being compatible with ScummVM (understanding that that build would be GPL-only).

What I was vaguely imagining was that the current AGS engine would be refactored/rewritten to match the ScummVM OSystem API, so there'd be a non-ScummVM backend that did not rely on GPL'd code.

Admittedly, I have no idea whether that is at all feasible given the codebase, and even if it was doable I can see that everyone might not be happy about it.

It's not about whether it is feasible -- rather, it completely misses the point .

First off, the ScummVM OSystem API *itself* is licensed under the GPL. Secondly, the backends (one for each system we run on) are under the GPL; even if you could write a non-GPL backend (which you can't), then you'd have to do that for every single system ScummVM runs on, at which point there is no reason to use ScummVM / OSystem at all anymore.

I'm not an expert by any stretch, but I don't think you can copyright/GPL-protect an API? If someone were to write, from scratch, a class with the same interface as OSystem (even if they did this by referring to the documentation), I believe that's permitted.

Second, the point wasn't to build a backend to match the portability of ScummVM, but just to have one backend that doesn't rely on ScummVM code, so that it's possible to distribute a working AGS build under the Artistic License. I imagined this separate backend to be similar to the current AGS engine in its portability, i.e. Windows, Mac and Linux (once a few seemingly minor issues are resolved).

Lastly, any frontend (=engine, such as AGS would be) contained inside ScummVM must make use of GPL'd stuff, such as OSystem, and ideally also our infrastructure code. Otherwise, there wold be tons of code duplication, which we don't like, for many good reasons (duplicated code means more maintenance work, means duplicated bugs, means increased code size and ram usage, means incoherent program behavior, and many other bad things).

This is why I stated earlier that I don't believe that a dual-licensed version of the AGS engine would help much.

Yes, and that's why I agreed with you. As you say, while it might be possible to create a clean separation of Artistic-licensed AGS code and GPL-licensed ScummVM code (plus an alternative backend that used the same interface), the amount of work this would involve and how it would limit the potential efficiency savings make the whole thing look much less attractive.

That said, maybe it would indeed make sense for us to work on AGS 2.x support, but then as far as I know, that version of AGS has not been open sourced. Sad .

Not yet, but since CJ has said he doesn't oppose a ScummVM port, I'm sure that could be arranged.

[fingolfin]

I'm not an expert by any stretch, but I don't think you can copyright/GPL-protect an API? If someone were to write, from scratch, a class with the same interface as OSystem (even if they did this by referring to the documentation), I believe that's permitted.

Of course you can copyright and license an API, whole industries are relying on that . But anyway, this is besides the point, and I don't really want to argue the finer points on whether we own copyright on OSystem or not.

Because we are not really talking about a simple clearly defined "API" here. I just used that word as simple, mostly appropriate but not 100% accurate description.

The ScummVM "API" is a living, constantly evolving set of code that provides functionality to frontends. This includes the entirety of the audio, common, graphics, gui and video directories in ScummVM, and chunks of backends. All of these are GPLed and heavily used by any engine. You'd have to (re)implement all of those, too.

Let's ignoree any legal issues for the moment. Even then, while the above is not completely impossible, it would be rather insane and a major waste of resources to attempt it. You'd need hundreds or thousands of man-hours to pull this off. Time that would be much better spent on improving the AGS engine, or the existing ScummVM code base.

Second, the point wasn't to build a backend to match the portability of ScummVM, but just to have one backend that doesn't rely on ScummVM code, so that it's possible to distribute a working AGS build under the Artistic License.

Yeah, I got that... and as I explained, I don't think that is possible. And even if it was: To what end?

I imagined this separate backend to be similar to the current AGS engine in its portability, i.e. Windows, Mac and Linux (once a few seemingly minor issues are resolved).

In many ways this would be like the "worst of both worlds":

See, one major advantage for integrating AGS into ScummVM (at least in my eyes) is synergy: The AGS folks can focus on what they do best, namely work on AGS and improve it. While the ScummVM side would provide a highly portable framework, lots of very experienced and active developers who could help with the adaption and portability; most importantly, we bring a lot of *knowledge* about portability, amongst other things. We represent an accumulation about adventure engines and how they can implement and do things that I don't believe is paralleled anywhere in the industry.

But the whole "re-create the non-frontend parts of ScummVM under the artistic license" business would force the AGS people to work on reimplementing code that already exists and works well, instead of working on the AGS engine. Also, none of the ScummVM folks would be interested in helping with this; to the contrary, this would create a kind of competition scenario. And it would be a never-ending task, too: As I said, ScummVM does not contain a single fixed "API", rather, this is a living thing: If an API is not flexible enough, we just change it. This means that external code constantly has to track changes we make.

So in this scenario everybody looses.

So, really, if the AGS team insists on the Artistic license (which of course is your right, no argument there), then its best bet is to work alone, and not touch ScummVM at all. This way you don't get any benefits from us, but you also don't heaps of energy on a pointless effort to reimplement our code

In the meantime, we are of course free (by the terms of the Artistic license) to make our own implementation of the AGS engine, either using the code in there, or using our own obtained from (clean room?) RE work.

That said, maybe it would indeed make sense for us to work on AGS 2.x support, but then as far as I know, that version of AGS has not been open sourced. Sad .

Not yet, but since CJ has said he doesn't oppose a ScummVM port, I'm sure that could be arranged.

Could have, would have, should have... We'll see what happens.

[LordHoto]

Simple solution: Distribute the game in two files, one for the engines, and one for the data file.

Right. Yeah, that sounds like it would do the trick. LordHoto's reply made it sound like all games distributed with a ScummVM-based engine would have to be fully open-sourced.

I am not sure where I talked about games though. I said engine(s).

[Barky]

Of course you can copyright and license an API, whole industries are relying on that .

No, I'm pretty sure you can't. There's a long history in computers of cloning APIs, and legal precedent (e.g. Lotus v. Borland, Sony v. Connectix) seems to support it. That's how AMD could go on making Intel-compatible CPUs after they lost the license, how Wine can emulate Windows, etc. In fact, unless all the engines have been explicitly donated to the project, I would assume this is the legal principle that allows ScummVM to reimplement the various game engines it supports.

Agreed that the point is pretty much moot, though.

Yeah, I got that... and as I explained, I don't think that is possible. And even if it was: To what end?

Like I said: "I've been trying to come up with a way that would allow us to have a working build of AGS under the Artistic License while also being compatible with ScummVM."

And we must be talking past each other, because I read you as saying it might be possible in principle, just not worth it.

See, one major advantage for integrating AGS into ScummVM (at least in my eyes) is synergy [...]

But the whole "re-create the non-frontend parts of ScummVM under the artistic license" business would force the AGS people to work on reimplementing code that already exists and works well, instead of working on the AGS engine. [...]

So, really, if the AGS team insists on the Artistic license (which of course is your right, no argument there), then its best bet is to work alone, and not touch ScummVM at all. This way you don't get any benefits from us, but you also don't heaps of energy on a pointless effort to reimplement our code

Right, that's the conclusion I've been agreeing with you about in the last couple of posts now! "The amount of work this would involve and how it would limit the potential efficiency savings make the whole thing look much less attractive. " "Maybe it's best to leave it for now."

In the meantime, we are of course free (by the terms of the Artistic license) to make our own implementation of the AGS engine, either using the code in there, or using our own obtained from (clean room?) RE work.

Sure. Didn't you already say you didn't want to do that, though?

Could have, would have, should have... We'll see what happens.

CJ has said he wants to release the earlier versions of the engine "in a consistent state with 3.2.1."

I am not sure where I talked about games though. I said engine(s).

Thanks for the clarification. That's not how I read your initial response, though:

I assume that a game made in AGS distributed with a hypothetical ScummVM backend would not have to go GPL

As Fingolfin explained already if you would distribute a binary utilising ScummVM code and your AGS engine in it it would have to be GPL. [...] even when you just link against ScummVM's backend your code needs to be GPL.

[fingolfin]

Yeah, I got that... and as I explained, I don't think that is possible. And even if it was: To what end?

Like I said: "I've been trying to come up with a way that would allow us to have a working build of AGS under the Artistic License while also being compatible with ScummVM."

And we must be talking past each other, because I read you as saying it might be possible in principle, just not worth it.

Ah, that was just me simplifying things down to conventional levels... Strictly speaking, of course it *is* possible (almost everything is possible, strictly speaking). But the reality is such that I think it would either take years, or heaps of money to do it, so I oversimplified it... But well, this, too, is a relatively moot point .