Initial AGS Engine Source Code release

Started by Pumaman, Wed 27/04/2011 01:55:57

Previous topic - Next topic

RickJ

Quote from: eriktorbjorn on Mon 30/01/2012 19:54:05
Quote from: RickJ on Mon 30/01/2012 07:37:15
Quote
But let's do a little thought experiment to get some clarity.  Suppose there is a GPL media player program that display a PNG file and plays an OGG file.  The programmer was very clever and so the binary and the source don't take up much space so the source, binary, and everything can be easily distributed together.   No I come along with a fabulous photo of myself and an OGG recording of me doing the funniest ever stand-up comedy routine.

I'm certainly no licensing expert, but I don't see any difference between the six cases you mention. In each of them, the player, the photo and the recording are separate works. The photo and the recording are yours to distribute, and the GPL allows you to distribute the player. You can even charge money for the whole thing, if you want to. Depending on the license of the photo and the recording, I may not be able to redistribute copies of the whole thing, but I should still be able to redistribute the player or request a copy of the source code for it.

What you describe, as I understand it, are different forms of distribution and I don't see why it would make any difference if you distribute on CD, as an ISO image, by carrier pigeon, or lovingly engraved on stone tablets. Even the self-extracting ZIP file should be ok. The GNU licensing FAQ explicitly says that an installer and the files it installs are separate works. I would guess that what the person you quoted meant is that if you embed the image and/or recording into the player itself, that could be a problem because then they would no longer separate. Your license could be violating the player's license by trying to impose additional restrictions on it.

But, as I said, I'm no expert on this.
I'm glad you agree with me on this.

eriktorbjorn

Quote from: RickJ on Sun 29/01/2012 19:40:20
Tim, the two responses you quote were not responsive to my suggestion, the quote I choose was where the poster "Well it seems plausible but the scumm team just doesn't seem to want to chase this pipe dream ...
Simple answer: No, won't happen - the scumm devs have other things to attend to..." and nobody disagreed with this assessment.

Well, you could read it that way... but when someone makes a sweeping generalization, basically saying "the scumm team doesn't want this, and you get banned for making suggestions", and the ScummVM project lead steps in to tell that poster that "thank you for speaking on the behalf of the ScummVM team" and then proceeds to contradict him on everything he said... I can't have been the only one who read that as a polite way of telling him "who are you, and what an earth are you talking about?"

