MAMEWorld >> Programming
Previous thread Previous  View all threads Index   Next thread Next   Threaded Mode Threaded  

Pages: 1

Bryan Ischo
MAME Fan
Reged: 03/28/10
Posts: 358
Send PM


What is the policy on distributing patches?
#266203 - 10/13/11 02:15 AM


Hello. I have a patch against MAME that I would like to make public and would like to distribute binaries based on the patch for user convenience.

What is the general policy for this?

The MAME license says that the "complete source code" for the modified version of MAME must be included. Does this mean that posting the patch is not sufficient if I want to post binaries and that I have to post the fully patched MAME source as well?

In any case, is it sufficient to put a link to the source on the site that distributes the binaries or do I have to package the binaries in a way that implicity includes the source - such as together in a .zip file?

Also the MAME license includes "the source code for all components used by a binary built from the modified sources" in this requirement.

Does that mean that if the MAME code is built into a shared library (.so or .dll), these license requirements for the programs that link against MAME are included?

I guess the two questions I am asking can be boiled down to this:

1. What does the term "redistribution" mean as MAME uses it in its license in the sentence fragment:

"Redistributions that are modified from the original source must ..."?

Does "redistribution" include "distribution of a binary that links against a shared library that includes MAME code"? If so, how does that work, because the binary itself doesn't contain any MAME code, it just contains code which has symbol dependencies on code that could be satisfied by MAME or could be satisfied by some other library that defines the same symbols ...

2. What does the term "include" mean as MAME uses it in its license in the sentence fragment:

" ... include the complete source code ..."

Does it mean making the source available from the same medium as the binary, but not necessarily implicitly included along with the binary? Or does it mean implicitly included along with the binary?



R. Belmont
Cuckoo for IGAvania
Reged: 09/21/03
Posts: 9716
Loc: ECV-197 The Orville
Send PM


Re: What is the policy on distributing patches? new [Re: Bryan Ischo]
#266358 - 10/14/11 05:42 PM


> What is the general policy for this?

Do what Google, Inc. (an actual company with actual lawyers) did with their Native Client MAME port and you won't be too wrong.

> The MAME license says that the "complete source code" for the modified version of
> MAME must be included. Does this mean that posting the patch is not sufficient if I
> want to post binaries and that I have to post the fully patched MAME source as well?

It is strongly recommended that you post the base source zip plus your patch, as separate downloads.

> In any case, is it sufficient to put a link to the source on the site that
> distributes the binaries or do I have to package the binaries in a way that implicity
> includes the source - such as together in a .zip file?

Source does not have to be included with binary downloads; however I don't quite understand what your binary downloads would be given the scope and intent of your project so I can't give a definitive answer.

> Does that mean that if the MAME code is built into a shared library (.so or .dll),
> these license requirements for the programs that link against MAME are included?

Yes. You will bring down the wrath of MAMEdev if you ever link any part of MAME against closed-source, for instance. This is why we explicitly endorse ClientServerMAME and explicitly condemn Kaillera (I mean, besides that the latter is also an exploit-ridden piece of junk).



Bryan Ischo
MAME Fan
Reged: 03/28/10
Posts: 358
Send PM


Re: What is the policy on distributing patches? new [Re: R. Belmont]
#266364 - 10/14/11 06:31 PM


Thank you very much for your answers - just the info I needed.

> > Does that mean that if the MAME code is built into a shared library (.so or .dll),
> > these license requirements for the programs that link against MAME are included?
>
> Yes. You will bring down the wrath of MAMEdev if you ever link any part of MAME
> against closed-source, for instance. This is why we explicitly endorse
> ClientServerMAME and explicitly condemn Kaillera (I mean, besides that the latter is
> also an exploit-ridden piece of junk).

OK no problem - I intended to release source anyway I just wanted to understand the requirements in more detail.

I do have another more interesting scenario for you to consider though.

What if someone implemented a MAME OSD layer that forwarded textures and audio segments over a network connection to a remote peer that did nothing except display those textures/audio and then supplied input back over the network to be fed back into MAME? Does that violate the MAME license? MAME itself is running in a binary that is not being distributed, but the runtime results of the MAME executable - audio and video, and user input going back the other way - are being distributed over the network. Does that count as a license violation?

