Software Interoperability and Reverse Engineering Clearance Checklist: A Practical Checklist

Summary. This checklist walks counsel and engineering leads through clearing a software interoperability or reverse-engineering project before work begins and keeping it cleared while it runs. It is organized in phases: scoping the compatibility objective, copyright, contract and terms of service, DMCA anti-circumvention, the Computer Fraud and Abuse Act and state computer crime laws, trade secrets, patents, trademarks and marketing, and execution controls and records. Each item is specific and tied to the governing statute, rule, or leading case, with practical notes on what to look for. Red-flag boxes mark the facts that should stop a project until counsel resolves them. A deadlines and timing table, a short worked example involving a health-technology company building a connector to a hospital records system, and a list of common failure points close the checklist.

How to use this checklist

Interoperability projects fail on facts that were fixed before anyone thought to call a lawyer: the license an engineer clicked through, the account that was terminated but kept being used, the new hire who brought a notebook from her old job. This checklist is designed to be run before the first packet capture or disassembly session, then revisited at each milestone and whenever the plan changes.

Work through the phases in order. Copyright comes first because it frames what may be copied, but in practice the contract, DMCA, computer-access, trade secret, and patent phases are where most projects encounter real risk. Each phase is independent: clearing copyright does not clear a contract claim, and a clean room does not clear a patent.

Mark each item done, not applicable (with a reason), or open. Keep the completed checklist with counsel's clearance memo. If the project is large enough to need team separation, the step-by-step method is in Running a Clean Room Software Development Project: A Practical Guide, and the forms are in Clean Room Toolkit: Protocols, Team Certifications, and Specification Records. The doctrine behind each phase is explained in Copyright in Software Interfaces After Google v. Oracle: APIs, Compatibility, and Reverse Engineering.

Phase 1: Scope the project

• Write the compatibility objective in one sentence. Name the target product and version, the product you are building, and what must interoperate (data exchange, file compatibility, API compatibility, device communication). Note: everything later is measured against this sentence; projects with vague objectives over-copy.
• List the interface elements the product must match. Function names and signatures, command languages, message formats, file formats, error codes, constants, timing. For each, state why compatibility requires it.
• List what the product does not need. Implementing code, documentation prose, internal names, user-interface layouts, internal algorithms. Note: this list is as important as the first; it is the record that you copied only what compatibility required, which carried significant weight in Google LLC v. Oracle America, Inc., 593 U.S. 1 (2021).
• Identify every information source (published specifications, documentation, observation, black-box testing, traffic capture, file analysis, disassembly, server access) and rank them from least to most legally exposed.
• Identify where each team member works. Note: European Union law (Articles 5(3), 6, and 8 of the Software Directive, 2009/24/EC) permits observation and, under conditions, decompilation for interoperability, and voids contrary contract terms. United States law generally enforces those terms. Get local advice for non-United States teams.
• Decide whether team separation (a clean room) is needed, based on who has had access to the target's code or confidential information and whether disassembly is planned.

Phase 2: Copyright

