Lyon, a Tuesday in October. Oscar closes his laptop a little too sharply.
“We pay a fortune every year for this scheduling software. My apprentice showed me a video last night. He says that with an AI agent he can rebuild it for us in two weeks. Free, in-house, no subscription.”
Oscar runs operations at a 180-person manufacturing company. He has never written a line of code. He spent his evening on GitHub, on YouTube and on LinkedIn threads announcing the end of the software industry.
“So, do we do it?”
I answered with questions. What exactly do you want to copy? What did you sign with the vendor? And who will maintain your clone two years from now?
He smiled. He was hoping for a yes or a no. I was handing him a diagnosis.
What happened in October 2026
Two stories circulated the same week, and many commentators merged them into one.
The first is about a developer, Brandon Thomas. In early October he launched ArtCraft, a collection of free applications that recreate Photoshop, Premiere and a good part of Adobe’s creative suite (Mac4Ever). A few days later he released WordCraft, GridCraft and DeckCraft, three open-source programs that reproduce Word, Excel and PowerPoint, open .docx, .xlsx and .pptx files, and require neither an account nor a subscription (Mac4Ever). Installers arrived less than a week after the first commit, for macOS, Windows, Linux and BSD. According to Mac4Ever, the code is written in Rust, with no Microsoft code reused, and much of it was generated by Claude Opus 5.5, Anthropic’s model (Mac4Ever). The applications work fully offline (NewsBytes).
The developer was aiming for parity with Office in one month. He now talks about several months to reach 99% compatibility (Mac4Ever). Keep that slippage in mind; I will come back to it.
The second story is a GitHub repository called REA, short for Reverse Engineer Anything. The project went from about 40 stars on October 2 to more than 270,000 on October 15. It is a free add-on that connects coding assistants such as Claude Code or Codex to decompilation tools such as Ghidra (YouTube). Its code is released under the MIT licence (brisk.vision).
Two methods everyone confuses
Rebuilding software can follow two very different paths, and the law treats them differently.
The first path is observation. You use the software, read its documentation, study the files it produces, then write your own program that behaves the same way. Engineers call this a reimplementation. The Office case looks like this path: new code, in another language, aiming for compatibility with file formats.
The second path is opening the box. You take the compiled program, machine code that humans cannot read, and translate it back into roughly readable code. This is decompilation. REA automates this path. The repository describes three phases: decompile, understand, then recreate the feature in your own project. Every finding comes with its evidence, a confidence level and its limitations. Lucija Tomšić, who analysed the repository, sums up this logic by separating what is seen, what is inferred and what remains unknown (brisk.vision).
The underlying tools are nothing new. Ghidra was released by the NSA in 2019, Hopper dates from around 2011 and IDA from the 1990s (brisk.vision). REA is a connector. It turns a specialist’s job into a request you can make in one sentence, and that explains how fast it spread.
Be wary of viral demos. The claim that an Adobe product line was cloned with REA is disputed: people who looked into it say those clones were built from public descriptions and videos (brisk.vision). Erwan, who devoted a video to REA, goes further: in his view, the Adobe clones have nothing to do with the tool (YouTube).
Why does this distinction matter so much? Because your legal exposure changes completely depending on the path you choose.
What European law says
In Europe, the reference text is Directive 2009/24/EC on the legal protection of computer programs.
Its Article 6 allows decompilation without the rightholder’s consent in one specific case: when reproducing and translating the code is indispensable to obtain the information needed for the interoperability of an independently created program. The same article forbids using this exception in a way that would unreasonably prejudice the rightholder or conflict with the normal exploitation of the program (legislation.gov.uk).
In plain terms: decompiling software so that your own tool can exchange data with it falls inside the frame. Decompiling software to sell a competing copy falls outside it.
Case law adds a key piece. In 2012, in SAS Institute v World Programming, the Court of Justice of the European Union held that a program’s functionality, its programming language and the format of its data files are not a form of expression protected by copyright (Inner Temple Library). World Programming never had access to SAS’s source code, and the Court examined a reproduction based solely on observing how the program worked. The British judge Richard Arnold nevertheless found that World Programming’s manual infringed the copyright in the SAS manual, because it reproduced a substantial part of its wording (Wikipedia).
Remember the boundary: imitating what software does is largely free; reproducing how it is written or documented is not.
One last point many executives ignore. In the European Union, a licence clause that contradicts the decompilation exception for interoperability is null and void, under Article 8 of the same directive (IP-PorTal). A licence can, however, govern everything else, and most vendor contracts do so carefully.
And across the Atlantic?
In the United States, the reference case is Google v Oracle. On April 5, 2021, the Supreme Court ruled, six votes to two, that Google’s reuse of about 11,500 lines of declaring code from the Java SE API for Android was fair use. Those lines were about 0.4% of the total API code. The Court did not decide whether that code was copyrightable: it assumed so for the sake of argument (Jones Day).
Two factors worked in Google’s favour. The copying was limited to what let programmers reuse their skills in a new environment, and the Android platform was not a market substitute for Java SE (Mondaq).
For Oscar, the consequence needs no lawyer to read. Copying an interface to enable interoperability can be defended. Copying an entire application to replace it in the same market carries a very different risk.
What my book already said about copying
I distinguish three ways to protect an invention: the patent, copyright and the trade secret. Software as such falls mainly under the last two. I also recall a reality lawyers know and executives forget: a granted patent does not stop anyone from copying you; it only gives you better means to defend yourself in court, provided you have the budget (My book, chapter 3).
I tell the story of a former executive at a very large Dutch group. His company applied a strategy nicknamed “proudly stolen elsewhere.” Before each borrowing, a risk analysis checked whether the game was worth the candle and whether the patent could be worked around.
When you need an invention someone else owns, you have three options: ask for a licence, work around the protection with another method, or copy deliberately. I advise against the third, while noting that it is widely practised (My book).
AI does not change these options. It changes their cost. Working around a protection used to take a team and months. Today an agent reads, compares and rewrites in a few hours. The risk calculation that Dutch group used to make, every small company now has to make, and quickly.
If your code can be copied, where is your advantage?
Switch seats and take the vendor’s. If a feature can be observed, described and rewritten by an agent in an afternoon, your code stops being a moat. It becomes an expense.
The Office case is instructive. LibreOffice has been doing this job since 2010, and Microsoft still sells its subscriptions. When Brandon Thomas is asked why he does not put his energy into LibreOffice, he does not really answer (Mac4Ever). What protects Microsoft cannot be cloned in a week: integration with email and storage, the trust of IT departments, support, and that last percent of compatibility that crashes the financial controller’s macro the night before the board meeting.
The slide from one month to several months will look familiar to any head of R&D. The first 80% of a feature comes fast. The last 20% costs everything else.
For a vendor, the conclusion is uncomfortable. Your unfair advantage has to live somewhere other than in lines of code: in your data, your customer relationships, your speed of iteration, your brand. I develop this difference between a moat and an unfair advantage in my book (My book).
A five-step method before you clone
If you are in Oscar’s position, here is how I would proceed.
- Name precisely what you want to reproduce. A feature, a file format, a behaviour? Or the code, the graphical interface, the name and the icon? The former are largely free to imitate. The latter expose you to copyright and trademark law.
- Reread the licence you accepted. Note what it forbids, and have a lawyer check which of those prohibitions can actually be enforced against you in your country.
- Prefer observation to decompilation. A specification written from visible behaviour, then development by a team that has never seen the original code, leaves a defensible trail. Engineers call it clean-room development.
- If you decompile, limit yourself to interoperability and document why it was indispensable.
- Test on a single feature, measuring before and after. How long to reach parity? Who fixes the bugs? What does maintenance cost over two years? Assumptions are dangerous: kill them with experimentation before they kill your budget.
Back with Oscar
Three weeks later, Oscar called me back.
“We ran your test. The apprentice rebuilt the scheduling screen in four days. It works. But the exports to our ERP, per-user permissions and change history are missing. For the rest, he estimates six months.”
He paused.
“On the other hand, we called the vendor with the demo in hand. They cut their price by 30%.”
That may be the most profitable use of these tools today: knowing you can leave. Erwan ends his video in the same spirit, advising people to talk first and to use REA only if there is a problem (YouTube).
The essentials
Remember four things:
- Reimplementing observed behaviour and decompiling a program are two distinct approaches, governed by two legal regimes.
- In Europe, a program’s functionality, language and file formats fall outside copyright. Code and documentation remain covered.
- Unauthorised decompilation is limited to interoperability. Building a substitute competitor falls outside that frame.
- AI is collapsing the cost of copying. Your advantage therefore has to sit in what an agent cannot rewrite.
I am not a lawyer, and every case deserves a lawyer’s opinion. The first reflex stays the same, though: know what you are copying before you ask an AI to do it. Innovate or agonize, the choice is up to you!
References
- (My book) https://philippeboulanger.com/book/
- (Mac4Ever) https://www.mac4ever.com/divers/198540-word-excel-et-powerpoint-recrees-gratuitement-avec-claude-par-un-seul-developpeur
- (NewsBytes) https://www.newsbytesapp.com/news/science/artcraft-developer-brandon-thomas-releases-free-open-source-wordcraft-gridcraft-deckcraft/tldr
- (brisk.vision) https://lucijatomsic.substack.com/p/rea-reverse-engineer-anything-github-explained
- (YouTube) https://youtu.be/lczZBPO6ITk
- (legislation.gov.uk) https://www.legislation.gov.uk/eudr/2009/24/article/6
- (IP-PorTal) https://www.ippt.eu/legal-texts/software-directive
- (Inner Temple Library) https://innertemplelibrary.com/2012/05/sas-institute-inc-v-world-programming-ltd-wlr-daily
- (Wikipedia) https://en.wikipedia.org/wiki/SAS_Institute_Inc_v_World_Programming_Ltd
- (Jones Day) https://jonesday.com/fr/insights/2021/04/supreme-court-google-wins-copyright-battle
- (Mondaq) https://mondaq.com/unitedstates/copyright/1056046/supreme-court-holds-that-googles-use-of-oracles-java-api-is-fair-use
