Making Exodus Open Source: What license model to use?

Official support forum for the Exodus Emulation Platform

Moderator: Nemesis

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

Post by Mask of Destiny » Fri May 24, 2013 6:37 pm

Nemesis wrote: 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?
I think the problem with Gens is that the main project was effectively abandoned shortly after it became open source. If the easiest way to "contribute" is just to fork it then that's what people will do.

It's also worth noting that distributed version control systems make re-integrating changes from forks much easier. So much so that the common workflow for those sort of projects is to fork the repository, make the changes in your fork and then submit a pull request.

DinnerX
Newbie
Posts: 1
Joined: Sat May 25, 2013 1:56 am

Post by DinnerX » Sat May 25, 2013 2:46 am

Have you looked at what byuu did with BSNES/higan? The project has been very successful with the GPL, and you seem to have a similar goal of perfect emulation in mind for Exodus. BSNES/higan has been forked a few times, but it certainly hasn't been detrimental, and despite the fact the project uses the viral GPL it has been developed essentially to completion.

I think the GPL is really a good license for a preservation project, because it ensures the freedom of the source code and all future developments of that source code. However as a consequence the source code can be forked and can be use for commercial purposes without payment to the author(s), and that may break it for you here.

zeromus
Newbie
Posts: 3
Joined: Sat May 25, 2013 8:47 pm

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

Post by zeromus » Sat May 25, 2013 8:53 pm

Nemesis wrote:Ultimately, I'm trying to chose a licensing model that I think will best help the project evolve.
Take a deep breath, hold it, and then release it. With the stale air, you also exhale your desires to control other people, leaving nothing but a core commitment to make cool stuff, and a trust that most other programmers just want to do the same.

Then choose a BSD or MIT license for the whole enchilada and copyright all committed files to you with an implicit copyright assignment. Since you're a mellow, trusting dude, contributors trust you too.

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

Post by Nemesis » Sun May 26, 2013 1:58 am

zeromus wrote:
Nemesis wrote:Ultimately, I'm trying to chose a licensing model that I think will best help the project evolve.
Take a deep breath, hold it, and then release it. With the stale air, you also exhale your desires to control other people, leaving nothing but a core commitment to make cool stuff, and a trust that most other programmers just want to do the same.

Then choose a BSD or MIT license for the whole enchilada and copyright all committed files to you with an implicit copyright assignment. Since you're a mellow, trusting dude, contributors trust you too.
This isn't about controlling other people, or about other people liking me, this is about leading and directing this project.

Programming isn't just my hobby, it's my job. What I can tell you from experience is that if you put 5 different programmers together on one project, you'll end up with 5 different opinions on how something should be designed. There are always differences of opinion on how something should be implemented. That's good and healthy. What you need to do when faced with this kind of situation though is talk it out. You need to sit down and look at each point of view, and discuss the merits of each approach, and at the end of the day, a decision needs to be made about a single direction to take, which incorporates the best points of each proposed approach.

The right approach is NOT to send all 5 developers off separately for 6 months to implement their own design separately. What you end up if you do this is 5 different implementations, none of which are often nearly as good as if you'd discussed and agreed on a unified approach to begin with, and ultimately, one of them is adopted and used, and the other 4 get scrapped. That's wasted effort, a poorer result, and you ultimately are left with 4 disillusiond progammers who no longer have any ethusiasm for the project because they feel like their efforts have been wasted and haven't been appreciated.

The thing is though, most programmers, especially hobbyists, don't like working in teams, they like to do their own thing. Now I'm more than happy for people to do their own thing when it comes to emulation cores, but when it comes to the emulation platform itself, it needs to be stable and unified. This emulator is plugin-based. The plugin system has a well defined API. There needs to be one version of it, with clear versioning control, in order for plugin authors to develop against it. If we have the core platform being forked, the plugin model itself is going to be compromised, because the plugin API is going to start to be modified between different forks and incompatibilities are going to arise. This isn't a one developer project, or at least, I believe it can be much bigger than that. I don't want developers who are unwilling to work as part of a team going off on their own and fragmenting the platform.

It's harder to agree on one direction for a project, but ultimately, it's what's best for the project itself. You get a better result if everyone works together.

vecna
Newbie
Posts: 4
Joined: Thu Aug 09, 2012 4:10 am
Contact:

Post by vecna » Sun May 26, 2013 5:24 am

