Hong Minhee on Things

Is legal the same as legitimate: AI reimplementation and the erosion of copyleft

2026-03-09T15:10:00.000Z

Is legal the same as legitimate: AI reimplementation and the erosion of copyleft

Last week, Dan Blanchard, the maintainer of chardet—a Python library for detecting text encodings used by roughly 130 million projects a month—released a new version. Version 7.0 is 48 times faster than its predecessor, supports multiple cores, and was redesigned from the ground up. Anthropic's Claude is listed as a contributor. The license changed from LGPL to MIT.

Blanchard's account is that he never looked at the existing source code directly. He fed only the API and the test suite to Claude and asked it to reimplement the library from scratch. The resulting code shares less than 1.3% similarity with any prior version, as measured by JPlag. His conclusion: this is an independent new work, and he is under no obligation to carry forward the LGPL. Mark Pilgrim, the library's original author, opened a GitHub issue to object. The LGPL requires that modifications be distributed under the same license, and a reimplementation produced with ample exposure to the original codebase cannot, in Pilgrim's view, pass as a clean-room effort.

The dispute drew responses from two prominent figures in the open source world. Armin Ronacher, the creator of Flask, welcomed the relicensing. Salvatore Sanfilippo (antirez), the creator of Redis, published a broader defense of AI reimplementation, grounding it in copyright law and the history of the GNU project. Both conclude, by different routes, that what Blanchard did is legitimate. I respect both writers, and I think both are wrong—or more precisely, both are evading the question that actually matters.

That question is this: does legal mean legitimate? Neither piece answers it. Both move from “this is legally permissible” to “this is therefore fine,” without pausing at the gap between those two claims. Law sets a floor; clearing it does not mean the conduct is right. That gap is where this essay begins.

The analogy points the wrong way

Antirez builds his case on history. When the GNU project reimplemented the UNIX userspace, it was lawful. So was Linux. Copyright law prohibits copying “protected expressions”—the actual code, its structure, its specific mechanisms—but it does not protect ideas or behavior. AI-assisted reimplementation occupies the same legal ground. Therefore, it is lawful.

The legal analysis is largely correct, and I am not disputing it. The problem lies in what antirez does next: he presents the legal conclusion as if it were also a social one, and uses a historical analogy that, examined more carefully, argues against his own position.

When GNU reimplemented the UNIX userspace, the vector ran from proprietary to free. Stallman was using the limits of copyright law to turn proprietary software into free software. The ethical force of that project did not come from its legal permissibility—it came from the direction it was moving, from the fact that it was expanding the commons. That is why people cheered.

The vector in the chardet case runs the other way. Software protected by a copyleft license—one that guarantees users the right to study, modify, and redistribute derivative works under the same terms—has been reimplemented under a permissive license that carries no such guarantee. This is not a reimplementation that expands the commons. It is one that removes the fencing that protected the commons. Derivative works built on chardet 7.0 are under no obligation to share their source code. That obligation, which applied to a library downloaded 130 million times a month, is now gone.

Antirez does not address this directional difference. He invokes the GNU precedent, but that precedent is a counterexample to his conclusion, not a supporting one.

Does the GPL work against sharing?

Ronacher's argument is different. He discloses upfront that he has a stake in the outcome: “I personally have a horse in the race here because I too wanted chardet to be under a non-GPL license for many years. So consider me a very biased person in that regard.” He goes on to write that he considers “the GPL to run against that spirit by restricting what can be done with it”—the spirit being that society is better off when we share.

This claim rests on a fundamental misreading of what the GPL does.

Start with what the GPL actually prohibits. It does not prohibit keeping source code private. It imposes no constraint on privately modifying GPL software and using it yourself. The GPL's conditions are triggered only by distribution. If you distribute modified code, or offer it as a networked service, you must make the source available under the same terms. This is not a restriction on sharing. It is a condition placed on sharing: if you share, you must share in kind.

The requirement that improvements be returned to the commons is not a mechanism that suppresses sharing. It is a mechanism that makes sharing recursive and self-reinforcing. The claim that imposing contribution obligations on users of a commons undermines sharing culture does not hold together logically.

The contrast with the MIT license clarifies the point. Under MIT, anyone may take code, improve it, and close it off into a proprietary product. You can receive from the commons without giving back. If Ronacher calls this structure “more share-friendly,” he is using a concept of sharing with a specific directionality built in: sharing flows toward whoever has more capital and more engineers to take advantage of it.

The historical record bears this out. In the 1990s, companies routinely absorbed GPL code into proprietary products—not because they had chosen permissive licenses, but because copyleft enforcement was slack. The strengthening of copyleft mechanisms closed that gap. For individual developers and small projects without the resources to compete on anything but reciprocity, copyleft was what made the exchange approximately fair.

The creator of Flask knows this distinction. If he elides it anyway, the argument is not naïve—it is convenient.

A self-refuting example

The most interesting moment in Ronacher's piece is not the argument but a detail he mentions in passing: Vercel reimplemented GNU Bash using AI and published it, then got visibly upset when Cloudflare reimplemented Next.js the same way.

Ronacher notes this as an irony and moves on. But the irony cuts deeper than he lets on. Next.js is MIT licensed. Cloudflare's vinext did not violate any license—it did exactly what Ronacher calls a contribution to the culture of openness, applied to a permissively licensed codebase. Vercel's reaction had nothing to do with license infringement; it was purely competitive and territorial. The implicit position is: reimplementing GPL software as MIT is a victory for sharing, but having our own MIT software reimplemented by a competitor is cause for outrage. This is what the claim that permissive licensing is “more share-friendly” than copyleft looks like in practice. The spirit of sharing, it turns out, runs in one direction only: outward from oneself.

Ronacher registers the contradiction and does not stop. “This development plays into my worldview,” he writes. When you present evidence that cuts against your own position, acknowledge it, and then proceed to your original conclusion unchanged, that is a signal that the conclusion preceded the argument.

Legality and social legitimacy are different registers

Back to the question posed at the start. Is legal the same as legitimate?

Antirez closes his careful legal analysis as though it settles the matter. Ronacher acknowledges that “there is an obvious moral question here, but that isn't necessarily what I'm interested in.” Both pieces treat legal permissibility as a proxy for social legitimacy. But law only says what conduct it will not prevent—it does not certify that conduct as right. Aggressive tax minimization that never crosses into illegality may still be widely regarded as antisocial. A pharmaceutical company that legally acquires a patent on a long-generic drug and raises the price a hundredfold has not something legal, but that does not make it fine. Legality is a necessary condition; it is not a sufficient one.

In the chardet case, the distinction is sharper still. What the LGPL protected was not Blanchard's labor alone. It was a social compact agreed to by everyone who contributed to the library over twelve years. The terms of that compact were: if you take this and build on it, you share back under the same terms. This compact operated as a legal instrument, yes, but it was also the foundation of trust that made contribution rational. The fact that a reimplementation may qualify legally as a new work, and the fact that it breaks faith with the original contributors, are separate questions. If a court eventually rules in Blanchard's favor, that ruling will tell us what the law permits. It will not tell us that the act was right.

Zoë Kooyman, executive director of the FSF, put it plainly: “Refusing to grant others the rights you yourself received as a user is highly antisocial, no matter what method you use.”

Whose perspective is the default?

Reading this debate, I keep returning to a question about position. From where are these two writers looking at the situation?

Antirez created Redis. Ronacher created Flask. Both are figures at the center of the open source ecosystem, with large audiences and well-established reputations. For them, falling costs of AI reimplementation means something specific: it is easier to reimplement things they want in a different form. Ronacher says explicitly that he had begun reimplementing GNU Readline precisely because of its copyleft terms.

For the people who have spent years contributing to a library like chardet, the same shift in costs means something else entirely: the copyleft protection around their contributions can be removed. The two writers are speaking from the former position to people in the latter, telling them that this was always lawful, that historical precedent supports it, and that the appropriate response is adaptation.

When positional asymmetry of this kind is ignored, and the argument is presented as universal analysis, what you get is not analysis but rationalization. Both writers arrive at conclusions that align precisely with their own interests. Readers should hold that fact in mind.

What this fight points toward

Bruce Perens, who wrote the original Open Source Definition, told The Register: “The entire economics of software development are dead, gone, over, kaput!” He meant it as an alarm. Antirez, from a similar assessment of the situation, draws the conclusion: adapt. Ronacher says he finds the direction exciting.

None of the three responses addresses the central question. When copyleft becomes technically easier to circumvent, does that make it less necessary, or more?

