Release Decision Framework
Seven questions to ask before you open source anything that could be misused.
The core test
"If someone forks this and removes every constraint, what have I given them?"
If the answer is "a surveillance tool", "a tracking system", or "an extraction engine", you need to think carefully about what you release and how.
If someone forks it and removes all safety constraints, do they get a working system?
Why this matters: Most safety-critical software has two layers: the capability layer (what it can do) and the constraint layer (what it must not do). If these layers are separable, a bad actor gets all the capability with none of the constraints.
The safe answer: Your constraints should be load-bearing. Removing them should break the system, not free it.
Could this enable surveillance or tracking without your constraints?
Why this matters: Technology that knows who you are, where you are, what you feel, or what you consent to is inherently dual-use. The same system that protects your identity can track it. The same system that verifies your consent can manufacture it.
The safe answer: If your technology is dual-use, you need protective licensing, not just an open licence.
Can the safety layer be removed without rewriting the system?
Why this matters: If your safety layer is a middleware that can be removed, it will be removed. If your consent checks are function calls that can be commented out, they will be commented out. Tightly coupled constraints survive forking. Loosely coupled constraints do not.
The safe answer: Constraints should be structural, not decorative. If removing safety is easier than rewriting the system, your architecture has failed.
If misused, do you have legal tools to respond?
Why this matters: Code released under MIT or Apache 2.0 cannot be un-released. If someone uses your identity protocol to build a surveillance system, an open licence gives you no recourse. Patents, copyleft, or restrictive clauses provide different levels of control.
The safe answer: Match your licensing to your risk. Low-risk utilities can be MIT. High-risk infrastructure needs stronger protection.
Do unconstrained alternatives already exist?
Why this matters: Sometimes the safest option is to release, because the alternative is that someone else builds the same thing without any safety considerations. But "someone else will build it" is also the most common justification for releasing things that should not be released. Be honest.
The safe answer: If alternatives exist, release your constrained version. If you are creating the category, protect it until the safety norms catch up.
Does your funding allow protective licensing?
Why this matters: Many grants require open source as a condition of support. But when the funded work is safety-critical infrastructure, mandatory open release can conflict with responsible disclosure. If your funder requires you to publish code that you believe is dangerous, you have a conflict.
The safe answer: Negotiate scope before accepting funding. If the funder requires you to release things you believe are dangerous, find a different funder.
Can you release the safety layer separately from the capability layer?
Why this matters: You do not have to release everything or nothing. The safety constraints should be everywhere. But the capability layer, the identity infrastructure, the biometric processing: this is what gets weaponised. Releasing constraints widely while protecting capabilities selectively is not hypocrisy. It is responsible engineering.
The safe answer: Design for partial release from the start. Make your safety layer independently valuable and freely available.
About this framework
The open source community has strong norms around releasing code. It has almost no norms around evaluating whether code should be released in a particular form. This framework fills that gap.
CC BY-SA 4.0, NOEVA Foundation, 2026