If I were inclined to twist the copyright tiger's tail, the way I would do it would be to encrypt the plaintext with a one-time pad and them publish the cyphertext and the pad anonymously in two different locations (preferably on two different domains). The key and the ciphertext in a one-time-pad are mathematically indistinguishable, so both publishing parties have plausible deniability that what they published was the key, i.e. just a string of random bits, which if course they have every right to do.
An even more interesting experiment would be to copyright the resulting key and the ciphertext, and put in the TOS for getting either one that you will not sue the publisher for any copyright violations.
> Treating Colour as a function is almost the same as attaching tags to the bits - the difference is that when the Colour is a function of the bits, we don't have to worry about the tags being detached; on the other hand, when the Colour is a function of the bits, we can never have more than one possible Colour for a given sequence of bits. Monolith depends on exploiting this problem: it assumes that one file can only ever have one Colour, asserts that the Colour of its output file is the "you may copy this" Colour because of the (correct) claim that fixing any other single unchangeable Colour would raise legal problems, and then follows the logic to a claim that it can produce what would otherwise be an illegal copy of the copyrighted input, without breaking copyright law. One Colour per file was never one of the lawyers' rules of Colour; it's merely a consequence of "Colour is a function", and Colour being a function is just something we computer people decided to believe because functions make sense to our training and Colour doesn't. Colour is not actually a function at all.
[1] https://en.wikipedia.org/wiki/Bloom_filter