PhotoCraft: the legal questions an AI-assisted rewrite leaves open

PhotoCraft arrived with a proposition that is easy to understand: an alternative to Adobe Photoshop, written in Rust, developed with AI, and released as open source under MIT or Apache 2.0, at the recipient’s option. It belongs to ArtCraft’s wider family of applications covering familiar Adobe workflows, including illustration, video editing and page layout. The developers describe PhotoCraft as a clean-room reimplementation, built from public specifications and observed behaviour without proprietary code or assets. The ArtCraft team’s PhotoCraft repository, storytold/photocraft documents both the project’s ambitions and its continuing development.

That description invites an obvious question: how can a developer reproduce the capabilities of a commercial product without the original vendor’s permission? Much of the discussion has concentrated on whether Adobe’s code was copied and whether the development process deserves the clean-room label.

Suppose the developers have successfully written their own implementation, using no protected Adobe code. Let us take that as the starting point. A business considering whether to deploy the software still needs to know what follows from it legally. The developers may remain subject to obligations governing how they investigated the original. The resulting software may also perform a patented method or reproduce protected visual elements.

Lawful research, independent implementation, and lawful use and distribution are three different propositions. PhotoCraft provides a useful way to examine them without reaching a verdict on its developers’ conduct.

I. What the clean-room claim establishes

A clean room is a method of producing evidence of independent development. Conventionally, one team studies the original and prepares a functional specification; another writes the replacement without access to the original implementation.

The underlying copyright distinction is between functionality and protected expression. I examined that distinction, and the consequences of cheaper AI-assisted reimplementation, in my earlier article, “Chardet: clean rooms, copyleft and the AI rewrite problem”. That article provides the copyright background. Here, I will leave the debate over independent creation aside and examine the further questions a business needs answered.

There is no universal legal requirement to employ two separate teams. As Andrés Guadamuz’s commentary on ArtCraft observes, the process serves an evidential purpose. Its significance depends on what information reached the implementers and what they produced from it.

Observing a program’s response to an input is different from decompiling it, which attempts to reconstruct readable instructions from its compiled form. The published materials examined for this article do not substantiate the circulating claim that Photoshop was decompiled. They document extensive behavioural testing.

II. Was the research conducted lawfully?

1. Testing a product can raise a contractual question

The ArtCraft team’s PhotoCraft test corpus, storytold/photocraft-corpus describes a collection of documents generated through Photoshop’s scripting interface. Photoshop renders them; PhotoCraft’s rendering can then be compared with the saved results. Other scripts use the same scripting interface to read the data structures Photoshop exposes for text layers. The corpus includes a script called dump-text.jsx for that purpose.

For a simple example, imagine two coloured layers combined using a particular blending operation. The developer records Photoshop’s result, performs the corresponding operation in the replacement, and compares the pixels. Differences identify behaviour that still needs to be reproduced. This is often called black-box testing: learning what a program does without examining its implementation.

Adobe’s General Terms of Use (published and effective October 3, 2025) define the contractual restriction broadly. Section 17(B) prohibits decompilation and disassembly, attempts to discover source code, data representations, underlying algorithms, processes or methods, and monitoring inputs and outputs to recreate the system.

The purpose of the testing matters. Comparing outputs is an ordinary part of using software. A programme of comparisons intended to reproduce Photoshop’s behaviour in a replacement has a much closer connection to the conduct this clause addresses. Adobe could therefore allege breach on the basis of the research method even if every line of the replacement were independently written.

The reference to data representations, meaning how information is structured within the software, also deserves attention. Reading the structures exposed for text layers through Photoshop’s scripting interface raises a question under this part of the clause. The availability of a scripting function establishes a technical capability; the agreement still determines the permitted uses of that capability, subject to applicable law. Any express permission covering the particular activity would need to be considered alongside the restriction.

Sections 6.18 and 6.5 add restrictions concerning data extraction and reverse-engineering datasets made from Adobe Content Files. Their application requires care: automated testing does not by itself establish prohibited extraction, and self-created test documents have a different provenance from Adobe-provided assets.

