@Tobias: Also worth mentioning that a design goal for @giacomo and I given the politics of the day was to minimise at all costs the additions/modifications to the OSD in order to maximise the chance of acceptance — every word should be “load bearing”. I’m not 100% happy with what we came up with, and it will no doubt need to be lawyered to death in due course, but it’s more meant as a proof of concept.
We could consider a longer/different text in future — I’d prefer OSD 2 be renamed from “Source Code” to “Source” for example and be written more generically to cover both data and code (as a type of data), and the repetitiveness of your proposal doesn’t sit well with me (per DRY).
Changes to the tried-and-tested OSD will be like a constitutional amendment though and subject to a very high bar of community consensus and support. Minimalism is key and we don’t want to break anything or scare the chickens.
Also, we should be using objective terminology like “actual form” rather than the subjective term “preferred form” per my proposal. This should not be necessary but it created a vulnerability they abused for the OSAID to totally redefine what it refers to (e.g. data information aka metadata rather than data).