Open Source Is Not Free

The word "freedom" in software always comes paired with open source. But as a developer working in Korea, that freedom rarely feels like mine. Having spent a fair amount of time programming, I want to write down a few things I have noticed about why that is.

(Richard Matthew Stallman)

Whose Freedom Is Open Source Freedom?

Richard Stallman's four software freedoms, to run, study, redistribute, and modify, carry an implicit precondition: that the user possesses the technical capability and linguistic access to exercise them.

English documentation. English GitHub issues. English Stack Overflow. The primary language of the open source ecosystem is English. For non-English-speaking developers, this freedom exists legally but is practically stratified.

The Roman freedman analogy is precise. Legally free, but without a patronus, social mobility was impossible. Open source has the same structure. Technically open, but exercising that freedom requires English, Anglo-American coding culture, GitHub networks, and Western software engineering vocabulary as patronus infrastructure.

The core of the problem is this: things that mainstream developers in Silicon Valley never have to think about are things that developers outside that world must always be conscious of.

Linux Is Not Free

The monetary cost of Linux is zero. The total cost of ownership is not.

For a Korean developer to actually run Linux, they must learn an English command-line system, solve driver problems manually, and troubleshoot using English documentation. Windows costs money but provides Korean language support, automated drivers, and localized community documentation. The actual cost is lower.

This creates a paradox where the free software is practically more expensive.

This cost scales nonlinearly by region. For English-speaking developers, Linux's hidden costs are low. For non-English-speaking developers, they are significantly higher. Open source ideology does not measure this cost.

The Terminology Barrier Goes Deeper Than It Looks

"Bootstrap", "Initialize", "Hydration", "Lazy loading". These terms are built on English cognitive structures. Translation into Korean loses meaning or sounds unnatural. Words like "bootstrapper" and "initializer" are not intuitive to a Korean speaker hearing them for the first time.

This is not simply a translation problem. It means the concepts themselves are designed on the mental model of a specific linguistic culture. Software engineering vocabulary is itself a barrier, and that barrier grows as you move away from the Anglosphere.

In that sense, LLM dismantles this terminology barrier.

A first-year university student in the Anglosphere takes these terms for granted. For a developer outside that world, they feel foreign. And this creates a wall.

If you wrote code in Korean, it would look something like this:

# 파이썬 예시

def 사용자_인증(사용자이름, 비밀번호):
    if not 사용자이름 or not 비밀번호:
        return 실패("입력값이 없습니다")
    
    사용자 = 데이터베이스.찾기(사용자이름=사용자이름)
    if not 사용자:
        return 실패("사용자를 찾을 수 없습니다")
    
    if not 비밀번호_확인(비밀번호, 사용자.해시된_비밀번호):
        return 실패("비밀번호가 틀렸습니다")
    
    토큰 = 접근토큰_생성(사용자.아이디)
    return 성공(토큰)


class 장바구니:
    def __init__(self):
        self.담긴_상품들 = []
    
    def 상품_추가(self, 상품, 수량=1):
        기존_항목 = self._항목_찾기(상품.아이디)
        if 기존_항목:
            기존_항목.수량 += 수량
        else:
            self.담긴_상품들.append(장바구니_항목(상품, 수량))
    
    def 총액_계산(self):
        return sum(항목.상품.가격 * 항목.수량 for 항목 in self.담긴_상품들)
    
    def _항목_찾기(self, 상품_아이디):
        return next(
            (항목 for 항목 in self.담긴_상품들 if 항목.상품.아이디 == 상품_아이디),
            None
        )

It is readable. The logic flow can be followed. But the moment this goes up on GitHub, there are zero contributors. No code review, no issues, no Stack Overflow answers.

authenticate, shopping_cart, add_item work with any developer anywhere in the world. 사용자_인증, 장바구니, 상품_추가 only work with someone who knows Korean. Regardless of the code quality, language determines the range of possible collaboration.

For a Korean developer, the shock of encountering their first English code is even greater than this. If you rewrote a programming language to match Korean word order, it would look like this:

가져옴 자료묶음에서 자료틀
가져옴 typing에서 선택적


자료틀 상품:
    아이디: 정수
    이름: 글자열
    가격: 실수
    재고: 정수 = 0


자료틀 장바구니_항목:
    상품: 상품
    수량: 정수 = 1

    묶음속성
    소계_구하기(자신) -> 실수 정의:
        자신.상품.가격 * 자신.수량 돌려줌


