Project licensing and contributor options

[Cervator]

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.

 

[Immortius]

I'm not sure I can agree with this, in its current state anyway.

On my part, it is important to me that the core engine (at least the code elements) remains open source and available for use both non-commercially and commercially. This is partially because I would like to retain the ability to make use of my submissions in future projects. I also don't mind if part of all of my work is used for a commercial product by others.

Other than that... I do understand the desire to prevent commercial lifting of the project as a whole. I would suggest that this be done through the licenses applied to the core asset and gameplay modules though. Without those any forker will need to develop their own assets and game logic, at which point they've actually made their own game so all power to them.

 

[Cervator]

That's fine by me - the above was intended more for content/modules than the engine itself. I should've pointed that out, even had that in my notes. I blame posting it past 2 am

Alternatively engine stuff could be free for unencumbered use by any official contributor, but not total strangers. I don't know if that is likely to be worth it, kinda doubt it.

I'm mainly throwing ideas out there to have something to start with and tweak to fit the community consensus. Not wanting to push it as-is on anybody

So maybe everything in the "Terasology" repo (which will have no actual content after the restructure) follows a 4th license setup? "Engine License" or what not, likely in some LGPL flavor? Edit: Actually, I guess Apache 2.0 would be fine there, if we're OK with a derivative work changing the license / going closed source (I think that's how it would work)

Libraries are kinda outside this too (TeraBullet, Jitter, etc)

 

[begla]

I'm also okay with using my/our code in commercial projects - as long as license in place is applied in the appropriate way. Assets are another topic... Thinking of Id Software who release their engine source from time to time without providing the assets. I like that.

But what really gives me the creeps are people who fork the game, change some of the textures, replace all headers and licenses and call it their game. We had that in the past. But that's far from what any license could restrict without further ado.

So keeping the Apache 2.0 license for the core is fine by me... I actually had my reasons when I picked the Apache 2.0 license in the first place.

 

[Immortius]

I'm also okay with using my/our code in commercial projects - as long as license in place is applied in the appropriate way. Assets are another topic... Thinking of Id Software who release their engine source from time to time without providing the assets. I like that.

But what really gives me the creeps are people who fork the game, change some of the textures, replace all headers and licenses and call it their game. We had that in the past. But that's far from what any license could restrict without further ado.

So keeping the Apache 2.0 license for the core is fine by me... I actually had my reasons when I picked the Apache 2.0 license in the first place.

I absolutely agree with begla here. One of the reasons I decided to start contributing to Terasology was because it used a reasonably permissive license.

And yeah, people who fork the game and try to pretend it is theirs are breaking the license. Then it becomes an enforcement issue, which is a problem regardless of license used.

 

[Immortius]

In response to further prompting by Cervator:

My only other comment is that any contribution that ends up in a Terasology or MovingBlocks repo must either be owned by the contributor, or the contributor must have permission to use. And we will need to make sure to track what can be used commercially and what cannot.

 

[Cervator]

Immortius - thanks

Added an "Engine" section and some minor tweaks here and there. I know there'll be space for more tweaking. Particularly I'm curious how the three different "content" tiers sound and if that's a valid way of dealing with different setups.

As I envision it there'll actually only be one "content license" (module) header we put in the LICENSE file (along with the separate engine license) and put at the top of all the (non-engine) files we touch (and have IntelliJ auto-insert / instruct contributors to add everywhere). Said content license will have three sections and location/commit conditions will determine which one is active:

• Contributor if the root repo is hosted under https://github.com/Terasology (and a commit message confirms the source as either having started there (Gooey auto-creates the repo) or an outside contributor provided authorization to move there)
• Modder if the root repo is hosted on GitHub, forked to https://github.com/Terasology, and likewise sourced with permission
• Private in any other situation

I really don't know if that is a valid tactic and it seems like it mighthave pitfalls? Here's a scenario:

