In early October, a developer project named ArtCraftsparked discussion in the software industry: the developer, with the help of Claude, launched seven open-source tools, each attempting to replicate Photoshop、Premiere and other core functions and user experiences of Adobe products.
This set of tools has not yet reached the level of fully replacing the original software, but it raises a question worthy of serious discussion: are software functions that previously required large teams and long-term investment now becoming easier to replicate?
For entrepreneurs, this may mean new product opportunities; for software companies, it means a more practical question—when competitors can re-implement core functions at lower cost, what remains of the original technical barriers and business models?
However, the fact that functions can be re-implemented does not mean the original code has been made public, nor does it mean that such implementation is necessarily lawful.To answer this question, it is necessary to examine technical capability, intellectual property, and commercial competition separately.
According to the developer, the ArtCraft-related tools were built based on public information and independent development, and did not use the original manufacturer's proprietary code or materials. This is the developer's own account,and does not mean that its development process and legal compliance have been independently verifiedPublic reports and actual testing also show that the relevant tools are still in an early stage of development and still lag behind mature professional software in terms of the accuracy of some functions, file compatibility, and stability.
What truly deserves attention is not how much software AI has already replicated, but how it is changing the costs, competitive barriers and legal risks of software development.
1. Functionality can be rebuilt, but rights do not disappear as a result
Creating similar functionality, obtaining the original code, and obtaining an open-source license are three different things.
For example, two image software products may both be able to crop photos, while the code behind them may be entirely different. Developers may study a product's public specifications and observable behavior, and then attempt to independently implement similar functionality.Seeing a piece of software being "replicated" does not establish that the original program has been decompiled, still less that the original source code has been made public.
Open source also does not mean there are no restrictions on rights. Open-source software remains subject to the applicable license, and modification, copying and redistribution generally require compliance with specific license conditions.Even if someone lawfully develops a substitute and open-sources it, the original manufacturer's software does not thereby become open-source software.
What AI may lower is the threshold for implementing some functionality. But for commercial software,being able to implement functionality is only the starting point of product competition。
When enterprises procure software, what they purchase is often not just a function button, but alsostability, compatibility, continuous updates and after-sales supportWhether files can be opened normally, whether data will be lost, whether existing workflows can continue, and whether problems can be resolved promptly all affect whether users are willing to pay.
From communications with startup teams and investors, I believe that a small team does not necessarily have to replicate an entire mature software product from the outset; a path more worth trying is tofirst solve a specific problem for a group of users。
For example, an image batch-processing tool for e-commerce merchants could first address needs such as standardizing product image dimensions, batch-adjusting backgrounds, and exporting according to the requirements of different platforms. Suppose an online store needs to process thousands of product images each week; if the tool can reduce repetitive operations and rework costs, it may generate genuine paid demand.
When AI lowers the cost of implementing features, the entrepreneurial opportunity may not lie in building larger software, but rather insolving a specific problem faster and more accurately。
II. How far one can learn depends on the specific approach
For Chinese startup teams, the first thing to examine iscopyright。
Article 6 of the Regulations on the Protection of Computer Software provides:
The protection of software copyrightdoes not extend to the ideas, processing procedures, operating methods, or mathematical conceptsused in developing the software, among others. Therefore, similarity in functions or operating processes does not automatically mean software copyright infringement.
However, this does not mean that all software-related content may be freely copied.Specific code, documentation, and interface elements such as icons and illustrations that may be original may still be protected by copyright.Submitting another party's code to AI to convert it into a different programming language or to modify variable names does not automatically mean that an independent result has been created.
Second, it is necessary to examinetrade secrets。
Research on products obtained from public channels and on technical information obtained through qualifying reverse engineering is different in nature from developing a product after obtaining a competitor's leaked internal code or technical documentation.is different in nature。
Article 14 of the Provisions of the Supreme People's Court on Several Issues Concerning the Application of Law in the Trial of Civil Cases of Infringement of Trade Secrets clearly provides:
Where relevant information is obtained throughindependent development or reverse engineering, such conduct does not constitute infringement of trade secrets. Reverse engineering here refers to the use of technical means to conduct, on products obtained from public channels,disassembly, surveying and mapping, and analysisand other means, in order to obtain the relevant technical information.
However, if a developer first obtains another party's trade secrets by improper means and then raises reverse engineering as a defense,the court will not uphold such a defense.。
Of course, a document does not automatically become a trade secret merely because it is labeled "internal materials." It is usually also necessary to examinewhether the relevant information is not known to the public, whether it has commercial value, and whether the rights holder has taken corresponding confidentiality measures.The nature of the specific information, the manner in which it was obtained, and its subsequent use all need to be determined based on the facts.
The law also does not categorically prohibit decompilation or technical analysis. Article 50 of the Copyright Law sets out:
carrying outencryption research or computer software reverse engineering researchand other specified circumstances in which the prohibition on circumventing technological measures does not apply. However, this does not mean that developers may arbitrarily bypass software protection measures, and still less may they use this as a means to infringe other lawful rights and interests of the rights holder.
Finally, even if the code is written by the developer itself, it is still necessary to considerhow to compete.。
Impersonating official products, overstating compatibility, leading users to believe that a cooperative relationship exists between the parties, or improperly obtaining and using others' data may all give rise to other legal disputes. Conversely,the original manufacturer cannot, merely on the basis that "I invested a great deal and you sell cheaply," automatically demand that competitors exit the market。
For example, a tool developed to be compatible with a certain file format may truthfully state the file types and functional scope actually tested; but if even the product name, icon and promotional pages are deliberately made to resemble an official product, causing users to mistakenly believe that authorization or a cooperative relationship exists between the parties,the dispute has already gone beyond the code itself。
In determining whether software replication involves legal risk, one cannot look only at whether the functions are similar; one must also examine the specific expression, the source of information, the development process and the manner of market competition.
III. Five Things a Startup Team Can Start With
(1) Write down user requirements first, then select reference materials
Do not simply give AI the instruction "build it by copying a certain piece of software."
First, state the requirements specifically:who will use it, what is input, what result is to be obtained, which functions are essential, and which are merely for reference.
Public specifications, lawfully obtained products and behavior observed in normal use may serve as a starting point for research;code leaked without authorization and internal documents of a former employer that an employee has no right to take away should be excluded from development materials。
It is advisable to keep a running record of what was referenced and where it was obtained. Software license agreements should also be reviewed in advance, particularly restrictions concerning reverse analysis, automated use and data extraction. Whether the relevant clauses are valid and the scope of their application require judgment based on the specific circumstances,and they cannot be ignored across the board, nor treated across the board as absolute prohibitions。
(2) Maintain a separation between research and coding
Where public specifications and ordinary testing are already sufficient to support development, implement on that basis first.
Where decompilation or circumvention of technical measures is genuinely necessary, first verifythe research purpose, necessity and specific legal basis, and the conduct cannot be deemed lawful merely on the ground of "developing a compatible product."
For projects that closely resemble a competitor's product, consider establishing an independent development mechanism: researchers compilefunctional specifications that do not contain the other party's protected code, trade secrets or other such content, and another team then independently implements the work based on lawful materials.
The value of such a mechanism lies in managing the risk of improper information entering the development process and in preserving a basis for subsequent factual verification.Merely declaring "independent development" on a website, without being able to explain the actual process, is not sufficient to resolve the issue.
AIconversation records, knowledge bases, code repositories and access permissions, should also be brought within the same management mechanism.
If the team has already accessed materials it should not have obtained,opening a separate AI conversation cannot eliminate the prior factsit should first ascertain which modules the materials involve and whether they have already been used, and then assess the risks of subsequent development and launch.
(3) Ensuring the development process leaves evidence
"This was written by AI" cannot answer where the materials came from or how the code was formed.
It is advisable to retainkey requirements documents, prompts and attachments, model outputs, records of manual modifications and code commit records, especially the development process relating to core functions.
These records help reconstruct the source of information, the implementation path and human contributions, butdoes not by itself prove independent development, nor does it automatically exclude liability for infringementIn trade secret disputes, where the statutory conditions are met, the burden of proof may shift; continuous and genuine development records are generally more helpful in ascertaining the facts than explanations written only after a dispute arises.
It should also be noted thatconfidential materials of clients or former employers must not be casually uploaded to modelseven if the service provider undertakes not to use the relevant content for training, this does not mean that the uploader is themselves entitled to disclose such materials.
In recruitment, outsourcing and joint development contracts, it is also possible to specifythe source of materials, confidentiality obligations, code ownership and deliverables handover requirements, so as to avoid a situation where the product is about to launch but the team cannot clearly explain who supplied the key modules and on what basis they were obtained.
(IV) Check the code, and also check the scope of authorization
A user-friendly interface design and copying someone else's icons or copy are different issues.Product names and logos should also enable users to clearly identify the source of the product and avoid confusion.
For open-source code introduced by AI, the license and the specific manner of use need to be verified. Some licenses requireRetain the copyright notice and license text, while some licenses may, under specific distribution conditions, requireprovision of the corresponding source codeor performance of other obligations.
"Publicly available online" must not be understood as "free to use in any manner," nor should it be simply assumed that using a certain piece of open-source code means the entire product must be made public.Whether source code must be opened and which obligations must be performed depends on the specific license and its applicable conditions.
When deciding to open-source your own product, you must also confirm which code, materials and dependencies you have the right to license to others.Placing unauthorized code into a public repository and attaching an open-source license cannot cure the authorization that was originally lacking.
(5) Before launch, verify the functional description once more
If it "can open some files," do not describe it as "fully compatible"; completing a demonstration does not mean it can undertake professional production tasks.
In external publicity, the product'salready supported functions, tested scope and known limitations should be clearly statedand avoid exaggerating performance or making compatibility commitments that cannot be fulfilled.
At the same time, with respect to the key technologies involved in the product, potentially relevant valid patents should also be identified based on the actual circumstances.Independent development of code does not automatically excludepatent infringement risknor can the absence of legal issues be established merely on the basis that "everyone does it" with respect to file formats, interfaces and functional implementation.
For software intended for commercialization, it is advisable to prepare a basic compliance checklist before release, coveringcode provenance, open-source licenses, third-party materials, trademarks and interfaces, data use, patent risk and product marketing。
IV. When software is easier to rebuild, what is the true moat?
As the cost of implementing software functions continues to decline, the reasons users choose a product may no longer be limited to what functions it can perform, but may also includewhether it is sufficiently stable, whether it can be integrated into existing workflows, whether it facilitates team collaboration, and whether it can continuously provide reliable services。
For software companies, this means that competitive advantage may gradually shift from individual functions toproduct experience, ecosystem compatibility, service capability and user trust。
This also raises another question worth discussing: can thefeedback, templates, workflows and data contributed by users in the course of using the softwarefurther participate in product decisions, or even share in the benefits brought by product development, through explicit agreements or governance mechanisms?
Of course,user contributions do not automatically translate into software ownership or rights to profit distributionhow the relevant rights arise and how they are allocated still need to be determined in light of intellectual property ownership, contractual arrangements and specific governance mechanisms.
As software becomes increasingly easy to reimplement, how products can establish sustained competitive advantages, and how the value of user contributions should be defined, may be worth continuing to discuss in the next article.
