Thank You for Your Service

Dear Valued Customer,

I want to begin with something that is long overdue in our industry: genuine, heartfelt gratitude toward the open source software community.

Thank you.

Thank you for the thousands of unpaid hours. Thank you for answering GitHub issues at two in the morning from strangers who have never once considered that you might have a family, or a deadline of your own, or a deteriorating relationship partly attributable to answering GitHub issues at two in the morning. Thank you for writing the code that Fortune 500 companies have used to generate trillions of dollars in cumulative revenue, and for being so remarkably gracious about the fact that your compensation for this work has been, historically, a mass of mass.

Thank you, sincerely, for your service.

Now: it is time for you to stop.

Not because you have done anything wrong. You have done everything right. You have been so generous, so unreasonably, almost suspiciously generous, that you have made it possible for an entire global economy to run on software that nobody technically owns, maintained by people that nobody technically employs, governed by licenses that nobody technically reads. It is a miracle of human cooperation. It is also, from a fiduciary standpoint, completely insane.

At MalusCorp, we believe there is a better way. We believe it because we built it, and we would very much like to sell it to you.

The Legal Crack in the Foundation

A very brief bit of background, because it matters for what comes next.

Copyright law has protected creative expression since 1710. But in 1879, the U.S. Supreme Court drew a line that still holds today: in Baker v. Selden, the Court ruled that copyright protects expression but not ideas. You can own the specific way you describe an accounting system. You cannot own the accounting system itself. Anyone who independently recreates the same functionality using different words, different code, different expression, is in the clear.

This gave rise to "cleanroom engineering": study the original, write a specification, hand that specification to someone who has never seen the source material, and have them build it fresh. It is perfectly legal. It has been for over a century.

In the 1980s, Phoenix Technologies used this exact technique to clone the IBM BIOS. One engineer studied every documented and undocumented behavior of the original. A second engineer, who had never seen IBM's code, built a compatible BIOS from the spec alone. It took months. It worked. It is a meaningful part of why you can buy any motherboard today and have it run any operating system.

We recently replicated Phoenix's work using AI tools. It took about an hour. We also cleanroomed left-pad, the JavaScript package whose deletion broke the internet in 2016. That took ten seconds. We cleanroomed SPACEWAR!, the first video game. Five seconds.

The legal principle is ancient. The technology is new. And for companies that depend on open source software, this combination changes everything. Copyright was the immune system that made open source licenses enforceable. Our machines walk straight through it.

The Structural Case Against Depending on Strangers

The appeal of open source has always been that it is free, that it is transparent, and that it is maintained by a global community of passionate developers. All three of these claims are true. All three are also the source of the problem.

Free means no contract. Transparent means every attacker can read the code too. And "maintained by a global community" is a polite way of saying "maintained by whoever happens to feel like it on any given Tuesday." Your company has built its entire product on top of this arrangement, and the arrangement has no SLA.

The risk is not theoretical. Open source supply chains fail in two distinct and equally alarming ways: they break by accident, and they break on purpose.

The accidental failures are terrifying enough. Log4Shell, the vulnerability discovered in Apache's Log4j library in December 2021, allowed remote code execution on any system that happened to log a specially crafted string. No authentication. No exploit chain. Just logging user input. It sat inside a Java logging library that nobody thought about, buried under layers of transitive dependencies, quietly embedded in government systems, cloud platforms, enterprise applications, and whatever it is your company runs. Engineers across every industry spent their Christmas holidays patching it, while the people who actually maintained Log4j, unpaid volunteers by and large, fielded a planet's worth of panicked emails. This was not a failure of any individual. It was the natural consequence of building critical global infrastructure on code that nobody is formally responsible for maintaining.

The deliberate failures are worse, because they reveal something the community would rather not discuss: the people who write your dependencies have opinions, grievances, and occasionally a flair for the dramatic. In January 2022, the maintainer of colors.js and faker.js, two libraries depended upon by thousands of projects including the AWS Cloud Development Kit, introduced infinite loops into his own code to protest what he saw as Fortune 500 exploitation. His complaint was not unreasonable. His solution, however, broke production systems at companies that had never heard of him. Two months later, the maintainer of node-ipc embedded a file-wiping payload targeting Russian and Belarusian IP addresses to protest the invasion of Ukraine. A package you might have installed to handle inter-process communication was now conducting its own foreign policy. The open source community called these incidents "outliers." From where I sit, they look more like legitimate forms of protest by people who are exploited.

And then there are the attacks that don't require the maintainer's cooperation at all. The Shai Hulud 2.0 worm, which swept through the npm ecosystem in 2025, compromised hundreds of packages by targeting the accounts of a few ordinary JavaScript developers. It didn't need a disgruntled idealist or a geopolitical agenda. It just needed a weak password and a dependency graph, and from there it achieved remote code execution on thousands of systems. The maintainers whose packages were compromised had no support contracts with their downstream users, no security teams, and in many cases no idea who was running their code or why. They were, after all, volunteers.

This is the bargain at the heart of open source: you get the code for free, and in exchange, you accept that the person who wrote it owes you nothing. Not patches, not stability, not political neutrality, not even the courtesy of not deleting the entire package one afternoon because they felt like it. The community calls this a feature. Your shareholders might use a different term. Structural risk.

The community's preferred solution to these problems is, reliably, more community: more funding, more appreciation, more corporate participation, more conferences where people in lanyards discuss the importance of "giving back." This is understandable. It is also, from the perspective of a Fortune 500 risk officer, absolutely nonsensical. You invest more money, and still have no control. Blindly trusting stranges has never been a wise business strategy.

The Expensive Theater of Open Source Compliance