1. User A creates new repo MyHappyModule on GitHub. At this point the "Private" terms reign by default (unless the user licenses it some other way, but in that case we wouldn't interact with that code by principle)
2. User B forks repo MyHappyModule on GitHub
3. User A accepts the "Modder" terms by submitting a commit authorizing us to fork the repo to https://github.com/Terasology/MyHappyModule (which we then do)
4. User B's fork ... ???

I'm thinking the authorizing commit can serve as a sort of checkpoint. If user B's fork pulls updates from user A and includes that commit then the terms change even for the fork. Alternative is to not pull updates if unwilling to accept the change in conditions. User B could still manually copy paste stuff from upstream but would then potentially be in violation of the terms (in particular if proceeding to monetize the module separately from the community - without explicit authorization by the original author who can relicense his own contributions). Thoughts?

What I'm looking for is making the terms "self maintaining" that way. We wouldn't need to keep some sort of central control over what is what (although we could generate some info automatically) - the idea of having to keep track of exactly what files can be used in a hypothetical monetized module on Steam via big Google Docs or something seems frightening

Couple more scenarios - examples can be useful!

1. User A creates a repo "ITotallyWillWorkOnThisForver" - private terms apply by default
2. User A accepts modder terms in a commit and we fork to https://github.com/Terasology/ITotallyWillWorkOnThisForver
3. User A later goes inactive (3-6 months without commits)
4. As per modder license inactivity terms we submit a commit to https://github.com/Terasology/ITotallyWillWorkOnThisForver invoking the inactivity clause and claiming it under the Contributor terms instead (as we really like the functionality and want to community-support it - hello RP2)
5. If User A does eventually come back the code can be "forked" back to the modder terms (with a git commit marking the point)

1. User A asks Gooey to create "IReallyWantToShareThis" under https://github.com/Terasology/IReallyWantToShareThis - "Contributor" terms apply
2. User A later decides he actually really didn't want to share it and wants to monetize it solo. Remains the only contributor to the module so he retains full rights (would otherwise have to get permissions from other contributors)
3. User A submits a commit with a request to transfer the repo to his personal account
4. We process the request and transfer the repo out. If wanted we could in theory still use the content as-is as per the original conditions - to do that we could fork the repo back or create a new one but cannot pull updates from User A's copy (I don't know if this makes sense, can a user revoke our rights to use content said user agreed to terms for? Would we ever want to keep such content?)
5. User A makes new changes and sells the module outside the community - users are able to pick if they want the old free module (that is likely to go out of date) or go with User A's version.

 

[Immortius]

Some further thoughts...

On the core module, this is likely going to need some work. I'm inclined to move stuff that has to be around into engine, and move a lot more out of engine into modules, and then remove the forcing of the core module to be active. This probably means we should look at getting all the good morning craft content out of engine and into its own module, possible as overrides of engine content. This also implies improvements to the override system too. We may still want the core module to be engine licensed, depending on what ends up in there.

You're going to have to really nail down the details of the contributor monetization, modder monetization and community pool.

I think "Private" is probably a bad name for the non-affiliated mods. And I wouldn't even bother having defined private terms, since they are outside of out system it is up to the developer to work that out. They can have whatever license they want as long as it doesn't impinge on Terasology's license - this include open source licenses if they wish. The implications for making use of those modules are thus outside of our control as well.

This sort of implies that contributor modules cannot depend on modder or private modules, and modder modules cannot depend on private modules.

One thing with most licenses is that they don't go away for existing stuff if you choose to switch for future stuff. So if a "Private" module owner chooses to switch from LGPL to being a Modder or Contributor module, then their existing code will remain licensed as LGPL as well, so User B can continue to work off of that, or switch to working off the new version with the new license.

I'm a little unsure of mechanics of the inactivity clause...I think that sort of thing sounds like it needs careful treatment. Particularly because however it is set up needs to reflect the good faith in which we intend it to be perceived - it could easily be seen as a "don't work on something for a little bit and we take it for ourselves" clause if framed wrong. If something works it might not need to be updated frequently either, so not sure commits time make sense. Keep in mind that the way things are framed modders can monetize their work and contributors cannot (ignoring the community pool which is somewhat vague).

I'm also thinking that private modules should not necessarily be excluded from steamworks or similar, as long as they accept the fee on their sales (which I think is mandatory in steamworks anyway)?

 

[mkalb]

https://github.com/blog/1530-choosing-an-open-source-license

 

[Cervator]

Yeah just saw that GitHub license thing. Good timing

Wish you could add your own organization-wide license templates, but then I figure we can do that with scripting.

"Private" I couldn't think of a good name for at the time. Maybe "Personal" ? Or "Default". Either way yes it isn't so much for the actual modules as for our conditions for interactions (can we fork it and use it for stuff or not, etc). It might be more work than it is worth, especially if something like monetization on Steamworks is mandated exactly by Valve without us having any say (or needing to do anything). Which I kinda hope is the case.