I think more. What the GPL protected was not the scarcity of code but the freedom of users. The fact that producing code has become cheaper does not make it acceptable to use that code as a vehicle for eroding freedom. If anything, as the friction of reimplementation disappears, so does the friction of stripping copyleft from anything left exposed. The erosion of enforcement capacity is a legal problem. It does not touch the underlying normative judgment.

That judgment is this: those who take from the commons owe something back to the commons. The principle does not change depending on whether a reimplementation takes five years or five days. No court ruling on AI-generated code will alter its social weight.

This is where law and community norms diverge. Law is made slowly, after the fact, reflecting existing power arrangements. The norms that open source communities built over decades did not wait for court approval. People chose the GPL when the law offered them no guarantee of its enforcement, because it expressed the values of the communities they wanted to belong to. Those values do not expire when the law changes.

In previous writing, I argued for a training copyleft (TGPL) as the next step in this line of development. The chardet situation suggests the argument has to go further: to a specification copyleft covering the layer below source code. If source code can now be generated from a specification, the specification is where the essential intellectual content of a GPL project resides. Blanchard's own claim—that he worked only from the test suite and API without reading the source—is, paradoxically, an argument for protecting that test suite and API specification under copyleft terms.

The history of the GPL is the history of licensing tools evolving in response to new forms of exploitation: GPLv2 to GPLv3, then AGPL. What drove each evolution was not a court ruling but a community reaching a value judgment first and then seeking legal instruments to express it. The same sequence is available now. Whatever courts eventually decide about AI reimplementation, the question we need to answer first is not a legal one. It is a social one. Do those who take from the commons owe something back? I think they do. That judgment does not require a verdict.

What makes the pieces by antirez and Ronacher worth reading is not that they are right. It is that they make visible, with unusual clarity, what they are choosing not to see. When legality is used as a substitute for a value judgment, the question that actually matters gets buried in the footnotes of a law it has already outgrown.

Why craft-lovers are losing their craft

2026-03-21T09:30:00.000Z

Why craft-lovers are losing their craft

Les Orchard made a quiet observation recently that I haven't been able to shake. Before LLM coding assistants arrived, the split between developers was invisible:

Craft-lovers and make-it-go people sat next to each other, shipped the same products, looked indistinguishable. The motivation behind the work was invisible because the process was identical.

The tools didn't create a division; they simply revealed an existing one.

Orchard himself belongs to the first camp. He learned BASIC at age seven not because BASIC was beautiful but because he wanted things to happen on screen. For him, LLM coding assistants are just another rung on the same ladder he's always been climbing. The puzzle didn't disappear; it moved to a higher level of abstraction. He grieves, but what he grieves is the ecosystem around the work, not the work itself.

Nolan Lawson grieves differently:

We'll miss the feeling of holding code in our hands and molding it like clay in the caress of a master sculptor. We'll miss the sleepless wrangling of some odd bug that eventually relents to the debugger at 2 AM. We'll miss creating something we feel proud of, something true and right and good.

His post reads like an elegy, and the grief in it is real. What he's mourning is the act itself.

Two developers, both thoughtful, both honest, looking at the same moment and feeling different things. That asymmetry is worth taking seriously, because it points to something the “just adapt” conversation keeps missing.

Alienated from the act

Marx identified four dimensions of alienated labor: separation from the product of one's work, from the act of working itself, from other people, and from one's own human capacities. In the context of LLM coding assistants, the second of these is doing most of the work.

What Marx meant by separation from the act is something like this. Humans, unlike other animals, can imagine what they want to make before they make it and then shape the material world to match that image. This capacity for conscious, intentional creation is close to what Marx considered distinctively human. When work is reduced to something mechanical, coerced, endured rather than inhabited, that capacity goes unused. The activity is still happening; the person is just no longer really present in it.

The craft-lovers mourning their work fit this description. What they valued wasn't the output. It was the process of building something, the hours of close attention, the feeling of understanding a system well enough to reshape it. Lawson says as much: the GitHub repo that says “I made this.” Not “something was made” but I made it.

This also explains why the two camps feel so differently about the same tools. Orchard never invested his sense of self in the act of writing code. He invested it in the result. When LLM coding assistants let him get to the result faster, nothing essential is lost for him. For Lawson, the act was where the meaning lived. LLM coding assistants don't bypass the output; they bypass the part he cared about. Marx's distinction between objective alienation (a condition that exists regardless of whether you feel it) and subjective alienation (experiencing the loss) maps almost exactly onto this split. Orchard isn't subjectively alienated because he was never objectively attached to the act in the first place. Lawson is both.

The usual response is that this is nostalgia, or that new crafts will emerge to replace the old ones. Maybe. But that response sidesteps the actual question: why are people who love coding being pushed away from coding? Nobody is stopping them from writing code by hand. The market is penalizing them for it.

Who's doing the penalizing

In Capital, Marx wrote about the Luddite movement:

It took time and experience before the workers learnt to distinguish between machinery and its employment by capital, and to transfer their attacks from the material instruments of production to the form of society which utilises those instruments.

The workers who destroyed the looms weren't wrong to be angry. The direction was off. Capital extended working hours, not the loom. Capital turned workers into appendages of the machine, not the loom. The distinction matters because it changes what the actual problem is, and therefore what might be done about it.

When a developer explains that their productivity is being measured against colleagues who use LLM coding assistants, and that they're using them because they need the job, not because they want to, the source of alienation is plain. It isn't the LLM coding assistant. It's the structure that ties livelihood to a metric, and that metric now favors whoever produces the most output the fastest. The LLM coding assistant is the lever; the market is the mechanism.

One caveat matters here. The tension between craft and efficiency doesn't disappear if you remove capitalism from the picture. LLM coding assistants produce faster results whether anyone is being paid or not, and any community, however it's organized, will eventually have to reckon with what to do with that speed difference. Capitalism gives the harshest possible answer to that question: the slower worker loses their livelihood. But the question itself would survive capitalism. Other forms of social organization might answer it more gently, but they'd still have to answer it.

What my situation reveals

I maintain open source software full time. My income comes entirely from public funding: grants, foundations, institutional support. I have no employer who can tell me to use LLM coding assistants or lose my job. No quarterly review where my output gets compared to a colleague's.

Under these conditions, my relationship with LLM coding assistants is nothing like what Lawson describes. I still write the code I find interesting by hand. The parts I don't want to do, the verbose test scaffolding and boilerplate I've written a hundred times, I hand to the model. The division follows a line I drew myself, between work that expresses something and work that just needs to happen.

This is close to what Marx imagined machinery could do in conditions other than capitalism: relieve people of repetitive labor so they could do something more fully human with the time. The same tool can feel liberating in one set of conditions and alienating in another.

My situation is unusual, and it exists inside a capitalist economy, a partial shelter rather than an escape. I'm not presenting it as a solution, only as evidence of that difference.

Where the grief should look

Knowing the source of a problem doesn't dissolve it. The developers being pushed toward LLM coding assistants they don't want to use are facing a real constraint right now, and a structural analysis doesn't help them this afternoon.

But it does change the question. If the grief Lawson describes is real (and I think it is), and if its deeper cause lies in the social relations around the technology rather than the technology itself, then the right target for that grief isn't the LLM coding assistant. It's whatever forces people to use tools they don't want to use, on terms they didn't choose.

Lawson gestures in this direction too:

I don't celebrate the new world, but I also don't resist it. The sun rises, the sun sets, I orbit helplessly around it, and my protests can't stop it.

That's honest. But I'd like to think resignation isn't the only option.

Acting materialistically in an imperfect world: LLMs as means of production and social relations

2026-02-21T21:40:00.000Z

Acting materialistically in an imperfect world: LLMs as means of production and social relations

This is a follow-up to last month's Histomat of F/OSS: We should reclaim LLMs, not reject them.

Cory Doctorow celebrated the sixth anniversary of Pluralistic by walking readers through his publishing workflow. Among other things, he mentioned running each post through Ollama, an open-source LLM, to catch typos before publication. People reacted exactly as you would expect. Two days later, German technology critic tante responded with a piece titled Acting ethically in an imperfect world.

His title was too good not to borrow. Acting ethically in an imperfect world: that is his question. I want to answer the same question on different ground. Not ethics, but materialism.

In my previous piece, I pushed licensing too far to the front as a means of reclaiming LLMs. I was called naïve, and I accept part of that criticism. I was trying to point to a direction, not lay down a program. Here I want to state that more plainly.

Two strawmen

