Note: Post has been edited to include feedback, particularly treating the "Engine" as its own thing under Apache 2.0 and most the below being specific to content / modules. Today's mega post that isn't quite as huge as the others. Or maybe it did get that long, now that I review. We've talked about project licensing and contributor guidelines in the past now and then but haven't really picked a sure-thing. I'm not a license expert but I put an item on my list to try to sort it out. Hasn't really gone anywhere but I think I was hitting it on the wrong angle - instead of picking a license first instead sort out the non-legalese version of how we want Terasology contributions to work, adapt with feedback, then in the end figure out what license (combo) works the best A big topic that isn't really super relevant now is how we feel about others using Terasology, especially if money gets involved. Some contributors are fine with others making money off their work, others not so much - they contribute here for the community, not so somebody can fork us, rebrand, then turn around and sell the game somehow (this has actually happened partially a few times but usually it doesn't get too far, certainly not far enough to actually sell anything... not to my knowledge at least). This is something we should prepare for so we only need to do this once. I'm using Steam examples below purely hypothetically. Note that I'm not at all including stuff like monetization on YouTube videos shot of the game. That's a side thing I'm not worried about, is probably covered by some fair use thing or what not anyway. So in going with the codebase restructure that would split out modules I came up with a matching contributor setup that relies heavily on where code lives to determine how it is allowable to use. Dunno if that's a common tactic to use for licensing but I'm giving it a shot. When I say "MovingBlocks" I mean any of our GitHub organizations. While I'm sure it needs more tweaking it ends up grouping people (and their work) into three types (beyond the engine, which is its own thing): Spoiler: Engine License / Agreement License type: Engine Code lives: https://github.com/MovingBlocks/Terasology Tag line: "Engine free for any use with attribution" Typical person: Core contributor (insider) or interested developer wanting to use the engine for a different project (outsider) Standard Apache 2.0 license terms as is currently in place for everything Means we only need to re-license a subset of files (unsure exactly how facades would factor in - at least some would be engine level too) The "Core" module might also be covered by this as it is needed to create a world? Engine is a central community project equally "owned" by everybody and available for everybody's use (including people outside the project) Anybody can use the engine for other projects and monetization as long as the Apache 2.0 terms are followed (attribution etc) Spoiler: Contributor License / Agreement License type: Contributor Code lives: On GitHub in a MovingBlocks root repo Tag line: "Contribute to the community, benefit with the community" Typical person:Contributor happy to be part of the core community and accepting of having others collaborate on their code Allows other contributors to help maintain and enhance your work (actually making decisions on functionality is a different topic - led by author/curator). Sort of a limited "official support" thing (although we are under no obligation to help, we just are authorized to do so) Allows inclusion of content in a package setup that can be monetized with money going into a big community pool (say providing the game plus a set of modules on Steam for a token fee) Allows content to be monetized directly where you benefit as a contributor (say offering a single module via SteamWorks for a fee) with a small portion going to the general community pool Disallows monetization outside the contributor community Anybody can fork and use for non-commercial purposes. Must remain open source. Question: How to handle curator (primary author) if somebody goes inactive? Spoiler: Modder License / Agreement License type: Modder Code lives: On GitHub, rooted under the user's account, forked to MovingBlocks Tag line: "Collaborate with the community, but do your own thing" Typical person: Modder who would like an official connection with the community and to benefit some from shared resources, but wants more independence. In return for benefits code is licensed to revert to Contributor style should author go inactive. Authorized by author submitting a commit to a LICENSE file and requesting to be forked to MovingBlocks Then allowed in official distributions (although with no official support, only minor tweaks if needed for packaging) Allows content to be monetized by author on something like Steamworks if agreed that a small portion goes to the general community pool (author does not share in community fund as a modder instead of contributor but gets the lion's share of their individual module sales) Allows content to be monetized elsewhere (independent of community) by author. Example: Donation button on personal site. Anybody can fork and use for non-commercial purposes. Must remain open source. Converts from Modder to Contributor license if author goes inactive for x months (defined as commits on publicly accessible codebase or updates on a forum / mod repo) Spoiler: Personal License / Agreement Note: this is really more of "how do we treat code not covered by the contributor or modder terms" than something we expect to see in a header for code we have no control over. In other words: the "default" state code is born in while not covered explicitly by contributor/modder terms. License type: Personal Code lives: Anywhere other than under MovingBlocks on GitHub Tag line: "Yours to keep, but no official support/inclusion" Typical person: Author who doesn't want to release source code or refuses the idea of inactive code reverting to community ownership Hosted anywhere at the choice of the author either open source or closed source Does not allow us to fork to MB org or adapt the code Does not allow monetization on Steamworks or similar digital distributions where there is an official connection to the community (clarification: This is to discourage fragmentation and encourage everybody to accept some official support and provide some back - and may be a completely invalid notion depending on how something like Steamworks actually works - you may be able to submit stuff regardless) Does not include official support for module manager, players can add private repo managers (with disclaimer presented by game) Does not convert license style after any period, author is in full control Reserves all remaining rights for author (make money elsewhere or not, can others fork or not, actual license choice, etc) Spoiler: Transitions License/terms can transition back and forward under certain conditions and actions taken by users will determine which of the three states their content falls under. Somebody starts a new content module in their own repo on GitHub. By nature that'll default to the "Personal" license terms If they want the module included in the official module repository they commit a specific message to a LICENSE file of some sort and let us know to fork the repo to MovingBlocks. This puts the content under the "Modder" license terms. If the author wants to go all in they can choose to transfer the root repo on GitHub to MovingBlocks (again likely with a specific commit message to authorize). This will put the content under the "Contributor" license terms. If "Modder" content sits inactive for a period of time (no new commits on GitHub, no forum posts by author, etc) we'll be authorized to swap the license terms for the forked repo from Modder to Contributor, if we want it. If a user wants to move permissions to a more restrictive setup I'm sure we can support that too (like deleting a forked repo or transferring out a repo back to a user) Would work well on a diagram I suspect. Users can also start at the Modder or Contributor terms. Gooey will be enhanced to allow us to create/fork repos via commands on IRC and will also recite the terms in short for the author's approval before doing said creation/forking. I'm not quite sure how exactly this would match with mainstream license types. Offering the option for "personal" style licensees to even keep their code closed source (if they so choose) seems to demand substantial flexibility so most certainly a hybrid license setup. Spout uses LGPL --> MIT after 6 months of inactivity. Maybe this would do something similar in three steps, but I really don't know the licenses themselves plus what we are able to customize well enough yet to know. Either way I'm posting this for initial feedback to see if this is looking reasonable, thinking we can figure out the license verbiage next. When we're happy with it this would be one of the big items involved in the restructuring. Since pretty much every file would be touched (if for nothing else a move from src --> engine/src) that would be the perfect time to also update the license header in every single file to the updated license details + correct (year) copyright to MovingBlocks. I'm not really overly worried about authorizing the license change if we get consensus with currently active contributors. I know we have some older inactive contributors, a few I even have "do anything you like with my code" disclaimers for, I'm going on the assumption we can sort that out and not be encumbered. Also, this all covers both code and non-code, although I realize they might need different licenses (like Apache vs. Creative Commons) I'm also trying to keep the setup fairly simple. Earlier designs included more categories or "addons" you could opt in and out of. But I figure something that's consistent and practically automatic based purely on author actions and commit notes would be ideal.