Making Exodus Open Source: What license model to use?

Official support forum for the Exodus Emulation Platform

Moderator: Nemesis

User avatar
Nemesis
Very interested
Posts: 670
Joined: Wed Nov 07, 2007 1:09 am
Location: Sydney, Australia

Making Exodus Open Source: What license model to use?

Post by Nemesis » Mon May 20, 2013 1:17 am

So, I'm planning to release Exodus as open source sometime soon. There is the looming question of which license model to use though, and I'm currently undecided on which direction to take. There are a few things I know I want the license to do:

-Must not allow free commercial use. That said, I'm not opposed to commercial use, as long as it doesn't impact on the free use of the platform for non-commercial purposes. Commercial use would require some kind of formal license arrangement and payment however. I don't see this happening anytime soon, if ever, but if it did, it could however open a can of worms in terms of what to do with that money and where it should go, if a large number of contributors were involved in the project. I want to make it clear from the get-go though that I'm not opposed to commercial funding coming in for this project, but I'm not sure how it should be managed. In my mind, the project could essentially be run on a not-for-profit basis, and community contributions could essentially be handled in the same way, with the money raised being fed back into the project to drive its development forward. I'm more than willing to hear any input anyone might have on the matter.

-Must not allow the core of the platform itself to be taken, forked, and released as a competing platform. Basically, this means only official builds of Exodus will be allowed to be distributed. I don't want this to be like linux, where you've got 15 different flavours of Exodus. There needs to be a single core platform. There can be multiple implementations of any one device, and users should be able to pick and choose which one they want to use, but a single platform needs to exist. Even worse would be someone picking up the main sourcecode, quickly tacking a few features on the side, and that release becomes more popular, and I lose main control over the project. In order for a project like this to work it needs a single focused direction. Note however, that I am not opposed to the sourcecode for an existing core, like an individual processor or device, being taken and forked, and I'm not opposed to people who do work on one or more cores publically releasing builds of modifications or alternate builds they have made for individual cores outside the main Exodus release. This means plugins and the emulator itself probably need to be licensed slightly differently, perhaps with just an extra clause for the main platform to add this restriction.

-Must force all plugins to be open source. One of the main goals of this emulator is to document and preserve hardware into the future. Closed source cores don't help that, and a very well made closed source core may discourage the development of a competing open source core. When the closed source core is inevitably abandoned, or gets spun off into a commercial product and the free version for Exodus gets dropped, that'll leave us effectively back at square one.

-Must allow the use of closed-source or pre-compiled components by plugins, as long as those components don't contain implementation for a given plugin which hide important details of how that plugin works, or how a given device is implemented. Basically, I don't want to exclude the use of third party libraries just because their license is less permissive than ours, but I don't want people to be able to write a "wrapper" plugin that essentially just calls a separate closed-source component in an attempt to work around the open source license requirement.


I don't know that any "standard" open source license meets the requirements I'm after. There are probably also a lot of issues I haven't even considered yet.

One thing that I think needs to be clarified is exactly what a contributor's rights are, and what responsibilities we have to past contributors. Obviously everyone has copyright over anything they create, but what if commercial funding does come in later, or if community donations are received? Do previous contributors have any claim to money that is raised? What if a change to the licensing model is proposed? Do all previous contributors need to give consent in order for the license to be amended? What if a previous author's contributions are ultimately rewritten, do they retain any rights or claim to the resulting work? I don't know the answers to these questions. I don't want to discourage contributions to this project, but I also don't want to stuff things up in the future or hold this project back from evolving because of a lack of understanding on both sides about what exactly it means when you make a contribution to this project.

Anyway, there's a lot to consider when it comes to licensing, and it's hard to fix if you get it wrong, so I don't want to rush into it. I'm very interested in any input or feedback anyone might have.

User avatar
TmEE co.(TM)
Very interested
Posts: 2285
Joined: Tue Dec 05, 2006 1:37 pm
Location: Estonia, Rapla City
Contact:

Post by TmEE co.(TM) » Mon May 20, 2013 2:06 am

I don't think anything suitable exits. Write up something yourself and take ideas from others and adapt to your needs.
You will have to be able to enforce your restrictions in some way.
Mida sa loed ? Nagunii aru ei saa ;)
http://www.tmeeco.eu
Files of all broken links and images of mine are found here : http://www.tmeeco.eu/FileDen