Now - what if that same client/server mechanism were used but instead of using a network connection it was using message passing over a shared memory segment on the same box. Now would the client that displayed MAME's output have to have its source released? It's not a part of the MAME binary, remember; it's nothing more than a program that can read and display the output of MAME, kind of like how a movie player application can play the output of AVI files written by MAME ...



R. Belmont
Cuckoo for IGAvania
Reged: 09/21/03
Posts: 9716
Loc: ECV-197 The Orville
Send PM


Re: What is the policy on distributing patches? new [Re: Bryan Ischo]
#266375 - 10/14/11 09:29 PM


> What if someone implemented a MAME OSD layer that forwarded textures and audio
> segments over a network connection to a remote peer that did nothing except display
> those textures/audio and then supplied input back over the network to be fed back
> into MAME?

I'd say that's a seriously inefficient way to do what ClientServerMAME (or OnLive, for that matter) does.

> Does that violate the MAME license? MAME itself is running in a binary
> that is not being distributed, but the runtime results of the MAME executable - audio
> and video, and user input going back the other way - are being distributed over the
> network. Does that count as a license violation?

It sounds as if you intend to try and violate MAMEdev's intent in that specific way, in sort of a "no, Mr. Bond, I expect you to die" manner. I'm sure you're not actually planning to do that, so please explain your *real* use case.



Bryan Ischo
MAME Fan
Reged: 03/28/10
Posts: 358
Send PM


Re: What is the policy on distributing patches? new [Re: R. Belmont]
#266378 - 10/14/11 10:06 PM


> It sounds as if you intend to try and violate MAMEdev's intent in that specific way,
> in sort of a "no, Mr. Bond, I expect you to die" manner. I'm sure you're not actually
> planning to do that, so please explain your *real* use case.

Sure. The specific details are this:

If you examine the libmame API that I wrote about in another post on this forum, you will see that once a game is started, the application using the library is responsible for three things:

1. Displaying the textures that come out of the emulator every frame.
2. Playing the audio that comes out of the emulator every frame.
3. Providing game control input to the game on every frame.

This is very much a thin wrapper around the OSD layer so these should be pretty familiar to you.

In my frontend program, I was linking MAME in using libmame and starting a game up in its own thread and displaying the game in an OpenGL texture mapped to a spot in the frontend's 3d scene.

What I found was that while this worked, it opened up the frontend to being crashed by MAME, which unfortunately happens sometimes. Some games crash 100% of the time in fact.

So what I decided to do was to run MAME in a separate process instead of a separate thread. So when I want to start a game, I allocate a shared memory segment, set up some message queue structures in it, then fork and in the forked program run the MAME emulator and deliver the audio and video and game input over the shared memory segment. This means that even if MAME crashes, the frontend program is unaffected (it detects that no more messages are coming from MAME and kills it off and releases the shared memory segment).

Works great. I can even run many games simultaneously this way if I wanted to, which I currently do not, except that when the user wants to switch to a new game, I start the new one before the old one has even finished shutting down so during those brief periods there are two games running simultaneously.

Now, I have every intention of releasing the source to my frontend once it is ready (if that ever happens), but if someone had the same idea as I did and *didn't* want to release their source, then I wanted to know whether that would be allowed. And since my patches to MAME are what enable this kind of functionality, I want to be able to provide guidance on this licensing issue to anyone else who uses libmame.

As an aside, this works great on Linux because fork() and exec() are two separate calls and I can easily have the forked child access the anonymous shared memory segment that it inherited from its parent. I'm still figuring out how to make this work on Windows, but I'm thinking that probably the spawned child process will be spawned with a command line argument identifying the not-anonymous shared memory segment so that it can attach to it. Hiding this behind an API that works the same on both Linux and Windows is a challenging bit, that I haven't quite gotten to yet because I can't even compile my frontend on Windows yet because it has dependencies on libraries that are easily available on Linux but much harder to come by on Windows.



R. Belmont
Cuckoo for IGAvania
Reged: 09/21/03
Posts: 9716
Loc: ECV-197 The Orville
Send PM


Re: What is the policy on distributing patches? new [Re: Bryan Ischo]
#266383 - 10/14/11 11:02 PM