tante makes some fair points. Doctorow portrayed LLM critics as purists who object to the technology because its creators are bad people—a strawman. The actual criticisms come from somewhere else: the enormous consumption of electricity and water, the collection of training data without consent, the exploitative labeling work done in the Global South, the harm inflicted on the knowledge commons including the open source ecosystem. Doctorow reduced all of this to “you just don't like Sam Altman,” and tante was right to call that out.

The Bluesky point lands too. Doctorow refused to create a Bluesky account on ideological grounds, because he objects to the centralized control Bluesky's corporation holds over the network. He believes in refusing technology based on one's values, and he practices it. When others refuse LLMs for the same kind of reason, he calls it purism. tante identified this double standard precisely.

But tante falls into the same trap.

In critiquing the direction of reclamation, he effectively limits it to one path: building a frontier model from scratch that rivals GPT. That would take billions of dollars and produce the same environmental costs, so reclamation is unrealistic, or so the argument goes. But just as Doctorow oversimplified the criticism of LLMs, tante oversimplified the paths to reclaiming them. There is legal resistance through licensing, regulatory pressure that might compel corporations to release proprietary models, the slower work of building public foundation models. Which of these can actually work depends on political and social conditions that haven't settled yet. When I mentioned licensing in my previous piece, it was the first example that came to mind, nothing more.

Machinery and its capitalist application

In the first volume of Capital, Marx assessed the Luddite movement in England:

It took time and experience before the workers learnt to distinguish between machinery and its employment by capital, and to transfer their attacks from the material instruments of production to the form of society which utilises those instruments.

The anger of the workers who smashed the looms was justified. The direction was wrong. The problem was not the machinery but the capitalist social relations surrounding it: machinery that extended working hours rather than shortening them, that turned workers into appendages rather than freeing them. That was not the nature of machinery; it was the nature of how it was deployed. Marx was not mocking the Luddites. He was describing how a struggle matures.

tante's approach is fundamentally ethical: he evaluates LLMs on moral grounds and decides whether to use them accordingly. Doctorow's approach is not so different; the evaluation just runs in the opposite direction. Both treat technology as a moral object.

A materialist approach asks different questions. What social relations does this technology sit inside? Who owns it, whose labor maintains it, where does the surplus go—and can those relations be changed?

The “for or against AI” framing buries all of this. The reason it looks inconsistent to criticize the major AI vendors while remaining open to LLMs as a technology is that the framing assumes the technology and its capitalist application are the same thing. That assumption is wrong.

Libraries and people

LLMs are not libraries. The criticism that a library connects people to the original source while an LLM produces answers without one is not entirely wrong. But I think LLMs are closer to people.

Human beings spend their entire lives absorbing text, code, and images, without asking permission from the copyright holders. They work that material into something of their own and produce, at times, something that is little more than pastiche and, at other times, connections nobody had made before.

Nicholas Carlini at Anthropic recently ran an experiment in which he tasked Claude Opus 4.6 with writing a C compiler in Rust from scratch, without internet access, in a clean-room setting. The result was a hundred-thousand-line compiler that builds the Linux 6.9 kernel on x86, ARM, and RISC-V; compiles PostgreSQL, FFmpeg, SQLite, and Redis; and passes 99% of the GCC torture test suite. To my knowledge, no Rust-written C compiler has come close to that. It is hard to call this reproduction.

That does not make them artists. It does mean the line that they “only reproduce” is less solid than critics pretend.

Not all generative AI is alike, and the difference is not purely technical. It is a difference in what kind of labor is displaced and how. When an image generation model produces work in the style of a specific artist, it directly encroaches on that artist's market. What gets displaced there is not some abstract function but a working artist trying to stay alive. Where the surplus goes in that transaction is telling. Marx's Verelendung of labor is more directly at work in image generation than in LLMs. Whether the same measure applies to LLMs is a much more complicated question.

The default viewpoint

One more thing, and it is personal.

tante's essay is on the web, but it appears to be configured to serve garbage to LLM scrapers. Korean is my first language; English is my second. A text like tante's, where the nuances of the argument and its unstated premises matter, does not survive conventional machine translation intact. You need something at the level of an LLM for the reasoning to come through. I ended up copying the essay by hand and feeding it to one.

tante argues that LLMs sever the connection between reader and author: search engines lead you to the original, while LLMs extract the content and keep you inside their own loop. There is something to that. But my experience shows whose perspective shaped that picture. If you already read English fluently, an LLM can look like a machine for cutting readers off from authors. If you do not, it can be the thing that lets the argument reach you at all. tante's decision to block LLM scrapers is consistent with his own logic, but it ended up reinforcing the asymmetry between readers who are fluent in English and those who are not.

That is not a side irony. It is the ordinary structure of technology discourse. Whose viewpoint is set as the default? What social relations produced that default?

The first question is not whether the technology is pure. It is who it serves, who labors under it, and who gets shut out. Once you ask that, “reject or accept” stops being the point. The point is whether these systems remain capital's property or become something else. I still think that is where we need to go.

Histomat of F/OSS: We should reclaim LLMs, not reject them

2026-01-16T06:00:00.000Z

Histomat of F/OSS: We should reclaim LLMs, not reject them

A few days ago I read a blog post titled On FLOSS and training LLMs. It captures well the frustration spreading through the free and open source software community. AI companies show no real respect for F/OSS developers; they exploit open source licensing's idealistic principles, and the law offers little protection against having our work scraped as training data for proprietary language models. I nodded along through most of it.

But I fundamentally disagree with the conclusion.

The proposed solution is denial and isolation: block the crawlers, withdraw from centralized forges like GitHub, make our work inaccessible to AI scrapers, shun those who use these “anti-ethical tools” from our communities. I understand the anger behind it. But I think it misses something important and misreads the historical pattern that has shaped FLOSS itself.

Where we agree

The author is right about much of this. The current situation is bad. AI companies have shown genuine disrespect for the sources of their training data. The phrase “I'm legally allowed to do so, so I will” captures the contempt these corporations show toward individual developers and communities. Their aggressive crawling amounts to a distributed denial of service attack; they ignore creators' explicit wishes and offer no working opt-out mechanism.

The legal battle is likely unwinnable, too. F/OSS licenses permit use for any purpose without discrimination. The Open Source Definition's sixth principle explicitly prohibits restrictions on fields of endeavor. Major licenses like GPL require attribution and have provisions about derived works, but any competent lawyer could argue that LLM training doesn't constitute creating a derived work in the traditional sense, and that statistical pattern extraction doesn't require attribution in the way code reuse does.

The law is inadequate. It was written for a different era, one where “use” meant running software, modifying it, or redistributing it, not feeding it into neural networks to extract patterns. The law serves power, and in this case, power resides with the corporations that can afford legal teams to navigate and exploit these ambiguities.

Where we diverge

My answer is different: not rejection, but reclamation.

The author frames this as a battle between respecting developers and allowing AI training. There's a third way, one more consistent with F/OSS history and more likely to produce a future we'd actually want. Instead of trying to prevent LLM training on our code, we should demand that the models themselves be freed.

I want my code to be used for LLM training. What I don't want is for that training to produce proprietary models that become the exclusive property of AI corporations. The problem isn't the technology or even the training process itself. The problem is the enclosure of the commons, the privatization of collective knowledge, the one-way flow of value from the many to the few.

This isn't a new problem. It's the same problem FLOSS has always fought, just wearing new clothes.

On accepting reality

Different views on LLMs often come down to different readings of reality itself.

Salvatore Sanfilippo (antirez), the creator of Redis, recently wrote about his experience with AI coding tools. He's someone who values hand-crafted code deeply, and like many of us cares about the human touch in software. Yet he writes: “It is simply impossible not to see the reality of what is happening. Writing code is no longer needed for the most part… Programming changed forever, anyway.”

His conclusion: adapt. Learn to use these tools. Don't fall into “anti-AI hype.” He sees LLMs as democratizing technology, much like open source did in the 90s, enabling small teams to compete with large companies.

I agree with most of antirez's reading of reality. LLMs have fundamentally changed programming, and we can't go back. The author of the original post seems to operate from a different one: resistance is still meaningful, withdrawal can be effective, we can meaningfully reduce LLMs' access to training data. I'm skeptical. OpenAI and Anthropic have already scraped what they need. GitHub already has everyone's code. The training data exists.

That's where I part ways with antirez's optimism. He worries about centralization but seems to trust that market competition, including open models from China, will solve it. He focuses on how developers can adapt and use these tools. That matters, but it sidesteps a deeper question: under what terms does this transformation happen?