Mask of Destiny
Very interested
Posts: 555
Joined: Thu Nov 30, 2006 6:30 am

Post by Mask of Destiny » Mon May 20, 2013 4:40 am

I'm not sure all of your requirements are compatible with the OSI's open source definition. In particular, your anti-forking requirement seems to run afoul of sections 3 and 4. The restriction against commercial use might run afoul of section 6, though that at least partly depends on what you mean. For instance, GPL doesn't technically forbid commercial distribution, it just makes it somewhat undesirable to do so due to the requirement to distribute the source and the ability for the person receiving the software to redistribute it.

Of course, you're under no obligation to release your source under a license conforming to the OSD (or to release it at all for that matter), but you might want to avoid calling it open source if your license doesn't meet the OSI definition.

User avatar
Nemesis
Very interested
Posts: 670
Joined: Wed Nov 07, 2007 1:09 am
Location: Sydney, Australia

Post by Nemesis » Tue May 21, 2013 9:39 am

Thanks for that link MoD, I wasn't even aware that the term "open source" had a formal definition beyond releasing the code publically.

Hmmm, what do you guys think? Is what I'm proposing too restrictive? Ultimately, I'm trying to chose a licensing model that I think will best help the project evolve.

User avatar
TmEE co.(TM)
Very interested
Posts: 2285
Joined: Tue Dec 05, 2006 1:37 pm
Location: Estonia, Rapla City
Contact:

Post by TmEE co.(TM) » Tue May 21, 2013 4:12 pm

Leave UI stuff all out and release sources of the individual emulation components. Will solve your forking+"destruction" problem.
Mida sa loed ? Nagunii aru ei saa ;)
http://www.tmeeco.eu
Files of all broken links and images of mine are found here : http://www.tmeeco.eu/FileDen

Mask of Destiny
Very interested
Posts: 555
Joined: Thu Nov 30, 2006 6:30 am

Post by Mask of Destiny » Tue May 21, 2013 8:48 pm

There's something to be said for picking a somewhat standard license. That way people know what to expect and license compatibility is a known quantity.

sega16
Very interested
Posts: 250
Joined: Sat Jan 29, 2011 3:16 pm
Location: U.S.A.

Post by sega16 » Tue May 21, 2013 10:37 pm

Nemesis wrote: Hmmm, what do you guys think? Is what I'm proposing too restrictive? Ultimately, I'm trying to chose a licensing model that I think will best help the project evolve.
No it is not too restrictive it is an important measure that you must take to ensure the quality and future of exodus especially the forking policy I hate to see projects forked just because of one stupid disagreement. Have people ever heard of #if /*insert code here*/ #endif? If there is a disagreement just use the pre-processor.

Unity311
Newbie
Posts: 2
Joined: Wed May 22, 2013 10:08 pm

Post by Unity311 » Thu May 23, 2013 2:45 am

Important preface: I am not a lawyer and my understanding of everything I state in this post may be inaccurate.

You may have to license different parts with different licenses (or come up with your own). I wouldn't recommend attempting to build something in that actually prevents your restrictions...it generally causes more harm than good. You have to rely on people respecting the license and then take appropriate actions if somebody does not.

For non-forking, see the AGPL. I don't believe it prevents it, but any changes must be provided back...it's tricky to work with though and difficult to use separate licenses with. It seems like something similar is mentioned in the following thread/post:
http://stackoverflow.com/questions/2127 ... -and-gplv3

An appropriate license for the core of Exodus should cause any extensions/modules/plugins to be open source. Most GPL licenses have this clause I believe. It even includes a clause allowing for closed source components with a "standard interface" to communicate. See the following:
http://stackoverflow.com/questions/5289 ... pplication

Your third requirement may be impossible... I'm not sure. If you attempt to use the "standard interface" clause to allow closed source, you pobably will not be able to prevent somebody from using a wrapper to get around it.

Also, explore licenses that are not GPL... There are many other popular ones. See the link below for some popular ones.
http://en.wikipedia.org/wiki/Comparison ... e_licenses

Keep in mind that you don't have to write the license from scratch if none of the existing ones meet your needs. It is fine to release a project under a modified GPL license (using other licenses as a base is probably fine as well).

A personal note about your first requirement:
If you ever abandon this project, it may make it difficult for somebody else to take over as maintainer. As long as you're prepaired for accommodating that eventuality it may not be an issue.

A second personal note:
Hurry up and find/create a license so you can release the source! I'm really looking forward to attempting to build another system on your platform!

