.hg Okay, let's talk about blockcodes!
I have a usecase for blockcodes.
They will be displayed on screens (printed much less commonly if at all) and scanned by phones (or other form factors of computers). They will usually encode ~192 bytes of binary data (but should be fairly scalable, just in case that grows significantly in the future).
I care about:
1. Sparsity (they'll frequently be rendered in one phone and scanned by another, so they should be able to encode those ~192 bytes without becoming too dense)
2. Resilience (an important part of any bitcode)
3. Free standards (everything about the encoding should be public, not behind a paywall or encumbered by a patent)
bonus 4. Ease of decoding by paw (see https://mst3k.interlinked.me/@moonbolt/106860351935131196 )
I don't care about:
* Conformity (the overall system design can be altered to accommodate; implementors will be told they should support whatever encoding I choose; compatibility with other systems is not a requirement)
Suggestions?
.hg Codes I've looked at:
* QR, the one everything uses: disqualified because the standard is an ISO standard which costs 200 CHF to license
* JAB (4-color KMYC mode): good, but the modules are laid out by an RNG, which is kinda aesthetically unpleasing
@moonbolt Wait, what? QR codes are nonfree?
Skimmed the Wikipedia article and it might not be the case anymore? The explanation there is confusing. :/
If one doesn't care about interoperability, why would one need to follow the standard exactly? Besides, there are lots of implementations of that standard with available source code, from which one can learn how the thing actually is supposed to work.
If I understand the Wikipedia article correctly, and if the article itself is correct, it used to be important (because anyone implementing some part of the standard was granted a license to some patent), but that is no longer the case (because the patent expired).
@robryk @timorl .hg It's the principle of the thing. I don't want to use even a free implementation of a free fork of a nonfree standard (assuming such a fork could even legally exist, which seems dubious at best).
Also, in this particular case—machine-readable, self-describing data packets—it seems bad form to have something that looks like a particular symbol type but actually isn't because it follows an incompatible standard. I don't want to do that.
I believe GIF is in the same situation: it used to be patented, with some not-very-clear general licenses, and patents have expired.
I understand the wish not to use things that weren't intended to be publicly usable by their original inventors' company, but do realise that this class of things contains many more things than one might think and that the limited lifetime of patents is designed precisely to allow such usage regardless of those wishes after some time.
@timorl