The question isn't whether to use LLMs or adapt to them; that ship has sailed. The question is who owns the models. Who benefits from the commons that trained them? If millions of F/OSS developers contributed their code to the public domain, should the resulting models be proprietary? This isn't just about centralization or market dynamics. It's about whether the fruits of collective labor remain collective, or become private property.

The materialist reading

The history of free and open source software, read through a materialist lens, shows a clear pattern: technological change creates new forms of exploitation, which force new forms of licensing to protect the commons.

The trajectory:

GPLv2 (1991) addressed the problem of binary distribution. Companies were taking GPL code, compiling it, and distributing only the binaries, effectively creating proprietary software from free code. The solution was copyleft: if you distribute the software, you must provide the source code.

GPLv3 (2007) addressed Tivoization. Companies like TiVo were technically providing source code but using hardware locks to prevent users from actually running modified versions. The solution was to require not just source code but installation information, ensuring users retained their freedom to modify.

AGPL (2007) addressed the SaaS loophole. Companies realized they didn't need to distribute software at all; they could simply run it as a service and never trigger GPL's distribution requirements. The solution was to treat network interaction as equivalent to distribution.

Each step followed the same pattern: new technology revealed a gap in existing licenses, corporations exploited that gap, and the community responded with evolved licensing that closed it. This isn't idealism meeting reality and failing; this is dialectical development, the ongoing process of refining our tools to match changing material conditions.

Now we face a new gap: the training loophole. Companies can use F/OSS code as training data for proprietary models without any obligation to release those models or even acknowledge the sources of their training. This is exploitation in the classic sense: value extraction without reciprocation.

The materialist response isn't to reject the new technology. It's to evolve our licenses to encompass it.

What a training copyleft might look like

I envision something like a GPLv4 or TGPL (Training GPL) that would include provisions such as:

Training is explicitly permitted. This code may be used as training data for machine learning models. This aligns with F/OSS principles of freedom and avoids discriminating against fields of endeavor.

But the resulting models must be freed. Any model trained on this code must have its weights released under a compatible copyleft license. Just as GPLv3 requires source code for binaries, a training copyleft would require model weights for trained systems.

Training data must be documented. Just as we expect documentation of dependencies, we should expect clear accounting of what data was used for training.

Fine-tuned models inherit the obligation. If you fine-tune a copyleft model, your derived model must also be freed. This prevents the “just barely modify and claim it's new” dodge.

Network use triggers obligations. Following AGPL's lead, providing a model through an API would be considered distribution, requiring weight release.

Technical challenges and precedents

Would this be technically feasible? Could it be enforced? Fair questions, but not new ones. They were asked at every previous GPL evolution.

How do you prove a binary was compiled from your source code? How do you prove hardware locks prevent modification? How do you prove a service is running your code? In each case, the answer has been a combination of technical evidence, community vigilance, and occasional legal action. Perfect enforcement is impossible, but that doesn't mean the license is worthless. GPL violations happen, but GPL also works; it has created and protected a massive commons.

The question of proving that specific code was used in training is admittedly harder than proving source code was used in a binary. But it's not insurmountable. Training datasets can be documented, model genealogies tracked, and statistical analysis can sometimes identify training sources. The mere existence of the license also creates social and legal pressure toward compliance.

There are also questions about mixed training sets. What happens when you train on both TGPL and non-TGPL code? This is analogous to questions about linking GPL and non-GPL code, worked out through years of community practice and occasional court cases. The details matter, but the principle is sound.

Why this matters more than withdrawal

The strategy of withdrawal has its appeal. There's satisfaction in saying “you don't respect us, so you can't have our work.” But it misses the larger picture.

It concedes the field. If F/OSS developers withdraw their code from public accessibility, we're not preventing AI training; we're just preventing open source AI training. OpenAI and Anthropic have already scraped everything they need; they have massive datasets. What withdrawal actually prevents is projects like Llama and Mistral from having access to quality training data.

It also mistakes the problem. LLMs aren't inherently exploitative any more than compilers or web servers are. They're tools, and like all tools under capitalism, they can concentrate power or distribute it. Focusing on denial rather than conditions of use means treating the symptom rather than the disease.

Then there's the purity problem. The author calls for shunning people who use “anti-ethical tools,” making them feel unwelcome. But where is the line? What if someone uses GitHub Copilot to write a contribution to a F/OSS project? What if they use ChatGPT to debug their code? Who decides? This kind of purity testing has historically been better at splintering movements than at achieving their goals.

The deepest problem is that withdrawal abandons the fundamental F/OSS strategy that has actually worked: ensuring freedom through licensing conditions, not access control. GPL's genius wasn't that it prevented anyone from using the code; it was that it guaranteed everyone's freedom by requiring that freedom be passed along. Withdrawal is the opposite philosophy.

The future we should build

I want to live in a future where powerful AI models exist and are accessible to everyone, not just to corporations that can afford to train them. A world where the knowledge encoded in millions of F/OSS projects becomes part of a commons rather than privatized into proprietary models; where if my code helps train a model, that model is available for me and everyone else to use, study, modify, and share.

This future doesn't come from withdrawal. It comes from engagement, from building the open source AI ecosystem we actually want. The strategy is the same one that built GNU/Linux and gave us the web as we know it.

The author writes that respect is earned, not given, and that those who disrespect us should be treated in kind. I agree with the principle, but apply it differently. The disrespect isn't in the training itself; it's in the enclosure, in the refusal to share back. Refusing to share in turn is a race to the bottom. The right response is to demand reciprocity, to insist on the same freedoms we've always insisted upon.

When Linus Torvalds released Linux under GPL rather than keeping it proprietary, he didn't say “corporations can't use this.” He said “anyone can use this, but if you improve it, you must share those improvements.” That condition, that requirement of reciprocity, built an ecosystem spanning volunteer developers and massive corporations alike, powering everything from smartphones to supercomputers, demonstrating what commons-based production can actually do.

The same principle applies to the AI era. Not “you can't train on our code,” but “if you train on our code, you must free your models.” Terms of engagement, not withdrawal.

A historical opportunity

The materialist view of history isn't about inevitability; it's about recognizing patterns and acting on them. Each major shift in F/OSS licensing went through the same rough cycle: someone identified the problem, the community argued about it, lawyers got creative, adoption was slow, then suddenly it wasn't. With respect to LLMs, we're at the beginning of that cycle now.

The conversation about what norms should govern AI training and model release is happening right now, while things are still in flux. Open source AI models are proliferating, and what licensing frameworks should apply to them remains genuinely unsettled.

If F/OSS developers withdraw from this conversation and focus solely on denial, we'll wake up in five years to find the norms set by corporations and corporate-friendly courts. The training loophole will be firmly established, and open source AI will be permanently disadvantaged relative to proprietary alternatives.

If we engage, push for training copyleft, and start releasing code under licenses that require model freedom, we can shape that future. It won't be easy. Legal work, community organizing, and probably some court cases will be needed. It took years for GPL to be tested and validated. But it worked, and there's no reason training copyleft couldn't work too.

Conclusion

I respect the anger and frustration expressed in On FLOSS and training LLMs. The author is right that current AI companies are behaving badly, that they're exploiting our work, that the law is inadequate. Where I differ is on the response. The situation calls for evolution, not rejection; for engagement on better terms, not withdrawal.

The question isn't whether LLM training on F/OSS code is ethical in some abstract sense. The question is: under what conditions is it ethical? The answer, I think, is the same one F/OSS has always given: when the freedoms we grant are preserved and passed on, when improvements return to the commons, when knowledge stays free.

Block crawlers, and you've changed nothing; change the rules they crawl under, and you might. Withdraw from GitHub, and open source AI loses training data while proprietary labs lose nothing; demand that GitHub's training respect copyleft, and you've shifted the terms. The tools already exist for this kind of pressure. We built them once before.

Historical materialism says that new forces of production require new relations of production. LLMs are a new force of production; training copyleft would be the relation of production that brings them into alignment with F/OSS values.

The code I write, I write to be free. I want it to remain free even when it passes through neural networks and emerges as model weights. That's not naïve idealism; it's the same principle that's guided F/OSS for decades. We've protected software freedom through multiple technological transitions, and we can do it again.

We should reclaim LLMs, not reject them. The alternative is to watch from the sidelines as our commons becomes their private gardens. I would rather fight for a future where AI models, like the code they train on, belong to everyone.

Why I don't destroy snowmen

2026-01-20T04:15:00.000Z

Why I don't destroy snowmen

In winter, I sometimes come across stories on X about men who deliberately kick over snowmen as they walk by. It's not like destroying a snowman causes real harm to anyone. But there's something visible in that act—a certain ethical disposition either lacking or being formed.