It's harder to agree on one direction for a project, but ultimately, it's what's best for the project itself. You get a better result if everyone works together.
If this is really how you feel, if you really want to disallow forks... You should consider keeping it closed source and attempting to recruit people to work on it with you while keeping the source closed.

Opening the source and disallowing forks is... really, not open source.

This may seem hyperbolic, but please consider that releasing the source under a incompatible-with-anything license may actually be harmful:

You have stated that you wish to adopt a code-as-documentation strategy. Ironically, for closed source emulators, the Exodus source code would be safe, as an author can freely examine the Exodus source, lift bits and pieces of it, and no one will ever be the wiser.

Who this damages is other open source emulator authors. The Exodus source code becomes something that, if you are smart, you will never download, and never look at, for fear that your code will be (legally) contaminated.

You are a major contributor to the spritesmind forums, and you have posted many code excerpts. Does browsing spritesmind itself become a legal minefield to the people who are its exact audience?

How do you even control what a "fork" is? I guess you just don't grant redistribution rights, so that you are the only one that can redistribute? For one, there are no major open-source hosting sites that will host code under such a license. You can distribute the code on your own website as a zip file, but that's not a great way to collaborate.

You said you wanted Exodus to evolve - evolution is chaotic and decentralized.

You cited gens as what you wanted to avoid - but why? First, the chaos is largely because no one was centrally maintaining it. But in the meantime, some people took gens, fixed some desync bugs, and turned it into gens-rr (re-recording). Other people took gens and added rewind capability. Other people took gens and add enhanced debugging capabilities.

If gens had still had an active central maintainer, there is no reason that maintainer could not have absorbed those enhancements from the various forks.

Having a central maintainer would have been nice, but are we really worse off for having all these gens forks, would we be better if those forks had never existed and gens just never moved forward?

Allowing forks does not diminish the capability of a central maintainer to integrate work done in those forks.

For the record, my vote is for MIT/BSD. If you want your code to exist as documentation for the Mega Drive, this is the license that allows it to be that without undue legal headaches.

Look at the D programming language. It existed under a restrictive license, then it changed licenses and put itself on github, and contributions EXPLODED. I note that D still has one strong, central distribution, because it is actively maintained by the core group.
People do work together, as a team - it is an active central maintainer that facilitates this, NOT a restrictive license.

zeromus
Newbie
Posts: 3
Joined: Sat May 25, 2013 8:47 pm

Post by zeromus » Sun May 26, 2013 6:29 am

Nemesis wrote: This isn't about controlling other people, or about other people liking me, this is about leading and directing this project.

It's harder to agree on one direction for a project, but ultimately, it's what's best for the project itself. You get a better result if everyone works together.
That doesn't make any sense to me. It sounds like it is about controlling people in order to result in an outcome you prefer, which is for them to be yoked to your engineering and project management direction to ensure a more perfect design and ecosystem.

None of this has anything to do with licenses. You can lead and direct and have (almost) everyone work together without legal micromanagement. The carrot of cooperation in a smoothly operating project far exceeds the significance of the stick of license restriction. Legal micromanagement is used to control your collaborators and punish the ones who resist by preventing the normal safety valve of forks. Without requiring any clever licensing, you can coordinate with your collaborators by being a benevolent dictator and leave open the safety valve for those who chafe.

The typical way for a hacker to deal with forks is to make the best fork, not create legal and biz-org constructs of complexity rivaling the software's.

Nobody wants developers to go off on their own and fragment a platform. It's one of those rights, like self defense, you have to know you have, but you hope you never have to exercise it, because the alternative of just getting along is much more pleasant. It probably won't happen, anyway. As vecna says, it seems not to happen while a project retains enthusiastic and skilled leaders and coordinators such as yourself.

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

Post by Nemesis » Sun May 26, 2013 6:46 am

vecna wrote:...
You make some good points.

Ok, let's talk a bit more in detail about open source licenses. Why would you choose the MIT/BSD license over something more restrictive? Specifically, do you think it's worth using a license that forces any source changes or improvements to a core for example to be released publicly, even if the core is being used in a closed source project?

zeromus
Newbie
Posts: 3
Joined: Sat May 25, 2013 8:47 pm

Post by zeromus » Sun May 26, 2013 5:08 pm

