Is Reverse Engineering Legal? Inspecting Competitor Software, Licences, Copyright and Contract Limits
Tools like REA make it easier to look inside an application, so the question comes up: is this legal? The answer is “it depends,” and the detail matters. Purpose, licence terms, national law and what you do afterwards decide it. We explain the general framework and the questions to ask.
Important: This article is for general information and is not legal advice. The rules on reverse engineering vary by country, contract and the specific case; consult an intellectual property/IT lawyer before deciding.
In brief: Reverse engineering is not automatically illegal or legal in itself. What decides it: 1) Purpose (security research, interoperability, understanding a legacy system, or copying/bypassing a licence?), 2) The software's owner/your authority (is it your own software, licensed, or a competitor's?), 3) The licence agreement and terms of use (do they prohibit reverse engineering?), 4) National law (copyright, rules against circumventing technical protection measures, trade secrets) and 5) What you do afterwards (are you using an idea you learned, or copying code/assets?). The official statement of tools like REA also says use is for lawful research, education, interoperability, software archiving and software the user owns or is authorised to examine (REA repo).
Last updated: 23 October 2026
Why is this question back in the news?
REA, which connects AI agents to reverse-engineering tools (see what is REA?), drew a lot of attention quickly. As InfoQ reported, some independent game developers worry that AI-assisted reverse engineering could make it easier to copy games, bypass paid features and exploit their work; one expert called the boundary “murky” (InfoQ). The project, for its part, stresses users' responsibility for authorisation and legal compliance.
Four layers of the legal framework
1. Copyright
As a general principle, copyright protects a software's expression (source code, object code, images, text, sound, database structure and other works), not its idea or functionality on their own. For example, the Court of Justice of the European Union has held that a program's functionality, programming language and data file formats are not subject to copyright (SAS Institute / World Programming, 2012). This shows the basic difference between learning how a feature works and copying code or assets. But which behaviours count as copying (such as reproducing compiled code) is assessed by country and case.
Some legal systems have special provisions that allow, under certain conditions, a computer program to be decompiled for interoperability. In the EU this is regulated by the Computer Programs Directive (2009/24/EC) and is subject to conditions. Other countries, including Türkiye, have their own copyright statutes; get expert advice on how they apply.
2. Licence agreement and terms of use
Many software licences (EULAs) and terms of use prohibit reverse engineering, decompilation or extracting the source. How binding these prohibitions are varies by country and contract, but where there is a prohibition, there can be a risk of breach of contract. Reading the licence text is the first step before inspecting any software.
3. Circumventing technical protection measures
Many countries separately regulate or prohibit circumventing technical measures (encryption, licence checks, copy protection) that protect copyright. Bypassing a licence check or using a stolen key can be a separate and serious problem in itself. REA's documentation also states plainly that cracked copies, stolen keys and licence bypassing are not authorised use.
4. Trade secrets, data and privacy
- Trade secrets: If the information you learn during an inspection is a trade secret, how you obtained it and how you use it matters. If you have a contractual confidentiality obligation (e.g. an NDA), you may be prohibited from using that information.
- Personal data: If the application or records you inspect (network traffic, database files) contain personal data, KVKK and similar rules apply; take care over processing, storing and sending it to third-party AI services.
- AI services: According to REA's documentation, the model provider's own data policy applies to tool results returned to the agent. Know which service you send the analysis results of a sensitive binary to. See our AI use policy guide.
The general picture by scenario
| Scenario | General assessment (not legal advice) |
|---|---|
| Understanding and documenting your own software (even if its source code is lost) | Usually the lowest risk; still check third-party component licences and contracts. See our legacy software guide |
| Authorised security testing (with the software owner's permission, scope in writing) | Legitimate and common; permission and scope should be in writing |
| Security research (unauthorised, in good faith) | Can be legally grey; country, licence and method are decisive. Coordinated disclosure (reporting to the vendor) and legal advice are recommended |
| Interoperability (making your product compatible with another system) | Some legal systems allow it under certain conditions; the conditions are narrow and detailed |
| Understanding a competitor's feature and rewriting it in your own code | The idea and function may be free; copying code, images and content is an infringement risk. Check licence prohibitions and trade secrets |
| Taking a competitor's code/assets, bypassing licence checks, producing cracked versions | High legal risk; not authorised use |
| Software archiving, education | Purposes accepted in some legal systems and project rules; still subject to licence and national rules |
A safe approach: 8 practical steps
- Write down the purpose: Why are you inspecting? Security testing, a legacy system, compatibility? Purpose is the basis of the legal assessment.
- Verify authority: Do you own the software, do you have written permission? Avoid unauthorised inspection.
- Read the licence: Are there prohibitions on reverse engineering, decompilation and benchmarking?
- Check your confidentiality obligations: An NDA or employment contract may stop you from using this information.
- Don't copy: After inspection, write your own solution in your own code. On large projects, the “clean-room” method, in which those who inspect and those who write are kept separate, is a practice used to protect against copying claims.
- Don't circumvent technical protections: Bypassing licence checks and encryption can have much heavier consequences.
- Protect data: Don't upload outputs and binaries containing personal data to unmonitored AI services.
- Keep records and consult: Record what you inspected, under what authority and how; work with a lawyer in critical cases.
What can you do as a software owner?
If it is your software being inspected: write reverse engineering and copying clauses clearly into your contracts and terms of use, apply technical measures (our 10-measure guide), offer a clear security reporting channel (a security contact address) and, if you suspect infringement, preserve the evidence and contact your legal adviser. For source code and intellectual property clauses in software development contracts, see our 15-clause checklist.
Safe and lawful development with Aktaş Digital
In our projects we settle source code and intellectual property in the contract phase and recommend that clients turn to their own legal advisers for legal questions. If you'd like to review your software's architecture and protection, you can use our quote form.
Frequently Asked Questions
Can I inspect my competitor's app and build the same thing?
Learning a feature's idea and function is different from copying code, design and content. Copying can create risks of licence and trade secret infringement and of circumventing protections. In every specific case, consult a lawyer.
My company's old software has no source code; can I inspect it?
Understanding your own software is usually the lowest-risk scenario; but it may contain third-party components and licences. Check the contracts and licences.
What if the licence agreement prohibits reverse engineering?
How binding the prohibition is varies by country and contract; breaching it can create contractual liability. First have the text and the applicable law assessed by an expert.
What should I do if I find a security flaw?
The general good practice is to report the flaw to the vendor before disclosing it publicly (coordinated disclosure). Legal risk depends on the country and method; get permission beforehand if you can, or obtain legal advice.
Is using REA legal?
REA is a tool; whether it is legal depends on what you inspect, under what authority and for what purpose. On its own page the project states it is designed only for lawful and authorised use.
Conclusion
Reverse engineering can be a legitimate way of understanding software; but purpose, authority, licence, national law and what you do afterwards set the limit. Keep the line between understanding and copying, don't circumvent technical protections and consult an expert in critical cases. The first thing you can do today: check whether your own products' terms of use contain reverse engineering and copying provisions.