For the same reason, I don't speak to LLMs dismissively, and I avoid barking commands at them. I know LLMs don't get hurt or offended by my tone. But what matters isn't the LLM's response—it's what kind of person I'm becoming. Think about someone who throws and hits stuffed animals. The stuffed animal doesn't feel pain, but the person doing it repeatedly becomes that kind of person, bit by bit.

In this vein, I'm uncomfortable with language that evokes slavery when talking about AI or LLMs. Expressions like “whipping the LLM” get used in tech communities as a kind of joke, and beneath that lies an attitude that treats the historical violence of slavery as a lightweight metaphor. Of course LLMs aren't actually slaves. (Or are they?) But the moment we feel comfortable using slavery as a casual comparison, we lose our sensitivity to the actual violence it refers to.

What we do and how we speak ultimately shapes who we are. How we act toward something that doesn't respond, when no one is watching, might reveal us more purely than anything else. Whether it's snowmen, LLMs, or the language we use—all of it shapes us.

That's why I don't destroy snowmen. I use respectful language with LLMs. I don't turn slavery into material for jokes. I believe these small choices make me who I am.

My 2025 with the fediverse

2025-12-09T15:00:00.000Z

My 2025 with the fediverse

Last year, I wrote an article titled A year with the fediverse, and this year I find myself writing on a similar theme again. Since I've started working full-time on open source software related to the fediverse,¹ I have a feeling I'll be writing articles like this every year as long as I continue this work.

Thinking Penguin Magazine Vol.0

I had the opportunity to contribute to Thinking Penguin Magazine Vol.0, the first doujinshi published by FediLUG, a gathering of fediverse developers in Japan. My article was titled From mixed script Korean to Hollo (国漢文混用体からHolloまで), covering how I came to create Fedify² and Hollo³. This magazine was also exhibited at the 11th Gishohaku (Technical Book Doujinshi Fair). Although I couldn't attend in person due to time constraints, just being part of the exhibition was a valuable experience.

BotKit

Early this year, I created BotKit, an ActivityPub bot framework built on top of Fedify. I believe I initially wanted to create some kind of fediverse bot account, but I honestly can't remember what it was anymore.

In any case, BotKit was born out of frustration with the limitations of creating an account on an ActivityPub server like Mastodon or Misskey and using their respective APIs to post. Instead, BotKit apps function as their own ActivityPub servers. This architecture provides freedom from various constraints like maximum character limits and rate limits.

After releasing it, several fediverse bots have been created using BotKit, though admittedly it's not widely used yet.

Hackers' Pub

I created Hackers' Pub, an invite-only ActivityPub-based community for software developers, late last year. This year, it gained a lot of traction, and I got to interact with a truly diverse group of software developers. In particular, Lee Jae-yeol enthusiastically promoted Hackers' Pub, which brought many people to the community.

In the summer, I commissioned designer Bak Eunji to create Hackers' Pub's visual identity, and we ended up with an adorable cat logo. Fortunately, people on Hackers' Pub loved this cat, and it even earned the nickname Pub Kitty (펍냥이). We also made T-shirts and stickers featuring Pub Kitty, and the response was great.

If you're reading this and are interested in Hackers' Pub, feel free to contact me personally and I can send you an invitation.

Software Sessions appearance

This spring, I had the opportunity to appear on Software Sessions, an internet radio show hosted by Jeremy Jung, to talk about ActivityPub and Fedify: Hong Minhee on ActivityPub. However, since it was conducted in English, I was quite nervous and rambled a lot, which I still regret. I thought I should practice English conversation more. (But as always, I only thought about it and never actually followed through…)

Finding Our Code appearance

For the first time in my life, I also appeared on YouTube. I was featured on the Finding Our Code (우리의 코드를 찾아서) series on Park Hyunwoo's One Day Dev channel, in an episode titled Exploring Fedify & Hollo with Minhee (民憙 님과 Fedify & Hollo 알아보기). I was able to share the behind-the-scenes story of how I came to create Fedify and Hollo in a relaxed atmosphere.

Open Source Software Contribution Academy (OSSCA)

Fedify was selected as a participating project for the 2025 Open Source Software Contribution Academy (OSSCA), hosted by the Open Source Software Integration Support Center (Open UP) under Korea's National IT Industry Promotion Agency (NIPA). This gave me the opportunity to connect with many excellent contributors. Over 90 people applied, and I was able to work on the Fedify project with about 20 of them.

In fact, Fedify 1.8 and Fedify 1.9 couldn't have been released without the contributions of the people I met through OSSCA.

In particular, ChanHaeng Lee, Hyeonseo Kim, Jiwon Kwon, and Lee Jae-yeol⁴ have continued to contribute to Fedify even after the OSSCA period ended, which is incredibly reassuring. Thanks to this connection, we all traveled to Fukuoka together in November.

Fedify investment

Last summer, after receiving funding from Ghost, I was able to work full-time on the Fedify project for a while. However, that ended in the first quarter of this year, leaving me back at square one. To find new funding sources, I applied to NLnet this spring, but unfortunately was rejected. Just as I was considering getting a job, fortunately my application to STF was accepted. I ended up receiving a much more generous investment than what I could have received from NLnet, turning misfortune into a blessing. I wrote about this in detail in STF invests in Fedify.

In any case, I'm grateful that I'll be able to focus full-time on the Fedify project for the next year.

Various presentations

This year, I had many opportunities to present at various meetups and conferences.

My first presentation of the year was at the 8th FediLUG study meetup⁵ held in early April. I presented under the same title as my article in Thinking Penguin Magazine Vol.0: From mixed script Korean to Hollo (国漢文混用体からHolloまで). The content was largely the same as the article. Since I couldn't afford to travel to Japan, the presentation was conducted online.

My next presentation was also in Japan, at the Making the fediverse: From the frontlines of developers and administrators (Fediverseのつくりかた〜開発者・管理者たちの現場から〜) seminar held at OSC 2025 Kyoto in early August. I presented on BotKit by Fedify: Easy ActivityPub bot creation for everyone (BotKit by Fedify：誰でも簡単に作れるActivityPubボット). This time too, I participated online since I couldn't make it to Kyoto.

In the fall, I gave the keynote speech at FOSS for All Conference 2025, Korea's first free and open source software conference, titled Embracing yak shaving (야크 셰이빙: 새로운 오픈 소스의 原動力). This presentation was based on my Japanese presentation From mixed script Korean to Hollo, but also covered my open source projects unrelated to the fediverse.

In winter, I presented at liftIO 2025, a Korean functional programming conference, with a talk titled Optique: Replacing CLI validation with TypeScript type inference (Optique: TypeScript의 타입 推論으로 CLI 有效性檢查를 代替하기). This was the only presentation I gave this year that wasn't related to the fediverse.

Wrapping up the year

I thought I hadn't done much, but looking back, I actually accomplished quite a lot this year. Since the STF investment extends until the end of next year, I'll likely continue many activities related to the fediverse, centered around the Fedify project. Personally, I'm worried that ActivityPub and the fediverse haven't yet established a solid foothold—despite X falling into Elon Musk's hands. I hope the situation improves next year.

A decentralized social media network, also known as the fediverse. The key concept is that various social media software and services implement the ActivityPub protocol, a W3C Recommendation, enabling interoperability between them. ↩︎
An ActivityPub server framework written in TypeScript. ↩︎
A single-user ActivityPub server built on top of Fedify. I created it because Mastodon was too heavy and had too many unnecessary features for solo use. ↩︎
Listed in alphabetical order. ↩︎
A study meetup held bimonthly by FediLUG in Japan. ↩︎

STF invests in Fedify

2025-10-03T12:00:00.000Z

STF invests in Fedify

After Fedify received funding from Ghost last year, I was able to work on the project full-time for a while. Even after the contract ended, Ghost continued to provide some sponsorship through Open Collective, though not enough to work on Fedify exclusively. Ghost's CEO suggested I look for more stable funding sources, which led me to apply to various foundation-run investment programs this spring.

NLnet

My first application was to NLnet. They have a strong interest in the fediverse and run a considerably large fund. More importantly, several ActivityPub-related open source developers I know had recommended them.

Unfortunately, my NLnet application was rejected. I later learned that projects have a lower chance of acceptance unless at least one maintainer is an European citizen. Of course, my application might simply have been inadequate.

I submitted the application in late January and received the rejection in mid-May. By then, my Ghost contract had ended and I was unemployed. Without income, I needed to either find a job or secure other funding.

Sovereign Tech Fund