The idea I was trying to work (which may not at all work or be something we want to do, but was just to get some sort of draft to play with) as far as monetization goes was something like outlined below. Again using Steam as a hypothetical example - I don't know how their terms work but figure Steam takes 30% and it is an option for the base game publisher to take a small set cut as well for stuff done through Steamworks (like 5%?) - but dunno. Most the stuff through Steamworks / Steam Workshop is free addon content, but I believe authors can enable monetization, just don't know how it works.

• Engine licensed content can (likely together with some minimal content that's either engine licensed or contributor licensed):
  • Be sold by us in an "official" release on various platforms like Steam for a token fee purely to support the community (is simultaneously available for free, but possibly not with something like Steam integration enabled). Money goes to the general fund short the Steam take (30%)
  • Be sold by others in whatever ways (as per Apache 2.0) but not as the "official" Terasology which would include at least a base amount of content / assets we provide
• Contributor licensed content can:
  • Be sold in an "official" content package (think Steam DLC, comparable to a mod package in FTB) by us on Steam. Multiple sources have contributed to this one sale, so the money goes to a general fund, short the Steam take (30%).
  • Be sold individually directly via Steamworks by the author. Steam takes 30%, we take 5%, author gets 65%
  • Be monetized in any other way by the author since it is their stuff (website donations, external module tracker with integrated payments of some sort, etc). Author takes 100%
  • NOT be monetized by anybody other than the original author or the community (unless author authorizes somebody explicitly)
  • Contributors gain a share from the general fund based on their contributions
• Modder licensed content can:
  • NOT be sold in an "official" content package (because we're not authorized to fully support it - author reserves those rights). Possibly multiple
  • Be sold individually directly via Steamworks by the author. Steam takes 30%, we take 5%, author gets 65%
  • Be monetized in any other way by the author since it is their stuff (website donations, external module tracker with integrated payments of some sort, etc). Author takes 100%
  • NOT be monetized by anybody other than the original author or the community (unless author authorizes somebody)
  • Modders do not get a share from the general fund
• Private licensed content (or whatever it is named / however it gets used) can:
  • NOT be sold in an "official" content package (because we're not authorized to support it at all - author reserves those rights)
  • ??? be sold individually directly via Steamworks. If Steam automatically only takes a cut for themselves or automatically takes a cut for themselves + a smaller one for the publisher then that answers that. If we have to somehow be actively involved in the process then I dunno. Last I checked Valve doesn't publish the monetization details publicly and a brief (read: very brief) Google search failed to enlighten me further. Having a hard time sorting this one out without more details.
    • Pushing a bit against this unless the author accepts a fee (which may be automatic anyway) is in big part to encourage community involvement over fragmentation and contributing back to the development of the core game. If we sell the base game on Steam for a token fee then that takes away half this argument.
  • Be monetized in any other way by the author since it is their stuff (website donations, external module tracker with integrated payments of some sort, etc). Author takes 100%
  • Be monetized by anybody else depending entirely on the author's whims, we're out of the picture

The "General" or "Community" fund would in short be our current burgeoning PayPal account (might hold about $100 of donations WOO!). If we do some sort of official monetization that drops money into it we need to eventually develop some process to reward contributors appropriately (after we break even on server hosting etc). I don't know what this process would be (a long time ago I proposed the goofy "TeraCents" thing to somehow help "quantity" contributions) and am reluctant to fully develop it since I don't know if we'll ever need it and don't want to get bogged down with it - I just want to be able to support something like that one day without having to re-change the license/terms globally in the future

Contributor and Modder are very similar (highlighted the only difference). Edit: Added a second (important!) distinction after remembering

This sort of implies that contributor modules cannot depend on modder or private modules, and modder modules cannot depend on private modules

Good observation. I guess so? Not sure what to do here. For MC this seems a very large gray area due to the near total lack of official structure/support from Mojang. Which is what I'm trying to rectify here - fully supporting a healthy modding community encouraging contributors/modders to get closer to the official source rather than skirting the law (well, the MC license details) by hacking together plugins in all kinds of fragmented ways (different MC plugin frameworks provided by the community)

Maybe unless the author expressly forbids it dependencies are OK as long as monetization is not involved. It seems sketchy for a contributor / us to base a premium module on a modder/private-licensed module, at least without getting authorization or having the other author pick an appropriate license. But then I'm trying to keep the license/term options low in quantity - so - dunno. Maybe that can be a git commit-dependent clause somehow. Or maybe a premium contributor module can depend on modder module as per standard terms if said modder gets a cut somehow. But then what prevents us from cloning/wrapping modder content for $$$, which would be bad.

I'm a little unsure of mechanics of the inactivity clause...I think that sort of thing sounds like it needs careful treatment

Absolutely agreed. I was inspired by the clause Spout has in their license - LGPL that reverts to MIT after 3 or 6 months (IIRC). Their justification was avoiding inactive (but useful) code being lost. Maybe we should expressly deny ourselves monetization options (or delay them further yet) on "reclaimed" code. Code that is "finished" wouldn't be reclaimed unless it suddenly needs to be changed - in which case it wouldn't be finished anymore. I'd count author forum posts or activity other than commits too as activity. "Inactive" would mean the author is entirely unreachable (or uninterested).

 

[Cervator]

Bump - renamed "Private" to "Personal" in just the first post and made some other minor tweaks. Still more needed, I'm sure.

 

[Linus]

I've read this thread a couple of times and until now I abstained from replying, because I have no experience with licenses or licensing.
I am now replying because I keep seeing requests for feedback and to at least let you know that I have read it and have and that I didn't see anything I didn't like.

I think the code I am currently working on would fit with the engine license. I'm fine with Terasology using it, as long as I can use it for my portfolio if I wish to do so. In other words, as long as my name is somehow attached to it and someone else cannot claim to have written my work, I am fine with it.

 

[AlbireoX]

I really only work on Gooey (not even that much), so I am fine with this post.

 

[Cervator]

More musings from a decidedly non-expert on licensing / contributor guidelines: If we define a "mode zero" set of basic modules primarily meant as modules, set those fundamental modules to Apache 2.0 in addition to the engine, would that make sense as a core open source product? Here's a fully functional engine and basic content, go nuts!

Light & Shadow would be an outright custom / unique game mode and go under the Contributor terms as detailed above.

With something like that in place all our core repos would be covered by standard OS licenses (Apache 2.0 and misc library licenses) - all that would really remain would be true content. Engine, core module (in whatever shape it ends up in), facades, etc, would all be Apache 2.0, just like now.

Could that then be one of the rare situations where applying the Creative Commons Attribution-NonCommercial-ShareAlike 3.0 Unported License would be appropriate, even for code? I ran across the Thaumic Tinkerer MC mod and noticed it had been licensed as such, despite being code. But I know using CC for code is generally frowned upon. Yet we likely would end up using a CC variant for non-code work like art in content modules anyway. If we piece out all the truly technical stuff and only content remains, even if part of said content is provided by code, might it make sense to just wholesale apply CC to each module fitting that description?

Both Contributor and Modder terms would normally go under that setup, IMHO. Likely there should probably be an option for modders to release work under straight Apache 2.0, which effectively is like Contributor, but leaves commercial rights wide open. Which differs from the private/personal/default/whatever scenario from us being able to use it commercially.

Or, alternatively, is there a non-CC license type similar to the ... CCANCSA3.0UL but specifically for code? That decidedly doesn't roll off the tongue very well

 

[Immortius]

http://wiki.creativecommons.org/FAQ#Can_I_use_a_Creative_Commons_license_for_software.3F

GPL is probably the closest mainstream license to ShareAlike, in terms of forcing the license on people creating derivative works. It isn't non-commercial as such (although it is hard to commercialize open source code in the first place), and I don't think it has a attribution clause.

I'm not aware of an open source license with a non-commercial clause, which is where things get tricky. It is easy to apply such things to art, and probably to apply them to closed-source binaries, but for source code... Don't know.

Then again, the question comes down to what do we expect from contributors and modders. For a project to be a contributor project, what we're talking about is project owner providing us (Moving Blocks) with a specific license for redistribution and derivation. They can have a separate license for other parties - we may require this to be some sort of open source of CC license for code and assets respectively, but it isn't necessarily essential. Similarly for modders (I'm not sure the modder tier is even a thing though, seems identical to personal now).

Honestly, if monetization is going to be a thing we probably need to consult with someone professionally legal (and probably someone professionally financial advisery) to get this right.

 

[Cervator]

Yeah that's probably good advice. While I'd like to start out with an ironclad setup that can support any possibilities we might encounter for years ... yup, not an expert

I did see that FAQ entry and look at CC in the past, but seeing it applied anyway to an MC mod made me wonder. In theory being open source might just be a side-effect on content modules, rather than the point - with an expanded base engine/game that goes Apache 2.0, that's more the important part.