There is in other areas of copyright law, like romhacks and action replay codes. Romhacks seem like a very grey area but generally don't get DMCAed when they distribute large binary patch files of the original roms. And "Lewis Galoob Toys, Inc. v. Nintendo of America, Inc." would imply that the dead simple 16 byte[0] "patch files" in the form of game genie codes are legal.
To take a more practical example. Is there no meaningful difference between the dwm multimon patch files[1] and the full forked repo[2]? For context, lots of suckless software keeps extra features/addons in semi-offical out of tree patches files. The philosophy of suckless is generally to hardcode config options in source code and recompile instead of editing .rc files. This reduces the complexity of the code, so you end up with some very minimalistic easy to patch recompile and code. So it's a natural (if very esoteric) way of implementing plugins.
Obviously this is a bit contrived because all the suckless code is actually open source, so none of this matters to them. But I think it's fair to say that distributing the 7 .patch files at [1] wouldn't count as distributing a forked version of dwm. The patch files contain some context lines ripped straight from the main codebase, but not the main repo. Hell I'd even wonder if there's some kind of fair use argument for patch files. After all, often they boil down to a criticism of the codebase, saying that it's bad because it contains all the lines of code starting with '-' signs and really would be better if it had these extra lines of code after the '+' signs.
The license doesn't seem contradictory to me. Counter-intuitive, unclear, and paradoxical (in the most general sense of the word), yes. But not contradictory.
Before the ambiguity of language can get in the way, there has to be a coherent idea that you want to express in the first place.
This license explicitly contradicts itself. It says you are encouraged to contribute changes to the source, and you may not share changes to the source with anyone ever.
It seems like the intent is to encourage giving changes to exclusively the maintainer, and that forking in this context refers to distribution beyond a private communication between the change proposer and the maintainer.
Which, this being a git repo, makes perfect sense, as despite the impression GitHub gave to a whole generation of developers, Git was designed with a different contribution workflow in mind: one of sending patches by e-mail. Cloning the repo locally, making changes, formatting a patch, and sending it to the maintainer, seems to be perfectly withing bounds of both intent and text of the license.
Not really. Legalese is vague on purpose because not every situation can be rigidly defined.
As for English, because of its plain nature, I have little trouble understanding someone who isn't proficient or who has a heavy accent, whereas languages with specific infections or tones might not have that kind of liberty.
> No Forking: You may not create, maintain, or distribute a forked version of the software.
There is no meaningful difference between the words "patch" and "fork"; and the act of creating an edited codebase is explicitly disallowed.
If that isn't what they want, then they had better write more clearly.