Your MES, your SCADA gateways, your quality dashboards: strip out the open source components and most of them stop working. Chester Wisniewski argues that 40 years of hard-won equilibrium around software licensing has been thrown out the window, because large language models are “consuming everything they find online, without regard for copyright or license.” His conclusion is blunt: the social contract has been broken. Developers now have every incentive to stop sharing, and to distrust what they find.

That sounds like a problem for maintainers on GitHub. It lands on your plant floor. AI-generated code with unclear provenance, unmaintained libraries, and licence obligations nobody tracked are supply chain and audit exposures. Here is what changes for manufacturers, and what to check first.

Forty Years of Open Source Equilibrium, Undone in Three

The equilibrium was never elegant. Copyleft licenses like GPL, MPL and CC-SA turned copyright against itself, forcing anyone who benefited from free code to pass those same freedoms downstream. Imperfect, litigated, argued over for decades. But it worked, and it built everything. Wisniewski’s point is that the modern internet and cloud simply could not exist without it: every cloud service is a derivative work standing on the previous generation’s giants.

Your operation sits on the same foundation. The connectors feeding your historian, the libraries parsing your OPC UA traffic, the Python stack behind your analytics dashboards. None of it was written by your vendor from scratch.

Take away the incentive to publish, and that supply quietly thins out. Nobody sends you a notice when it does.

What Actually Broke: Licenses Without Enforcement

Copyleft’s enforcement model and why LLM training bypasses it

A license is only worth what a court will make someone do about it. Copyleft never relied on goodwill. It relied on the fact that if you shipped a product containing GPL code and refused to release your modifications, the copyright holder could sue you and win. That threat, not the text of the license, is what made the whole arrangement function.

LLM training walks straight past that mechanism. The model ingests the code, strips it of provenance, and emits something that resembles the original without carrying its obligations. Wisniewski notes there is currently “no appetite for legal enforcement of these obligations”, which means derivative works may or may not reflect the licenses of the original creators. Nobody knows which, and nobody is checking.

What ‘the social contract has been broken’ means for code you already ship

Here is where it stops being abstract. Your integrators, your automation vendors, and your internal engineers are all using coding assistants now. Some of what they commit into your line control software, your reporting layer, and your custom PLC tooling was generated by a model trained on copyleft code. None of it carries a license header. None of it shows up in a software bill of materials.

That is a compliance exposure sitting inside a production system, and it has a shelf life. Enforcement is quiet today. It will not stay quiet forever, and the code you commissioned in 2025 will still be running your packaging line in 2032. Litigation lands on the company that shipped the product, not the model vendor.

The practical consequence is that your supplier contracts and acceptance criteria are now out of date. If a vendor cannot tell you what generated the code they delivered, they cannot tell you what license governs it. Ask that question at the next procurement review, in writing, before the next system goes live.

The Four Risks That Land on Your Engineering Team

Wisniewski lists what he now watches for in anything he pulls off the internet: slop code, a poisoned malicious library, code that quietly sends data to third parties, or code “comprised of someone else’s stolen work, implicating me in the crime.” Four categories. Every one of them arrives in your plant through the same door, a developer or integrator pulling a package to finish a job on schedule.

• Slop code: Plausible, functional-looking, untested against your edge cases. It passes review because it reads well.
• Poisoned libraries: Typosquatted or hijacked packages that sit dormant in a build until they don’t.
• Silent exfiltration: Process data leaving your network through a dependency nobody audited.
• Stolen work: Licensed code laundered through a model, shipped by you.

Provenance risk: inheriting someone else’s copyright problem

The stolen-work scenario is the one that stops being an IT conversation. If a model reproduces GPL-licensed code without attribution and your integrator ships it inside a machine controller, the copyright holder’s claim runs against the company that distributed the product. That is you, not the model vendor.