(Incidentally, he could very well be right about the "scumm team" since they would be the subset of the ScummVM team who work primarily on the SCUMM engine. But that doesn't really mean anything, does it?)

Quote from: RickJ on Sun 29/01/2012 19:40:20
I asked the folks over there to opine on the idea of documenting a game file format common to both AGS and ScummVM not to do any work.   Instead of discussing the relative merits, potential benefits, and problems all I got was pretty much "Nobody wants to work on this."   It's as if they didn't even read my post or didn't understand what I said. 

So... instead of explaining to them that they misunderstood you (which could certainly happen when you have people from around the world using English as their lingua franca) or were getting off topic, you just went away? I did ask about something I saw as either a drawback, or a gigantic misunderstanding on my part. I guess I could always have worded it better - if it came across as confrontational, I apologize - but I never saw any reply telling me that I had misunderstood, so I forgot about it.

Quote from: RickJ on Sun 29/01/2012 19:40:20
It seems to me that anything I have to say is not taken seriously as if I were some kind of retard.

Well, I know that I at least never intended to imply any such thing. Personally, I think you're seeing insults where none were intended.

RickJ

Quote
. but when someone makes a sweeping generalization, basically saying "the scumm team doesn't want this, and you get banned for making suggestions"
I never said I got banned for making suggestions.  I said that the responses were negative and did  not address what I suggested. 

Quote
(Incidentally, he could very well be right about the "scumm team" since they would be the subset of the ScummVM team who work primarily on the SCUMM engine. But that doesn't really mean anything, does it?)
Pardon my ignorance on this point.  I was unaware there was a distinction between the two.

Quote
So... instead of explaining to them that they misunderstood you (which could certainly happen when you have people from around the world using English as their lingua franca) or were getting off topic, you just went away?
I have always been taught when you are a guest in someone else's house you should obey their house rules.  It wasn't my role to keep discussions in your forum on topic nor would I have any power to do so.

Btw, my wife's native language is Spanish, I help her run a medical interpretation business, and regularly present a "Working Through an Interpreter" seminar.  So I understand and am sensitive to the language issues you raise.  Thanks for calling my attention to scummvm's diverse demographics.   

Quote
I did ask about something I saw as either a drawback, or a gigantic misunderstanding on my part. I guess I could always have worded it better - if it came across as confrontational, I apologize - but I never saw any reply telling me that I had misunderstood, so I forgot about it.
I am not sure which post you are referring to.  But I also apologize if I took something you said the wrong way.  Frankly, I didn't perceive that anyone misunderstood but rather they were just being asses for the most part.  I don't mean to insult anyone but that is what I thought of the response I got.

Quote
Well, I know that I at least never intended to imply any such thing. Personally, I think you're seeing insults where none were intended.
Thank you for saying so.  I wasn't insulted, I just didn't see how anything could be accomplished by continuing the discussion with people who seem so intransigent.   

What do suggest the two communities cooperate?

eriktorbjorn

Quote from: RickJ on Mon 30/01/2012 21:53:23
I never said I got banned for making suggestions.  I said that the responses were negative and did  not address what I suggested. 

I didn't mean to imply that you did. I was thinking about the guy who replied that "the scumm team just doesn't seem to want to chase this pipe dream with evidence of this thread being in the junk yard portion of the forum and banning people who bother to suggest about the PSP ported model as being proof that it is possible." Never mind that I think he's twisting the meaning of the "junkyard" forum, I have absolutely no idea what that last part was referring to.

Quote from: RickJ on Mon 30/01/2012 21:53:23
Pardon my ignorance on this point.  I was unaware there was a distinction between the two.

I was just being a smart-ass. Sorry about that. "SCUMM" is what we call the engine used by the LucasArts adventure games. I'm told that this may be a slight misnomer; that SCUMM was the name of the authoring system ("Script Creation Utility for Maniac Mansion") and that the engine should really be called SPUTM, but the name has stuck. Originally, that was the only game engine ScummVM supported, and while others have been added over the years, the name "ScummVM" has also stuck. So when he said "scumm team" you could interpret that as the people who work on that engine and little else, but it's probably not really what he meant.

Quote
I have always been taught when you are a guest in someone else's house you should obey their house rules.  It wasn't my role to keep discussions in your forum on topic nor would I have any power to do so.

Perhaps, but if people misunderstand the subject and there are no further posts by the original poster, people like me are probably going to assume that, "oh well, I guess he wasn't that interested after all" and start talking about other things. Of course, in a few days I'll probably have forgotten about this boart - no malice intended - so I'm not exactly practicing what I'm preaching.

Quote from: RickJ on Mon 30/01/2012 21:53:23
Btw, my wife's native language is Spanish, I help her run a medical interpretation business, and regularly present a "Working Through an Interpreter" seminar.  So I understand and am sensitive to the language issues you raise.  Thanks for calling my attention to scummvm's diverse demographics.

Someone made a map of ScummVM developers several years ago - so it's probably badly out of date now - and back then it seemed like most of them lived in the northern half of Europe (mostly Germany), but there were still quite a few in other places and only a couple of them in English-speaking countries. Me, I'm from Sweden.

Quote
I am not sure which post you are referring to.  But I also apologize if I took something you said the wrong way.  Frankly, I didn't perceive that anyone misunderstood but rather they were just being asses for the most part.  I don't mean to insult anyone but that is what I thought of the response I got.

My concern was if a new game file format would mean that all the old games would have to be recompiled from the original game source code. (I'm not familiar with how AGS works, but I assume the games are scripted in some sort of custom programming language.) Because to me it sounded like that would mean tracking down all the authors (which could be difficult or even impossible) to get them to recompile the games (assuming the source code still exists), and if you're unlucky you may have to do it again because the translator turned out to have a bug in it.

Perhaps you meant that the translation could be made from the data files, rather than the source, but then I would think that it would be just as easy - or hard - to support the old data format directly. I assume it's pretty much frozen now anyway. I have no idea what the situation is like in the currently developed versions.

Or perhaps you meant something else entirely, and I just misunderstood.

Quote
What do suggest the two communities cooperate?

I don't know. To be honest, I haven't really followed the AGS discussion. I have a disturbingly large stack of old DOS and Windows games that I haven't played yet, and the thought of adding the AGS games on top of that is a bit daunting. Also, I wouldn't dare to presume telling the AGS developers what they should do or how they should run their project. While I'm sure there's a lot of mutual respect between the two projects, I don't know what they'd have to gain by working with ScummVM on the actively developed versions of AGS. The ScummVM framework could very well be too limited for what they are planning. There could be people within the ScummVM project who has the know-how to get AGS working on other platforms than are currently supported, but the various ScummVM ports are usually one-man projects so they may not have the time or the interest. Who knows?

I think that when people talk about adding AGS support to ScummVM, they're usually talking about the older versions. The ones which aren't developed any more. Maybe they have some problem with the official binaries (I've had some minor issues with the Linux version myself), or maybe they want to run the games on unsupported platforms. Having the ScummVM project take over maintenance of those versions (if there are developers interested in doing that, and if there are no licensing issues, etc.) could possibly be a good thing, if the AGS developers feel they'd rather concentrate on current and future versions instead. Though from what I hear, the source code for the old versions isn't publicly available at this time.

RickJ

Quote
Perhaps you meant that the translation could be made from the data files, rather than the source, but then I would think that it would be just as easy - or hard - to support the old data format directly. I assume it's pretty much frozen now anyway. I have no idea what the situation is like in the currently developed versions.
This is similar to what I had in mind.  AGS has done a pretty good job over the years of being able to upgrade older games to new ones just by recompiling the source.  This would seem to suggest that the data format has changed but the old functionality remains.  The one thing that comes to mind that may be problematic is the strings are handled in the 2.x branch versus the 3.x branch. 

There is some discussion over here about making some degree of separation between editor, compiler, and runtime.  I suppose "separation" could mean a lot of things.  At minimum it would mean a formal definition/documentation of the editor-compiler and compiler-engine interfaces.   So my thoughts were that if these interfaces were well designed and formally defined  it would be possible to target multiple game-engine runtimes simply by making either compilers and/or translators. 

It seems to me that scummvm, the backend engine parts, likely already has almost all of the required functionality.   The missing middle part would be the data formats and VM instructions.   If AGS and ScummVM were able to use the same definitions then AGS could have it's own native engine and could also easily target ScummVM as a runtime target.  With this kind of cooperation , between the two communities, the planned refactoring of the AGS engine could be done in a way that makes it easier to port to ScummVM

But people on the ScummVM forum have said no. no, no we can't share API or anything because all our stuff is GPL and AGS is not.  They also said they don't want to work on something that is not GPL.   

That's how I see it, where we are.  Am I wrong?


eriktorbjorn

Quote from: RickJ on Tue 31/01/2012 00:11:40
This is similar to what I had in mind.  AGS has done a pretty good job over the years of being able to upgrade older games to new ones just by recompiling the source.  This would seem to suggest that the data format has changed but the old functionality remains.  The one thing that comes to mind that may be problematic is the strings are handled in the 2.x branch versus the 3.x branch.

By "the source", you mean the source of the AGS runtime, not the games themselves? I've seen some minor glitches when running old 2.x games with newer 2.x runtimes, but if it's possible to figure out the appropriate version from the game's data files that should be a fairly minor problem. (I'm not sure where this would require the converter I thought you described, though, so I must still be missing something here.)

How things are separated and handled on the AGS side is really something I can't have an opinion on, since I've only seen AGS from a player's perspective, and even then just a handful of games.

Quote from: RickJ on Tue 31/01/2012 00:11:40
It seems to me that scummvm, the backend engine parts, likely already has almost all of the required functionality.   The missing middle part would be the data formats and VM instructions.   If AGS and ScummVM were able to use the same definitions then AGS could have it's own native engine and could also easily target ScummVM as a runtime target.  With this kind of cooperation , between the two communities, the planned refactoring of the AGS engine could be done in a way that makes it easier to port to ScummVM

The ScummVM backend is fairly simple, and there isn't really anything in it that's specific to adventure games. Each game engine has its own script interpreter, or hardcoded game logic, or whatever. Porting the AGS runtime to ScummVM would, I imagine, be mostly a matter of implementing the game detection (the parts that can identify that a set of data files is in fact an AGS game), the few functions needed for the ScummVM GUI to launch the game, replacing all the low-level bits (sound, graphics, file access ...) with calls to the ScummVM backend, use the standard decoders for sound/graphics where it's practical to do so, use the appropriate data types for 8/16/32-bit integers, make sure there are no left-over assumptions about byte ordering, etc. But I don't see  if AGS would have to make any changes to their data formats to do that, unless you really want to. After all, the various game engines in ScummVM right now have little or nothing in common in that respect.

Quote from: RickJ on Tue 31/01/2012 00:11:40
But people on the ScummVM forum have said no. no, no we can't share API or anything because all our stuff is GPL and AGS is not.  They also said they don't want to work on something that is not GPL.

Well, any AGS-related code distributed as a part of ScummVM would - I assume - at the very least need the option to distribute it under the GPL. I don't think anyone was suggesting that AGS can't use functions like copyRectToScreen() or playRaw(), if it provides its own implementation of them. I suppose a ScummVM-compatible engine could be developed and maintained outside the ScummVM project, using a different license. It seems impractical to me, though, and licensing could possibly prevent an AGS-enabled ScummVM from being distributed. Again, I'm no expert on this and I haven't really given it much thought.

I'm not sure if I understood you correctly, and I was in a bit of a hurry even ten minutes ago so now I really need to run.  :)

timofonic

About the "universal game format" idea, there are some valid points in the following forum thread (even by Chris Jones himself)

   
About merging with ScummVM, open-source and AGS

Endres

#187
The only problem is that the thread is from 2007 and I think CJ's feeling about OpenSource has changed a bit.

What is by the way the problem to make a fork of ScummVM and add AGS support to that fork? Then it could be licensed as anything, just the ScummVM part has to be still in GPL, I suppose. But does this really matter to be either in one or the other license? I mean, it is all OpenSource, so we could use it, right? Otherwise there is no point to make something open source, well, only for security reasons, but it isn't really needed. Let's look at the PSP port again!
Either the AGS Engine can be included into ScummVM, or the ScummVM can be cloned and modified to work with AGS. One of these would absolutely work even with the complicated licensing!

By the way, what is about the older scumm games anyway regarding ScummVM? I mean, the Scumm Engine is also not GPL licensed, is it?

timofonic

#188
Quote from: Endres on Tue 31/01/2012 10:28:21
The only problem is that the thread is from 2007 and I think CJ's feeling about OpenSource has changed a bit.

Just a bit? It changed A LOT!

Anyway, that's not the point. There were some interesting points in the discussion...


What about this? It seems is something now proven to be not so true (as latest AGS is able to play games from 2.6)
Quote from: scotch on Mon 03/12/2007 00:21:55
This makes a lot of assumptions about how the AGS source code works and how well AGS would fit into the SCUMMVM scheme.

Each version of AGS engine can only run games made with a narrow window of previous engines, sometimes a few releases, sometimes none. You couldn't take a snapshot of the code and support even 20% of AGS games with it. A widely compatible AGS engine would require months of dedicated work and lots of reverse engineering, even if the AGS source code was released.

It's mainly for that reason I don't think SCUMMVM compatability is a good idea. Users would expect most AGS games to run, when they probably wouldn't.

That's not to say I think open sourcing the engine would be a bad idea, if CJ wanted to do it. It would make the existing ports easier to maintain for a start, as well as allow people to make their own if they're desperate for that.

Quote from: Pumaman on Mon 03/12/2007 22:35:47
QuoteWith me so far? Ok, now when this universal XML game language (slage-based or not) is developed by SCUMMVM, they can (nicely, of course) ask the developers of game engines (such as AGS) if they would be so kind to create an export function which exported their game to this new universal XML game language.

That's all well and good for defining inventory items, characters, etc ... but what about the game scripts? Chances are that this "universal language" would have a different set of script commands to existing systems like AGS, and probably a different scripting language as well; converting that all over would be a mammoth task and probably impossible in several places.

As scotch says, it's pretty much an impossible task.



Quote from: Endres on Tue 31/01/2012 10:28:21
What is by the way the problem to make a fork of ScummVM and add AGS support to that fork? Then it could be licensed as anything, just the ScummVM part has to be still in GPL, I suppose. But does this really matter to be either in one or the other license? I mean, it is all OpenSource, so we could use it, right? Otherwise there is no point to make something open source, well, only for security reasons, but it isn't really needed. Let's look at the PSP port again!
Either the AGS Engine can be included into ScummVM, or the ScummVM can be cloned and modified to work with AGS. One of these would absolutely work even with the complicated licensing!

By the way, what is about the older scumm games anyway regarding ScummVM? I mean, the Scumm Engine is also not GPL licensed, is it?

I'm not an expert or a programmer at all, but I can explain a bit on the matter.

About the relicensing ScummVM code, that's a question to the ScummVM Team. So I prefer that question to be answered by one of them.

The official SCUMM/SPUTM engine is not GPL licensed, that's owned by Lucas Arts. The implementation inside ScummVM it is GPL.

ScummVM has a lot of game engines implemented, here's a list of some of them: AGI, AGOS, Cine, CruisE, Draci, Drascula, Gob, Groovie, Hugo, Kyra, Lure, MADE, Mohawk Parallaction, Queen, SAGA, SCI, SCUMM, Sky, Sword1, Sword2, Teenagent, Tinsel, Toon, Touche, TsAGE, Tucker, CGE, Composer, Dreamweb, Lastexpress, Sword25, Toltecs (plus a dozen more of in-progress engines and the list is periodically growing)

Endres

#189
Quote from: scotch on Mon 03/12/2007 00:21:55
This makes a lot of assumptions about how the AGS source code works and how well AGS would fit into the SCUMMVM scheme.

Each version of AGS engine can only run games made with a narrow window of previous engines, sometimes a few releases, sometimes none. You couldn't take a snapshot of the code and support even 20% of AGS games with it. A widely compatible AGS engine would require months of dedicated work and lots of reverse engineering, even if the AGS source code was released.

It's mainly for that reason I don't think SCUMMVM compatability is a good idea. Users would expect most AGS games to run, when they probably wouldn't.

That's not to say I think open sourcing the engine would be a bad idea, if CJ wanted to do it. It would make the existing ports easier to maintain for a start, as well as allow people to make their own if they're desperate for that.
I think it is still the best if the games with version 2.6 upwards would work. Lower versions without a doubt do indeed need much more work as to support all later versions. The PSP Port at least also supports 2.6 games, and I don't think that there was so incredibly much effort put on this. Eventhough there could be multiple engines for different versions. For example one for AGS 2.6 - 3.x games and one for 2.0 - 2.6, and so on.

Quote from: timofonic on Tue 31/01/2012 10:54:54
The official SCUMM/SPUTM engine is not GPL licensed, that's owned by Lucas Arts. The implementation inside ScummVM it is GPL.
So why aren't we able to make a GPL implementation or relicensing of the AGS Engine?  ;)
Also, I don't really see where the Artistic license disallows such inclusions in other projects which have a similar license.

Quote from: timofonic on Tue 31/01/2012 10:54:54
ScummVM has a lot of game engines implemented, here's a list of some of them: AGI, AGOS, Cine, CruisE, Draci, Drascula, Gob, Groovie, Hugo, Kyra, Lure, MADE, Mohawk Parallaction, Queen, SAGA, SCI, SCUMM, Sky, Sword1, Sword2, Teenagent, Tinsel, Toon, Touche, TsAGE, Tucker, CGE, Composer, Dreamweb, Lastexpress, Sword25, Toltecs (plus a dozen more of in-progress engines and the list is periodically growing)
Yes, Scumm was only one example I gave.

I think the most complicated task in the engine are the plugins. In the PSP port there are some of them included, but it is nearly impossible to include all plugins without enforcing an Microsoft Windows environment for the games with other than the best known plugins (snowrain, ...) in it.

timofonic

#190
Quote from: Endres on Tue 31/01/2012 11:27:47
Quote from: scotch on Mon 03/12/2007 00:21:55
This makes a lot of assumptions about how the AGS source code works and how well AGS would fit into the SCUMMVM scheme.

Each version of AGS engine can only run games made with a narrow window of previous engines, sometimes a few releases, sometimes none. You couldn't take a snapshot of the code and support even 20% of AGS games with it. A widely compatible AGS engine would require months of dedicated work and lots of reverse engineering, even if the AGS source code was released.

It's mainly for that reason I don't think SCUMMVM compatability is a good idea. Users would expect most AGS games to run, when they probably wouldn't.

That's not to say I think open sourcing the engine would be a bad idea, if CJ wanted to do it. It would make the existing ports easier to maintain for a start, as well as allow people to make their own if they're desperate for that.
I think it is still the best if the games with version 2.6 upwards would work. Lower versions without a doubt do indeed need much more work as to support all later versions. The PSP Port at least also supports 2.6 games, and I don't think that there was so incredibly much effort put on this. Eventhough there could be multiple engines for different versions. For example one for AGS 2.6 - 3.x games and one for 2.0 - 2.6, and so on.

It seems so, but not a proper extensive testing team has been done to know it. That's something interesting to know, so a testing from the community would be something nice to happen.

Quote from: Endres on Tue 31/01/2012 11:27:47
Quote from: timofonic on Tue 31/01/2012 10:54:54
The official SCUMM/SPUTM engine is not GPL licensed, that's owned by Lucas Arts. The implementation inside ScummVM it is GPL.
So why aren't we able to make a GPL implementation or relicensing of the AGS Engine?  ;)
Also, I don't really see where the Artistic license disallows such inclusions in other projects which have a similar license.

I suposse there's not problem at all to GPLize the code that ends in ScummVM, especially if being targeted at classic AGS versions.

I think if you put source code using the Artistic License 2.0 into a GPL code base, the whole result ends being GPL. I'm not totally sure, so a confirmation by others can be nice :)

I have my own ellaborated and more than justified reasonings about Free Software and believing it's very compatible to commercial selling of games, but maybe those are contrary to the ones by members of this community. I just will just say for now that the illicit copying reason is a fallacy, because millions of people already copy and distribute commercial software without the author's permission (and I also think  the warez issue is a socioeconomical problem, not an ethical one).


Quote from: Endres on Tue 31/01/2012 11:27:47
Quote from: timofonic on Tue 31/01/2012 10:54:54
ScummVM has a lot of game engines implemented, here's a list of some of them: AGI, AGOS, Cine, CruisE, Draci, Drascula, Gob, Groovie, Hugo, Kyra, Lure, MADE, Mohawk Parallaction, Queen, SAGA, SCI, SCUMM, Sky, Sword1, Sword2, Teenagent, Tinsel, Toon, Touche, TsAGE, Tucker, CGE, Composer, Dreamweb, Lastexpress, Sword25, Toltecs (plus a dozen more of in-progress engines and the list is periodically growing)
Yes, Scumm was only one example I gave.

I think the most complicated task in the engine are the plugins. In the PSP port there are some of them included, but it is nearly impossible to include all plugins without enforcing an Microsoft Windows environment for the games with other than the best known plugins (snowrain, ...) in it.

Are there a list of the plugins implemented and the games using it? If not, it could be a good task for a wiki :)

Maybe there are lots of plugins, but those are not as widely used as it seems.

Anyway, reverse engineering those plugins can be a difficult task. Or maybe not, an expert opinion is needed here too...

doimus

#191
Quote from: RickJ on Tue 31/01/2012 00:11:40
But people on the ScummVM forum have said no. no, no we can't share API or anything because all our stuff is GPL and AGS is not.  They also said they don't want to work on something that is not GPL.    

That's how I see it, where we are.  Am I wrong?


So, the situation is basically like this:

- if AGS engine was supported by ScummVM, AGS games would gain massive multiplatform exposure and zero worries about technical issues. Something this community has been wanting for ages.

- in turn, ScummVM users would get authoring system that would enable creation of new games. Something that community has been wanting for ages.


And the only thing preventing this from happening is AGS not being GPLicensed?

Why is AGS not GPL (now that it's already open source)? What prevents AGS from being GPL? And what are the benefits and/or limitations of AGS being GPL?

Does GPL prevent commercial usage of software? Would it require open sourcing the scripts in every AGS game?

And in any case, like it was mentioned above, what prevents ScummVM team from reverse-engineering AGS engine, just like all other angines they support?


RickJ

Quote
Why is AGS not GPL (now that it's already open source)? What prevents AGS from being GPL? And what are the benefits and/or limitations of AGS being GPL?
IMHO, the problem of GPL is not with AGS it's self but with the games people make with AGS.   Most of the people that come here to make games don't have their own website.  They make their game and find free file hosting somewhere which is notoriously unreliable for an number of reasons.   The requirement of them having to provide source or offering to provide source for a period of three years is a major inconvenience.   A way around this is that they be allowed to offer source from the AGS or ScummVM website.  However, when I made this this suggestion on the ScummVM forum it was met with much negativity and summarily rejected.

The other potential obstacle to GPL is confusion over the status of the game file and if it is a derivative work or not.  The game file ought to be considered a separate work don't have confidence that this is true.  The obvious solution is to add a clause in the GPL explicitly stating so.  This suggestion was also rejected by the folks on the ScummVM forum.

Quote
And in any case, like it was mentioned above, what prevents ScummVM team from reverse-engineering AGS engine, just like all other angines they support?
I believe the Artistic License allows ScummVM to take the source and make a ScummVM GPL port.  CJ has also stated so on the ScummVM forum.

eriktorbjorn

#193
Quote from: doimus on Thu 02/02/2012 10:36:21
Does GPL prevent commercial usage of software? Would it require open sourcing the scripts in every AGS game?

No, in fact ScummVM is already being used commercially and in accordance with the license. The Free Software Foundation (who are the ones behind the GPL) not only allow that sort of thing, they encourage it. I've never heard anyone claim that the games ScummVM have been bundled with should be affected by ScummVM's license. They're separate works that just happen to be distributed together. In some cases, the original authors have released the games as freeware, but it was never a prerequisite.

Even if the AGS compiler itself was released under the GPL (which is not what's being suggested here, but let's say it was), it wouldn't affect the license of the games created with it. Well... actually, the licensing FAQ does mention cases where it technically would, but notes that there are ways around that.

Quote from: doimus on Thu 02/02/2012 10:36:21
And in any case, like it was mentioned above, what prevents ScummVM team from reverse-engineering AGS engine, just like all other angines they support?

Well, I can think of several reasons that applied in the past. If we're talking reverse-engineering without access to the source code, some of them still do.

AGS used to be closed source, and reverse-engineering is a very time-consuming process. Trying to keep up with an actively developed game engine (presumably by people intimately familiar with it) just isn't very realistic. Also, because it was being actively developed I guess people were a lot more respectful of the bit in the AGS FAQ about not wanting the data file formats to be publicly known. I gather that something similar happened with the Smacker video format, where RAD Game Tools supposedly had said they didn't want that format reverse engineered. (Eventually people outside the ScummVM project did anyway, and we have taken advantage of that.)

And of course, it's a matter of manpower. Not every game engine generates the same amount of developer interest. Some linger untouched for ages, while others are updated very frequently. Even engines for well-regarded games don't always get the attention you'd think they deserve. Just look at how long it took for ResidualVM (which while not a part of ScummVM is still a close relative) to gain momentum, and that's for Grim Fandango.

eriktorbjorn

Quote from: RickJ on Fri 03/02/2012 06:32:29
The requirement of them having to provide source or offering to provide source for a period of three years is a major inconvenience.   A way around this is that they be allowed to offer source from the AGS or ScummVM website.  However, when I made this this suggestion on the ScummVM forum it was met with much negativity and summarily rejected.

I've been trying to find this negativity of which you speak, but all I could see was someone responding that it depends. As I understand it, the GPL already lets you distribute copies of a program, with only its original offer to provide the source code, as long as it is done non-commercially. If so, that should handle at least some of the otherwise inconvenient cases.

I guess the expectation is that doing something commercially obligates you to do a bit more work, though personally I wouldn't care much either way unless the distributed version of ScummVM had been modified in any substantial way. (In case anyone's concerned about it, you do not have to modify ScummVM to disable game engines that you do not want to include. That's a compile-time option.)

Quote from: RickJ on Fri 03/02/2012 06:32:29
The other potential obstacle to GPL is confusion over the status of the game file and if it is a derivative work or not.  The game file ought to be considered a separate work don't have confidence that this is true.  The obvious solution is to add a clause in the GPL explicitly stating so.  This suggestion was also rejected by the folks on the ScummVM forum.

Well, it was pointed out that changing the ScummVM license may be difficult because the copyright isn't held by any one single entity. But I honestly don't understand where the fear that the games would in any way, shape or form become derivative works of ScummVM comes from. It certainly has not been the case for any of the other games that ScummVM supports so far. Not even in the cases where we have received source code from the original developers.

Calin Leafshade

Products are *clearly* not deriviates works of the program used to interpret them. What are you guys *talking* about?

RickJ

Quote from: eriktorbjorn on Sat 04/02/2012 13:54:34
Quote from: RickJ on Fri 03/02/2012 06:32:29
The requirement of them having to provide source or offering to provide source for a period of three years is a major inconvenience.   A way around this is that they be allowed to offer source from the AGS or ScummVM website.  However, when I made this this suggestion on the ScummVM forum it was met with much negativity and summarily rejected.

I've been trying to find this negativity of which you speak, but all I could see was someone responding that it depends. As I understand it, the GPL already lets you distribute copies of a program, with only its original offer to provide the source code, as long as it is done non-commercially. If so, that should handle at least some of the otherwise inconvenient cases.   ..,.
You are not being responsive.  do you or do you not support the idea of allowing game developers to offer  source code directly from the ScummVM website?

Quote from: eriktorbjorn on Sat 04/02/2012 13:54:34
Quote from: RickJ on Fri 03/02/2012 06:32:29
The other potential obstacle to GPL is confusion over the status of the game file and if it is a derivative work or not.  The game file ought to be considered a separate work don't have confidence that this is true.  The obvious solution is to add a clause in the GPL explicitly stating so.  This suggestion was also rejected by the folks on the ScummVM forum.
Well, it was pointed out that changing the ScummVM license may be difficult because the copyright isn't held by any one single entity. But I honestly don't understand where the fear that the games would in any way, shape or form become derivative works of ScummVM comes from. It certainly has not been the case for any of the other games that ScummVM supports so far. Not even in the cases where we have received source code from the original developers.
Adding a clause to the license that explicitly re-states what it already says wouldn't be a problem unless one or more of the copyright holders has a different interpretation than you and I do.  The reluctance to add a clarifying clause indicates this may indeed be the case.

 

eriktorbjorn

Quote from: RickJ on Sat 04/02/2012 17:45:54
You are not being responsive.  do you or do you not support the idea of allowing game developers to offer  source code directly from the ScummVM website?

To me personally, that seems like an appropriate way of doing it unless there have been substantial changes made to the distributed version of ScummVM. (By that, I mean substantial changes to the ScummVM source code. Adding a custom program that launches ScummVM with the appropriate command-line options or something like that wouldn't count because that too would be a separate work, governed only by its own license.) And as I said, I believe that even if someone wanted to get really anal retentive about the license (I haven't seen any signs of that myself), it still explicitly allows you to do that for non-commercial distribution.

Quote from: eriktorbjorn on Sat 04/02/2012 13:54:34
Adding a clause to the license that explicitly re-states what it already says wouldn't be a problem unless one or more of the copyright holders has a different interpretation than you and I do.  The reluctance to add a clarifying clause indicates this may indeed be the case.

I don't know about that... I mean, I'm still hesitant about adding things to the license but that's because to me it doesn't really seem necessary. I could very well see adding it to a FAQ though.

Snarky

Quote from: doimus on Thu 02/02/2012 10:36:21
So, the situation is basically like this:

- if AGS engine was supported by ScummVM, AGS games would gain massive multiplatform exposure and zero worries about technical issues. Something this community has been wanting for ages.

Creating a ScummVM-based AGS engine wouldn't lead to "zero technical worries" (cf. other ScummVM engines that are not 100% perfect), although it's true that the ScummVM backend and various platform ports are of high quality and would allow us to piggyback on existing code. But this elides the crucial point that this isn't something that can happen just by saying the word. Someone has to do the work of porting the AGS engine to ScummVM, fixing any resulting bugs, etc. That's a lot of work.

Quote- in turn, ScummVM users would get authoring system that would enable creation of new games. Something that community has been wanting for ages.

Have they? Usually when I see people asking for it on the forums, the devs tend to say it's not something they're interested in. Of course, that's what they used to say about supporting Sierra games, too...

QuoteAnd the only thing preventing this from happening is AGS not being GPLicensed?

No. It's one reason, but not the only one. Probably the biggest reason (as stated from the ScummVM side) is that AGS is intended as an engine under ongoing development, with new features and changes in future versions. The ScummVM devs aren't interested in chasing AGS versions, so the only scenario under which they'd contemplate this is if all AGS development was brought into and taken over by the ScummVM project. Among other things, this would mean adhering to the ScummVM release cycle.

How would this affect the development of new features, which might require basic changes in the engine? I don't know, but it's reasonable to think it would complicate it, since you have a backend that must remain compatible against a bunch of other engines too. In any case, it's not clear that the AGS community is prepared to hand over ultimate control over the process and the direction of the engine to some outside group of developers, and it's very uncertain how the two communities could work together. Compared to ScummVM, AGS has a more complicated set of interests to align, since it's made for players on one hand and game developers on the other, for people making traditional adventure games as well as people pushing the technical and genre-defining boundaries, for newbies and non-technical artists as well as experienced programmers, and for rank amateurs and newbies through experienced hobbyists to commercial developers. It also has a long-standing community and social aspect, with multiple channels of communication (forums, blogs, IRC, social networks) and regular meets.

Another big issue is the work involved. Converting the AGS engine to ScummVM would involve almost a top-to-bottom rewrite, and you wouldn't have a feature-complete engine until you were done. No one who's competent to do that has volunteered. The alternatives offer a less daunting path forward, since you can fix problems and refactor parts of the code bit by bit and have a fully functioning engine every step of the way. So if we decide to go with ScummVM, we have to hope that someone with the necessary skills materializes and hope they keep working on it until it's ready.

QuoteWhy is AGS not GPL (now that it's already open source)?

Because CJ released it under the Artistic License 2.0, and requested that it be kept under a permissive license. Since it's CJ's work and he spent more than ten years making it, I'd argue that we should respect his wishes.

QuoteWhat prevents AGS from being GPL?

Only the choices of AGS developers and contributors, who will presumably be guided by the wishes of CJ and the community.

QuoteAnd what are the benefits and/or limitations of AGS being GPL?

The benefits are that we could integrate GPL components, such as ScummVM or certain libraries. Some also believe that under the GPL license the project would attract more contributors, under the theory that talented open-source programmers prefer strict copyleft licenses over permissive licenses.

The limitation is that GPL imposes a number of restrictions on what you can do (or have to do) with the software, and once you switch to GPL you can't change it to something else (without the permission of every individual contributor, which is usually impossible). It only allows the integration with other GPL (or GPL-compatible) software, and this excludes anyone who isn't prepared to adhere to the GPL licensing restrictions. This can be an obstacle not just for commercial developers, but also for other open-source projects (as the ScummVM-AGS issue demonstrates).

QuoteDoes GPL prevent commercial usage of software? Would it require open sourcing the scripts in every AGS game?

It doesn't technically prevent commercial use, but the licensing requirements are such that you'd have to provide the source code and allow people to distribute it and compile it freely, so you can't stop people from giving it away. There are business models that work under these conditions, but probably not for commercial adventure games.

I believe that the way AGS works now, where the engine and game logic/data are compiled together into one binary, the GPL would technically require the scripts to be open-sourced. ScummVM doesn't work that way: the engine is distributed separately from the game logic/data, so there's no question of its license covering them.

It would be possible to change the way AGS is built so that the engine code and game code are kept in completely separate files, and this would probably address the concern. Though in most cases you would probably still want to distribute the engine along with the game and have it launch the game directly on startup with a single click. In spite of what RickJ says about the absurdity of what a "binary file" is, I think the distinction matters. And I also think an expansive reading of GPL could mean that e.g. distributing an AGS game with the engine as an executable installer could require open-sourcing the game (or at least the installer), though probably no one would be likely to press this interpretation.

What I think would be a more realistic concern would be that a game developer couldn't make changes to the engine that relied on closed-source APIs. For example, I don't think the Steam plugin that monkey and Dave made for the Blackwell games could be integrated into a GPL version of AGS. (And I believe I remember that the ScummVM team was unwilling to create a plugin API for the engine to link to separate DLLs, partly, I guess, because it's platform-dependent.)

timofonic

Quote from: Snarky on Sun 05/02/2012 11:58:53
Quote from: doimus on Thu 02/02/2012 10:36:21
So, the situation is basically like this:

- if AGS engine was supported by ScummVM, AGS games would gain massive multiplatform exposure and zero worries about technical issues. Something this community has been wanting for ages.

Creating a ScummVM-based AGS engine wouldn't lead to "zero technical worries" (cf. other ScummVM engines that are not 100% perfect), although it's true that the ScummVM backend and various platform ports are of high quality and would allow us to piggyback on existing code. But this elides the crucial point that this isn't something that can happen just by saying the word. Someone has to do the work of porting the AGS engine to ScummVM, fixing any resulting bugs, etc. That's a lot of work.

Of course there's no zero worries, that's totally obvious.

OSystem's ScummVM is a framework designed to be quite portable from the practice, and even the coding guidelines in ScummVM are crafted with very high portability in mind.

The work must be done, like it happened with all the available engines in ScummVM. There's not a magical wand to get it. But the same can be said about making AGS portable and having clean code, that's A LOT of work (and maybe recreate the same level of portability can be higher than just reusing stuff like OSystem).


Quote from: Snarky on Sun 05/02/2012 11:58:53
Quote- in turn, ScummVM users would get authoring system that would enable creation of new games. Something that community has been wanting for ages.

Have they? Usually when I see people asking for it on the forums, the devs tend to say it's not something they're interested in. Of course, that's what they used to say about supporting Sierra games, too...

You seem to generalize the opinions of the ScummVM Team, anyway they have a pragmatic thinking. ScummVM is a project consisting of different subprojects, having subteams for each game engine developed. The monolithic thinking that can be applied to a project like AGS can't be applied to the modular ecosystem ScummVM is.

And you agree about Sierra AGI/SCI games. The things changed when people in the project or wanting to join offered their work on those engines. Usually the procedure in FOSS is "release early, release often" and that often means doing experimental forks like the early FreeSCI adaptation to OSystem's ScummVM.

There are people already interested in AGS into ScummVM for different reasons. Some want it for classic games (like DrMcCoy is interested in Yahztee games, for example) to be supported, and that seem something most people in both communities agree to support into ScummVM.

Quote from: Snarky on Sun 05/02/2012 11:58:53
QuoteAnd the only thing preventing this from happening is AGS not being GPLicensed?

No. It's one reason, but not the only one. Probably the biggest reason (as stated from the ScummVM side) is that AGS is intended as an engine under ongoing development, with new features and changes in future versions. The ScummVM devs aren't interested in chasing AGS versions, so the only scenario under which they'd contemplate this is if all AGS development was brought into and taken over by the ScummVM project. Among other things, this would mean adhering to the ScummVM release cycle.
What's the point about ongoing development? That's quite subjective right now, because AGS progress is quite stalled these days.


What's so limiting about the ScummVM release cycle? They are an organized team, they release a new version each six months. I see it a quite standard way like most of the software projects out there, even better than most commercial ones with larger release cycles.

Quote from: Snarky on Sun 05/02/2012 11:58:53
How would this affect the development of new features, which might require basic changes in the engine? I don't know, but it's reasonable to think it would complicate it, since you have a backend that must remain compatible against a bunch of other engines too.

I think you are forgeting how FOSS development works these days, using modern computer programming tools like distributed revision control systems  like Git and others like Buildbot.

* Git makes development quite easier, by making operations like forking and merging easier. Forks are a common practice in most complex projects, because they make the development of experimental stuff a lot easier. When the stuff is done to include it into the main branch, you merge the results back.

* Buildbot is a great tool to constantly test if the modified code is able to be built for different platforms, so it's a great way to check the portability and basic bugs in the code.

Each porter gets sure the engines work as intended on the platform, there's testing periods in the project too.

Quote from: Snarky on Sun 05/02/2012 11:58:53
In any case, it's not clear that the AGS community is prepared to hand over ultimate control over the process and the direction of the engine to some outside group of developers, and it's very uncertain how the two communities could work together. Compared to ScummVM, AGS has a more complicated set of interests to align, since it's made for players on one hand and game developers on the other, for people making traditional adventure games as well as people pushing the technical and genre-defining boundaries, for newbies and non-technical artists as well as experienced programmers, and for rank amateurs and newbies through experienced hobbyists to commercial developers. It also has a long-standing community and social aspect, with multiple channels of communication (forums, blogs, IRC, social networks) and regular meets.

There's the real point! The feeling of property about a project and a community...

Contrary to what it seems to certain people, that's very relaxed in FOSS due to the Copyleft philosophy of collaboration and meritocracy. That's something not well understood to most people outside FOSS. Sense of ownership is considerated as ridiculous for true FOSS developers, because anyone can fork a project to take a different direction.

About experienced developers in AGS, I disagree. I see there are very few developers on this community, but very experienced ones in ScummVM.  Computer programming must be quite organized to get proper results and certain ideas that can be amazing to a graphics artist can be totally and ridiculous nonsense to a proper computer programmer because of solid and objective technical reasons.

ScummVM isn't a monolithic project as explained before, but a bunch of projects on a common ecosystem (using a framework named OSystem) and with a common interest in adventure game engines.

Let's go to speculate a bit about how AGS would live inside ScummVM, here's my ideas:

- AGS would have it's own set of developers, the AGS subteam. Those are developers focused on the progress of the AGS runtime, cooperating with the developers of the AGS authoring tools (the real deal of the AGS community, in my opinion).

- ScummVM would integrate the stable versions of the AGS runtime in each 1.x version, having experimental ones in separated forks that can be built automatically by using Buildbot.

- Forums  would stay the same, having a link on the ScummVM forums redirecting to the AGS ones.

- The wiki would be merged, at least the technical part of the AGS runtime.

Quote from: Snarky on Sun 05/02/2012 11:58:53
Another big issue is the work involved. Converting the AGS engine to ScummVM would involve almost a top-to-bottom rewrite, and you wouldn't have a feature-complete engine until you were done. No one who's competent to do that has volunteered. The alternatives offer a less daunting path forward, since you can fix problems and refactor parts of the code bit by bit and have a fully functioning engine every step of the way. So if we decide to go with ScummVM, we have to hope that someone with the necessary skills materializes and hope they keep working on it until it's ready.

Well, ScummVM developers managed to do difficult efforts like merging tons of engines plus rewriting ones. Some examples are AGS, SCI and Tinsel. But I agree new developers are needed to take this great effort, with volunteer work to get it done.

Refactoring with AGS alone can look easier, but the rest of the effort could be less friendly in this environment. There would be needed to prepare the project with high portability in mind if AGS want to stay relevant in these days, with lots of available platforms in the market.

Quote from: Snarky on Sun 05/02/2012 11:58:53
QuoteWhy is AGS not GPL (now that it's already open source)?

Because CJ released it under the Artistic License 2.0, and requested that it be kept under a permissive license. Since it's CJ's work and he spent more than ten years making it, I'd argue that we should respect his wishes.

OK, so you are recognizing the reasons are not pragmatical at all, but dogmatical ones. I agree on this.

But a proper community must follow it's own path, and not get into a religion.

Quote from: Snarky on Sun 05/02/2012 11:58:53
QuoteWhat prevents AGS from being GPL?

Only the choices of AGS developers and contributors, who will presumably be guided by the wishes of CJ and the community.

I agree about the first part, but in the rest you are talking like a preacher.


Quote from: Snarky on Sun 05/02/2012 11:58:53
QuoteAnd what are the benefits and/or limitations of AGS being GPL?

The benefits are that we could integrate GPL components, such as ScummVM or certain libraries. Some also believe that under the GPL license the project would attract more contributors, under the theory that talented open-source programmers prefer strict copyleft licenses over permissive licenses.

The limitation is that GPL imposes a number of restrictions on what you can do (or have to do) with the software, and once you switch to GPL you can't change it to something else (without the permission of every individual contributor, which is usually impossible). It only allows the integration with other GPL (or GPL-compatible) software, and this excludes anyone who isn't prepared to adhere to the GPL licensing restrictions. This can be an obstacle not just for commercial developers, but also for other open-source projects (as the ScummVM-AGS issue demonstrates).

I agree about the first paragraph, there's lot of projects under GPL and that's something objetively verificable. It's quite common open source programmers prefer Copyleft over BSD/MIT style licenses, because it makes their code to be always available and not closed sourced by other individual or company/corporation (like Microsoft and Apple does most of the time, for example).

It hasn't been an obstacle to many commercial developers and publishers already using ScummVM. So what's the problem?

Even ID Software releases their games as GPL too, but the game data still being propietary and need to be bought.

Quote from: Snarky on Sun 05/02/2012 11:58:53
QuoteDoes GPL prevent commercial usage of software? Would it require open sourcing the scripts in every AGS game?

It doesn't technically prevent commercial use, but the licensing requirements are such that you'd have to provide the source code and allow people to distribute it and compile it freely, so you can't stop people from giving it away. There are business models that work under these conditions, but probably not for commercial adventure games.

Excuse me, but what's wrong with giving back the code to the community? You receive it, then give something back!

Nobody can stop giving away an unauthorized copy, even by using samizdat-like laws like SOPA and ACTA. That relies on the personal ethic of the individual, not on the software license itself.


Quote from: Snarky on Sun 05/02/2012 11:58:53
I believe that the way AGS works now, where the engine and game logic/data are compiled together into one binary, the GPL would technically require the scripts to be open-sourced. ScummVM doesn't work that way: the engine is distributed separately from the game logic/data, so there's no question of its license covering them.

It would be possible to change the way AGS is built so that the engine code and game code are kept in completely separate files, and this would probably address the concern. Though in most cases you would probably still want to distribute the engine along with the game and have it launch the game directly on startup with a single click. In spite of what RickJ says about the absurdity of what a "binary file" is, I think the distinction matters. And I also think an expansive reading of GPL could mean that e.g. distributing an AGS game with the engine as an executable installer could require open-sourcing the game (or at least the installer), though probably no one would be likely to press this interpretation.

I'm sorry, but you and others are misinterpreting the virality of GPL. This has been talked ages and it's just theoric speculation, because commercial game development companies like ID Software already release their games as GPL and we all agree they have a lot of lawyers to check this kind of things.

It's quite possible to extract the games of the already available games from the AGS bundle, that's not a problem at all.

About using an installed or bundler, that's quite possible to do without breaking the GPL. It has been done with other projects.

Quote from: Snarky on Sun 05/02/2012 11:58:53
What I think would be a more realistic concern would be that a game developer couldn't make changes to the engine that relied on closed-source APIs. For example, I don't think the Steam plugin that monkey and Dave made for the Blackwell games could be integrated into a GPL version of AGS. (And I believe I remember that the ScummVM team was unwilling to create a plugin API for the engine to link to separate DLLs, partly, I guess, because it's platform-dependent.)

That's something that need to be discussed, as Steam is closed source and having a strict license. I would like to know the opinion of other people on this matter, it looks a quite interesting situation to know for me.

SMF spam blocked by CleanTalk