The definition is well-accepted; the interpretation of the definition in difficult (and perhaps intentionally-difficult) cases is not. That seems perfectly reas

The definition is well-accepted; the interpretation of the definition in difficult (and perhaps intentionally-difficult) cases is not. That seems perfectly reasonable and pretty common. The existence of cyan doesn't mean the definition of blue isn't well-accepted. And in any case, I'm not making my decision based on the OSI approving it. I'm making my decision based on my personal consideration that the DFSG expresses principles that are important to me, and the OSD is basically the same thing. (The DFSG, however, does clarify that certain licenses are "a compromise," which seems to have been dropped in the OSD, and I think it's perfectly valid for a definition to have this level of nuance.) I'm making my decision based on my personal belief that "innovating" on these principles isn't great, and the market is the exact opposite of the entity I want deciding on how free/open source software works. For the record, I do actually see the AGPL as "innovating" against the spirit of the DFSG/OSI, although I don't think there's a strong argument that they're non-compliant with the letter of the OSD/DFSG, and I personally avoid it. There's a practical problem that AGPL code becomes unusable when embedded in contexts that don't admit an obvious way to offer source through network interactions (e.g., you can't incorporate something into OpenSSL). But it is innovating in a different way from the SSPL.