Open Source and the Creator’s Right to Benefit from Their Work

Richard Stallman and Linus Torvalds were not wrong to expand freedom and collaboration in software. But the success of that freedom does not exempt its economic system from scrutiny. We have reached a point where the world can benefit from a programmer’s work while that programmer struggles to secure paid time to maintain it. That outcome deserves to be confronted, however noble the surrounding slogans may be.

I belong to the generation of programmers who started in the 1980s. I grew up in a culture that regarded source code as its author’s capital, and keeping it closed as a way to sell software and protect years of work. I understand that culture, just as I understand the anger over excessive licensing fees and restrictions that trap users inside a single product. My personal position is that user freedom and the creator’s dignity must coexist in the software economy. I cannot accept either being sacrificed for the benefit of the other.

Nevertheless, I do not regard every closed-source program as a monopoly, or every high price as exploitation. A price may fund expensive development, testing, warranties, and specialized services. The objection begins when control is used to obstruct competition, restrict users’ ability to switch products, and impose terms disproportionate to the value provided. High prices may also encourage some people to seek pirated copies, but they neither justify piracy nor fully explain its prevalence.

Fairness also requires getting the history right. Stallman is associated with the free software movement and its philosophy of user rights. The “open source” label and its institutional movement took shape in 1998, with a stronger emphasis on collaboration and its practical and commercial advantages. Torvalds supported that terminology early on. Neither man invented code sharing from nothing, and they did not necessarily represent the same philosophical position. ^[2]

Nor did Stallman make unpaid work a condition of freedom: the GNU Project explicitly permits selling free software. But permission to sell something is different from the ability to sustain an income from it, particularly when recipients can redistribute it under its license. That is where the economic problem begins, and a slogan alone cannot solve it. ^[1]

The spread of open source does not establish that most developers have abandoned proprietary software, or that most companies have been forced to open their products. Those are generalizations that require data. In my view, openness has not eliminated the possibility of concentrated power. Source code may be available to everyone while the ability to reach customers, operate services, and market them remains concentrated in relatively few hands.

I see the root of the problem in the difference between the cost of copying software and the cost of creating and maintaining it. Once code is published, many people can obtain it at negligible marginal cost. Reviewing changes, fixing vulnerabilities, supporting platforms, improving documentation, and responding to issues, however, require continuing human effort. Allowing people to copy the work does not automatically create a system for paying those who keep doing it.

A project may therefore have enormous value to society while its creator has little ability to capture a share of that value. A company may possess the sales skills, distribution channels, and business relationships that the developer lacks, allowing it to build a commercially successful offering on top of that developer’s work. This does not automatically make the company a thief. It does help explain why the distribution of profits does not always match the distribution of technical contributions.

A 2024 study of open source funding offers relevant evidence. In a survey of 501 organizations, 86% of reported investment took the form of employee and contractor labor. Of the financial funding disclosed by respondents, approximately 4% went directly to maintainers. That figure does not mean everyone else was unpaid, nor does the survey constitute a comprehensive census of projects. It does, however, demonstrate why we must distinguish between funding the ecosystem and money reaching the independent people who maintain it. ^[5]

That is why I reject the claim that the success of a few large projects is enough to prove the system is fair. Equally, I reject sweeping claims that most creators have failed, or that those who succeeded did so only through luck. Such assertions require evidence we do not have here. The stronger criticism is that technical achievement and widespread adoption do not guarantee a return for the creator. That failure deserves an institutional response, rather than making every programmer responsible for becoming a skilled entrepreneur.

It is essential to distinguish legitimate use from license violations. The MIT License, for example, permits use, modification, and sale, while requiring preservation of the copyright and permission notices in copies or substantial portions of the software. That does not require announcing the author’s name in every marketing post. When commercial use complies with those conditions, it should not be called piracy simply because it generates no income for the author. Removing required notices is a different matter. ^[3]

Yet compliance with a license does not close the ethical and economic discussion. When a profitable organization depends on a critical component, can afford to fund its maintenance, and nevertheless leaves the entire cost to its creator’s unpaid time, it is shifting part of its cost of doing business onto someone who does not share in the returns. That may be legally permitted, but it deserves scrutiny as a business practice. Refusing to call it piracy does not oblige me to applaud its fairness.

This is a painful but necessary point: the behavior that disappoints me economically may be permitted by the license I chose. A license should therefore reflect a project’s actual goals. It should not be selected out of enthusiasm, or on the vague promise that widespread adoption will eventually bring money.

Permissive licenses suit those who want to reduce barriers to adoption and accept the possibility of their work being incorporated into closed-source products. Copyleft licenses such as the GPL impose conditions when covered works are distributed, but they do not entitle the author to a share of other people’s profits. The AGPL adds an obligation, when a program is modified and made available for interaction over a network, to offer the corresponding source code to users of that modified version. Its purpose is to preserve source availability in that context, not to impose royalties on cloud services. ^{[4] [8]}

Dual licensing can combine a release under an open source license with a commercial license granting different permissions. Qt provides an established example of open source and commercial licensing, with obligations varying by component and license. This does not mean every commercial use of Qt requires purchasing a license: the LGPL may permit a closed-source application when its conditions are satisfied. ^[9]

