Well, sure: but if the company doesn't want to release the source code at a future date, they just... don't do it. That's sort of a separate problem. If you a

Well, sure: but if the company doesn't want to release the source code at a future date, they just... don't do it. That's sort of a separate problem. If you assume the company (or the developers, whatever) actually want to reveal the code, but just don't want to give it away to their competitors today, it seems like it would work. One situation that seems relatively common is developers who are working on a commercial product who might want to see it open-sourced down the road. The developers (not the company) could prepare the source code on the company's hardware (i.e. where they normally do development), timelock-encrypt it, and then take it home with them or publish it somewhere. They would then have the assurance—since they actually prepared and encrypted the source code snapshot—of what's inside. Average Joe Coder might not have the pull to get their company to agree to such a scheme, but I can imagine some very high-profile people might. E.g. if you're a recognized expert in your field (think John Carmack or someone of his stature in whatever niche you want), maybe you put a requirement for timelocked access to the code you write as a must-have in your consulting contracts. Then you would still be able to get work with private companies, but have some assurance that your work would be publishable and benefit the public down the road. I'm sure you could probably even rig up some Git hook that timelock-encrypts every commit and pushes it to a public repo somewhere (Internet Archive, maybe?) that's expected to be available for a good long while.