When AI Can Rebuild Any App: Licensing, IP and Vendor Lock-In

Between 30 September and 7 October 2026 the team behind the AI studio ArtCraft published a family of open-source applications on GitHub, each describing itself as a clean-room reimplementation of a commercial product: PhotoCraft (Photoshop), VectorCraft, FilmCraft, LightCraft, PdfCraft, EffectCraft and DesignCraft for the rest of Adobe's desktop line, then WordCraft, GridCraft and DeckCraft for Word, Excel and PowerPoint, CADCraft for AutoCAD and SoundCraft for Pro Tools. Most commits in every repository list an Anthropic Claude model, mostly Claude Opus 5.5, as co-author. The projects say they work from public specifications and observed behaviour, not from the vendors' code, and nothing published so far shows otherwise. None is finished, and each says so:

Whether these particular projects mature is not the point. A small team, working with AI, produced credible early versions of a dozen flagship desktop applications in about a week. When an application's visible behaviour can be reimplemented that quickly, the code stops being the moat. That has consequences for how software is protected, how large vendors defend their pricing, and how much leverage their customers have.

What this does to software IP

Copyright protects code as written, not what the code does. The Court of Justice of the EU said so plainly in SAS Institute v World Programming (2012): the functionality of a program, its programming language and its data file formats are not protected, and a licensee may observe, study and test a program to understand its underlying ideas. The EU Software Directive (2009/24/EC) builds that right into Article 5(3) and makes contract terms that override it void. In the United States, Sega v. Accolade (1992) treated copying for interoperability as fair use, and Google v. Oracle (2021) held that reusing the declaring code of an interface was fair use.

File formats matter as much as code. Word, Excel and PowerPoint files are openly standardised as Office Open XML (ECMA-376, ISO/IEC 29500), and Microsoft documents its own implementation through its Open Specifications program, with many related patents covered by the Open Specifications Promise. Adobe publishes its PSD specification, which PhotoCraft says it worked from. DWG has no open specification, but independent implementations exist, and CADCraft uses one, the MPL-2.0 acadrust library.

AI also works on the other side of the line. Tools such as GhidraMCP and ida-pro-mcp (both March 2025) connect disassemblers to language models, and research models such as LLM4Decompile (EMNLP 2024) decompile small binaries directly. Decompiling a commercial program is where the law is narrow: Article 6 of the Directive allows it only for interoperability, only for the parts needed, and never to build a substantially similar program. The difference between a lawful rebuild and an infringing one is therefore less about the tools and more about the inputs: public specifications and observed behaviour on one side, the vendor's code on the other.

So a well-run clean-room rebuild is hard to stop with copyright. Vendors have other tools, each with limits:

• Contract. Adobe's General Terms of Use (section 17) define reverse engineering to include monitoring an application's inputs and outputs in order to recreate it. Microsoft's Product Terms say customers may not use the Products to "replicate product functionality" unless expressly permitted. Autodesk's Terms of Use prohibit reverse engineering and decompiling except where the law allows it.
• Patents. A patent covers a method however it is coded, so it can reach a clean-room implementation. It has to be valid, specific and asserted, which is slow and public.
• Trademarks and trade dress. These stop a clone from using the product's name or confusing buyers. They do not stop the same features. The ArtCraft projects use their own names and, in CADCraft's case, an explicit disclaimer of any Autodesk affiliation.
• Terms of service for cloud features. Generative AI, sync and collaboration run on the vendor's servers under account terms, and a desktop clone cannot reach them.

The open question is the contract route. A licence agreement binds the people who accepted it. If a clean-room team never accepted Adobe's or Microsoft's terms, or worked only from public documents and from behaviour described by others, it is unclear what a vendor could enforce against it, and the answer will differ between the EU, where Article 5(3) cannot be contracted away, and the United States, where courts have enforced anti-reverse-engineering clauses against licensees. Expect the first test cases to be about who observed what, under which licence. This is general information, not legal advice.

What it means for large vendors

If code is cheaper to replicate, the defensible parts of a software business are the parts that are not code:

• Data and format gravity. Decades of files, templates and libraries in a vendor's formats keep customers in place, and full fidelity on complex files is the hardest thing for a clone to reach.
• Cloud services and AI features behind accounts. What runs on the vendor's servers cannot be rebuilt from observing the desktop app, and it is where vendors have been adding most new capability.
• Ecosystems and integrations. Plug-ins, add-ins, macros, APIs and partner products depend on the original platform. None of the ArtCraft projects runs Photoshop plug-ins or VBA macros.
• Identity and management. Microsoft 365 is Exchange, Teams, SharePoint, Entra ID and Intune as much as Word and Excel. Replacing the editor leaves the platform in place.
• Assurance. Security certifications, accessibility conformance, support contracts and IP indemnities are what enterprise buyers pay for, and a pre-alpha open-source project offers none of them.