Anyone offering an alternative commercial license needs the necessary rights or permissions, including those covering contributions incorporated into the release. A project owner cannot grant exceptions for rights they do not hold. Contribution policies must therefore be clear and fair from the beginning. Contributors should not discover unexpectedly that their efforts have become an exclusive source of profit for someone else. ^[10]

There is another boundary that must be stated plainly. Prohibiting commercial use, banning competition, or requiring every commercial user to pay changes the nature of a license and places it outside the Open Source Initiative’s definition of open source. A developer may choose a model that makes source code available subject to commercial restrictions. That is a legitimate subject for debate, but it must be described honestly. Likewise, an open-core model with proprietary extensions is a mixed model, rather than complete openness across the entire product. ^[11]

C++ also deserves a more precise treatment. The language is a standardized specification maintained through the WG21 committee, not a single repository of open source code. The Standard C++ Foundation supports community activities and standards meetings, and provides assistance and grants under its policies. It is therefore inaccurate to describe C++ as unsupported simply because no single company owns it. ^{[6] [7]}

That correction does not remove the broader question: does support reach different kinds of work and contributors according to their needs and impact? The existence of a foundation or a budget does not, by itself, establish that every independent researcher, library developer, or standards contributor receives enough support to continue. We need to examine how funding is distributed, rather than merely establish that it exists.

The solutions I favor begin by making sustainability part of how software is purchased and managed. They can be pursued through the following approaches:

1. Purchase maintenance through clear contracts. Companies that depend on an important project should be able to contract for security reviews, fixes, platform compatibility, and defined response times. Developers receive payment for specified work and commitments, while users retain their rights to the code. Contracts should include preventive maintenance. We should not wait for a disaster before considering the expertise that prevented it worth paying for.

2. Fund work before it is performed. Several organizations can jointly fund a feature, a release, or a year of maintenance, with a stated budget and delivery milestones. If the improvements will be published for everyone, that is an agreed part of the arrangement. Paid work does not require a promise of exclusive ownership of its results. The maturity or continued availability of a shared tool may be sufficient to justify the purchase for those who benefit from it.

3. Create pooled funds that pay people. Foundational projects need budgets for maintenance, documentation, and testing, with transparent administration and developer representation. The organization collecting the money should disclose how much it spends on technical work, its selection criteria, and conflicts of interest. Raising money in the community’s name is not enough if the people carrying the daily workload cannot access it.

4. Include sustainability in public procurement. I propose that institutions allocate an appropriate portion of their systems budgets to maintaining the open source components they depend on, according to importance and risk rather than download counts alone. The Sovereign Tech Fund provides a practical example of investment in open infrastructure, including foundational libraries, tools, and protocols. We need to expand the ability to purchase this maintenance through processes that small teams can navigate. ^[12]

5. Provide shared commercial and legal administration. Cooperatives or intermediary organizations can handle contracts, billing, compliance, and marketing for multiple projects in return for disclosed fees, while leaving technical decisions with the people doing the work. Every programmer should not have to build a complete company just to sell a few months of expertise. License violations also require practical assistance with detection and enforcement.

6. Fund work that is difficult to market. Testing, build improvements, change reviews, resolving longstanding issues, and transferring knowledge to new contributors belong in contracts and budgets. Relying exclusively on vulnerability bounties or eye-catching features leaves essential work unpaid. A good project also needs paid time devoted to preserving its quality.

7. Protect project independence and distribute income fairly. Projects should diversify their funding, prevent financial contributions alone from buying technical control, and establish policies for compensating founders and current contributors. Founders are entitled to payment for their work and to negotiate commercial arrangements involving rights they hold. Founding a project, however, does not automatically confer a permanent entitlement to other people’s work. Fairness includes those who started it, those carrying the burden today, and those who will keep it going tomorrow.

These approaches do not guarantee income for every project, just as closing source code does not guarantee sales. Demand, quality, alternatives, and timing still matter. We can nevertheless build fairer mechanisms for funding work that has demonstrated its value, rather than leaving it dependent on chance and the ability to attract attention.

I also do not want to call seeking funding begging, or looking for a job failure. Both can be dignified professional choices. My objection is to repeated appeals for support becoming the only option for someone whose work others depend on, while those same people demand continuing service as though they were paying that person a salary. Volunteers have the right to set limits on their time and decline commitments they never made.

My position is that opening source code is a major decision that should be accompanied by a plan for rights, funding, and governance. I do not want a return to restrictions that hold users captive, and I reject using freedom of access as an excuse to ignore the cost of production. A community capable of building mechanisms for reviewing code and approving releases can also build fair mechanisms for purchasing maintenance and paying people.

What I am asking is that the creator’s compensation be included in the calculation of software’s value from the beginning. A company that pays to operate its services and market its products can also assess the cost of sustaining the components on which it depends. When those components are critical to its business, funding their maintenance should be a responsible management decision, rather than a temporary emotional response to a security incident.

Free and open source software has helped expand people’s ability to learn, build, and compete. We now need to develop its funding mechanisms with the same seriousness. I will not accept a thank-you message, followed by another request for unpaid work, as the permanent reward for someone who maintains infrastructure that others benefit from.