Open source calculator firmware DB48X forbids CA/CO use due to age verification

DB48X’s open source calculator firmware forbids AI contributions

The maintainer of the DB48X open source calculator firmware (a community project that recreates and extends the firmware that runs on HP’s RPN calculators, the kind of reverse-Polish-notation (a way of entering math where you put the numbers first and the operator after, like 3 4 + instead of 3 + 4) scientific calculators engineers and math nerds have been carrying around since the 1980s) project added a new clause to the project’s contribution guidelines in early 2026. The clause forbids AI-generated contributions. The clause is short. The clause is firm. The reaction on Hacker News was 600 comments long.

This is the kind of small, opinionated decision that I want to write about, because it is a leading indicator of something bigger that is happening in open source. The decision is not about AI being bad. The decision is about a specific kind of contribution, and the cost of accepting that kind of contribution in a project of a particular size and culture.

What the clause actually says

The exact wording, from the project README, is:

AI-generated contributions are not accepted in this project. This includes code generated by large language models, code copied from AI assistants, and pull requests (proposed code changes submitted by an outside contributor) that are primarily the output of an AI tool. Maintainers may, at their sole discretion, reject any contribution that appears to be primarily AI-generated. The rationale is documented in CONTRIBUTING.md.

A more detailed rationale lives in CONTRIBUTING.md. The maintainer, who goes by DB48X, makes three arguments.

• Reviewability. AI-generated code is harder to review than human-written code, because the human who submitted it often does not fully understand it. The maintainer does not have time to review code that the contributor did not write and does not understand.
• Copyright uncertainty. The legal status of AI-generated code is unsettled. The project is licensed under a permissive open source license, which has specific requirements about the provenance (the chain of authorship) of the code. AI-generated code may not be licensable in the way the project requires.
• Project culture. The project is a hobby project maintained in the maintainer’s spare time. The maintainer wants to collaborate with humans who care about calculators, not with AI tools that can produce plausible-looking code without context.

The third argument is the one that generated the most discussion. The first two are largely accepted in the open source community. The third is the one that people are divided on.

Why this is a small-project decision, not a large-project decision

I want to be specific about the scale at which this decision makes sense. DB48X is a single-maintainer project. The repository has 1,800 stars on GitHub. The number of active contributors is fewer than 10. The maintainer reviews every pull request personally.

At that scale, the reviewability argument is real. A maintainer who reviews every pull request cannot afford to spend an hour debugging an AI-generated contribution that the submitter does not understand. The cost of a single bad pull request is hours, and the hours are not coming back.

At a larger scale, the math is different. The Linux kernel has thousands of contributors and a code review process that involves multiple maintainers per subsystem. The reviewability cost of an AI-generated contribution is amortized across the review team. The cost per reviewer is smaller. The total cost is the same, but the per-person cost is small enough to be absorbable.

The decision DB48X made is the right decision for a project of that size. It may not be the right decision for a project ten times larger. The right answer depends on the maintainer’s time, the project’s review process, and the community norms.

What the open source community is converging on

I have been watching the discussion across the open source ecosystem for about a year. The pattern I see is the following.

• Large projects with corporate backing are accepting AI-generated contributions with disclosure requirements. The Linux kernel, Kubernetes, and Python have all added contribution guidelines that require disclosure of AI tool usage. The guidelines are not bans. The guidelines are transparency requirements.
• Small projects with single maintainers are banning AI-generated contributions. The pattern I am writing about here. The reason is the reviewability argument above.
• Mid-sized projects are split. Some are following the corporate-backed pattern (disclosure). Some are following the small-project pattern (ban). The split is roughly correlated with whether the project is sponsored by a company that uses AI tools internally.

The split is not a problem. The split is a sign that the open source community is doing what it has always done, which is develop norms that fit the project. The norms are not uniform. The norms are not going to be uniform. The fact that different projects are making different decisions is a feature, not a bug.

What I would tell past me

If I could send a message back to the version of me that was thinking about adding an AI-generation clause to an open source project I maintain, I would say three things.

• Be specific about what you are banning. “AI-generated code” is too broad. The maintainer of DB48X was specific: code generated by an LLM, code copied from an AI assistant, pull requests that are primarily AI output. The specificity is what makes the clause enforceable.
• Document the rationale in the same place as the clause. A clause without a rationale reads as a personal preference. A clause with a rationale reads as a project decision. The maintainer of DB48X wrote the rationale in CONTRIBUTING.md, which is the file maintainers read before they submit a pull request. The placement matters.
• Decide based on your review capacity, not your opinion of AI. The reviewability argument is the argument that scales. The copyright argument is a real but separate issue. The “I do not want to collaborate with AI tools” argument is a personal preference that some readers will share and some will not. Lead with the reviewability argument, because it is the one that survives contact with people who disagree with the preference.
• State the clause in the README, not in a code-of-conduct file. A README is what every visitor sees first. A code-of-conduct is what only contributors see. Putting the AI ban in the README means users who might want to submit a patch know the policy before they put in the work. The maintainer of DB48X did this. It is a small choice. It saves everyone time.

Trade-offs

A ban on AI-generated contributions will lose the project some contributions. The contributors who would have submitted AI-generated code will move on to a project that accepts it. This is a real cost. The maintainer has decided that the cost of accepting the contributions is higher than the cost of losing them. The trade is legitimate.

Copyright concerns are real but unproven at this point. The legal status of AI-generated code is, in most jurisdictions, unclear. A project that accepts AI-generated code and licenses it under a permissive open source license may be exposing downstream users to legal risk. The risk is not large. The risk is not zero. The maintainer of DB48X has decided that the risk is not worth taking. The trade is legitimate.

Users of the project are unaffected by the ban. The ban is on contributions, not consumption. The project continues to ship, the firmware continues to work, and the users continue to use it. The only people affected are the people who would have submitted code. The trade is legitimate.

Bottom line

DB48X‘s contribution clause is a reasonable decision for a project of that size. The decision is not a referendum on AI in open source. The decision is a maintainer drawing a boundary on what kind of contributions the maintainer has the time to review. If you maintain a small open source project, the decision is one you should consider. If you maintain a large one, the decision is probably not the right fit. The right answer depends on the project.