If the person or business conducting the research was bound by an enforceable restriction covering that activity, the research can constitute a breach. Identifying that party and its agreement is essential. An individual subscription and a negotiated business arrangement may produce different obligations; Section 1.2 also gives conflicting product-specific terms priority over the General Terms. The remaining question is whether the applicable law allows the restriction to be enforced.

2. Mandatory EU rights and contractual enforceability

Adobe’s own choice-of-law provision explains why jurisdiction matters here. Section 1.1 generally places North American customers under Adobe Inc. and California law, and customers outside North America and Japan under Adobe Systems Software Ireland Limited and Irish law, subject to overriding local law.

Article 5(3) of Directive 2009/24/EC (on the legal protection of computer programs, the “Software Directive”) permits a person entitled to use a copy to observe, study or test its functioning to determine underlying ideas and principles, while carrying out operations they are entitled to perform. Article 8 makes contractual provisions contrary to that protection null and void.

The Court of Justice of the European Union confirmed the scope of this protection under the preceding Software Directive in SAS Institute Inc v. World Programming Ltd (Case C-406/10, EU:C:2012:259). Its judgment makes clear that a licensee can study functionality for the purpose of producing a competing implementation, subject to the relevant conditions.

Applied to the example, running permitted operations and comparing the resulting images has a substantial argument for falling within protected observation. Extracting implementation material would require a different examination.

Where Article 5(3) applies, the licence cannot make protected observation a breach, even if its wording expressly prohibits that activity.

3. The American SAS litigation shows why the distinction matters

The same dispute between SAS and World Programming also reached the American courts. World Programming had used SAS’s Learning Edition to compare outputs and develop its competing implementation. In the English proceedings, informed by the CJEU’s ruling, the contractual restrictions could not prevent observation protected by the Software Directive.

In SAS Institute Inc v. World Programming Ltd (874 F.3d 370, 4th Cir. 2017), the US Court of Appeals for the Fourth Circuit applied the North Carolina law selected in the licence and upheld contractual liability. It declined to treat the English judgment as barring the American claims, pointing to differences in the relevant public policies. The parallel proceedings show how substantially the same development activity can receive different contractual treatment across jurisdictions.

The compensatory award was approximately $26.4 million. Its increase to approximately $79.1 million arose under North Carolina unfair-trade-practices law, alongside findings extending beyond an ordinary contractual breach. The decision does not determine PhotoCraft’s position under Adobe’s California-law terms. It does establish why a contractual claim concerning the research deserves attention even where the finished code is independently written.

4. AI assistance adds a question of its own

Adobe’s Section 17(C) also restricts using its software or derived information to create, train, test or improve AI systems. Its application requires attention to what was being improved.

An AI assistant can write a conventional image-processing function without its own model being trained or modified. Comparing that function’s output with a reference image may test the editor. Using the reference images to develop an AI image-editing agent presents a different question.

The distinction is relevant, but the provision extends beyond model training. Neither the presence of an AI assistant nor unchanged model weights supplies a complete answer. On the published facts, the ordinary reverse-engineering restriction provides the more direct starting point.

III. What other material informed the implementation?

A project may draw on several products. Each source requires its own examination.

PhotoCraft’s repository history contains references to Photon Studio, another image editor. Earlier documents described studying its behaviour and architecture and instructed contributors not to paste from an extracted bundle. An October 2, 2026 commit in storytold/photocraft (9c9a680) removed the explicit Photon references.

That history supports asking what implementation material was examined and how it was used. It does not establish that protected Photon code was copied into PhotoCraft, which agents received particular files, or why the references were removed.

The legal analysis must also distinguish copies made during investigation from expression reproduced in the finished application. The Software Directive regulates reproduction and adaptation as separate restricted acts. A non-infringing final implementation does not retrospectively authorise every intermediate copy; the relevant permissions and exceptions still need consideration.

