You wouldn’t download a creative suite.
There’s been a fascinating story brewing in software development which has exploded into my social timelines in the last few days. A creative suite called ArtCraft has been making headlines in software circles as it is an open source, lightweight version of more expensive commercial software, particularly the Adobe creative suite which includes programs like Photoshop.
The noise has been prompted by how this suite came into being. A software developer named Brandon Thomas reportedly used Claude Opus 5.5 to help recreate seven of Adobe’s creative applications on Rust. Both on the website and on Github, the ArtCraft apps are described as clean-room reimplementations, this means that they were built using public specifications and observations of how Adobe’s software works, without copying its proprietary code or assets. For example, the image tool called PhotoCraft uses Adobe’s published specification for the PSD file format. But lots of things are still unclear, we don’t yet know exactly how much of the code was generated by Claude, or how much was directed and guided by Thomas. We also do not know whether the claimed clean-room process stands up to scrutiny.
You may be wondering why should anyone care about the release of an open source software product. What has caught everyone’s attention is the manner and speed in which this was released. Claude Opus 5.5 was released on September 22, just over two weeks ago. If this reimplementation was done in that time, it proves some amazing capabilities, but also opens the question as to which other software tools are next. We may be entering an unprecedented age in software development.
Opening software
The ArtCraft case is just the latest and most visible example of a trend that has been building for the last few months, particularly due to the constant improvement of LLMs in software development. The age of vibe coding has brought an amazing array of capabilities that seemed farfetched in the past. Developers have been using AI to take software apart and put it back together, and the results are increasingly impressive.
One thing that users have been managing is to patch existing software, usually by altering its compiled code to change how it behaves. Patches can be entirely benign, such as fixing a bug in abandoned software, or translating a game that was never released in your language. I’ve seen social media posts of people who have patched old printers, or modified games to run in other platforms, or to create new emulators.
Other users have been using AI tools to remove technological protection measures, or to jailbreak devices. Jailbreaking is the removal of technical restrictions a manufacturer has placed on a device, this is typically done to allow the installation and/or running of software that is not approved, or being capable of running unlicensed versions of software. The term is often associated with iPhones and games consoles, but it now applies to anything with a locked-down operating system. As “everything is computer” now, this includes things such as tractors, cars, and printers.
One AI software capability is emulators, this is software that imitates the hardware of another system, so that programs written for that system can run elsewhere. This is usually done with old software that may be abandoned or no longer supported. The classic example is running old console games on a PC. A well-built emulator does not need the original system’s code; it needs to behave like the original hardware. For example, I got an agent to help me install an emulator on my laptop so that I can play an old DOS game.
Then there is reverse-engineering and decompilation. Reverse engineering is an umbrella term which refers to the study of a program to understand how it works. This can be “black box”, where you observe inputs and outputs without looking inside, or “white box”, where you examine the code itself. Reverse engineering is widespread in the industry, it allows all sorts of legitimate uses such as creating compatibility between systems.
Decompilation is a specific form of reverse engineering. Programs are written in human-readable source code and then compiled into machine-readable code, which the computer can then execute. The act of decompilation attempts to run that process backwards, in other words, you are trying to reconstruct something that resembles source code from the binary files that are released and distributed by the original developer. The result is never an exact replica of the original because many elements are missing, such as comments, variables, and the structure of the program. What remains is a functional approximation of the software which is not likely to share any of the code with the original. Decompilation has been very difficult to achieve in the past, sometimes taking months and even years to achieve. This is why the use of AI to considerably reduces the effort and time that goes into reverse engineering and decompilation is important. LLMs can read code and infer what a function is trying to do, and then translate and rewrite the code into another programming language.
But don’t take it from me. I asked Claude Opus 5.5 what are its capabilities when it comes to software, and this is what it answered:
“I can’t verify how Artcraft was built, so I can only speak in general terms. I’m reasonably good at reading disassembled or decompiled output, explaining what a function does, suggesting meaningful names and rewriting the logic in another language such as Rust. I’m also good at working from documentation, such as a published file format specification, and producing an implementation that conforms to it. I’m considerably less reliable with large, heavily optimised, stripped or deliberately obfuscated binaries. There I can make confident-sounding mistakes, and anything I produce needs to be tested against the original. Two caveats seem relevant. First, I can’t always tell whether code I write resembles code I encountered during training, so I’m no guarantee of a “clean” output. Second, much of the speed people attribute to me depends on a human who decides the architecture, tests the behaviour and knows what to build. I’m a powerful accelerant, not an autonomous replacement for that judgement.”
This helps to explain the current capabilities of very good models such as Claude 5.5. But we can also assume that in the future the models will continue to improve, so perhaps larger binaries will become capable of decompilation in this manner.
Legal issues
It is evident that the above describes scenarios that raise a lot of legal questions, and I wouldn’t be surprised if we see some litigation at some point. I don’t want to go into too much detail at this point because there are many things that we don’t know, so this is mostly a broad analysis of the state of the law, normal caveats apply.
The first aspect of note is that the ArtCraft developers claims to have made a clean-room reimplementation of the Adobe suits. The clean-room has a long history in the software industry, its most famous use came in the early 80s when developers needed to produce IBM-compatible BIOS firmware without infringing IBM’s copyright. The method involves two separate teams; the first one examines the original product and writes a functional specification describing what it does, without including any of its code; the second one writes new code from that specification alone without having been exposed to the original code.
A common misconception is that a clean-room is required by copyright law, but this isn’t entirely accurate, it’s mostly about evidence. Computer code itself is protected under copyright as a literary work, but the idea is that a program could be a derivative of another even without copying the actual code if the new code is derived from the original. This means that copyright infringement requires copying of the code itself, and in the absence of that, copying could be inferred if the coders had access to the code. So the clean-room breaks the evidence chain, allowing the developer of the new program to argue that the code was developed independently.
Software companies usually had different ways to deal with clean-room implementations. One is the reality that clean-room was still expensive and required a lot of work, so it was not always worthwhile. The second was the use of clauses forbidding decompilation and reverse engineering in end user licence agreements. In the US, Bowers v Baystate allows for these clauses, while in the EU and the UK the picture is less clear, particularly from cases such as SAS v WPL. However, anti-compilation clauses do not map exactly to clean-rooms, as it doesn’t involve decompilation in the strict sense.
We don’t know how clean the ArtCraft clean-room actually was, so I will not try to guess. The reality is that this could fall on the details of of how separate were the teams. With AI, this could mean separate agents acting independently, but there would be an issue if the clean-room is just the same developer that observes Adobe’s software, writes the specifications, and then prompts the model to write the code. I’m still not sure if this one-person clean-room using different agents would mean that there is more likely to be infringement rather than not. It may all rest on the details.
There are other ways in which companies could try to stop the AI decompilation apocalypse though, this includes trademarks, anti-circumvention legislation (section 1201 of the DMCA), more restrictive clauses, patents, designs, and even GUI-specific copyright (see THJ v Sheridan in the UK). In the US, you have a long line of attempts to protect the so-called “look and feel” of a program. In Lotus v Borland, the First Circuit held that Lotus 1-2-3’s menu command hierarchy was an unprotectable method of operation, a decision the US Supreme Court left standing. In Apple v Microsoft, Apple’s attempt to protect the overall appearance of its graphical interface largely failed, with most elements found to be either licensed or unprotectable ideas. More recently, in Google v Oracle, SCOTUS found that Google’s implementation of the Java API was fair use. US courts have also been relatively friendly to reverse engineering for compatibility, see Sega v Accolade and Sony v Connectix.
Not knowing any details, I would be willing to say very tentatively that ArtCraft may be on the right side of the law in the US, where litigation is more likely to occur first. This is assuming that ArtCraft used a clean-room technique that replicates Photoshop’s functionality and workflow without copying its code, icons or other graphical assets. The weaker points are elsewhere: licence terms, patents, and trademarks. On the last point, some of the product names are suggestive enough that one suspects a trade mark lawyer is quietly making notes.
Concluding
It is too early to tell what will happen here. I would be surprised if software developers such as Adobe allow this development to go unchallenged. My initial impression is that for the most part copyright as it stands tends to allow decompilation and reverse engineering of existing software, specially if clean-room development was used. But I cannot help but feel that the courts may start looking more closely at protection of visual elements. But we can expect more litigation testing whether AI-assisted clean rooms are as clean as advertised.
But regardless of what happens to ArtCraft specifically, we will definitely see more code being decompiled and reverse engineered using AI. The models are just going to improve, so we’re in uncharted territory and the scale of the problem is likely to be huge. But I suspect that software development will never be the same. Heck, it already is not, but things may accelerate.
On the meantime, I’ll be playing with the agents to jailbreak a few devices. I’m looking at you, printer, I laugh in the face of your proprietary ink requirements.
0 Comments