> Now, I have every intention of releasing the source to my frontend once it is ready
> (if that ever happens), but if someone had the same idea as I did and *didn't* want
> to release their source, then I wanted to know whether that would be allowed. And
> since my patches to MAME are what enable this kind of functionality, I want to be
> able to provide guidance on this licensing issue to anyone else who uses libmame.

All right.

First up, I need to mention that the QMC2 frontend does more or less what you're describing on Linux with totally stock MAME/MESS binaries (they fork/exec MAME as a separate process and then find and hijack the X window handle, I think). We're investigating adding an IPC protocol to allow QMC2 (and anything else) to have live control of MAME settings (and to swap media in and out in MESS) as MAMEUI does, because "integrated" frontends are the worst idea in computer science since MS-DOS.

Secondly, the viewer itself probably is not subject to the MAME license (although as such it also can't use the registered trademark "MAME" anywhere either). The backend MAME/libmame process obviously still is.

Edited by R. Belmont (10/14/11 11:05 PM)



Bryan Ischo
MAME Fan
Reged: 03/28/10
Posts: 358
Send PM


Re: What is the policy on distributing patches? new [Re: R. Belmont]
#266384 - 10/14/11 11:18 PM


> because "integrated" frontends are the worst idea in computer science since MS-DOS.

Why? You do realize that there are features that simply cannot be provided any other way, or at least not without incredible hacks such as hijacking X window handles and whatnot (and even if you hijack an X window handle, how do you make the output of that X window display in a virtually rendered arcade cabinet "off in the distance"?).



R. Belmont
Cuckoo for IGAvania
Reged: 09/21/03
Posts: 9716
Loc: ECV-197 The Orville
Send PM


Re: What is the policy on distributing patches? new [Re: Bryan Ischo]
#266387 - 10/15/11 12:54 AM


> Why? You do realize that there are features that simply cannot be provided any other
> way, or at least not without incredible hacks such as hijacking X window handles and
> whatnot (and even if you hijack an X window handle, how do you make the output of
> that X window display in a virtually rendered arcade cabinet "off in the distance"?).

On a coherent graphics/windowing system you could use the captured window as a texture. X11 is not that system, although I think Windows and OS X would allow it, and I have hopes for Wayland.



Bryan Ischo
MAME Fan
Reged: 03/28/10
Posts: 358
Send PM


Re: What is the policy on distributing patches? new [Re: R. Belmont]
#266388 - 10/15/11 01:04 AM


> > Why? You do realize that there are features that simply cannot be provided any
> other
> > way, or at least not without incredible hacks such as hijacking X window handles
> and
> > whatnot (and even if you hijack an X window handle, how do you make the output of
> > that X window display in a virtually rendered arcade cabinet "off in the
> distance"?).
>
> On a coherent graphics/windowing system you could use the captured window as a
> texture. X11 is not that system, although I think Windows and OS X would allow it,
> and I have hopes for Wayland.

That doesn't explain why integrating the frontend with MAME is a bad idea, at least if it's done as I suggest where 'integrated' means that MAME delivers the raw output to the frontend for display and takes input from it.

Then the frontend can implement any number of effects that it desires; having access to the raw data (textures, sound) allows the frontend to be unlimited in the features that it can provide.

I just don't see why it's a bad idea. Not being limited to the functional but klunky MAME menu system is nice.



R. Belmont
Cuckoo for IGAvania
Reged: 09/21/03
Posts: 9716
Loc: ECV-197 The Orville
Send PM


Re: What is the policy on distributing patches? new [Re: Bryan Ischo]
#266406 - 10/15/11 02:50 AM


> I just don't see why it's a bad idea. Not being limited to the functional but klunky
> MAME menu system is nice.

Because from our perspective 1) it always ends in tears and/or bad code (MAMEUI, MAME OS X - not necessarily in that order) and 2) we'd rather someone that driven about user experience just fix the "klunky" MAME menu system. There have been discussions on the list about making it all mouse-driven like ZSNES or the old Sardu emulators. But working code always trumps discussions


Pages: 1

MAMEWorld >> Programming
Previous thread Previous  View all threads Index   Next thread Next   Threaded Mode Threaded  

Extra information Permissions
Moderator:  Pi 
0 registered and 62 anonymous users are browsing this forum.
You cannot start new topics
You cannot reply to topics
HTML is enabled
UBBCode is enabled
Thread views: 3325