At 1:04 a.m. on November 6, ERPNext released v16.54.0. Of the 13 features, the least conspicuous one is: restricting operations that modify data to use only POST requests.
It won't slow down any page, nor will it pop up errors in the interface. It will only cause a batch of scripts that run overnight to fail quietly the next morning—or worse, quietly do nothing at all, while reports come out as usual, with stale numbers.
Two other things happened in the same week: on November 12, ERPNext released v16.55.0 and v15.125.0 again; on November 6, media reported that ThreatBook issued a copyright statement regarding the closed-source release of the Artex project, clarifying that forks circulating after October 8 are not official versions. Putting these three things together reveals the true cost structure of open-source software in enterprises: what you get is a piece of code, not a timeline.
1. Patch Day: The Change Is to the Interface Contract, Not the Functionality
First, look at this series of version releases. Below are the times that can be found on the GitHub releases page:
| 版本 | Release date | Key changes | Who will be affected |
|---|---|---|---|
| v15.124.5 | 2026-11-04 | v15 maintenance branch routine fixes | Existing deployments still on v15 |
| v16.54.0 | 2026-11-06 | Write operations restricted to POST; company-level restrictions added for materials/customers/suppliers; customer freeze and unfreeze dates; sales orders directly generate proforma invoices | Self-developed integration scripts, multi-company groups, credit management processes |
| v16.55.0 | 2026-11-12 | Production plan filters warehouses and orders by permission; when reservation is closed, reservations are no longer created | Manufacturing and Warehousing Roles |
| v15.125.0 | 2026-11-12 | Production planning only displays submitted sales orders accessible to the user | v15 Multi-company deployment |
From 2026-11-04 to 11-12, ERPNext released a total of 4 versions across the two maintenance branches v15 and v16 (GitHub releases page)
Pace isn't the problem—open source projects move frequently by nature. The problem is the nature of the change. For the POST item, the corresponding PR is #62519, and the official description is straightforward: operations that modify data can only use POST, and scripts still calling it with GET must be changed; incidentally, the "Pay" button on the sales order portal has also been switched to the new method.
Why is this harmful? A lot of "glue code" in enterprises is written like this: a scheduled task uses GET to assemble a URL and pushes the status of a document in the ERP to the WMS, OMS, reconciliation platform, or bank front-end processor. Such scripts often have no tests, no monitoring, and no owner, and are only remembered on the day something goes wrong.
Before upgrading, do one thing first: find all calls that "use GET to modify data".
The method isn't complicated: in the test environment, turn on access logs and filter out requests whose method is GET and whose path hits write-type endpoints; then run a full search of the in-house script. The change isn't just swapping the method name—retry logic, idempotency keys, and timeout settings all need to be reviewed accordingly, because the replay behavior after a POST failure is completely different from that of a GET.
There is another detail that is easy to overlook: the GitHub release page itself notes that the release notes are an LLM-generated summary and may contain errors, so for details you need to go back to the PR. This is not bashing open source; rather, it is a reminder to enterprises—release notes are clues, the PR is the evidence. When doing change review, copying the PR number into the change ticket is far more useful than copying a phrase like "fixed several issues".
II. The Company Boundary of Master Data: From Default Sharing to Explicit Authorization
Another change in v16.54.0 with a deeper impact is that two settings, "Restrict Companies" and "Allowed Companies", were added to the three master data tables for materials, customers, and vendors (PR #63045). The official description is: only users from allowed companies can see these records; transactions from other companies cannot use restricted records; records associated with hidden master data will also be hidden together.
In the past, the default state of multi-company deployment was 'shared': one material table used by the entire group, distinguished by price lists and warehouses. Now the default state has become 'explicitly tightenable': who can use this material and this supplier in which company can be set item by item. The direction is correct—sharing suppliers within a group while branch companies procure and settle independently should naturally have boundaries. But for a system that has been running for several years, this is a rewrite of the data contract.
The most common time to run into problems is during month-end closing. If a purchase order references a restricted vendor record, the document will be hidden or rejected; if a sales order references a restricted customer, you may only discover at invoicing that the master data cannot be found; for intermediate documents in intercompany transfers, master data visibility is inconsistent between the two sides. Such problems will not appear on go-live day; they will surface in concentrated form during the first intercompany closing.
Dependency order is a hard requirement: this feature requires Frappe 16.55.0 or later (PR #63977).
Upgrade the framework first, then upgrade the application; otherwise, the false impression that "the function menu is there but the configuration items are not" will occur, and implementers can easily misjudge it as a wrong version and repeatedly reinstall. There is another change in the same batch: customers can set "freeze" and "unfreeze dates"; during the freeze period, sales orders, delivery notes, sales invoices, and POS invoices cannot be saved or submitted, while quotations can still be created—this turns credit management from "relying on people to remember" into "system blocking," but it also means that legacy freeze flags will take effect immediately.
This is also the direction open-source ERP has taken over the past two years: the catching-up on features is basically over, and the remaining work is to make the boundaries of multi-organization and multi-permission solid. Odoo 20 merged operation and record domains, while ERPNext pushed company boundaries down to the master data layer; the paths differ, but the conclusion is the same—before agents come in, "who can see what and who can change what" must first become executable rules.
3. Branch day: fork is not a backup
On November 6, media reported that ThreatBook issued a copyright statement regarding the closed-sourcing of the Artex project. The key points are clear: Artex officially became closed source on October 8, 2026; since then, all kinds of forks circulating publicly on the Internet are not official releases; the original version is governed by AGPL 3.0, and distributing the original or modified versions externally requires retaining the copyright notice, including the complete license text, and marking changes; if a third party wants to build a commercial closed-source product based on it, they need to negotiate a separate commercial license. The commercial version Artex Pro is available to enterprise customers only through its RedAgents platform.
This is not an isolated case but a standard move in open-source commercialization: first use AGPL to gather the community, then use a closed-source version to complete the commercial loop. For users, what really needs to be understood is AGPL's viral nature—it governs not 'whether you have modified the code' but 'whether you have distributed it.' Using and modifying it internally within an enterprise carries limited obligations; once it is delivered to customers along with a project, or packaged as a service and provided externally, the obligation to provide the source code follows. Pitfalls often arise not from trying to take advantage, but from mixing 'internal use' and 'delivery to customers' in one codebase.
| Source code available | Has maintenance |
|---|---|
| You can read it, modify it, and self-host it; when problems arise, you can diagnose them yourself instead of waiting for the vendor's schedule. This is real control. | Someone continuously merges security patches, follows up on dependency upgrades, and responds to vulnerability disclosures; branches have ownership, SLAs, and a clear license status. |
These two things are often conflated. What happened on the day it went closed-source was not "the code disappeared," but rather your fork changed from "a branch of upstream" to "your own private branch". Security patches have to be written yourself, dependency upgrades have to be borne yourself, compliance reviews have to be evidenced yourself, and when a vulnerability emerges, there is no upstream to point to. If no one on the team is specifically responsible for this, it will keep sinking to the bottom of the to-do list until some scan report digs it out.
The most dangerous misconception is: "We have forked before, so we are not afraid of closed source."
What a fork preserves is the code at that moment, not the maintenance thereafter. After going closed source, derivative versions circulating add another layer of risk: the source cannot be verified, and code poisoning cannot be investigated. ThreatBook specifically flagged this in its statement. What enterprises should do is not keep looking for the "latest usable branch," but register this code as a "self-maintained asset," clarifying the owner, patch cadence, and fallback plan.
IV. Write the third expiration date into the contract
On November 12, CETC Digital, under China Electronics Technology Group Corporation, announced: the group standard 'Specification for Open Source Application Risk Assessment of Software Products', led by Huaxun Network and jointly compiled by industry units in finance, transportation, energy and other sectors as well as Fudan University, has been officially released on the National Group Standards Information Platform. Public information states that the specification systematically specifies the assessment objects, assessment process, assessment indicators, risk classification and handling requirements for open source application risk assessment of software products.
I have not obtained the standard's number or the original text of its clauses; here I treat it only as a signal that "a framework has already emerged." What is noteworthy is the shift in the object of assessment: in the past the question was "how much open source was used"; now the question is "can these three dates be answered?"
| Expiration date | The question to be answered | Where is the evidence | Responsible person |
|---|---|---|---|
| Patch Day | Which interface contracts did this patch change? Can our callers keep up? | Release page PR number, changelog, integration call list | Integration Lead |
| End of support date | How much longer can this version line hold out? Which module is missing on the upgrade path? | Official support matrix, dependency minimums, and version status of third-party modules | Platform lead |
| License Change Date | Will the license change? If it changes, will we still be able to deliver to the customer? | License text, commercial terms, upstream governance structure | Legal + Procurement |
Incidentally, a word on the longevity of version lines. A third-party review (Cloud Converge, November 2026) states that ERPNext v15 is planned to be supported until the end of 2027, and v16 until the end of 2029; by the same measure, Odoo only supports the latest three major versions. These are third-party compilations, not official commitments, but they remind us of one thing: the "support period" of an open-source project is not just a matter of saying "the community will handle it"—it is a table that needs to be clearly understood.
Three actions for CIOs to start next week:
- Add three columns to the ledger. For each open-source component, record three items: version line and minimum dependency, upstream branch status (active/stalled/closed-source), and license and commercial terms. Do not build a new system; first add columns to the existing CMDB or procurement ledger.
- Run two probes before patching. One read-only probe verifies permissions and visibility; one write-path regression verifies every call that modifies data. Clearing the "using GET to modify data" checklist all at once is far cheaper than investigating again every time something goes wrong.
- Put two sentences in the contract. How many days' advance notice is required for license changes; if the upstream goes closed-source, whether the source code, build scripts, and dependency list are delivered into escrow. These two sentences are more concrete than any "vendor support" promise.
Open source's "free" buys you the act of obtaining the code. What you pay for is the schedule: when patches are applied, when upgrades become mandatory, when the license may change. The CIO's job is to take that schedule out of the community's hands and put it into their own change calendar.
Go back to that patch in the early hours of November 6. It didn't make the news, and there was no launch event. But it can determine whether a system will still run normally next year more than most AI features—because AI can wait, scripts can't.
Sources: ERPNext GitHub Release page (v16.54.0, 2026-11-06; v16.55.0 / v15.125.0, 2026-11-12; PR #62519, #63045, #63041, #63977, #62152); itHub Directory ERPNext entry (updated on 2026-11-07, including dependency notes for Python 3.14 and Frappe 16.55); Frappdate release summary (2026-11-06); Consumer Daily Network "Domestic cybersecurity company Weibu issues a statement regarding secondary development of Artex for commercial use" (2026-11-06); China Electronics Technology Group officially releases "Specification for Open Source Application Risk Assessment of Software Products" (2026-11-12); Cloud Converge "Odoo vs ERPNext" (2026-11).
Terminology note: Version dates and PR changes are subject to the GitHub release page; release notes are LLM-generated summaries, and details have been checked against the PR entries. The Artex closed-source date, license obligations, and RedAgents capability data are all cited from ThreatBook statements and media reports; among them, “dozens of large enterprises” and “100% RCE-level breakthroughs” are vendor self-reported claims and have not been independently audited. The number and original text of the clauses of the group standard were not obtained; this article only cites public descriptions of its assessment framework. ERPNext support periods and Odoo version policies are third-party review interpretations and do not represent official commitments.