Next, I applied to the Sovereign Tech Fund, an open source investment fund operated by the Sovereign Tech Agency. The STF primarily invests in foundational open source projects that are essential for developing other software or enabling digital networking. Their portfolio includes projects like Servo, systemd, Babel, FreeBSD, Samba, GNOME, and FFmpeg.

Already discouraged by the NLnet rejection, my confidence was low. Still, I rallied and meticulously prepared my application. Looking back at my emails, I apparently applied to the Sovereign Tech Fund the same day I received the NLnet rejection.

Again, the response took quite a while. Living on savings without income, I grew increasingly anxious as two months passed without word. I was almost certain it wouldn't work out, so I started job hunting as well. However, having spent the previous year working full-time on open source had been such a rewarding experience that I couldn't fully commit to the job search.

Fortunately, I received a response in early August—and surprisingly, the STF had selected Fedify for investment! The next two months flew by exchanging paperwork via email. Finally, yesterday, we officially kicked off Fedify's work under the STF program. I'll now receive funding as I complete the milestones I outlined in my application. The total investment is €192,000, with all milestones due by the end of next year.

Details about the STF's investment in Fedify are available on the Sovereign Tech Agency website, and the milestone roadmap is outlined in the Fedify project announcement.

Interestingly, since the Sovereign Tech Agency's funding comes from Germany, an ex-ante about the Fedify project investment appeared on a European Union website.

Reflections

Through this experience of seeking funding for Fedify, I couldn't help but wish Korea had public funds that invest in open source projects. I felt this particularly strongly when NLnet rejected my application. While I was fortunate to receive investment from the STF, which invests in open source projects regardless of nationality, having a program like the STF in Korea from the start would have made things much easier. It would also give many Korean open source developers the opportunity to dedicate themselves to their projects.

Additionally, since I'm currently Fedify's sole maintainer, I'm receiving these funds alone. My hope is to bring on co-maintainers before I need to seek funding again at the end of next year, so we can work together on this open source project full-time.

Recent open source development updates

2025-09-12T11:10:00.000Z

Recent open source development updates

I've found myself creating quite a few open source projects lately, so I thought I'd write up a status report and overview of my ongoing open source work. All these projects are interconnected in various ways.

Hollo

This project is actually the catalyst for all the open source projects I've created recently. After Elon Musk bought Twitter and renamed it to X, I started using Mastodon more actively than before. However, writing in Korean mixed script made me self-conscious about whether it might be difficult for others to read. I considered adding a feature to Mastodon that would convert Korean mixed script to hangul-only writing using Seonbi, but… it seemed unlikely anyone else would use this feature, making it unrealistic to push upstream to Mastodon. That would mean maintaining downstream patches while self-hosting a Mastodon server, which I wanted to avoid given Mastodon's notorious resource requirements. So I decided to create my own lightweight ActivityPub implementation for personal use: Hollo. I named it Hollo from the Korean word meaning alone, since it's a single-user ActivityPub server.

I successfully dogfooded it and have now moved my fediverse account to Hollo. My fediverse handle is @hongminhee@hollo.social. I can freely write in Korean mixed script, with Chinese characters annotated with Korean pronunciations using <ruby> tags.

Since achieving dogfooding status, all the features I urgently needed have been implemented, so I'm mainly doing maintenance and bug fixes now.

Fedify

When I first started implementing Hollo, I tried to build the ActivityPub implementation from scratch. However, I realized the ActivityPub implementation code was thicker and more complex than expected. So I paused Hollo development and created an ActivityPub server framework called Fedify. Less than six months after creation, it received funding from Ghost, which allowed me to work on Fedify full-time for a while. Currently, it's been selected as a participating project in the OSSCA hosted by the Open Source Software Support Center under NIPA of South Korea, and I'm working on it with excellent mentees.

ActivityPub server frameworks existed before Fedify, but none provided the level of abstraction I needed. Some were closer to small libraries that only provided WebFinger or signature algorithms, while others were almost complete social media platform implementations comparable to Mastodon, rather than frameworks. To use an analogy, there were HTTP libraries and CMS platforms like WordPress, but nothing comparable to frameworks like Rails or Django.

The goals I had in mind when creating Fedify were:

Make it usable by as many developers as possible.
Be database and storage agnostic. Application developers should be able to use whatever database they want.
No restrictions on how to utilize the ActivityPub protocol. Don't assume a specific application form like microblogging.
Provide everything needed for ActivityPub implementation: authentication, signatures, outbox and inbox queues, etc.
Provide documentation rich enough that even those unfamiliar with ActivityPub can use it.
Be type-safe.

As I write this, I believe I've largely achieved these goals. As a result, Hollo was rebuilt on Fedify, and other projects like Hackers' Pub (discussed below) and Ghost have implemented ActivityPub using Fedify. Additionally, projects like Kosmo and Cosmoslide are implementing ActivityPub with Fedify, though they're not yet complete.

LogTape

When I wanted to add logging to Fedify, I searched for JavaScript logging libraries but couldn't find one that met my requirements, so I created LogTape.

My requirements weren't particularly demanding: I just wanted something equivalent to Python's standard library logging module. In retrospect, the logging module is quite well-designed. My requirements were:

Libraries should be able to log, but applications should control the library's log output. Unless the application configures output, library logs shouldn't appear anywhere.
Loggers should be hierarchically managed. Sinks installed on parent loggers should apply to child loggers.
Sinks should have an easy-to-implement interface.
Be type-safe.
Work across various JavaScript runtimes including Node.js, Deno, Bun, edge functions, and web browsers.

These were mostly requirements for logging from libraries rather than applications. Since I made it for Fedify anyway, I left it alone after creating it, but it somehow gained word-of-mouth popularity last fall and many people started using it.

Hackers' Pub

I wanted to create a blog for software development posts and started using [velog]¹ briefly, but was disappointed it didn't support ActivityPub, so I opened an issue on the velog issue tracker. Fortunately, I received a positive response about considering it, but the team was busy and there's been no news since. Eventually, I decided to create my own social media and blogging platform for software developers that supports ActivityPub: Hackers' Pub.

Shortly after launching last winter, Lee Jae-yeol joined. Despite it being invitation-only, thanks to Lee Jae-yeol's incredibly enthusiastic promotion of Hackers' Pub everywhere, many people joined and became active. The short-term goal is widespread adoption in Korea, with medium to long-term goals of reaching across East Asia and English-speaking regions. However, most contents are still in Korean, with a few Japanese users occasionally posting Japanese contents.

Since it implements ActivityPub through Fedify, it naturally communicates with Hollo, Mastodon, Misskey, and others. You can write short posts (Note) like X, or longer articles (Article). It also provides features like emoji reactions and quotes that Mastodon doesn't have.

Another point of pride for Hackers' Pub is our code of conduct for creating a safe and equitable community. My favorite passage is:

We distinguish between discriminatory speech and speech that confronts discrimination.

On the technical side, it was originally built with Deno and Fresh, but we're currently migrating to GraphQL and SolidStart with help from Iha Shin, who has deep expertise in web frontend development.²

The source code is available on GitHub under AGPL 3.0. Many Hackers' Pub users actively submit pull requests to fix issues they encounter.

My Hackers' Pub account is @hongminhee@hackers.pub.

Upyo

While building Hackers' Pub, I needed to send emails and looked for an email sending library that would allow easy switching between email providers. Unable to find anything satisfactory, I created Upyo. Its name is derived from the Korean word 郵票 (postage stamp).

I was originally looking for something like .NET's FluentEmail in the JavaScript ecosystem, but was surprised to find nothing suitable. Is switching or multiplexing email providers less common than I thought?

This was also my first project seriously using an LLM-based coding agent³. Still, my expectations for LLM capabilities aren't that high, so I did the design and initial coding myself, then got significant help from the LLM when expanding the variety of transports. I think it took two days to build. The coding agent's impressive productivity was notable.

Like my other libraries, it supports various JavaScript runtimes including Node.js, Deno, Bun, edge functions, and web browsers.

Optique

Fedify provides a CLI tool called the fedify command alongside the framework. I was using Cliffy, a Deno-specific CLI framework, reasonably well, but needed to find an alternative when we had to support Node.js and Bun in addition to Deno⁴. Following a similar pattern… I couldn't find anything I liked.

Actually, I already had a near-ideal CLI parser library in mind: optparse-applicative, a Haskell library. I just couldn't use it with Fedify because it was in Haskell. The idea behind optparse-applicative is simple: since CLI parsers are parsers, let's build them with parser combinators.

Anyway, unable to find the CLI parser library I wanted, I had to make my own. That's how Optique was born.

