ORPHANWARE The short answer, with the caveats attached
Most owners asking this question are not planning to publish anything. They want to keep a program they paid for running after the vendor disappeared, fix a bug nobody else will fix, or move data out of a format nobody else reads. That purpose, maintaining your own system, sits on the strongest ground in the law. United States courts have long recognized reverse engineering for interoperability as fair use, and the statutes carve out space for repair, maintenance, and security research. The problems start when the purpose changes: copying a program to sell it, stripping its copy protection to give it away, or using what you learn to build a competing copy of someone else's product. Purpose is the first question any lawyer will ask, so it should be the first question you ask yourself.
Three things decide most cases, and none of them is a feeling about fairness. First, what do you actually own or hold a license for. Second, what do your license and contract say about reverse engineering, backup copies, and transfer. Third, whether any technological protection measure stands in the way, and whether an exemption covers getting past it. Work through those three in order before commissioning any recovery.
What the law actually protects
Copyright protects the expression of a program: the source code as written, and by extension the compiled form. It does not protect ideas, procedures, or methods of operation. That distinction is why reverse engineering exists as a lawful activity at all. Studying how a program behaves, what file formats it reads and writes, and how its parts communicate is studying function, and function is not what copyright locks up. What copyright does lock up is copying the expression and distributing it. A recovery that rebuilds your own program from your own binary, for your own continued use, and keeps the result in your hands, is a very different act from a recovery that hands a copy to the public.
Trade secret law adds a second boundary. If you learn something genuinely secret by lawful means, such as by examining a program you legitimately possess, that is generally lawful. If you learn it by breaking a confidence, such as by misusing access someone trusted you with, it is not. The method of learning matters as much as what is learned.
Your license and contract come first
Statutes set the floor. Your license and contract set the ceiling. Many commercial licenses contain a clause that forbids reverse engineering outright, and many contain clauses about backup copies, transfer to new hardware, and what happens on vendor insolvency. Read the actual documents before anything else, including the order form, the end user license agreement, and any maintenance agreement. Look specifically for terms covering maintenance by third parties, transfer to replacement hardware, and the vendor's obligations on insolvency or discontinuation.
Two cautions here. First, a clause forbidding reverse engineering is not automatically the end of the story: courts have sometimes treated such clauses as unenforceable where they conflict with statutory rights, and the outcome depends on the jurisdiction and the exact wording. Second, the reverse is also true: a license that expressly permits backup and maintenance work is a strong green light, and it should be filed with the project records. Either way, the contract is evidence, not decoration. If it is ambiguous, that ambiguity is itself the reason to get a lawyer's reading before spending money on recovery.
The DMCA and its exemptions
The Digital Millennium Copyright Act, section 1201, makes it unlawful to circumvent a technological measure that controls access to a copyrighted work, with a set of exemptions. The exemptions are the part owners usually miss, because they are renewed and adjusted every three years by the Librarian of Congress. Exemptions have covered, in various cycles, repair and maintenance of software-controlled devices, security research, and interoperability work. The exemptions are specific: they name the class of work, the purpose, and sometimes the kind of user. They do not grant a general right to strip copy protection from anything for any reason.
The practical rule for an owner is simple. If the program you need to recover is protected only by ordinary compiled code, with no access control or license enforcement mechanism to circumvent, the DMCA question is usually small. If getting at the program means defeating a dongle, a license server check, an encryption wrapper, or a similar access control, the exemption question becomes central, and it needs a specific answer for your facts. That answer comes from the current exemption list and, where the facts are close, from a lawyer.
When the vendor has dissolved: the licensing question
A dissolved vendor raises a question owners ask in exactly these words: if the company is gone, do I still have to follow the license? The short version is that dissolution does not automatically erase license terms. A license is a contract, and a company's assets, including its intellectual property, usually pass to someone in a wind-down: a successor, a creditor, or an estate. Your rights under the license generally survive the vendor's disappearance, because the license was granted to you, but the obligations in it can survive too, including any limits on copying and transfer.
What dissolution does change is enforcement and permission. There may be nobody left to ask for consent, nobody to renew a maintenance agreement with, and nobody to object to continued use. That practical reality does not convert a licensed copy into an owned one, and it does not create a right to distribute the program. It does mean that continued internal use, maintenance, and backup of a system you paid for is, in most situations, the lowest-risk course available, and it is the course most businesses in this position actually take. Document your reasoning: keep the license, the purchase record, and a note of the vendor's status with the project file. If a successor ever appears, that file is your evidence.
What we will not touch
At Orphanware Recovery, Josiah Wilson directs every engagement and signs off on every result, and the decompilation, reconstruction, and testing pipeline is carried out by AI agents under his direction. Our rule is strict and simple: we only work on binaries the client owns or has the right to reverse engineer, and we take no work involving malware, cracks, keygens, or DRM circumvention. If the ownership or the right is unclear, we say so before any work starts, and the client gets that answer for the price of a conversation, not a recovery bill. A recovery engagement begins with a record of what the client owns and what they are entitled to do with it, and that record stays with the project.
What to document before you start
Whatever you decide, create the paper trail before the work begins, not after:
- The license and the purchase record. The agreement, the order, the invoice, and any maintenance contract. If the vendor is gone, note the date and the source of that fact.
- The chain of custody. Where the binary came from, who held it, and how it reached the people doing the work. This is the same discipline as the source hunt in our vendor guide.
- The purpose, in writing. Continued internal operation, repair, interoperability, or migration of your own data. One sentence, filed with the project.
- The scope boundary. What will be recovered, who will hold the result, and what will not be distributed. A recovery for internal use should stay internal.
- The exemption check, where one applies. If any access control is involved, note which exemption you are relying on and its current wording.
When to get a lawyer
Get a lawyer before commissioning recovery work when any of these is true: the license expressly forbids reverse engineering and you are relying on a statutory right to override it; the program is protected by an access control you would need to defeat; a successor company, creditor, or estate claims the vendor's rights; or the recovered source would be shared outside your organization. A short review of a license and a purpose statement is inexpensive compared with a recovery, and it converts an assumption into a documented decision. The $45 Recon Report is the cheap fact-finding step for the technical question, whether recovery is realistic. The legal question deserves its own cheap fact-finding step, and that step is a lawyer reading your documents.
The fear that stops most owners is not a real legal barrier. It is the absence of a plain-language answer. Decompiling your own software to keep your own business running is, in general, a lawful maintenance decision, and it becomes safer the better it is documented. Read the license, note the purpose, respect the boundaries, and get counsel where the facts are close. Then the recovery question is a technical one again, and that is the question we answer.