User avatar
ElBarto
Very interested
Posts: 158
Joined: Wed Dec 13, 2006 10:29 am
Contact:

Re: Making Exodus Open Source: What license model to use?

Post by ElBarto » Thu May 23, 2013 8:31 am

Nemesis wrote:So, I'm planning to release Exodus as open source sometime soon. There is the looming question of which license model to use though, and I'm currently undecided on which direction to take. There are a few things I know I want the license to do:

-Must not allow free commercial use. That said, I'm not opposed to commercial use, as long as it doesn't impact on the free use of the platform for non-commercial purposes.
What do you mean by "free commercial use" ?
Nemesis wrote: Commercial use would require some kind of formal license arrangement and payment however. I don't see this happening anytime soon, if ever, but if it did, it could however open a can of worms in terms of what to do with that money and where it should go, if a large number of contributors were involved in the project. I want to make it clear from the get-go though that I'm not opposed to commercial funding coming in for this project, but I'm not sure how it should be managed. In my mind, the project could essentially be run on a not-for-profit basis, and community contributions could essentially be handled in the same way, with the money raised being fed back into the project to drive its development forward. I'm more than willing to hear any input anyone might have on the matter.
For that you need dual-licensing.
One license like GPL (who prevents someone to distribute binaries without source code) and the commercial one (a simple copyright is enough).
Nemesis wrote: -Must not allow the core of the platform itself to be taken, forked, and released as a competing platform. Basically, this means only official builds of Exodus will be allowed to be distributed. I don't want this to be like linux, where you've got 15 different flavours of Exodus. There needs to be a single core platform. There can be multiple implementations of any one device, and users should be able to pick and choose which one they want to use, but a single platform needs to exist.
This is really the opposite of OpenSource. The main goal of OpenSource (besides having people fixing your bugs instead of you :P) is to allow multiple uses of your source code in other projects (an emulator will take your m68k core for example) in a fork (a "low-cost" version for mobile device ...).

When you say multiple implementation of one device, you mean multiple m68k core for example ?
I don't really see the point of doing that (except for "low-cost" implementation of course like byuu did with the profile thing in bsnes).

You said in another thread that you will not maintaining Linux build of Exodus.
Let say I take your source when it will be available and I port it to Linux (well FreeBSD in my case but let's say port it to X11/GTK/Whatever) and for some reason you don't want to commit my changes to the official Exodus repo (one reason would be that I changed a lot of stuff in the source tree to make the core architecture/OS-agnostic and you don't like it).
What do I do with my unix fork of Exodus ?

For Linux this is different. It's a kernel and not an OS so it's normal to have multiple OS uses the same Linux kernel.
Nemesis wrote: Even worse would be someone picking up the main sourcecode, quickly tacking a few features on the side, and that release becomes more popular, and I lose main control over the project. In order for a project like this to work it needs a single focused direction. Note however, that I am not opposed to the sourcecode for an existing core, like an individual processor or device, being taken and forked, and I'm not opposed to people who do work on one or more cores publically releasing builds of modifications or alternate builds they have made for individual cores outside the main Exodus release. This means plugins and the emulator itself probably need to be licensed slightly differently, perhaps with just an extra clause for the main platform to add this restriction.

-Must force all plugins to be open source. One of the main goals of this emulator is to document and preserve hardware into the future. Closed source cores don't help that, and a very well made closed source core may discourage the development of a competing open source core. When the closed source core is inevitably abandoned, or gets spun off into a commercial product and the free version for Exodus gets dropped, that'll leave us effectively back at square one.
You can't.
The only way to do so it to not have a plugin system so every component will be in the same binary.
Nemesis wrote: -Must allow the use of closed-source or pre-compiled components by plugins, as long as those components don't contain implementation for a given plugin which hide important details of how that plugin works, or how a given device is implemented. Basically, I don't want to exclude the use of third party libraries just because their license is less permissive than ours, but I don't want people to be able to write a "wrapper" plugin that essentially just calls a separate closed-source component in an attempt to work around the open source license requirement.
Same a above.
Nemesis wrote: I don't know that any "standard" open source license meets the requirements I'm after. There are probably also a lot of issues I haven't even considered yet.
Yeah a lot of issues, the biggest is your not a big company, you don't have money (or at least not enough to throw it away in layers) so you'll never sue someone that will not respect your license so :

1) go for a existing license
2) starts putting in your mind that someone, someday, will do something that you don't like and you will have to deal with it.
Nemesis wrote: One thing that I think needs to be clarified is exactly what a contributor's rights are, and what responsibilities we have to past contributors. Obviously everyone has copyright over anything they create, but what if commercial funding does come in later, or if community donations are received? Do previous contributors have any claim to money that is raised? What if a change to the licensing model is proposed? Do all previous contributors need to give consent in order for the license to be amended? What if a previous author's contributions are ultimately rewritten, do they retain any rights or claim to the resulting work? I don't know the answers to these questions. I don't want to discourage contributions to this project, but I also don't want to stuff things up in the future or hold this project back from evolving because of a lack of understanding on both sides about what exactly it means when you make a contribution to this project.
NetBSD solved this by founding the NetBSD foundation and all source code is the property of the foundation. So every commiter "give" the source code to the foundation.
Nemesis wrote: Anyway, there's a lot to consider when it comes to licensing, and it's hard to fix if you get it wrong, so I don't want to rush into it. I'm very interested in any input or feedback anyone might have.
It's really not difficult.