• Identify the target's copyrights. Software, documentation, sample code, and any SDK. Check registration status; registration is a prerequisite to suit on United States works, 17 U.S.C. § 411, and timing affects statutory damages and fees, 17 U.S.C. § 412.
• Classify each element on the Phase 1 list as likely unprotected (idea, procedure, system, method of operation under 17 U.S.C. § 102(b); facts; elements dictated by compatibility or efficiency), contested (API declarations and their organization), or protected (implementing code, documentation prose). Note: the First Circuit treats command hierarchies as methods of operation, Lotus Development Corp. v. Borland International, Inc., 49 F.3d 807 (1st Cir. 1995); most circuits filter compatibility-driven elements under Computer Associates International, Inc. v. Altai, Inc., 982 F.2d 693 (2d Cir. 1992).
• Identify the governing circuit for a likely suit (your location, the owner's, where customers are) and note its interface precedents. Note: a case that includes patent claims goes to the Federal Circuit on appeal, which held Java declarations copyrightable in Oracle America, Inc. v. Google Inc., 750 F.3d 1339 (Fed. Cir. 2014), before the Supreme Court decided the case on fair use.
• Run a fair use analysis for contested elements under 17 U.S.C. § 107, applying Google (nature of declaring code, reimplementation on a new platform, copying limited to what programmers need, market effect) and Andy Warhol Foundation for the Visual Arts, Inc. v. Goldsmith, 598 U.S. 508 (2023) (substitution in the same market for the same purpose). Note: a compatible product sold to the owner's own customers is the hardest case; build the record of added features and user lock-in. See Conducting a Fair Use Analysis: A Practical Guide.
• If disassembly or decompilation is planned, confirm the reverse-engineering fair use conditions: a lawfully obtained copy; no practical alternative way to reach the unprotected information; a legitimate purpose; intermediate copies only; and a final product with no copied code. Sega Enterprises Ltd. v. Accolade, Inc., 977 F.2d 1510 (9th Cir. 1992); Sony Computer Entertainment, Inc. v. Connectix Corp., 203 F.3d 596 (9th Cir. 2000).
• Confirm how the copy was obtained. Note: the reverse engineer in Atari Games Corp. v. Nintendo of America Inc., 975 F.2d 832 (Fed. Cir. 1992) lost its fair use defense because it obtained source code from the Copyright Office by misrepresentation.
• Assess section 117. If the company owns its copy, 17 U.S.C. § 117 permits copies that are an essential step in using the program and archival copies. Note: licensees often are not "owners," Vernor v. Autodesk, Inc., 621 F.3d 1102 (9th Cir. 2010); compare Krause v. Titleserv, Inc., 402 F.3d 119 (2d Cir. 2005).
• Check for open-source components in the target. If the target ships open-source code, its license governs copying that code; a team that reads it is exposed to it. See Open Source Software Compliance Checklist: A Practical Checklist.
• Check the derivative-work theory. Note: the Ninth Circuit rejected the idea that software is a derivative work merely because it interoperates with the target, Oracle International Corp. v. Rimini Street, Inc., 123 F.4th 986 (9th Cir. 2024); the product must not incorporate protected expression.
• Plan to write all documentation independently. Manuals and API references are ordinary literary works.

Red flag: copyright. Anyone on the project has the target's source code, from any source. Someone proposes to "translate" the target's code into another language. The plan includes copying documentation text or code samples. Stop and get counsel's review.

Phase 3: Contract and terms of service

• Collect every agreement touching the target: end-user licenses, SDK and developer program terms, API terms of service, trial and academic licenses, partner agreements, NDAs, and customer contracts that grant access.
• Identify who accepted each one, on behalf of which entity, and when. Include individual engineers' personal acceptances and acceptances at prior employers.
• Read each for: reverse-engineering, decompilation, and disassembly bans; "no competing" or "no functionally equivalent product" clauses; benchmarking bans; confidentiality; use limits; audit rights; choice of law and forum; survival after termination.
• Assume a reverse-engineering ban is enforceable in the United States. Bowers v. Baystate Technologies, Inc., 320 F.3d 1317 (Fed. Cir. 2003); Davidson & Associates v. Jung, 422 F.3d 630 (8th Cir. 2005); ProCD, Inc. v. Zeidenberg, 86 F.3d 1447 (7th Cir. 1996). Note: preemption arguments under 17 U.S.C. § 301 rarely succeed against negotiated or clickwrap terms; Vault Corp. v. Quaid Software Ltd., 847 F.2d 255 (5th Cir. 1988) preempted a state statute, not a contract.
• Test formation for any terms the company did not expressly accept. Note: browsewrap terms without reasonable notice and assent may not bind, Nguyen v. Barnes & Noble Inc., 763 F.3d 1171 (9th Cir. 2014). See Website Terms of Service and Online Contract Formation: Clickwrap, Browsewrap, and Enforceable Arbitration.
• Decide for each restricted copy or account: do not use it; quarantine everyone who used it under the restriction from any implementation role; or negotiate a license that permits the work.
• For customer-provided access, get the customer's written confirmation that its license permits the activity, signed by someone with authority. Note: using a customer's license beyond its scope can expose the customer and invite an inducement claim against you.
• Review your own customer contracts for representations that your product does not infringe or breach third-party rights, and for indemnities that would be triggered.
• For used or secondhand copies, check whether the license purports to bind subsequent holders and whether a transfer was permitted.

Red flag: contract. The only available copy is under a license that bans reverse engineering. A team member accepted the target's license at a prior employer and used it for the same kind of work. An account was suspended or terminated and someone wants to "use another one." Stop.

Phase 4: DMCA anti-circumvention

• Identify every technological measure between the team and the information: encryption, authentication handshakes, license keys, signed or encrypted firmware, obfuscation, secure boot.
• Determine whether each measure "effectively controls access" to a copyrighted work within 17 U.S.C. § 1201(a)(3). Note: a measure that leaves the work freely readable may not qualify, Lexmark International, Inc. v. Static Control Components, Inc., 387 F.3d 522 (6th Cir. 2004).
• If circumvention is planned, confirm the section 1201(f) conditions in writing: lawful right to use the copy; sole purpose of identifying and analyzing elements necessary for interoperability of an independently created program; elements not previously readily available; no infringement. Note: the exemption failed in Davidson because the resulting server facilitated play of unauthorized copies.
• Check the current triennial exemptions at 37 C.F.R. § 201.40 (for example, good-faith security research and certain repair and diagnosis categories). Record the exemption, its conditions, and its expiration date.
• Assess the circuit's nexus rule. The Federal Circuit requires a connection between circumvention and infringement, Chamberlain Group, Inc. v. Skylink Technologies, Inc., 381 F.3d 1178 (Fed. Cir. 2004); the Ninth Circuit does not, MDY Industries, LLC v. Blizzard Entertainment, Inc., 629 F.3d 928 (9th Cir. 2010).
• Check trafficking exposure if the product itself, or a tool the project distributes, circumvents a measure (sections 1201(a)(2) and (b)). Civil remedies, including statutory damages, are in 17 U.S.C. § 1203; willful commercial violations are criminal under 17 U.S.C. § 1204.
• Do not remove or alter copyright management information in materials the team handles, 17 U.S.C. § 1202.

See The DMCA Anti-Circumvention Provisions: Section 1201, Digital Locks, and the Triennial Exemptions.

Red flag: DMCA. The plan requires extracting keys, bypassing signature checks, or defeating authentication, and no one has written down which exemption applies. The product will ship with a circumvention capability. Stop.

Phase 5: Computer Fraud and Abuse Act and state computer crime laws

• Identify every server, cloud service, or account the project will touch. Note: reverse engineering a network service usually means sending requests to someone else's computer.
• Confirm authorization for each. Under Van Buren v. United States, 593 U.S. 374 (2021), liability under 18 U.S.C. § 1030 turns on entering parts of a system that are off limits, not on purpose. Public pages are generally not "without authorization," hiQ Labs, Inc. v. LinkedIn Corp., 31 F.4th 1180 (9th Cir. 2022).
• Stop on revocation. A cease-and-desist letter or account termination followed by continued access can be unauthorized, Facebook, Inc. v. Power Ventures, Inc., 844 F.3d 1058 (9th Cir. 2016). Write a rule: on any revocation, all access stops and counsel is notified.
• Prohibit credential sharing, borrowed accounts, IP rotation to evade blocks, and fake identities.
• Check state computer crime statutes, which may be broader than the CFAA (for example, Cal. Penal Code § 502).
• Rate-limit testing against third-party systems, and avoid tests that could degrade service.

For scraping and network-access issues in depth, see Data Scraping After hiQ v. LinkedIn: Copyright, Contract, and Computer Fraud Claims.

Red flag: computer access. Testing requires credentials the company was not issued, or continued access after a block or warning. Stop.

Phase 6: Trade secrets

• Confirm that reverse engineering is of a lawfully obtained product or lawfully observed behavior. Reverse engineering and independent derivation are not improper means, 18 U.S.C. § 1839(6)(B); Kewanee Oil Co. v. Bicron Corp., 416 U.S. 470 (1974); Bonito Boats, Inc. v. Thunder Craft Boats, Inc., 489 U.S. 141 (1989).
• Check for acquisition that could be improper even without a break-in. Note: courts have found improper means in conduct that was not otherwise unlawful, such as aerial photography of a plant under construction, E.I. duPont deNemours & Co. v. Christopher, 431 F.2d 1012 (5th Cir. 1970), and automated scraping of a database at a scale no ordinary user could reach, Compulife Software Inc. v. Newman, 959 F.3d 1288 (11th Cir. 2020).
• Identify every current or former employee, contractor, and partner of the target on your payroll or in your vendor list. Confirm each returned the target's materials, and wall each off from the technical work.
• Screen incoming documents. Prohibit use of anything marked confidential by the target, partner-only documentation, and "leaked" material from forums or repositories.
• Review NDAs and partner agreements the company signed with the target; confidential information received under them may not be used for the project.
• Consider the target's remedies: injunctions and damages under 18 U.S.C. § 1836, and state trade secret law, which is not preempted by copyright to the extent it requires a breach of confidence, see Data General Corp. v. Grumman Systems Support Corp., 36 F.3d 1147 (1st Cir. 1994).

See Trade Secret Misappropriation Litigation Under the Defend Trade Secrets Act: A Practical Guide and, for AI tools as a leakage channel, Generative AI Trade Secret Protection Checklist: A Practical Checklist.

Red flag: trade secrets. A recent hire from the target is the person who "knows how it works." Someone has partner-only documentation. Stop.

Phase 7: Patents

• Run a freedom-to-operate search directed at the functionality the element list requires (protocols, codecs, compression, synchronization, data structures). Note: reverse engineering and independent development are not defenses to infringement under 35 U.S.C. § 271.
• For each relevant patent, get a written analysis of non-infringement, invalidity (including eligibility under Alice Corp. v. CLS Bank International, 573 U.S. 208 (2014)), or design-around. Note: enhanced damages for egregious infringement are available under 35 U.S.C. § 284 as interpreted in Halo Electronics, Inc. v. Pulse Electronics, Inc., 579 U.S. 93 (2016); a reasoned opinion is relevant to willfulness.
• Check standards and specification licenses for patent commitments that cover compliant implementations, and their conditions (field of use, reciprocity, defensive termination).
• Check exhaustion where the product works with hardware customers bought; an authorized sale exhausts patent rights in the item sold, Impression Products, Inc. v. Lexmark International, Inc., 581 U.S. 360 (2017).
• Record design-around decisions in engineering records.

Red flag: patents. The compatibility requirement maps onto a claim of an issued patent and there is no analysis. Stop.

Phase 8: Trademarks and marketing

• Use the target's marks only to describe compatibility ("works with," "compatible with"), in plain text, without logos or styling, and without implying endorsement. Note: nominative fair use, New Kids on the Block v. News America Publishing, Inc., 971 F.2d 302 (9th Cir. 1992); Toyota Motor Sales, U.S.A., Inc. v. Tabari, 610 F.3d 1171 (9th Cir. 2010).
• Avoid false statements about compatibility or affiliation, which can support claims under 15 U.S.C. § 1125(a).
• Review marketing for statements that undercut the fair use position ("a drop-in replacement so customers never have to pay [Owner] again"). Note: after Warhol, substitution rhetoric is evidence.

Phase 9: Execution controls and records

• Write counsel's clearance memo summarizing each phase, the sources approved, and the conditions. Keep it privileged and separate from process records.
• If a clean room is used, adopt the protocol, certify the teams, and set up the gatekeeper channel before investigation starts.
• Adopt an AI tools rule (approved enterprise tools, logging, code-reference filters, no target code or documentation in prompts, separate workspaces).
• Keep lab notebooks that tie each fact in the specification to a cleared source.
• Preserve records and be ready to issue a litigation hold; loss of electronically stored information can draw sanctions under Fed. R. Civ. P. 37(e).
• Design privilege deliberately. Expect to produce process records if you rely on them; protect counsel's analysis; obtain a Fed. R. Evid. 502(d) order in any litigation.
• Re-run this checklist at each milestone, on any new information source, on any new hire, and on any new target version.

Deadlines and timing

Worked example: Lumen Health and the Marrow connector

Lumen Health builds care-coordination software for clinics. Its customers use the Marrow electronic health records system and want Lumen to read appointment and referral data from Marrow automatically. Marrow offers a partner SDK, but its terms prohibit reverse engineering and "any product that competes with Marrow functionality." Marrow also exposes a standards-based interface for some data, documented publicly.

Phase 1. Lumen writes its objective: "Lumen will read appointment and referral records from a clinic's Marrow installation, with the clinic's authorization, so that Lumen can schedule follow-ups." The element list includes the standards-based endpoints Marrow documents publicly, two proprietary referral fields not covered by the standard, and Marrow's export file format for referrals.

Phase 2. The standards-based interface raises no copyright issue; Lumen implements it from the public standard. The export file format is functional, and Lumen can learn it from files clinics export themselves. No disassembly is needed.

Phase 3. Lumen's chief technology officer accepted the partner SDK terms two years earlier during a trial. Counsel concludes Lumen is bound and that the SDK copy and the CTO's notes from that trial are off limits; the CTO will not design the connector. Lumen's customer agreement with each clinic gains a clause confirming that the clinic authorizes Lumen to access its own Marrow data and that the clinic's Marrow license permits it. Two clinics' counsel confirm in writing.

Phase 4. Marrow's export files are not encrypted. The proprietary referral fields are available through an authenticated interface the clinic controls, using the clinic's own credentials, issued for this purpose by the clinic's administrator. Counsel concludes there is no circumvention.

Phase 5. Lumen accesses only clinic-controlled endpoints with clinic-issued credentials. The protocol requires stopping immediately if Marrow or a clinic revokes access.

Phase 6. A Lumen engineer previously worked at Marrow's implementation partner. She is walled off from the connector work, and her onboarding confirmation is retrieved from HR.

Phase 7. A patent search identifies a Marrow patent on a referral-routing method. Lumen's connector only reads data; it does not route referrals. Counsel documents non-infringement.

Phase 8. Marketing describes the feature as "works with Marrow" without logos, and the sales deck's line "replace Marrow's referral module" is removed.

Phase 9. The clearance memo, clinic confirmations, wall acknowledgment, and patent memo go into the project file. No clean room is needed for copyright, but the wall around the former partner engineer and the CTO's exclusion serve the same evidentiary purpose for trade secrets and contract.

Common failure points

• Clearing copyright and stopping. The contract, DMCA, computer-access, trade secret, and patent phases are independent and often more important.
• Missing personal and prior acceptances. The license an engineer accepted at home or at a former employer is the most frequently overlooked fact.
• Treating the former employee as an asset for the technical work. Use her expertise for customer integration, not for learning the target.
• Ignoring revocation. Continued access after a warning converts a defensible project into a computer-access case.
• No patent search. A perfect clean room does not answer an infringement claim.
• Marketing that reads as substitution. It undercuts fair use and invites Lanham Act claims.
• Leaving the checklist on the shelf. New target versions, new hires, and new information sources all require a fresh pass.

This document is general information, not legal advice for any particular situation; the law changes, and the facts matter.

Related Documents

Related Articles

• Copyright in Software Interfaces After Google v. Oracle: APIs, Compatibility, and Reverse Engineering: the doctrine behind each phase of this checklist.
• The DMCA Anti-Circumvention Provisions: Section 1201, Digital Locks, and the Triennial Exemptions: the Phase 4 rules in detail.
• Data Scraping After hiQ v. LinkedIn: Copyright, Contract, and Computer Fraud Claims: computer-access and contract issues for network interfaces.
• Paid Vulnerability Disclosure and the Line Between Research and Extortion: when reverse engineering turns up security flaws.
• Failed Software Implementations: Contract, Fraud, and Warranty Claims When an IT Project Goes Wrong: failed technology projects and the contract, warranty, and fraud claims that follow.

Related Guides

• Running a Clean Room Software Development Project: A Practical Guide: the step-by-step method when clearance calls for team separation.
• Conducting a Fair Use Analysis: A Practical Guide: the Phase 2 fair use analysis.
• Trade Secret Misappropriation Litigation Under the Defend Trade Secrets Act: A Practical Guide: the Phase 6 claims if they are brought.
• Pursuing or Defending a Failed Technology Project Claim: A Practical Guide: failed technology projects and the contract, warranty, and fraud claims that follow.

Related Checklists

• Open Source Software Compliance Checklist: A Practical Checklist: obligations when the target ships open-source code.
• Generative AI Trade Secret Protection Checklist: A Practical Checklist: AI tools as a leakage and contamination channel.
• Software License Agreement Review Checklist: A Practical Checklist: reading the target's license terms in Phase 3.
• Patent Eligibility Checklist: A Practical Checklist: eligibility challenges to patents found in Phase 7.
• Troubled Technology Project Checklist: A Practical Checklist: failed technology projects and the contract, warranty, and fraud claims that follow.

Related Toolkits

• Clean Room Toolkit: Protocols, Team Certifications, and Specification Records: the forms for execution controls and records.
• Vulnerability Disclosure Toolkit: VDP Policies, Safe Harbor Terms, Researcher Agreements, and Response Letters: safe harbor terms that can authorize testing.
• Software and Open Source Licensing Toolkit: From IP Layers to Compliance Programs: license terms that govern interfaces.
• Technology Project Dispute Toolkit: Notice of Breach Letters, Cure Plans, and Project Record Protocols: failed technology projects and the contract, warranty, and fraud claims that follow.