Development records help establish what happened: which materials were available, who or what accessed them, and what information reached the implementation. Instructions describe the intended boundaries; access controls, specifications and retained records help show whether those boundaries were observed.

IV. Can the resulting product be used and distributed lawfully?

Patents provide the clearest example of a right that independent implementation does not answer.

A patent can protect a technical invention defined by its claims. Independently written code may still perform the claimed method. The relevant questions include what the claim covers, whether it is valid and enforceable, and where the relevant activity takes place. A US patent does not automatically confer rights in Europe. 35 U.S.C. § 271 separately addresses activities including making, using and selling a patented invention.

PhotoCraft’s image-filling implementation cites PatchMatch research, concerning efficient searches for similar image regions. Adobe has obtained patents concerning such correspondence methods, including US 8,811,749 B1, Determining correspondence between image regions. That identifies a separate question; it does not establish that a live claim is infringed.

Patent law is outside my specialist practice, and this article offers no opinion on infringement, validity or current enforceability of those patents. The narrower point is sufficient: demonstrating that the code was independently written does not resolve the patent analysis. Nor can the project’s open-source licence grant rights belonging to an unrelated patent holder.

The licence choice has practical consequences. Both the MIT Licence and Apache Licence 2.0 permit commercial use, modification and redistribution, subject to their conditions. Separately licensed components retain their own terms. Apache’s Section 3 expressly grants rights under patent claims that contributors can license and that are necessarily infringed by their contributions, alone or combined with the work to which they were submitted. That grant cannot supply permission under Adobe patents the contributors have no authority to license. MIT contains no comparable express patent clause.

A separate question is whether, and to what extent, the AI-assisted implementation itself attracts copyright protection. Releasing a project under MIT or Apache 2.0 does not settle that question, which depends on the human contribution and the applicable law. The consequences for licensing and reuse deserve a fuller examination than this article can provide. I will return to them in a standalone analysis of copyright protection for AI-generated code.

Both licences disclaim warranties, including non-infringement, and seek to limit liability, subject to applicable law. Neither promises to defend a user against an IP claim or compensate it for resulting losses. A business seeking those protections would need a separate agreement with a party willing to provide them. Compliance with the project’s licence and contractual protection against third-party claims therefore require separate attention.

Visible elements also require their own examination. A new implementation can reproduce graphics or an original visual arrangement even where its underlying code is independent. In Bezpečnostní softwarová asociace – Svaz softwarové ochrany v. Ministerstvo kultury (Case C-393/09, EU:C:2010:816), the CJEU distinguished a graphical interface from the expression of a computer program while recognising possible copyright protection under the ordinary originality rules. Familiar functionality alone does not establish such protection or infringement.

Finally, the position of a downstream user differs from that of the person who conducted the research. Downloading a replacement does not, by itself, make that user a party to the original developer’s contract with Adobe. Equally, the absence of that contractual relationship does not eliminate any independently applicable intellectual-property rights.

V. What the assurance is worth

Consider the question in an ordinary commercial setting. An engineering team proposes replacing a licensed tool with an AI-assisted implementation. It explains that the code was written from scratch and that none of the vendor’s source was used. The legal team is asked whether the replacement can be deployed or supplied to customers.

The legal team’s next questions should follow the three propositions. Which agreement governed the investigation of the original product, who was bound by it, and which law applies? What records show the material made available to the developers or AI agents who wrote the replacement? Do its methods or visible elements require a patent, copyright or design-right assessment in the countries where the business intends to use or supply it?

The answers should lead to a decision about the proposed use. A business developing its own replacement may need permission for a research method or changes to the way its team obtains reference material. A business adopting someone else’s software needs to establish which risks affect its own use and what assurances the supplier can support. A particular feature may require specialist review before deployment.

An assurance that the code was independently written is valuable. For counsel advising on deployment, it needs to sit alongside evidence of the development process and an assessment of the rights relevant to the intended use. Together, those findings give the business a basis for deciding whether to proceed, what conditions to impose, and which issues require resolution first.