You may wish to check the MPL at http://www.mozilla.org/MPL/2.0/ which forces changes to be submitted back in a less practically repugnant way than the GPLs. Remember, the GPLs arent exactly about forcing changes back to the community, but are actually about letting end-users run different code. This is impossible in many commercial use contexts and makes the use of even a whiff of the idea of GPL code completely impossible.

From the faq at http://www.mozilla.org/MPL/2.0/FAQ.html
* MPL: The copyleft applies to any files containing MPLed code.
* LGPL: The copyleft applies to any library based on LGPLed code.
* GPL: The copyleft applies to all software based on GPLed code.

Any engineer should be able to fiddle around with the MPLed sources to keep the proprietary code out, before being forced to send the changes back. More importantly, imho, it communicates the moral statement that substantial changes are requested for back-contribution, and nobody cares if you have to scrub your proprietary stuff.

I have no information about the success of the legal history of the MPL, but like I said, it makes a clear moral statement, and immoral people will just use the code without obeying the license anyway.

vecna
Newbie
Posts: 4
Joined: Thu Aug 09, 2012 4:10 am
Contact:

Post by vecna » Sun May 26, 2013 7:19 pm

Ok, let's talk a bit more in detail about open source licenses. Why would you choose the MIT/BSD license over something more restrictive? Specifically, do you think it's worth using a license that forces any source changes or improvements to a core for example to be released publicly, even if the core is being used in a closed source project?
I would ask you to think realistically about what your concerns are.

Some emulators authors are concerned about commercial exploitation of their work that they won't be compensated for. It's not an absurd concern, but, I respectfully submit that people aren't going to use Exodus for this. Most of the commercial opportunities exist in the mobile space, where cpus are less powerful, and more importantly, battery is king - you can get excellent compatibility on the MD while being dramatically faster than cycle-accurate allows.

Now maybe someone wants to write an emulator, maybe a closed source, maybe a commercial, maybe a MIT licensed. Maybe they're just writing it for fun and want to release the code under a permissive license. Maybe this emulator author wants to make use of Exodus, for either information regarding the workings of the Megadrive, or to utilize its debugging capabilities, or for A/B core testing. Is this a negative outcome?