틀 장바구니_관리자:
    초기화하기(자신) 정의:
        자신._담긴_목록: 목록[장바구니_항목] = []
        자신._할인율: 실수 = 0.0

    담기(자신, 상품: 상품, 수량: 정수 = 1) -> 없음 정의:
        이미_담긴_것 = 자신._기존_항목_탐색_하기(상품.아이디)
        이미_담긴_것 있으면:
            이미_담긴_것.수량 += 수량
            돌아감
        자신._담긴_목록.덧붙임(장바구니_항목(상품=상품, 수량=수량))

    빼기(자신, 상품_아이디: 정수) -> 참거짓 정의:
        찾은_항목 = 자신._기존_항목_탐색_하기(상품_아이디)
        찾은_항목 없으면:
            거짓 돌려줌
        자신._담긴_목록.제거함(찾은_항목)
        참 돌려줌

    할인_적용하기(자신, 할인율: 실수) -> 없음 정의:
        (0.0 <= 할인율 <= 1.0) 아님이면:
            값오류("할인율은 0과 1 사이여야 합니다") 던짐
        자신._할인율 = 할인율

    최종금액_계산하기(자신) -> 실수 정의:
        원래금액 = (항목.소계_구하기() 담긴_목록_각항목에_대해 항목).합산()
        원래금액 * (1 - 자신._할인율) 돌려줌

    _기존_항목_탐색_하기(자신, 상품_아이디: 정수) -> 선택적[장바구니_항목] 정의:
        다음값(
            (항목 담긴_목록_각항목에_대해 항목 항목.상품.아이디 == 상품_아이디 조건으로),
            없음
        ) 돌려줌

The moment def add(self, item): becomes 담기(자신, 상품, 수량) -> 없음 정의:, an Anglophone developer can get as far as "this looks like some kind of function declaration" but cannot immediately tell where the name ends and where the type begins.

return value flipping to 값 돌려줌. if not x: becoming x 아님이면: with a postpositional particle attached. The structure is visible but the reading direction keeps going wrong. This is the reverse of what a Korean developer experiences when learning English keywords for the first time.

LLM dismantles this barrier not through translation. You can ask in Korean what authenticate means, why bootstrap has that name, why hydration uses that word, and get the answer with full context. What an Anglosphere first-year absorbs naturally in class can now be acquired asynchronously.

GitHub Dependency Is an Irony Open Source Created

In the current hiring market, "portfolio = GitHub account" is effectively standard. Participating in open source requires existing on GitHub, and GitHub is owned by Microsoft.

Open source ideology claims independence from specific corporations, while the infrastructure realizing that ideology is dependent on a specific corporation. This is structural irony.

AI Slop Is the Output of Structural Pressure

Some view the flood of AI-generated low-quality contributions into open source communities as an individual ethics problem. But examining the structure reveals something different.

Companies included GitHub contributions and open source activity in hiring criteria. People who need to build careers within a high-barrier structure use AI as an entry tool. The output accumulates as slop in the community.

Slop is an effect, not a cause. If open source were genuinely open, people with lower entry costs would participate in ways that raise contribution quality. Because entry barriers are high, AI is used as an entry mechanism, and the result is slop.

Open source became stratified rather than open, which is why slop exists. And slop alone is not what is destroying open source.

A DDoS analogy makes the structure clear. A DDoS attack does not directly destroy a server. As requests flood in at volume, vulnerabilities that were always present get exposed. The flood of requests is the trigger, but what actually brings the server down is the internal structure that cannot withstand that pressure.

AI slop works the same way. The volume of slop is not the problem. What is being exposed is the structural vulnerability of open source communities that cannot handle that volume. When entry barriers lowered, the mechanisms for verifying contribution quality could not hold. Slop is not the attacker. It is a load test. And open source has failed that test by exposing its own weak points. This is a problem inherent to the PR system itself. I think it is evidence that the PR system needs to evolve into something different.

LLM Dependency vs. GitHub Dependency

One criticism of LLMs is corporate dependency. How does this differ from GitHub dependency?

The structure of entry conditions differs.

GitHub dependency has cumulative entry conditions: English, version control culture, community etiquette, terminology, network. These must be satisfied sequentially. Missing one blocks the next step.

LLM dependency has a single-layer entry condition: internet connection and subscription fee. You can ask in Korean. You can ask what a term means directly. Language barriers, terminology barriers, cultural barriers all lower simultaneously.

Does this make LLM dependency unconditionally superior to GitHub dependency? It is not that simple.

One thing needs to be stated clearly. The structural problems of open source must not be conflated with the work of the people inside it. The thousands of contributors maintaining the Linux kernel. The unpaid maintainers managing libraries. The people reading bug reports through the night. Their labor is the foundation of the current software ecosystem. A significant portion of the code LLMs trained on is the product of that labor. Criticizing the structural stratification of open source is an entirely different matter from dismissing the contributions of the people who built it.

Structural problems can be created by people with good intentions. The Anglophone stratification of open source was not the result of anyone's malice. It was a limitation of scope. The free software movement set out to solve the problem of ownership, and it succeeded. The unequal distribution of access was simply never part of the agenda.

If LLMs close part of that gap, it is only possible on top of what the open source community built. Not opposition. Succession.

Does LLM Externalize Capability?

Another criticism is the externalization of capability. If you do not code yourself, the argument goes, capability never internalizes.

