This is my plan for publishing the Hollow Knight Modding API to GitHub without infringing on copyright.
- Hollow Knight by Team Cherry: http://hollowknight.com/
- Modding API: (Link not available due to copyright infringement. That's the point of this document.)
- Discussion about this problem: MyEyes/RandomizerMod#1
- dnSpy: https://github.com/0xd4d/dnSpy
- Xdelta: https://github.com/jmacd/xdelta
Currently, Hollow Knight modders are editing the binary game file Assembly-CSharp.dll directly with dnSpy, and publishing the modified binary to Google Drive at a secret link that's shared in the #modding channel of the Hollow Knight discord server. This means that you can only be a Modding API developer/contributor if you are invited to the Hollow Knight discord server.
The modding community is already using GitHub for several other mods (examples below). It would be ideal to have the Modding API on GitHub in some form as well.
Examples of mods already on GitHub:
- Blackmoth by Gradow: https://github.com/Ayugradow/blackmoth
- Bonfire by Gradow: https://github.com/Ayugradow/bonfire-mod
- Randomizer by Seanpr & Firzen: https://github.com/MyEyes/RandomizerMod
The most obvious way to put the Modding API on GitHub is to simply publish the modified Assembly-CSharp.dll to GitHub. However, the modified file still contains lots of content from the original Hollow Knight, which is copyrighted and proprietary. Publishing the modified Assembly-CSharp.dll to GitHub is illegal copyright infringement.
It's conceivable that Team Cherry will never enforce copyright claims against such a violation, but it's still a legally risky and frankly impolite way to treat the developers of the game that we love enough to mod.
The part of the modified Assembly-CSharp.dll that is not copyrighted by Team Cherry is the modifications that the modding community makes. This is the Modding API. It is not illegal to publish the modifications, as long as the publication contains no content from the original file.
The Modding API GitHub repository will contain only the modifications to the file, not the original file.
It's possible to allow the community to use Google Drive as they are currently doing, and have a daemon running that polls the Google Drive file for modifications. When a modification is made, the bot makes a git commit with the new modifications, and pushes the commit to GitHub with an auto generated message like "Updates on DATE by PERSON".
And if someone pushes a commit to the GitHub (without updating the Google Drive version), the daemon bot can detect that as well, and make a modified version of the binary file and publish it to Google Drive.
This bot should be open source, but in order to run, it would need a few non-open source pieces of information, like an original Assembly-CSharp.dll file to compare against, and the secret link to the Google Drive file. The daemon's admin will need to provide those as command line parameters when running the bot.
Ideally the diff algorithm will not emit any content from the original file. For naive diff algorithms, this will happen by simply rearranging parts of the file. For two-way patches (such as those generated by diff and git diff), the - lines contain original content.
Generating binary diffs is a hard problem. Xdelta appears to be the best solution we've got. Some cursory experimentation showed that Xdelta recognizes simple reorderings and duplications without emitting the original content in the patch. It does not generate 2-way patches, so deleting content does not emit the original content in the patch.
It's possible that Xdelta emits a significant portion of copyrighted material in a patch, because Xdelta was not designed for copyright purposes but for compression purposes. Even so, this situation seems pretty harmless. First, the content output by Xdelta is gzip deflated, which marginally obfuscates the content. Second, the copyrighted material you would get from such a leak would be pretty useless without the greater binary file anyway. You still need the original file for the patch to be meaningful, so this solution seems acceptable, albeit not perfect. I think it certainly demonstrates to Team Cherry that we respect their intellectual property.
Xdelta is open source (Apache Public License 2.0) and cross platform, so depending on that tool shouldn't be a problem.
This is the whole point of this proposal. It should be possible to get the Modding API from GitHub without any access to the Hollow Knight discord server or to Google Drive. This would be necessary for both developers and users. Users are anyone who wants to play with mods that depend on the Modding API, such as the Randomizer Mod.
There should be instructions for manually patching your Assembly-CSharp.dll file with xdelta from the command line.
Additionally, there should be a wizard (written in C# probably) that locates Assembly-CSharp.dll and your xdelta installation, and runs the command for you.
The most complicated workflow will be when a developer wants to publish their changes to the Modding API to GitHub directly (as opposed to through Google Drive). On the developers local machine, this requires running Xdelta, making a git commit, and pushing to GitHub. This can be assisted via a helper utility, but it's also not prohibitively difficult to do manually.
Additionally, this workflow triggers the GitHub-to-Google-Drive direction of the two-way sync described above. I expect that that is the direction that will be more difficult to implement.
I expect this workflow to be more difficult to implement than the current workflow of publishing to Google Drive, so I don't expect this to be implemented right away.
A much simpler and easier to implement/understand/maintain solution would be to get rid of the file on Google Drive and only support distribution of the Modding API through the "directly from GitHub" usecase above. This is slightly more legally friendly as well.
Publishing updates would then become a little harder, because you'd need to use xdelta and git yourself.