Likely vendor responses follow from that list: stricter terms on observation and automated use, more capability moved into cloud services that require an account, more bundling of desktop apps with services that cannot be cloned, and enforcement aimed at customers' use of licensed software rather than at independent cloners. Pricing pressure is likely at the edges, on lighter plans and occasional users, where a free alternative is closest to good enough.

Exposure is uneven. Vendors whose value sits mainly in a desktop application with a documented file format are most exposed. Vendors whose value sits in services, data, identity or the runtime of business systems are least exposed. Adobe's desktop apps and Autodesk's drafting tools sit nearer the first group; Microsoft 365 as a whole, Oracle's databases and Broadcom's VMware stack sit nearer the second, because the hard part to replace is the platform and the contracts around it, not the user interface.

What it means for customers who are locked in

Many organisations are in a difficult position with a vendor already. Broadcom moved VMware to subscription bundles, set a 72-core minimum order and sent cease-and-desist letters to perpetual licence holders. Oracle prices Java SE by employee count, which is why Java audits price headcount, not installs. Microsoft 365 is usually the largest software line at renewal, and Adobe combined 2025 price changes with early cancellation fees that make mid-term exits expensive.

Microsoft is the clearest case of where the line falls. An E3 or E5 renewal pays for Exchange Online, Teams, SharePoint, OneDrive, Entra ID and Intune as well as the desktop apps, and the saving available from a desktop alternative is in the licence mix: users who only read and lightly edit can often move to a plan without desktop apps. That is the analysis in our guide to E3 and E5 optimisation, and a credible desktop editor for occasional users makes the case easier to put to the business. It does not remove the platform.

AI-built alternatives lower switching costs for some layers and not others:

A credible alternative changes the negotiation even if you never switch. Vendors price against the customer's next best option; when that option goes from "none" to "a tested pilot covering our occasional users", the discussion about seat counts and plan mix changes. The position that holds up is built on usage data and on alternatives you have actually tested, not on a repository's star count.

Evaluating a move responsibly means checking the alternative and your own contract together:

• The alternative's licence and dependencies. Permissive licences (MIT, Apache 2.0) are simple to use; weak copyleft dependencies such as MPL-2.0 add conditions on modification and distribution.
• Security. Release signing, maintainer activity, advisories and network behaviour, plus a review of any AI agent interface the tool exposes.
• Support and indemnity. Who fixes a defect and who stands behind an IP claim. With most open-source projects the answer is nobody, unless a commercial distributor offers it.
• Data migration. Test round trips on your own files, templates and macros, not on samples.
• Your own contract. Have legal read your agreement's restrictions before anyone in your organisation studies, instruments or benchmarks the vendor's software to compare it.

The risks that do not go away

• Unvetted installs. Free tools with famous names attract look-alike installers and quick forks. Staff will try them before policy catches up.
• IP indemnity gaps. Vendor contracts usually include an indemnity against third-party IP claims; open-source alternatives usually do not. If a clean-room claim is ever disputed, the user carries that risk.
• Audit exposure. Installing an alternative does not reduce what you owe. Vendor software installed without an entitlement is still a finding, and the steps in a 90-day audit preparation plan still apply.
• Paying twice. The most expensive outcome is a half-switched estate: new tools rolled out, the old seats still renewed because nobody reduced the order before the anniversary or true-up.

If you are considering leaving a vendor

1. Measure actual use. Find who uses what, how often and which features, per product. Most estates have a large group of light users.
2. Map the dependencies. List what the product connects to: identity, data, integrations, plug-ins, macros and downstream systems. That list, not the editor, sets the switching cost.
3. Read the exit terms. Renewal dates, notice periods, minimum commitments and cancellation fees determine when a change can save money.
4. Pilot an alternative properly. One that passes your licence, security and support checks, with real users and real files, for the light-use group first.
5. Negotiate with the evidence. Bring usage data and pilot results to the renewal, and decide the target seat count and plan mix before the order is due.
6. Close the loop. Remove what you no longer license, update the records and keep proof, so the next audit sees the estate you are paying for.

LICENSEWARE's SaaS apps give you that usage view for the two largest desktop estates: Adobe Deployment Manager for Adobe and Microsoft Deployment Manager for Microsoft.

FAQ

Are these AI-built apps legal?

Reimplementing functionality and open file formats without copying code is generally lawful in the EU, the UK and the United States. Copying code, assets or trademarks is not, and vendor contract terms restrict what licensees may do to study the original.

Were they made by decompiling Adobe or Microsoft software?

The projects say no: they describe clean-room work from public specifications and observed behaviour, and no evidence to the contrary has been published.

Can a company replace Microsoft 365 with them?

Not today. The Office copies are pre-alpha desktop editors, and Microsoft 365 is also mail, collaboration, identity and device management, which they do not touch.

Does a free alternative help at renewal if we do not switch?

Yes, if it is real: a tested alternative for a defined group of users changes the discussion about seat counts and plan mix. An untested one does not.