Links to some random slashdot discussion (for whatever that's worth):

http://developers.slashdot.org/story/11 ... ining-fast
http://developers.slashdot.org/story/13 ... e-licensed

I would just note that none of the OSI-compatible licenses actually forbid commercial use, including the the GPL. And licenses that forbid forking are essentially unheard of.

MIT is just more flexible than the GPL. GPL isn't just at odds with closed-source programs, or platforms where the GPL cannot be used at all, it's also at odds with more permissive open-source licenses, and virtually any open source license that isn't the GPL.

Modern software is super complicated and built with countless layers and libraries. "GPL all the way down" is just too impractical in a lot of cases. Someone, somewhere along the software chain, has to make money so they can eat. As C is the "lingua franca" of programming languages, MIT is the lingua franca of licenses. Everything can make use of C code, and everything can make use of MIT/BSD/Apache code.

-------------

On a personal note, those of us who are really passionate about the Genesis, are what, in our thirties now? We have jobs and families and real lives. The number of people in the world with both the significant skillset required to do this work, AND the interest, AND the time and dedication, is small. On this forum there has been a good spirit of cooperation and mutual helping-each-other-out.

It occurred to me the other day that I am one of about..6(?) people in the world, who have written a working / non-toy Turbografx emulator. It was a lot of damn work, and mine isn't even super special. It's not cycle-accurate or anything yet. The intersection of capability and interest and time just isn't that large.

I think it is fair to say that you are in a relatively small company of people that understand the MD internals the way you do. The risk of someone fixing a bug in Exodus and only releasing it in their closed-source Exodus fork is just... insignificant. And if AamirM or Snake finds a bug, even if their emulators are closed source, I would bet that they would let you know.

For me, the interests of long-term preservation and truly open, unencumbered documentation, just massively outweigh the risks of what a script kiddie might do with your code that you don't like. And I'm not going to tell you that no one is going to do things with your code that you might not like - only that it doesn't matter.

One of the goals that we had with bizhawk was to write MIT-licensed cores so that people could stop re-inventing the damn wheel all the time (unless they wanted to). "Here is a relatively high-quality implementation of this system. Maybe you don't like C#, but you are welcome to examine this code as reference code, port it to your language of choice, A/B test against it, pull out the sound chip and use it in a VST plugin, or use it to put a chiptune in the About box of your commercial data analysis tool, whatever you like, under mostly whatever terms you like. The answer to 'Can I use this code?' is yes."

You mentioned Exodus as an emulation platform bigger than the Genesis. If you one day wanted to add Turbografx capability to it, and you went with your original idea for a no-forks-allowed license, you would be completely legally unencumbered to make use of my MIT-licensed PCE core for whatever purpose you like, whether it just be to take snippets from it, or just to read the code to get a big-picture view of the hardware, to help you debug your code or what, but you would legally unable to make use of any other major PCE emulator, unless you used their license.

Of course, you would probably rather do solely hardware tests, but I think the point stands. Do you want to completely re-invent the wheel if you don't HAVE to? I promise you that reading the code of a working, high-compatibility emulator is more productive to get a feel for the system's hardware than any of the non-code documentation that exists out there.

People may use your code in ways you don't expect. Embrace it. I suspect I don't have to convince you that a kickass 68000 core is useful for more than just Genesis emulation, and more than just console emulation, and more than just emulation in general. Someone might use it in an assembler/simulator style app that helps people learn assembly language and CPU, or even EE concepts. Who knows.

One of the goals of a bizhawk or libretro is that people can take good cores and abstract them to a relatively clean, easy API, and write custom clients that the cores are well integrated into. I have some ideas that I think are really fun for new types of emulator UIs, if I ever get time to work on it. But classic UIs are good too. Some UIs will target lua scripting and TASes. Some will focus on making the best possible experience for people to just play a game. Some will target maximum debugging and homebrewing. Some will want a maximally accurate core. Otherwise would rather take a high-performance core.

It would be ideal if the release of the Exodus code can facilitate all of these things by being a high-quality reference implementation and documentation of MD internals (and the significant amounts of hardware testing that you have done), in a way that doesn't make looking at the Exodus source code a legal liability.

Genesis emulation is currently in a frustrating state, we currently have a number of very high quality emulators, most of which are closed source. KEGA is an amazing piece of software.... but the client just isn't very good and unfortunately because of its closed source nature, it's an evolutionary dead end. Regen is cool but there are many tiny issues, crashes, stupid things about window scaling not working well with different sized window chrome, that no one besides AamirM can fix. It's also a dead end.

genplus gx is a high-quality open source emulator, but it is a combination of GPL and MAME-like licenses which make it problematic for use as a reference emulator.

You have an opportunity to bring us to a happier place. So I apologize for writing a wall of text, but it's something I care about! There aren't enough of us out there for us to each have to reinvent the wheel completely. (and "the wheel" is too damn big!) We need to be able to stand on each other's shoulders. And my estimation is that MIT is hands-down the license which best facilitates this.

Eke
Very interested
Posts: 818
Joined: Wed Feb 28, 2007 2:57 pm
Contact:

Post by Eke » Sun May 26, 2013 11:17 pm

genplus gx is a high-quality open source emulator, but it is a combination of GPL and MAME-like licenses which make it problematic for use as a reference emulator.
Not anymore, Genesis Plus (and by extension my GX "fork") have been entirely switched to a MAME-like license (with only some use of LGPL library code from Shai Green, which is very different from GPL) and, afaik, it's now only problematic to people who want to reuse the code in their own GPL project.

For the record, it was changed because unfortunately GPL does not protect or gives back to original authors as it should in some specific case, namely when being distributed on closed commercial markets like Android or Cydia which encourage paid applications over free alternatives. Also, I don't like the fact that with GPL, anyone could keep modified/forked sourcecode private until someone actually ask for it, which could never happen and is bound to being able to communicate with the developper in the first place.

Suffice to say I was not much aware of licensing issues before that and, although i am pretty sure we won't see a commercial exodus spinoff on android soon, i can understand why Nemesis would want to keep minimal control on how his code is being used, even if in the end, off course, you cannot really control much once the code is out.

From experience, forks rarely bring anything worth back to the original emulation and only benefits to the limited user community using the fork (multiple Gens forks examples) but sometime it does, and I like to think Genesis Plus GX is one good example.

So maybe you could have some quality "rules" about how any additional or clone work should be done if using the exodus engine (the general exodus design goals on your website is a good start).

You could also maybe writeup a license with different terms for:

1) "cores", which could be reusable/modificable separately in other emulator projects with different philosophy/goals from exodus, providing they remain "open-source" (as in "distributed with sourcecode", not necessarely the strict OSI proprietary definitition). Maybe LGPL could be a viable option, as it permits linking with GPL-incompatible code, if you do not mind your cores being eventually reused in commercial apps.

