Computing History · Open Source History
What a Neutral Foundation Holds and What It Cannot Change
Foundations exist to hold the assets a project cannot own as a group: copyright title, trademarks, funds and release infrastructure; their legal form decides what they can do, and neutrality is a matter of procedure rather than of intent.
A group of contributors is not a legal entity. It cannot hold a trademark registration, sign a contract, own a bank account, carry insurance, employ somebody, or be named as a plaintiff. Those gaps appear at the moments a project most needs them: when a distributor puts the project name on a product, when a contributor’s employer asks who the counterparty is, when a security response needs coordination with an embargo, or when a license violation requires a rights holder with standing to sue. The organisation that fills the gap is what open-source practice calls a foundation, and what it holds is always the same short list.
Neutrality is the other motive, and it is easier to describe as a procedure than as a virtue. When several companies depend on one project, each wants the assurance that no competitor can unilaterally change the license, seize the name, or direct releases. An entity whose governance documents say who may make those decisions, and whose decisions are reviewable, is the standard answer.
The assets, and why the name is the important one
The first asset is copyright title, which is normally partial. A foundation can only hold what contributors assigned or licensed to it, so its effective control over the codebase depends entirely on which inbound mechanism the project uses; a project that collected signed-off certifications has a foundation that can defend the license but cannot relicense, as set out in contribution agreements. Mixed title is the common state, and it is the reason a foundation is often unable to do the one thing outsiders expect of it.
The second asset is the trademark, and it is the strongest lever precisely because no license grants it. Permissive and copyleft licenses alike pass on copyright permissions only; the Apache License 2.0 states expressly that no trademark rights are conveyed. A modified build published under the original name therefore does something the license never permitted, and the trademark policy becomes the instrument that governs how far a downstream distributor may go before it must rename. Distributions that patch a program and rename the result are following that policy rather than the license.
The third set is operational: the domain, the hosting, the signing keys for releases, the mailing lists, and the accounts that publish packages. Whoever holds these holds the practical authority described in maintainer authority and forks, which is why a stewardship transfer in practice means transferring accounts rather than announcing a change of leadership.
The legal form decides the range of action
In the United States the two categories that recur are the charitable organisation and the business league. The difference is not cosmetic: charitable status affects whether donations are deductible for the donor and constrains what the organisation may do with its funds, including how much activity may serve the commercial interests of its members, while a business league can serve members’ interests directly and does not offer the same treatment of donations. Foundations in other jurisdictions take whatever local form plays the equivalent role.
Within the charitable or league form there are two structural choices. The first is fiscal sponsorship: an established organisation holds the money, employs staff, and signs contracts on behalf of a project that has no legal existence of its own. The project keeps its own governance and its own name, and the sponsor supplies the legal person. The second is ownership: the organisation holds the project’s copyright and trademark, admits the project through a review process, and defines who may speak for it. The Apache Software Foundation is the clearest example of the second, with projects admitted through an incubator and the foundation holding the marks. The Linux Foundation hosts projects, sometimes as distinct legal entities funded for a single scope, which is the arrangement used when several competing vendors want one neutral home for a shared component. The Software Freedom Conservancy operates as a sponsor with a compliance programme for the licenses it stewards, and the Free Software Foundation holds copyright for the GNU packages whose licenses it publishes. Structures also split along a commercial line: an organisation may hold the project’s assets while a wholly owned for-profit subsidiary runs the product and the services built on it.
Neutrality as procedure
Procedural neutrality shows up in three places. The first is who may change the license. A foundation that holds assignment-based title can relicense; one that holds a license grant can do so only within the grant; one that holds nothing must ask the contributors, and the answer can be no. The second is who controls releases and the name, which is settled by the trademark policy and by the account-holding arrangement rather than by technical leadership. The third is the license itself, where a copyleft license with an “or later” clause gives a special position to the license’s publisher: the recipient of a work under GPL version 2 or any later version may choose a later version published by the Free Software Foundation, so the stewardship of the license text becomes a governance role that projects inherit by choosing that form of words. The grant remains a choice offered to each recipient, not an obligation, which is why projects can stay on version 2 while the license steward publishes version 3.
The admission process is where neutrality is tested before it is granted. Larger foundations run a staged intake in which a project must show an intellectual-property review of its code and dependency licenses, a contributor base that is not dependent on one employer, and a documented decision process before it is accepted. The review is procedural by design: it does not judge the code, it documents who holds what.
Where the money comes from and what it can buy
Stewardship organisations are funded by donations and by membership dues from the companies that depend on the projects they host. Membership commonly buys participation in a governance forum and, in member-governed organisations, a vote in the elections that choose the board, which is the structural difference between a sponsor with influence and a sponsor with formal authority; elsewhere the dues buy nothing but the right to be listed and to attend a technical advisory call.
Money can be spent only on what the entity is chartered to do: contracting development work, employing maintainers or administrators, buying infrastructure, paying for legal advice, funding security review, and covering the costs of events and travel. The important capability is employment, because it converts volunteer attention into contracted time. A maintainer employed to work on a project still holds merge rights through the project’s own conventions and not through the employment relationship, and whether the employing organisation can replace that person is decided by the governance documents rather than by the payroll. That separation is deliberate and it is also the source of the recurring tension: a funder who cannot instruct the maintainer can stop funding them.
Earmarked donations and grant programmes direct money at a named component or a named task, which is how organisations respond to the problem that a widely depended-on library may have no users willing to fund it as a whole. The limit on all of it is that money buys time and not knowledge: a module whose only expert has left the project cannot be maintained by hiring someone, and a budget cannot shorten the interval during which the new maintainer becomes that expert.
The limits that no foundation removes
Three limits apply regardless of form. A foundation cannot make anyone work on a project; maintainers who leave take their attention with them, and a well-funded project can be as unmaintained as an unfunded one. A foundation cannot make technical decisions that the project’s own committers would refuse, short of replacing the governance that appoints committers, which is an option that costs the community it is applied to. And a foundation cannot relicense code whose rights it does not hold; the same consent problem that confronts a company confronts a trustee, which is the whole subject of relicensing a mature project.
The failure mode that follows is nominal stewardship. An organisation exists on paper, holds the trademark and the domain, and ratifies decisions already made by a single vendor whose employees write the code. Nothing about the arrangement is illegal or even unusual, but the neutrality the entity advertises is not supplied by anything it does. The opposite failure is over-formalisation: intake processes, committee seats, and trademark reviews imposed on a project with three contributors and no commercial users, where the paperwork costs more attention than the code receives.
Winding down is the least-discussed limit. Organisations do dissolve, and when they do the assets need destinations: the marks, the domains, the rights to code whose holders have scattered. Projects that had no entity at all reach the same point earlier, when the last maintainer stops responding and the domain registration lapses with nobody to renew it.
References
- Working in Public: The Making and Maintenance of Open Source Software — Nadia Eghbal, Stripe Press
- Roads and Bridges: The Unseen Labor Behind Our Digital Infrastructure — Nadia Eghbal, Ford Foundation
- Apache License, version 2.0 — Apache Software Foundation
- GNU General Public License, version 2 — Free Software Foundation
- Software Freedom Conservancy — Software Freedom Conservancy