Add forking guide
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.
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 :)
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.
we need some more forking guidelines around here I'm forking sick of it
@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.
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 AGPLin 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 theall commits after X are AGPLroute)
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.
thanks for this doc! if you know about it and if you have time, could you please also add information about setting up GitHub tests? Thanks in advance!
thanks for this doc! if you know about it and if you have time, could you please also add information about setting up GitHub tests? Thanks in advance!
Github's documentation about github actions (what I assume you are talking about) is very good and I would recommend you read that instead. ss14 uses github actions in a very "brute forcey" way and I would recommend you not try and learn from it and instead use github's resources.
I am very happy to learn that somebody found this doc useful dispite it being in wizden review hell for months.
Hi, just in case any wizden maint is reading this. I have not made any changes because I do not want to turn this into a copyright guide. (I had made this decision a while ago but I realized I never actually said that on the PR) I am not a lawyer and I think I disagree with quite a few people within space wizard's in regards to my stances on copyright. If you are interested in merging this without a copyright guide component let me know. If you are not please close this PR.
I personally think the short section about licensing is good enough.