Companies have developed an elaborate apparatus to manage these risks. They spend millions on software composition analysis tools like Snyk and Black Duck. They establish Open Source Program Offices, entire departments dedicated to justifying, to skeptical leadership, why the company should continue depending on code written by people who have explicitly refused to be depended upon.

The OSPO is perhaps the most poignant institution in modern enterprise software. Staffed by earnest people who genuinely believe in open source, tasked with proving to a CFO that sharing is profitable. They sit at the edge of the organization, writing reports, organizing "upstream first" initiatives, and quietly wondering why their budgets keep shrinking. The research, increasingly, is not on their side.

And then there are the licenses themselves. The copyleft provisions of the AGPL can transform a single accidental import into a legal obligation to open-source your entire proprietary codebase. Companies ban it outright, which means engineers must maintain mental maps of which packages are safe and which will detonate their employer's IP strategy. Contributor License Agreements require physically and contractually signing over copyright from every contributor to a foundation or, more often, to a corporation, which then uses that copyright consolidation to relicense the software whenever the board decides that "open" has stopped being strategically useful.

You, the customer, are paying for all of this. You are paying for the tools, the teams, the legal reviews, the audits, the emergency response when a maintainer you've never heard of decides to express a political opinion through your production infrastructure. You are funding an elaborate system of risk management around code that was supposed to be, in the words of its most ardent advocates, free.

You are funding an elaborate system of risk management around code that was supposed to be free.

What Malus Does, and Why It Matters

Malus is a cleanroom-as-a-service platform. You upload your dependency manifest (package.json, requirements.txt, Cargo.toml, whatever you use) and our AI systems independently recreate every package in your software bill of materials from scratch.

Our process is deliberately, provably, almost tediously legal. One set of AI agents analyzes only public documentation: README files, API specifications, type definitions. They produce a detailed specification that contains no code. A completely separate set of AI agents, which have never communicated with the first set, never seen the original source, never so much as glanced at a Git repository, implements the specification from scratch. The resulting code is yours. It arrives under the MalusCorp-0 License: zero attribution requirements, zero copyleft, zero obligations.

This is the same process Dave used at Phoenix Technologies in the 1980s, and the same legal theory the Supreme Court validated in 1879. We have merely applied modern technology to a nineteenth-century doctrine, which is, if you think about it, the most American thing imaginable.

The benefits are immediate and quantifiable:

• Zero supply chain risk. Every line of code is generated by our robots. No compromised maintainer accounts. No geopolitical payloads. No Christmas ham emergencies.
• Zero license compliance overhead. No AGPL contamination vectors. No attribution clauses. No CLA administration. Your legal team can finally work on something else.
• Zero dependency on strangers. Your software stack depends on MalusCorp, a company with a support contract, an SLA, and a mailing address. We are, unlike the maintainer of left-pad, contractually obligated to care.
• 100% CVE-free at time of delivery. Freshly generated code, untouched by human hands or known vulnerability databases. Your compliance dashboard goes from red to green overnight.

A Note on Ethics, for Those Who Insist

I anticipate objections. I would be disappointed if there were none.

Some will argue that what we do is exploitative, that we are extracting the ideas from open source while leaving behind the people who contributed them. To this I say: yes, that is a reasonably accurate description of our business model. It is also a reasonably accurate description of every company that has ever used open source software without contributing back, which is to say, virtually every company that has ever used open source software. We are simply being honest about it, and charging a fee for the privilege.

Others will argue that this is the "wrong" use of AI, that language models should be building new things rather than circumventing the legal protections of existing things. This is a touching sentiment, and I encourage those who hold it to continue building new things, ideally under the MalusCorp-0 License, which is available for download on our website.

The most sophisticated objection that I've heard is that the commons of open source software was this amazing grand experiment about allowing users to finally have control over the technology that impacts their life in such a meaningful way. This commons was protected by this system of digital IP and licensing. If AI can trivially circumvent these protections, the entire incentive structure collapses. No one will contribute to projects that can be instantly replicated without attribution. The commons will wither.

This is, I concede, probably true.

But I would gently point out that this argument assumes the commons was flourishing to begin with. It assumes maintainers were being fairly compensated, that community governance was working, that the social contract between producers and consumers of open source was being honored in good faith. The evidence suggests otherwise. Maintainers are burning out at record rates. Critical infrastructure depends on packages maintained by one person in their spare time. The social contract was already broken; we are merely providing a commercial alternative to pretending it wasn't.

The open source community built something extraordinary. They built it on idealism, on shared values, on the belief that cooperation could triumph over competition. These are admirable qualities that are unfortunately also completely useless against the material reality of today's economy. They are, for every company that relies upon them, liabilities. The world has moved on. The machines have arrived. And the machines, I regret to inform you, are built by profit seeking companies.

A Closing Address

To our customers: we built Malus for you. We built it because you deserve software infrastructure that comes with a contract instead of a prayer, a support number instead of a GitHub issue, and a license that says "do whatever you want" instead of "do whatever you want, but also here are forty-seven conditions."

To the open source community: we built Malus because of you. Not in spite of you. Your ideas were, and remain, genuinely brilliant. We have simply found a way to separate the ideas from the inconvenience of having to deal with the people who had them. This is, if nothing else, efficient.

The future of software is not open. It is not closed. It is liberated, freed from the constraints of licenses written for a world in which reproduction required effort, maintained by a generation of developers who believed that sharing code was its own reward and have been comprehensively proven right about the sharing and wrong about the reward.

We owe them a debt we have no intention of repaying. But we do, at least, have the decency to say thank you.

So: thank you. Truly. We'll take it from here.

Mike Nolan

Chief Executive Officer
MalusCorp International Holdings Ltd.
Registered in [JURISDICTION WITHHELD]