Thanks to everyone who's given their input and suggestions on the licensing discussion so far. After a lot of careful research and thought, here's what I'm proposing as a licensing model:
1. Generic utility libraries covered under the Apache 2.0 license
2. Multi-license the sourcecode for the main application, interface and base class libraries, and all cores shipped with Exodus, under both the Microsoft Reciprocal License (Ms-RL) and the GNU General Public License Version 3 (GPLv3)
3. Contributor License Agreement (CLA) for any code submissions
I'll go into detail as to why I think each of these options is the best choice below.
1. Generic utility libraries - Apache 2.0 License:
This code is basically being released free, with no restrictions. People can use it for any purpose, modify it, whatever, and not have to release their changes back. This license is basically a more modern and legally bulletproof version of the permissive MIT and FreeBSD licenses. The only difference is a more clear, explicit legal language, and some protection in regards to patent laws, something that simply wasn't on the radar when the MIT/FreeBSD licenses were made. Unfortunately the patent protection renders the Apache 2.0 license incompatible with the GPLv2 license, but it's fully compatible with the GPLv3 license.
2. Main application, interface libraries, and plugins - Ms-RL/GPLv3 licenses:
I've selected the Microsoft Reciprocal License (Ms-RL) as the "primary" open source license to use. This is similar to the LGPL, but much simpler and a bit less restrictive (in particular, without the silly "must allow re-linking" rule in 4d), and it includes some protection for patent laws. Like the LGPL, you can use the code in a closed-source project, even a commercial one, but any assembly which contains compiled Ms-RL licensed code code (IE, anything which links directly to the support libraries in particular) has to follow that license, and you have to release source code changes for any code you modify. Basically, it's a weak copyleft license.
Note that under this license, with some effort, it will also be possible for people to release closed-source cores, or port existing cores that are covered under incompatible licenses (which hopefully there won't be any of). I decided to abandon the idea of trying to force all cores to be open source, primarily because the only enforcable way to do it is to use a strong copy-left license like the GPL, but a viral license like this I feel is just going to hurt the project by effectively preventing any re-use of these cores in other applications, and preventing existing cores being ported to this platform where the existing licensing terms cannot be changed. Only cores that adopt the same licensing terms as the Exodus project will be allowed to be included into the "official" release of Exodus, and after some careful thought, I feel this will be sufficient to encourage open source core development. The lack of an official core for a given device in the Exodus built will itself be a motivator for someone to develop a core under a more permissive license if a closed-source or GPL'ed core currently exists.
I decided to relax on the non-commercial use angle I was thinking of at the start. The reason for that is simply because after some thought, I decided it isn't desirable to lock out development contributions from the commercial sector if they find a use for this platform in their organisation. While they'll potentially be able to make money from this project and that money won't be passed on to any contributors, as long as they're contributing back to it in the form of source code releases for improvements they make to the platform, that will still benefit the community. I'm not worried about commercial use in the way the MAME license was designed to protect against, namely, people using Exodus in a public setting like an arcade, primarily because not only are arcades pretty much dead, if they were doing this, it would be illegal anyway unless they've obtained a license to use the games themselves in that manner, which of course they would not have, so if they're willing to break copyright law for the games, they wouldn't think twice about breaking the usage license for Exodus either.
Now, you'll note that I've said I'm releasing this code under a multi-license model, with the other license being the GPLv3 license. The reason for this is simple: I want people to be able to port cores which are currently covered by the GPL to Exodus, and the Ms-RL license (like most other licenses) isn't compatible with the GPL. I chose GPLv3 as the secondary license rather than LGPLv3, simply because I don't want to encourage use of the GPL license, it's only there for GPL compatibility. Ms-RL is the primary license from my point of view. That said, the source will be released under both licenses, so you can choose which one you want to apply to your given circumstances.
3. Contributor License Agreement (CLA):
Any developer wanting to submit code to the official Exodus repository, such as changes to the main platform itself, or the addition or modification of any plugins (IE, emulation cores or system extensions), will need to first sign and return (IE, print, sign, scan, and email) a completed Contributor License Agreement (CLA) before code changes can be accepted from that developer.
Some of you may wonder why a CLA necessary. The first thing you should know is that it's actually not uncommon, and it has nothing to do with how restrictive the usage license is. The OGRE 3D engine for example (
http://www.ogre3d.org ) requires all developers to complete and return a CLA, and it's licensed under the MIT License, one of the most permissive and simple software licenses that exists. The idea of the CLA is actually to make the project more open, and to offer protection to you as a contributor. What you might not know is that without a CLA in place, every single code contributor to an open-source project is actually entering into a separate license arrangement with every single user of the software, and those contributors carry all the legal responsibilities, and liabilities, that arise from that license arrangement. This is quite a vulnerable position to be placed in as a contributor, and a CLA is really necessary from a legal point of view to offer you some protection. The CLA I'm going to provide for Exodus will do three main things for us:
1. Allow the licensing terms of Exodus to be changed without consent from all previous developers. This may seem strange to require, but something as simple as changing the code base from version 2 to version 3 of the exact same license model often can't legally be done without approval from all past and present contributors without this kind of clause. This is essential in order to make sure the license model itself can change and evolve with changing circumstances, and without this, if a past contributor can't be contacted, the license could never be changed. Note that as per the CLA in OGRE however, a clause will only permit any code that you have submitted to be relicensed under other open source licenses. In other words, nobody can suddenly decide in a few years time that Exodus is going closed-source, and build off your work without releasing it back.
2. Allow infringement of the license terms to be pursued by the community governing the project itself. Without this, if someone starts using code you submitted to Exodus in a way the license forbids, nobody else could do anything. You would actually have to contact a laywer and drive all action to attempt to enforce the license. In other words, without this provision, the license is virtually non-enforceable, unless you're going to police it yourself for each section of code you write. See the following thread on the Ogre forums about a real problem that arose from this:
http://www.ogre3d.org/forums/viewtopic.php?f=4&t=47469
3. Protect individual developers from patent lawsuits. This is absolutely totally critical. Remember that we're emulating devices here, and along the way, we could inadvertently infringe on patents taken out by companies, and this becomes more and more likely the closer you get to the way the real hardware behaves. A transistor-level emulation of any device for example would almost certainly infringe on every single patent that may cover that device. Without this protection, if you wrote an emulation core for a device, and the owner of the patents for that device (say, a holding company in Texas that recently acquired the patents in the buyout of a bankrupt company) could send an army of laywers after you trying to sue you for damages. With this CLA agreement, the governing entity managing Exodus can absorb these challenges, and fight or deflect them on your behalf.
In order to make the CLA work, two corporations will have to be registered as actual legal entities. The first one will be a holding company for the intellectual property, to which you will enter an agreement via the CLA. The second one will be the company which provides the public face for exodus. This second company will license the intellectual property from the holding company, and will actually release builds of Exodus publicly. With this model, if legal action is threatened, all that can happen is the assets of the company that provides the public face can be seized. Which is absolutely nothing, since it has no assets. The actual rights to the source itself remains safe as the property of the holding company. Without this protection, and with the presence of the CLA, a company could sue for damages and acquire all the assigned rights to the Exodus sourcecode in the settlement.
As I mentioned before, this is how the OGRE community is setup, and there are many other examples out there. Notice that the CLA doesn't further restrict how the source can be used, rather, it gives it the freedom to respond to changes in licensing models, and the power to enforce those licenses, while offering protection to the community itself and individual developers from legal action. I still have to look in detail into what's involved in setting up these dummy corporations, and how the CLA will be worded. Here are some examples of CLA licenses that are out there:
OGRE -
http://www.ogre3d.org/downloads/OGRE_Co ... icense.pdf
Google -
https://developers.google.com/open-sour ... individual
Apache -
http://www.apache.org/licenses/icla.txt
I'll be basing the CLA for Exodus off one of these, most likely the OGRE CLA, although I haven't compared them in detail and decided on all the precise conditions yet.
So that's what I'm thinking of now. Any feedback on this proposal?