- Don't mind closed-source project be based on your code -> BSD-style
- Do mind -> GPL2
- Don't mind commercial product (but opensource) -> GPL2
- Do mind -> GPL3

User avatar
Huge
Very interested
Posts: 171
Joined: Sat Dec 13, 2008 11:50 pm

Post by Huge » Thu May 23, 2013 4:52 pm

Personally I think that the points you want for your license are all very smart, and would prevent the terrible mis-use that prevents many open source projects to actually get anywhere (how many thousand different Linux distros are now?).

It's a shame that TECHNICALLY it wouldn't even be considered open source, and that tells a lot about free software advocates nowadays. Too busy defining "free as in freedom" instead of producing a model that is actually useful.

Perhaps you need to invent a new, sane licence model as well, to befit your new, fully accurate emulation model, haha.
(or just make it Beerware - I'd certainly buy you a round!)

User avatar
Christuserloeser
Very interested
Posts: 145
Joined: Sun Jan 28, 2007 2:01 am
Location: DCEvolution.net
Contact:

Post by Christuserloeser » Thu May 23, 2013 11:40 pm

As a fan of your work especially in regards to FM synthesis I'd hope for this project to be released under the GPL so it can in part be used freely in other projects.
http://www.DCEvolution.net - Gigabytes of free Dreamcast software for you

Image

User avatar
Nemesis
Very interested
Posts: 670
Joined: Wed Nov 07, 2007 1:09 am
Location: Sydney, Australia

Post by Nemesis » Fri May 24, 2013 1:21 am

Thanks for all the feedback so far guys. I'm taking it all on board and carefully thinking and researching what direction to take. I'm still not decided on all the terms, so keep the feedback coming if you've got something to add.


To clarify one point, I'm definitely going to be licensing the plugins themselves (IE, the emulation cores such as the M68000 core, YM2612, VDP, etc) with a license that allows them to be re-used in other projects, as long as the sourcecode for the modified cores is also released. This will ensure people can use the cores developed for Exodus, and adapt them for other emulators and other purposes, while ensuring any improvements or additions they make can also be folded back into the main release for Exodus.

I don't necessarily want to use a totally "viral" license like GPL though, because I don't want to punish other authors for not releasing their work as open source. For example, say the author of a closed source emulator like Regen or Kega wanted to adapt a core currently in Exodus for use in their emulator. With the GPL, they could only do that if they released their entire emulator as GPL as well. I think this is much too heavy handed. I'd be happy for anyone else to use and adapt cores written for Exodus in other projects, as long as the sourcecode they use for those cores is also released, along with any changes they make, so that other people can benefit from those enhancements. I feel that the normal GPL is too extreme, in that its intent seems to be to actively hinder closed source development, not just advance open source development. I personally have no such intent. I think the development and advancement of the cores themselves is best achieved if any project, closed source or not, is able to use it and contribute to its development.

User avatar
Nemesis
Very interested
Posts: 670
Joined: Wed Nov 07, 2007 1:09 am
Location: Sydney, Australia

Post by Nemesis » Fri May 24, 2013 1:45 am

NetBSD solved this by founding the NetBSD foundation and all source code is the property of the foundation. So every commiter "give" the source code to the foundation.
I've actually seriously been thinking along those lines too. When you're writing code for a corporation, that's the way things work. While you always retain copyright over your work, the company gets ownership rights. I think contributors will need to relinquish at least some ownership rights over the code they submit to some kind of governing body, to ensure that big changes can be made in the future without requiring the consent of all past contributors, particularly changes to the license terms.

Reading the license for MAME, you can see the kind of issues that can creep in without this kind of provision. For example, on the MAME license page ( http://mamedev.org/legal.html ), it says the following:
"The code in MAME is the work of hundreds of developers, each of whom owns the copyright to the code they wrote. There is no central copyright authority you can license the code from. The proper way to use the MAME source code is to examine it, using it to understand how the games worked, and then write your own emulation code. Sorry, there is no free lunch here."
And then later on in the same page you see the following question:
Q. Can my non-profit use MAME or an arcade cabinet running MAME to help raise money?
A. No, sorry. Even for the most worthwhile cause, this still is a commercial use of MAME and is prohibited by the license.

And here's a case where even if they now wanted to change the license to allow charitable or non-profit use like this, they can't do it, because they would need approval from every past and present contributor to the project before they could allow it. I don't want Exodus to be chained down like this forever. Projects that are unable to change can die if they're unable to adapt to changing circumstances.

Most significantly for me, I don't want to lock out commercial opportunities. Say a commercial interest did arise with Exodus in the future, IE, let's say we developed some killer Saturn emulation and Sega was interested in using it for Xbox Live arcade releases or something, I wouldn't want to exclude that possibility. Commercial licensing terms could be negotiated, which would provide revenue for the project, and these funds could be used to assist in development, such as being used to acquire hardware or pay for services. It might even happen that Sega would come to the party, and provide documentation or other proprietary information to assist in emulation for problematic titles or systems if it was in their interest. As long as any development done on the emulation cores for this commercial venture also requires the sourcecode for the cores to be released, it could greatly assist the goal of emulating and documenting these systems.

Taking advantage of commercial licensing opportunities like this is only possible if a single entity has the power to negotiate those terms however. Some kind of body or organisation should have the power to amend, change, and alter the terms under which the sourcecode is licensed in the future. This will allow the project to move with changes in technology and circumstances.

User avatar
Nemesis
Very interested
Posts: 670
Joined: Wed Nov 07, 2007 1:09 am
Location: Sydney, Australia

Post by Nemesis » Fri May 24, 2013 2:16 am

This is really the opposite of OpenSource. The main goal of OpenSource (besides having people fixing your bugs instead of you Razz) is to allow multiple uses of your source code in other projects (an emulator will take your m68k core for example) in a fork (a "low-cost" version for mobile device ...).

When you say multiple implementation of one device, you mean multiple m68k core for example ?
I don't really see the point of doing that (except for "low-cost" implementation of course like byuu did with the profile thing in bsnes).
I'm perfectly happy for cores to be forked and developed separately from the existing core. In fact, if someone has an idea for a radical modification to an existing core that is too major to simply be incorporated in the existing code, I encourage them to fork it and make a separate implementation, so that its merits can easily be determined and compared. I'll be doing this with my new M68000 core for example, where I'm attempting to emulate microcode-level bus timing. These changes are too far reaching in order to just do them as an enhancement of the existing core, it's a fundamental rewrite. For changes like this, I expect new and experimental cores to often be provided alongside a more stable, older core. Once the experimental core stabilizes, it can replace that core. It's also possible to have "high performance" builds like you mentioned, perhaps just being the same core with some high impact debugging features excluded from the build.
You said in another thread that you will not maintaining Linux build of Exodus.
Let say I take your source when it will be available and I port it to Linux (well FreeBSD in my case but let's say port it to X11/GTK/Whatever) and for some reason you don't want to commit my changes to the official Exodus repo (one reason would be that I changed a lot of stuff in the source tree to make the core architecture/OS-agnostic and you don't like it).
What do I do with my unix fork of Exodus ?
That's a very good question. I don't know if I have the perfect answer to that, other than to say, perhaps a design should be agreed upon before developing the Unix build, so that there isn't any problem integrating everything together into one official repository? Or maybe rather than just releasing the Unix fork, development should continue until there is an agreement that the changes are acceptable to be merged in?

If the Unix fork was allowed, consider the reverse problem: what if you've just spent 6 months getting an awesome cross platform Windows/Unix/MacOS build working, and then I release a new major version that changes a bunch of architecture under the hood that requires you to do another 6 months work in order to integrate it back into your fork. What if the same thing happens in another 6 months time? Should I avoid large changes in the main repo because I'm worried about breaking the Unix build? Will you give up on maintaining your separate fork, and it gets stuck 3 years behind the main release? Will users stick with your outdated fork rather than adopting the main release? What if another developer doesn't like the way you've done your build, and creates another cross platform build? Should users have to try each version until they find the one that's best for them? Should plugin authors have to maintain support for deprecated platform features, or hold off using new features, because of worrying about losing support for an outdated yet popular fork of the platform?

Here's what I'm worried about:
http://segaretro.org/Gens
Look at how many different "unofficial" releases of Gens there are out there. Most of them just add a few bells and whistles. Heck, even I've released one, and I can tell you, all I did was tack on one quick and dirty feature I needed, and I only released it because other people were interested in using it. Which of these releases is the best for debugging? Which is the most accurate? If I was a new user how should I know which one is best to try? If as a developer, you now wanted to integrate all the various additions from each project back into a single distribution and unify the development effort, how much work would that involve?

User avatar
ElBarto
Very interested
Posts: 158
Joined: Wed Dec 13, 2006 10:29 am
Contact:

Post by ElBarto » Fri May 24, 2013 8:16 am

Nemesis wrote:
You said in another thread that you will not maintaining Linux build of Exodus.
Let say I take your source when it will be available and I port it to Linux (well FreeBSD in my case but let's say port it to X11/GTK/Whatever) and for some reason you don't want to commit my changes to the official Exodus repo (one reason would be that I changed a lot of stuff in the source tree to make the core architecture/OS-agnostic and you don't like it).
What do I do with my unix fork of Exodus ?
That's a very good question. I don't know if I have the perfect answer to that, other than to say, perhaps a design should be agreed upon before developing the Unix build, so that there isn't any problem integrating everything together into one official repository? Or maybe rather than just releasing the Unix fork, development should continue until there is an agreement that the changes are acceptable to be merged in?

If the Unix fork was allowed, consider the reverse problem: what if you've just spent 6 months getting an awesome cross platform Windows/Unix/MacOS build working, and then I release a new major version that changes a bunch of architecture under the hood that requires you to do another 6 months work in order to integrate it back into your fork. What if the same thing happens in another 6 months time? Should I avoid large changes in the main repo because I'm worried about breaking the Unix build? Will you give up on maintaining your separate fork, and it gets stuck 3 years behind the main release? Will users stick with your outdated fork rather than adopting the main release? What if another developer doesn't like the way you've done your build, and creates another cross platform build? Should users have to try each version until they find the one that's best for them? Should plugin authors have to maintain support for deprecated platform features, or hold off using new features, because of worrying about losing support for an outdated yet popular fork of the platform?

Here's what I'm worried about:
http://segaretro.org/Gens
Look at how many different "unofficial" releases of Gens there are out there. Most of them just add a few bells and whistles. Heck, even I've released one, and I can tell you, all I did was tack on one quick and dirty feature I needed, and I only released it because other people were interested in using it. Which of these releases is the best for debugging? Which is the most accurate? If I was a new user how should I know which one is best to try? If as a developer, you now wanted to integrate all the various additions from each project back into a single distribution and unify the development effort, how much work would that involve?
For all those questions and the "gens problem" there is only one answer :
Port it to unix/linux/macos yourself from the start or don't care about those platform.

Something I've learned being in the opensource world since +10 years is your project will be forked/ported as a separate project at some point.
If it doesn't happens, it's either you did a really good job or a really bad one.

I don't really remember when Stef stopped working on Gens but doesn't all those forks happens later ?

Nowadays it's easier to submit changes to an opensource project, especially if it's hosted on a platform like github. Some guy want to add something, he clone your repo, make branch for his change, commit/push code and then to a pull request so you can examine his changes.
This way you can either accept and pull the new code onto the official repo or reject the request because some stuff aren't acceptable (license, coding style etc ...).

Back on the topic of unix/linux/macosx.
If you don't maintain a build yourself you will be exposed to some problems.
Just look at mame, avdmame had the problem you described (old fork, not maintain at some point) but it was the only way to use mame on unix/linux before the SDL OSD was commited in the official mame.
I'm not saying that all development have to be done by you, but you have to, someway, be in the development process.

Post Reply

Who is online

Users browsing this forum: No registered users and 1 guest