My original suggestion actually modified OSD 2 directly, which to your point is likely the better approach, but I don’t like lists as there will invariably be things you leave off them (which is one of my concerns about the current proposal — a point @giacomo and I discussed at length).
Really the Open Source Definition should be generic enough to cover all use cases, but specific enough to be meaningful. For example, by using source instead of source code we can pick up data as well as code, but what about hardware (which was raised this week in another conversation)?
The devil’s in the details, but those details belong in the licenses, which could cover code, data, hardware, etc. as required. This would not expand the scope of Open Source in terms of what is expected (i.e., the preferredactual form a programmerpractitioner would require to use, study, modify, and share a system), but it would expand its applicability into adjacent fields.
We do need to keep in mind what is nice to have (i.e., a refactored document) and what is actually achievable (i.e., a bugfixed document), and the OSI being off on its own crusade to water down the meaning of Open Source for AI with the OSAID, we can’t rely on them to drive consensus until that definition is repealed and the board replaced. I’m convinced that will happen now Debian/FSF/SFC/etc. have rejected it, but there is still the danger that they will succeed in making Open Source meaningless, and that they will run interference on any attempts to modernise the definition without their blessing. That is to say, for now at least I think we need to confine ourselves to changes that are a no-brainer for anyone (including their own membership) to accept and support. I’m not sure if that means we need 2 WIPs, one for fixes, and one refactored, but I think we at least need to focus on minimalist fixes until this self-induced storm passes.