2) exodus engine/api, which is unlikely going to be modified by anyone else than you (unless it is not 100% portable) or at least used anywhere else from exodus and could eventually remain closed source (altough i guess adding new cores would probably require some modifications/adaptations and could benefit from being "open source")

3) user interface, which is what you could want to see ported to other architectures by other people.

4) the whole application (or a predetermined set of code which would define the application as a whole) which could be licensed under more restrictive terms, to prevent dirty forks or unwanted commercial use in development solutions, etc

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

Post by sega16 » Tue May 28, 2013 1:43 am

Using a BSD/X11 MIT style license is not a good idea under those licenses it is possible for someone else to sell exodus for profit without any legal issues in addition to that someone else would be able to patent anything released under those licenses. Nemesis knows what he is doing and a restrictive license appears to be needed. If Exodus was to become open-source how would I contribute code I may want to do a GNU/Linux port but what happens after I made the changes? How would I contribute them?

frederic
Interested
Posts: 23
Joined: Tue May 28, 2013 7:32 pm
Location: France

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

Post by frederic » Tue May 28, 2013 8:34 pm

Hi everyone,
Nemesis wrote:I don't want this to be like linux, where you've got 15 different flavours of Exodus. [...] 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.
Linus Torvalds created Linux in 1991 and released it under the GPL. 22 years later, he hasn't lost main control over the project (see "Torvalds remains the ultimate authority on what new code is incorporated into the standard Linux kernel" on this page).

I only know of two forks of Linux. The first (μClinux) has been integrated back into the original kernel, and the second (Android) is in the process of doing the same thing. So nothing became more popular than the original kernel in 22 years.

This kernel has been used in dozens of Linux distributions, which is a good thing. There is a need for Ubuntu for people who want a free (as in free beer) Windows-like operating system, there is a need for Debian for geeks who hate Windows-like operating systems, there is a need for Damn Small Linux for people who wants to reuse their old 486, etc.

With GPL, you'll never lose control over your project. You'll only lose some control over what people do with it. It's unlikely that someone will make a fork of Exodus that becomes more popular than the original (which wouldn't necessarily be a bad thing anyway). People will probably rather create cores for it, like people create distributions of Linux. Linux is a base to make operating systems, and Exodus is a base to make computer system emulators.

Anyway, I hope that one day I'll be able to "apt-get install exodus-genesis" :-).

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

Post by Nemesis » Thu May 30, 2013 5:37 am

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?

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

Post by Nemesis » Thu May 30, 2013 5:46 am

Just to give a bit more info about how things would work too, I'll be hosting the sourcecode on bitbucket.org as a Mercurial repository. I'll be doing bug tracking and managing development tasks using a JIRA OnDemand (hosted) instance under the free open source licensing offer, linked to BitBucket for code change integration. That'll all be free, and should allow easy collaboration and a transparent development process.

clobber
Newbie
Posts: 1
Joined: Wed Jun 05, 2013 6:58 pm

Post by clobber » Wed Jun 05, 2013 7:11 pm

I've selected the Microsoft Reciprocal License (Ms-RL) as the "primary" open source license to use.
Contributor License Agreement (CLA) for any code submissions
Wat.
I'll be doing bug tracking and managing development tasks using a JIRA OnDemand (hosted) instance under the free open source licensing offer, linked to BitBucket for code change integration.
I really can't believe how difficult you're making this. You wrote a cycle-precise Mega Drive emulator, not an operating system kernel. The amount of hoops you want people to jump through just to send you a patch is insane and will lead to no contributions.

You should take a few steps back and think about if you really want to open source, because it sounds like you don't.

You're worried about forks and cite Gens, but Stéphane open sourcing the original Gens is one of the best things that happened to the community. Same with Genesis Plus from Charles.

It's just a shame more users aren't aware of the amazing work Eke has done with GenesisPlus-GX, because it's the best Mega Drive/CD emu out right now.

Post Reply

Who is online

Users browsing this forum: No registered users and 1 guest