I have considered such a license, but rejected that avenue after a while. It turns out that eventually you run afoul of the OSD’s letter (less so the spirit, at least as some would interpret that).
Part of the issue lies in a similar direction as Perens and his Post-Open proposal, in that it invariably exceeds copyright law, and so licensing terms, and instead becomes a contract. What I strongly dislike about the Post-Open proposal is less that, and more the specifics of the contract template he proposes (TL;DR). Also, contracts violate #7 of the OSD.
In terms of OSD violation, any obligation immediately violates #5 - or at least that can be argued. If one makes participation contingent on giving back, it’s a clear violation. If one defines giving back as “according to their ability”, which is the approach I am taking, it’s a lot better in this regard.
But a particularly aggressive reading of #5 could convince one party that giving back is possible and the other that it is not, and have them argue over whether this point is violated. You can avoid this via a contract (which in turn violates #7).
So first, implementing this in an OSD compatible fashion is not possible. Implementing it in a different way would look very much more like the Post-Open construct, except I’d favour more of a framework with configurable parts similar to CC licensing.
One specific concern is that #6 turns out not to serve humanity as well as it should. Not restricting fields of endeavour per se is IMHO the right approach for a framework, but for an individual agreement, it is not.
Take the following kind of scenario, which we have seen play out:
- A creates an innocuous piece of software
- B uses that software to violate the rights of C. Legally, this may be possible because B’s legislation permits such violations, even if C’s does not.
- For simplicity’s sake, assume A and C share legislation or have compatible legal backgrounds.
- You now have a situation in which C must receive protection, and A would have to give it, but because of B’s outside-of-the-local-legislation status, neither has recourse to addressing the issue.
My suspicion is that #6 exists primarily to keep licenses simple. But if we have to move from licenses to contracts anyway, then a) a framework with optional elements is the best form of reducing complexity, and b) this kind of consideration is no longer central.
This path has led me down to precisely what I started out with, that rather than focus on licenses first, or maybe the OSD as it stands first, we should likely revisit the foundational ideals first. An adjustment of the OSD should likely happen in parallel to an effort to create such a contractual framework, for much the same reasons you raise. But if you finish one before the other, chances are they’re not going to match as well as one would like.