Initially, I tried to port it almost identically to optparse-applicative, but Haskell and JavaScript have significant differences in expressive power for constructing DSLs. After much consideration, I decided to mimic the API of validation libraries like Zod, which TypeScript developers are already familiar with.

Unlike the Upyo project, I used LLM coding agents very limitedly for documentation and test code writing, which may be why it took over a week to build.

After completion, I can say I created a fairly unique CLI parser library within the JavaScript ecosystem. While many CLI applications don't require such complex options, I'm confident that anyone building a moderately complex CLI application won't regret using Optique.

Oh, and like the other libraries I've introduced, it works on Node.js, Deno, Bun, and even edge functions and web browsers. You might wonder if that's necessary; it's just self-satisfaction, I suppose. However, it did make the library very easy to test.

Yak shaving

Come to think of it, the driving force behind my open source development might be yak shaving. I once read Anthony Fu's About Yak Shaving and was struck by how similar our motivational approaches are. When something bothers me and I try to build a tool to fix it, I encounter another annoyance while building that tool and end up creating another tool to solve that. Often I don't accomplish what I originally set out to do, but the byproducts created along the way don't just disappear.

Looking back to the very beginning, what I really wanted was to write on the fediverse in Korean mixed script. To achieve this, I created Hollo, Fedify, LogTape, and even Optique. Along the way, new desires emerged, and I formed valuable connections through communities like Hackers' Pub. Oh, and I finally achieved my original goal of writing in Korean mixed script on the fediverse late last year! Though I did have to submit patches to Mastodon and Misskey in addition to the byproducts I mentioned.⁵

All this happened over roughly two years, and it's been an incredibly fun and enriching journey. I'll likely continue doing open source development full-time for a while, and I'm grateful for this opportunity and determined to make the most of it.

A blogging platform for software developers widely used in Korea, similar to DEV.to. ↩︎
While I regret using Deno for various reasons, we're stuck with it even after migration. ↩︎
I used Claude Code. ↩︎
While the Fedify framework itself already supported Node.js, Deno, Bun, Cloudflare Workers, etc., the CLI tool fedify command was Deno-only. ↩︎
The receiving side also needed to be able to render <ruby> tags. ↩︎

A year with the fediverse

2024-12-23T15:00:00.000Z

A year with the fediverse

2024 was truly a year where I was deeply immersed in the fediverse. I worked on various projects, both large and small, related to the fediverse and ActivityPub, and some of them received quite positive responses from many people. I'm writing this to preserve these good memories.

What is the fediverse?

Let me briefly explain what the fediverse is—it's a network where different types of social media can communicate with each other. In other words, two accounts on completely different social media platforms can follow each other, comment on each other's posts, and like each other's content. Technically, this interoperability between different social media platforms is implemented using the W3C technical standard called ActivityPub.

Currently, notable social media platforms participating in the fediverse include Mastodon, Pixelfed, Akkoma, Misskey, WordPress, and many more projects too numerous to list. Most of them are also open source projects. Additionally, while not open source, Meta's Threads has been gradually implementing ActivityPub since this summer and can now be considered somewhat part of the fediverse.

Since it's a way for different social media platforms to communicate, accounts in the fediverse include not just a username but also a server name. This address format, commonly called a fediverse handle, looks similar to an email address: @username@host. Through this, accounts belonging to different servers and platforms can follow and communicate with each other. I also have a fediverse account, and you can follow me at @hongminhee@hollo.social.

Fedify

Fedify is probably my biggest achievement this year. Fedify is an ActivityPub server framework written in TypeScript, which I created because I couldn't find an appropriate level of abstraction for implementing ActivityPub servers. I initially tried building an ActivityPub server app from scratch several times and managed to create something that worked, but I wasn't entirely satisfied with the code. As I started writing it again with proper abstraction in mind, I realized I was essentially building a framework, and this made me deeply appreciate the necessity of an ActivityPub server framework like Fedify.

Fedify went through four rewrites—initially in TypeScript, then Python, then C#, and finally back to TypeScript. The language choice involved several considerations. First, it needed to support JSON-LD, ActivityPub's data exchange format, and needed to be somewhat dynamic to handle JSON-LD easily. Second, even as a dynamic language, it needed good static typing support, specifically what's known as gradual typing. Finally, it needed to have a large user base and rich ecosystem because I wanted Fedify to be widely used. After considering everything, I settled on TypeScript.

Including all the rewrites, I started working on it in early December last year, but counting from the final rewrite, I began development in late February and released the first version 0.1.0 in early March. Before release, I had planned to call it Fedikit, but just before release, I discovered there was already a project with the same name, so I quickly changed it to Fedify. The Python version I worked on under the codename Fedikit is still available on GitHub.

I can proudly say that Fedify currently provides the most comprehensive set of features needed for building an ActivityPub server. The fediverse isn't just about implementing ActivityPub—you need to handle many specifications including JSON-LD, Activity Vocabulary, WebFinger, NodeInfo, HTTP Signatures, Linked Data Signatures, and Object Integrity Proofs. Fedify covers all of these. In fact, Fedify implements many features that aren't even implemented in major ActivityPub implementations like Mastodon or Misskey. I often see people who mistakenly think implementing an ActivityPub server is simple after just skimming the ActivityPub spec, start without any ActivityPub framework, and end up overwhelmed by its complexity. I strongly recommend using Fedify for anyone thinking about building an ActivityPub server.

Another aspect I focused on while building Fedify was documentation. I believed it needed not just reference documentation but also comprehensive manuals covering all of Fedify's features. I would even write the manual documentation first before implementing new features. As a result, the documentation has grown quite extensive, and now I'm contemplating how to translate it into languages other than English.

Finally, my greatest achievement with Fedify was the Ghost's funding of Fedify. This allowed me to work on open source full-time for the first time in my life. Moreover, Ghost is Fedify's biggest user. Ghost's ActivityPub implementation is well underway and currently in private beta. It will likely be released to the public next year.

Hollo

Hollo is a single-user ActivityPub server. While people typically create fediverse accounts by joining a Mastodon or Misskey server they like, some software engineers prefer to set up their own server connected to their own domain name. However, software like Mastodon or Misskey is designed for multiple users and has many features unnecessary for single users, making it heavy and complicated to install. Hollo was created for such people. Hollo only needs PostgreSQL to run, making installation relatively simple, and it only includes features necessary for single users, which is its main advantage.

The background of creating Hollo is somewhat complex. Actually, Hollo could be said to be the catalyst for creating Fedify, as it was while starting to build an ActivityPub server like Hollo that I realized the need for an ActivityPub server framework. However, the code from that initial project wasn't reused in Hollo, and the project name wasn't even Hollo at that time, so strictly speaking, Hollo wasn't the direct cause for creating Fedify. But it's true that after creating Fedify, what I ultimately wanted to build was something like Hollo.

However, after creating Fedify, Fedify itself became what I wanted to focus on, and the original motivation somewhat faded. So by the time I actually started building Hollo, its main purpose had become creating a demo for Fedify. In fact, while building Hollo, I added needed features to Fedify and fixed bugs. However, since it was part of the Fedify project, Hollo's code quality is much lower compared to Fedify. I started addressing this issue after Hollo stopped being considered part of the Fedify project, but there's still much room for improvement in code quality.

Unexpectedly, Hollo gained a user base in Japan, leading me to translate the official documentation into Japanese and even set up a booth at an event called Open Source Conference 2024 Tokyo/Fall in Japan. At this event, I received tremendous help from Esurio, a local Hollo user who helped manage the booth with me.

Recently, for dogfooding, I migrated from my Mastodon account to Hollo.

FediDev KR

One day, I realized there wasn't much exchange between developers creating fediverse software in Korea. So I convinced Lee Jae-yeol, who had created a Mastodon client for Neovim, to help establish the FediDev KR. We first set up a Discord server where quite a few developers gathered.

We also planned regular sprint meetups and held our first meetup on August 31st at the returnzero office, which surprisingly attracted many participants. I still maintain connections in the fediverse with people I met there.

Recently, offline interactions have been less frequent due to the year-end, but we plan to resume active engagement next year.

First doujinshi sale

Since fall this year, I started actively engaging in the Japanese-speaking fediverse, which led to interactions with Japanese Hollo users. Among them, Esurio suggested participating in the Open Source Conference in Japan, and after some consideration, I decided to exhibit. Since it was my first time both participating in a Japanese event and setting up a booth, I received various forms of help from Esurio. I want to take this opportunity to express my gratitude.