Procurement and legal need to see this before contract renewal, not after a notice letter. Ask every software supplier for a software bill of materials and a written statement on AI-generated code in their deliverables. If they cannot produce either, you have no provenance chain and no defence.

Security risk: AI-assisted vulnerability discovery in published code

Wisniewski points out a nasty asymmetry. Publish your code and AI makes it far easier for someone to find your coding errors. Keep it closed and those same mistakes stay hidden, which is security by obscurity, and obscurity is not a control.

For manufacturers running custom HMI logic or bespoke integration layers, this shifts the timeline. Vulnerabilities that used to take a skilled researcher weeks now surface fast. Patch cadence on operational systems, historically measured in quarters, no longer matches the speed of discovery.

The Maintainer Burnout Problem Nobody Priced In

Most open source libraries are maintained by a handful of unpaid people, often one. That person now faces a new tax on their time. Wisniewski describes publishing to a public repository and being “inundated with pull requests generated by AI bots and inexperienced users, flooding me with mostly useless slop and taking all of my spare time away just triaging it.”

Triage is not development. Every hour spent reading a generated patch that nobody understands is an hour not spent on the security fix, the compatibility update, or the bug your integrator filed eight months ago. The work still looks busy from the outside. Commit graphs stay green. Actual progress stalls.

The downstream effect is slower patch cycles on the exact components buried in your quality system. A CVE drops in a serialisation library used by your MES middleware. Two years ago the maintainer shipped a fix in a week. Now they are three hundred pull requests deep and considering whether to keep the repository public at all. Some will archive it. Some will go quiet without saying so.

That turns an abstract argument about AI open source licensing into a vendor question you can actually ask. Not “is your software secure” but “who maintains your dependencies, and are they still active?” Put it in the next renewal conversation and watch how quickly the room gets uncomfortable.

Three things worth asking every industrial software vendor before you sign:

• Produce the SBOM: A software bill of materials, current, for the version you are actually running. If they cannot generate one, they do not know what is in their own product.
• Name the top ten dependencies: Then check the last commit date and the number of active maintainers on each. This takes twenty minutes.
• Ask about the replacement plan: When a critical library goes unmaintained, who forks it, who patches it, and does that cost land on you?

What Operations Leaders Should Change Before 2027 Procurement Cycles

None of this gets fixed by a policy memo about AI ethics. It gets fixed in procurement, where you still have leverage over what enters your systems. Four changes, all of which you can make before your next contract renewal.

Start with a software bill of materials. Require one from every automation, MES and AI vendor, machine-readable, updated at each release. If a vendor cannot tell you what is inside their product, they cannot tell you what breaks when a component is abandoned or found to be infringing.

Due diligence questions to add to your AI vendor checklist

• Provenance: Which components were generated or substantially modified by an LLM, and how was the licence of the training material verified?
• Indemnification: Does the contract cover you if a copyright holder brings a claim against code shipped in their product?
• Maintenance health: For each critical dependency, how many active maintainers, and what is the release cadence?
• Egress: Does any bundled library make outbound network calls, and to whom?

Score maintenance health alongside price and feature fit. A library with one unpaid maintainer is a migration project you have not budgeted for yet. Treat it that way in the scoring matrix, not in the footnotes.

Setting an internal policy for AI-generated code in production

Write down where generated code is allowed and where it is not. Internal reporting scripts, fine. Anything touching control systems, safety interlocks or regulated quality records, human-authored and human-reviewed, with the author named. Ambiguity here defaults to the schedule, and the schedule always says yes.

Require disclosure from integrators too. If a contractor uses a coding assistant on your PLC-adjacent code, you want that in writing before commissioning, not after an audit finding.

The return here is entirely downside protection: remediation you never pay for, legal exposure you never argue about, migrations you never rush. Wisniewski’s warning is that creators now have every incentive to stop sharing. If the well runs dry, the organisations that mapped their dependencies first are the ones still moving.

Source: chesterwisniewski.com