Add forking guidelines

[dffdff2423]

Adds a page outlining forking guidelines and best practices. A large amount of content in this is derived from https://gist.github.com/moonheart08/2d3945faf3cf691437e1e1fa0e922420. I have permission from the author to use their work in this PR. It also incorporates some of my own advice gained from working on Cosmatic Drift.

[Jezithyr]

This looks great so far! But it's missing a section on licensing and attribution. We should at the very least give people a basic idea of what copyright is/does, since not everyone is familiar with it and there are a ton of common misconceptions that can get you into trouble.
I'll write something up and run it by a couple of my industry connections to make sure that it's accurate to how copyright works. Licensing stuff shouldn't be a problem for most forks since they'll likely just going to keep the MIT license but it's still a good idea to make sure people are aware of misconceptions and common pitfalls.

Actually, I might just make a separate doc on copyright/licensing and then just include a brief summary in the forking guidelines. Great work on this :)

[dffdff2423]

I actually ended up writing a short copyright gide. Let me know if you want me to change anything. My goal was to take as neutral of a stance as possible while giving a basic explanation of all of the licenses that I am aware of ss14 forks using. If people don't understand the basics of software copyright I think they should be referred elsewhere given it is such a complex topic and most (all?) of the people who work on ss14 are not experts in it and such should not be writing a guide on copyright.

[Everturning]

we need some more forking guidelines around here I'm forking sick of it

[dffdff2423]

@Jezithyr Could you take another look at this given that it has been a month? I think it would be useful even without the legal stuff as this covers the most common mistakes most forks make.

[deathride58]

Regarding the licensing section: you'd probably want to detail some best practices on how to apply a license to a fork, as the current prominent methods (namely, the act of laying down a all commits after X are AGPL in the readme) are ones that make it trivial to accidentally violate the MIT license through the accidental relicensing of MIT code (the MIT license can only be sublicensed, not relicensed, so any commit containing MIT-licensed code needs to explicitly declare it when using the all commits after X are AGPL route)

A particularly good standard that's increasingly common across the open source dev community as a whole is SPDX IDs (https://spdx.dev/learn/handling-license-info/). These are quite easy to copy-paste across files, and make it incredibly explicit what license a given file is under, which makes lawyers happy due to how cut-and-dry violations become with 'em (and similarly makes hub rule enforcement far easier to investigate). For licenses like the AGPL, use of SPDX IDs should be paired with an explicit declaration somewhere reasonable (like the readme) that the codebase is subject to the terms of the AGPL (just without the all-commits-after-x statement, as that's a legal pitfall)

[deathride58]

It'd be worth being a bit more in-depth about the pros and cons of AGPL compared to the MPL. For instance:

• The AGPL is compatible with CLAs that require forfeiting copyright to the repo owner when contributing (this is a fairly common practice among predatory projects), while the MPL is completely incompatible with that due to the MPL explicitly granting individual contributors the rights to exercise enforcement
• The file-scoped license of the MPL has the additional benefit of making it compatible with every non-viral license, so long as it doesn't conflict with the terms of the MPL. When using the AGPL on the other hand, additional licenses are only compatible if the AGPL explicitly states their added terms to be permitted (see Section 7, Additional Terms). This has particularly huge implications in the context of SS14, as non-commercial licenses (which there's an abundance of) simply aren't permitted by the AGPL. This means that an AGPL codebase would have to do a license audit to replace or remove all existing noncommercial assets in the codebase to be AGPL-compliant. Not doing so can lead to a fork becoming liable to getting either C&D'd or DMCA'd (these won't be from Wizden itself since we're licensees for the most part, but there's nothing stopping contributors, Goonstation, or anyone else behind the noncommercial assets present in SS14 from doing so)
• The AGPL has a rather infamous loophole where you only need to offer a copy of the source code to those you've distributed the program to, which is something that various SS13 servers have exploited in the past to remain closed-source despite the AGPL license. The MPL lacks this loophole, requiring the MPL-licensed source code to be reasonably and publicly available

[dffdff2423]

I don't think we should be turning this into a entire guide on open source copyright licenses. There are plenty of other resources online that are written by actual lawyers. I would rather link some other third-party source. Do you know of any good ones?

[dffdff2423]

Regarding the licensing section: you'd probably want to detail some best practices on how to apply a license to a fork, as the current prominent methods (namely, the act of laying down a all commits after X are AGPL in the readme) are ones that make it trivial to accidentally violate the MIT license through the accidental relicensing of MIT code (the MIT license can only be sublicensed, not relicensed, so any commit containing MIT-licensed code needs to explicitly declare it when using the all commits after X are AGPL route)

Will add something about it, this is probably the most common mistake forks make in terms of licensing.

A particularly good standard that's increasingly common across the open source dev community as a whole is SPDX IDs (https://spdx.dev/learn/handling-license-info/). These are quite easy to copy-paste across files, and make it incredibly explicit what license a given file is under, which makes lawyers happy due to how cut-and-dry violations become with 'em (and similarly makes hub rule enforcement far easier to investigate). For licenses like the AGPL, use of SPDX IDs should be paired with an explicit declaration somewhere reasonable (like the readme) that the codebase is subject to the terms of the AGPL (just without the all-commits-after-x statement, as that's a legal pitfall)

I fully agree with you about the SPDX (I use the reuse spec in most of my new non-ss14 projects). I opted to not link it because wizden does not use SPDX indicators at all and again, I wanted to keep this very limited in scope. However, if you want, I can add something about it.