Anyway, since we decided to exhibit, we needed something to display, so as part of this, I decided to print and sell a paper version of the Japanese translation of Fedify's tutorial Creating your own federated microblog (自分だけのフェディバースのマイクロブログを作ろう！). Fortunately, most of the books we brought were sold, so we could return quite light. One of the book purchasers, Monaco Koukoku (モナコ広告), even gave a talk titled I tried making an ActivityPub server with Fedify (FedifyでActivityPubサーバを作ってみた) at a FediLUG study meetup, sharing their experience following the tutorial.

It was great to interact with people, even those who didn't buy the book, despite my limited Japanese.

Full-time fediverse development

Unexpectedly, things have taken a direction I couldn't have predicted at the beginning of the year, and I've become a sort of full-time fediverse developer. Next year, I plan to focus on expanding the fediverse's foundation. As part of this effort, I'm working on creating an ActivityPub-based social platform for software engineers, which I hope to release soon.

Ghost funds Fedify

2024-07-03T02:00:00.000Z

Ghost funds Fedify

I am happy to announce some great news! Fedify, an open source project I've been working on since this spring, has been funded by Ghost, a global publishing platform.

What is Fedify?

First, let me explain what Fedify is.

Fedify is an ActivityPub server framework. ActivityPub protocol is behind the technology that allows disparate social media services like the Mastodon, an open source project, and Threads from Meta to come together and communicate. This federation of social media is called the fediverse.

ActivityPub may seem like a simple protocol at first glance, but it's actually quite complicated to implement interoperability with other services. I was looking for a framework that would take care of those tricky parts for me, and since none existed, I created one.

Ghost's adoption of Fedify

Until a couple of months ago, Fedify was more of a toy for people's hobby projects, but it still had a small community of users, and one day someone told me about Ghost's adoption of ActivityPub and suggested that I should try to sell Fedify to the Ghost team, since Ghost is also written in TypeScript. I was hesitant at first, wondering if it would work, but when I heard that the person who encouraged me to sell to Ghost had sent an email directly to the Ghost team, I got the confidence to contact them.

I was surprised to find out that the Ghost team was reviewing Fedify in a positive way, and they told me that they had indeed decided to go ahead with Fedify. It was a surprise, and I was thrilled!

Funding

After that, I stayed in close contact with the Ghost team, especially the team building ActivityPub into Ghost, and it wasn't long before they approached me with an offer to fund the Fedify project and implement the features they wanted to see added to Fedify. I was in the middle of a job hunt and was sending my résumé to various companies, so this was quite a tempting offer.

I agreed to work with them for about a couple of weeks and got a little funding. I was able to work on Fedify while preparing for my job search, and I found it to be very immersive and enjoyable. Eventually, I expressed my interest in working on Fedify full-time if I could be funded for a longer period of time, and the Ghost team responded positively.

So I've been able to continue working on Fedify with funding for quite some time now. I once worked on an open source project full-time at my previous job, but this is the first time I've ever worked on an open source project I started in a funded way, and I'm excited about the future.

My new blog

2021-12-28T18:27:00.000Z

My new blog

I've had two blogs in my life.

My first blog, which I started right before I graduated from high school, lasted about three years and I wrote over a hundred posts. It was initially created with a software called Typo¹, and I moved to WordPress a few months later.

I started my second blog in 2010 and wrote over 200 posts in seven years. I started it as a Tumblr, but later moved it to GitHub Pages using a static blog generator — something most software engineers do at some point.

I stopped blogging for a while in 2017. As I stopped writing, I lost what I wanted to write about, and I had no idea what to write about. So last spring, I decided to write short pieces on what I read. Writing them made me want to start blogging again, but my old blog felt dusty and unmotivating. Even a lot of what I wrote previously seemed unpleasant. I've changed my mind about a lot of things since then, so it wasn't enough to make a few changes.

I was also getting tired of my static blog generator, which was a single file Python script I made myself. In the meantime, I had started writing almost all of my private notes in Korean mixed script (國漢文混用體), so I wanted to write my blogs in mixed script, at least the raw text.² I had also written a software called Seonbi, which converts Korean mixed script to hangul only (한글전용). So I decided to just create a third blog.³

I started by creating a blog with Jekyll, which is available on GitHub Pages without any setup, but it wasn't long before I realized that this setup made it difficult to take advantage of Seonbi. I probably spent a month or two trying out other static blog generators. After doing some research, I found that many of the requirements I was asking for were not very reasonable and therefore not commonly asked for. In 21st century Korea, who would want to write articles in Korean mixed script and then publish them in hangul only.

For some strange reason, I ended up creating another static blog generator called Jikji. I also used Deno to learn a new platform, and I liked it a lot, so I'm going to use Deno a lot instead of Python in the future. It's a shame that I already dislike it right after I finished making it, but I promised myself to start a blog before 2021.

Anyway, now that I've created a new blog, I'm going to start writing regularly again.

It was a blogging software written in Ruby on Rails that was popular at the time, and I believe it's now called Publify. ↩︎
Note to non-Korean speakers: Much of the vocabulary of modern Korean comes from Literary Chinese (漢文), just as much of the vocabulary of modern English comes from Latin.

When these words are written in Chinese characters and the rest of the vocabulary is written in hangul, it is called mixed script, and when all vocabulary is written in Hangul only, it is called hangul only.

See also related entry on Wikipedia: Debate on mixed script and hangeul exclusivity. ↩︎
I moved my blog three times, but I always did my best to keep the permalinks. Although I've stopped updating both the first and second blogs, I'm going to keep them as archives. ↩︎

Nobody Knows

2020-07-08T19:07:00.000Z

Nobody Knows¹

I watched Hirokazu Kore-eda's Nobody Knows (誰も知らない) with Lisa, and I had to choke back tears several times. To put it bluntly, it was a total disaster and a systemic tragedy.

Artificial structures have redundancies, so even if one or two parts fail, it usually doesn't disrupt what the whole structure is trying to accomplish. Therefore, if a structure malfunctions significantly, it can be said that there are already many layers of failure. Watching the first half of the film, I thought that the tragedy that befell this family had to be the result of more than just one or two things going wrong, it had to be the cumulative effect of many things going wrong on a larger level — hence the total disaster. But by the end of the film, this idea was turned inside out. The tragic loss of life in one or two of these families does not interfere with the benefit (functioning) of the social system for most of us, and therefore Nobody Knows about their deaths — that is, they are systemic tragedies, and they function as redundancies in the system for the rest of us to enjoy our lives…

I originally posted this in Korean on my Facebook, but now I don't use Facebook anymore, so I'm posting it here. ↩︎

Hong Minhee on Things

Is legal the same as legitimate: AI reimplementation and the erosion of copyleft

Is legal the same as legitimate: AI reimplementation and the erosion of copyleft

The analogy points the wrong way

Does the GPL work against sharing?

A self-refuting example

Legality and social legitimacy are different registers

Whose perspective is the default?

What this fight points toward

Why craft-lovers are losing their craft

Why craft-lovers are losing their craft

Alienated from the act

Who's doing the penalizing

What my situation reveals

Where the grief should look

Acting materialistically in an imperfect world: LLMs as means of production and social relations

Acting materialistically in an imperfect world: LLMs as means of production and social relations

Two strawmen

Machinery and its capitalist application

Libraries and people

The default viewpoint

Histomat of F/OSS: We should reclaim LLMs, not reject them

Histomat of F/OSS: We should reclaim LLMs, not reject them

Where we agree

Where we diverge

On accepting reality

The materialist reading

What a training copyleft might look like

Technical challenges and precedents

Why this matters more than withdrawal

The future we should build

A historical opportunity

Conclusion

Why I don't destroy snowmen

Why I don't destroy snowmen

My 2025 with the fediverse

My 2025 with the fediverse

Thinking Penguin Magazine Vol.0

BotKit

Hackers' Pub

Software Sessions appearance

Finding Our Code appearance

Open Source Software Contribution Academy (OSSCA)

Fedify investment

Various presentations

Wrapping up the year

STF invests in Fedify

STF invests in Fedify

NLnet

Sovereign Tech Fund

Reflections

Recent open source development updates

Recent open source development updates

Hollo

Fedify

LogTape

Hackers' Pub

Upyo

Optique

Yak shaving

A year with the fediverse

A year with the fediverse

What is the fediverse?

Fedify

Hollo

FediDev KR

First doujinshi sale

Full-time fediverse development

Ghost funds Fedify

Ghost funds Fedify

What is Fedify?

Ghost's adoption of Fedify

Funding

My new blog

My new blog

Nobody Knows

Nobody Knows1

Nobody Knows¹