Socrates criticized writing for externalizing thought. But Plato's works exist because someone recorded them. Writing externalized memory capability but simultaneously internalized argumentation, editing, and nonlinear reading capabilities. The total volume of capability did not decrease. The form changed.

The debate about YouTube-generation literacy follows the same structure. Decline in reading capability is an observation, but understanding editing grammar, compressing visual information, and reading multi-track narrative are capabilities the previous generation lacked. Capability shift, not capability loss.

LLM use has the same structure. Some capability to write code from scratch is externalized, but simultaneously, system design judgment, output validation, and requirement refinement capabilities are internalized. The simple externalization frame omits this half.

Here the structural difference between GitHub dependency and LLM dependency needs clarification. GitHub is owned by Microsoft, but its foundation, Git, is a decentralized protocol. If Microsoft changes its policies, a developer can take the local .git folder intact and migrate to GitLab or a self-hosted server. Knowledge capital is fully preserved.

LLM dependency, by contrast, is closer to cognitive subcontracting to a black-box infrastructure. If API prices increase tenfold or access from certain countries is blocked, the reasoning capability that was externalized simply evaporates. In this sense, LLM freedom resembles not the Roman freedman but the tenant farmer. Prosperous only while the rent is paid, unable to own the means of production: the model weights.

But this argument rests on one assumption: that LLMs will always exist only as external services. If LLMs become sufficiently lightweight that individuals can own and fine-tune them locally, that model becomes a form of self-owned capability. Whether you ride a Harley-Davidson or a Honda, the essential direction of riding remains largely the same. Tuning and riding style differ at the margins, but a transferable core of capability persists. When the model changes, the fundamental skill of working with models moves with you.

The deeper question is the allocation of cognitive resources.

In real production environments, C++ code is typically a mixture of everything from C++98 to modern C++11. When you go deep into local performance optimization, making global architectural judgments becomes harder. This is not a criticism of C++ performance itself. The structural problem is that concentrating cognitive resources on local optimization weakens the capacity for macro-level judgment.

Human cognitive resources are finite. Prioritizing local perspective weakens global perspective. LLM changes this allocation structure. As the cost of low-level code writing decreases, cognitive resources shift toward architectural judgment, system design, and the capability to converge multi-layered instructions toward a single purpose. Is this simple externalization of capability, or is it reallocation of capability?

To be direct: algorithmic skill and code quality judgment do weaken in the LLM era. That is true. But there is something gained in exchange. Programming style varies significantly by layer. Moving toward lower levels, code writing and optimization become central. Moving toward higher levels, most work becomes assembling specific libraries and frameworks. LLM lowers the cost of lower-level work, enabling more cognitive resources to be invested in higher-level judgment. The cost of moving between layers decreases.

Can this be called the externalization of capability? At minimum, it cannot simply be called that.

The core question is which layer you occupy and where you place your capability.

A writing analogy makes the structure clear. People at lower layers are those who build the words and sentences that go into the dictionary. People at higher layers take words and sentences from that dictionary and write novels. This is not a question of which is more important. The roles are different.

When a service stabilizes and enters an optimization phase, lower-layer capability becomes necessary again. But most services disappear before reaching that phase. And even for those that do reach it, the possibility of simply relearning at that point is consistently ignored. Capability is not a fixed asset. It can be reallocated when needed.

Capability gets refactored the same way code does. Mature programming is not mastery of a specific approach. It is the ability to judge which layer you are in at a given moment and change your approach accordingly. The change LLM brings should be read in this context. Lower low-level costs means more resources can be invested in high-level judgment. It also means the cost of going back down to lower levels when necessary has decreased. What has improved is the flexibility to move between layers.

Infrastructure Has Always Cost Money

Before AWS, the cost of standing up a single server was prohibitive for individuals. AWS converted that capital barrier into hourly billing. You can criticize this as corporate dependency, but the capital barrier that existed before that dependency does not disappear.

Infrastructure has always had costs, always distributed unevenly by region. Beyond certain geographic boundaries, infrastructure costs spike dramatically. LLMs carry a subscription fee, but summing the information access costs, learning costs, and troubleshooting costs for non-English-speaking developers, total cost may actually be lower.

The structure converts uneven implicit costs into uniform explicit costs.

The Form of Freedom Is Changing

The free software movement succeeded in securing the legal freedom of software. But equalizing the social conditions required to exercise that freedom was never part of the agenda. The result is open source creating stratification without ownership. No one owns the code, but the people who can practically leverage it are structurally a specific stratum.

LLMs partially dissolve that stratification. They lower entry barriers, reduce language barriers, and convert hidden costs into explicit ones. They change the form of capability without eliminating capability itself.

The tradeoffs are real. LLM freedom exists only while the subscription is maintained, and pricing authority rests entirely externally. As monopoly strengthens, this structure becomes more fragile.

But at this point in time, if a freelance developer in Ulsan, Korea can discuss system architecture without parsing English documentation, that is also a form of freedom. Practically exercisable freedom is sometimes more meaningful than freedom as legal right.