bits.

FREE Companies & institutions LESSON · Companies & institutions

1983: Make code a commons

GNU, Linux, Debian, licensing, and open-source firms

Richard Stallman's1983 announcement proposed GNU as a free Unix-like system. Linux and Debian appeared later and contributed different parts of widely used software systems. A kernel, a collection of tools, a distribution, and a governance organization are not the same thing. Distinguishing them makes it possible to credit contributors accurately and understand what must be maintained for users to receive a working system.

Source availability is only one boundary. A license specifies permissions and conditions concerning use, modification, and redistribution. Free-software and open-source definitions impose more than the ability to read code. A source-visible program can still forbid sharing or commercial use. Conversely, selling copies or support does not automatically contradict software freedom. The relevant question is which rights recipients actually receive under the applicable terms.

Compare two simplified policies, without treating this exercise as legal advice. PolicyP allows modified redistributions under different licensing terms while retaining required notices. PolicyC requires covered redistributed modifications to preserve specified freedoms and provide corresponding source under its conditions. These policies create different incentives and obligations. Their scope must be read from the actual license: linking, distribution, and network access are not universally treated alike across all copyleft licenses.

Imagine a public library used by ten companies. Each independently spending 20 days to fix the same defect consumes 200 engineering days. One shared fix taking 30 days including review and testing can avoid much duplicated effort. Yet somebody must fund those 30 days and maintain the result. Public availability does not guarantee that every beneficiary contributes. Governance and maintenance capacity determine whether the shared resource remains dependable.

Debian's constitution gives a concrete example of institutional design. It distributes authority among developers, the project leader, technical bodies, and voting processes. Its Social Contract and Free Software Guidelines state commitments about the distribution. These documents do not write code themselves; they explain who can decide, how disputes can be handled, and which promises constrain the project. A permissive repository without a functioning decision process can still stall.

Forking supplies an exit mechanism but is not free in the economic sense. A fork needs maintainers, security response, release infrastructure, compatible packages, documentation, and users willing to move. An organization can have permission to fork while lacking the capacity to do so. Practical autonomy depends on transferable knowledge and operational competence as well as legal permission.

Evaluate sustainability with a specific maintenance ledger. Who reviews changes? Who can publish a release? How are vulnerabilities handled? What happens if a key maintainer leaves? Which dependencies have different licenses or release schedules? Open code makes inspection and collaboration possible, but it does not prove correctness, security, or inclusive governance. The historical lesson is that licenses and institutions jointly shape a commons; neither can substitute for the other.

Reconstruction exercise

Ten firms each expect to spend 20 days repairing the same dependency defect. A coordinated upstream fix needs 30 days, plus each firm spends two days integrating it. Compute the total effort and saving. Then suppose only one maintainer can approve releases and leaves. Explain why source access alone does not restore service, and propose two governance or operational measures that reduce this dependency without sacrificing review quality.

Worked solution

Independent repairs cost 200 days. Shared development and integration cost 30+10×2=50 days, saving 150 under the stated assumptions. The calculation excludes coordination failures and assumes the fix suits every firm. If the sole release maintainer leaves, users still need trusted signing, review authority, build procedures, package distribution, and someone able to investigate failures. Documented release procedures and more than one trained, accountable release maintainer reduce the single-person dependency. A published succession or delegation process can preserve legitimacy while independent review and reproducible builds preserve quality. Permission to fork remains valuable, but maintaining a usable replacement requires people, knowledge, and operating systems around the repository.

Test the limits and transfer the idea

1. Queue and governance design · allow 25 minutes

A shared fix still needs review capacity

A fictional open-source project receives 12 patches per week. One maintainer can review eight per week; 20 are already waiting. Assuming constant rates and no withdrawals, compute the backlog after six weeks. Two trained reviewers then add four reviews each per week. How long does clearing that backlog take while new patches continue arriving? Explain one governance change and one quality check needed before counting the extra capacity as real.

Get a starting hint

Backlog changes by arrivals minus completed reviews; clearing uses spare capacity after new arrivals.

Compare your reasoning with the worked solution

With one maintainer, backlog grows by four per week and reaches 20+6×4=44. Total later review capacity is 8+4+4=16, leaving four reviews per week beyond the twelve arrivals, so clearing requires eleven weeks under the fluid model. A governance change must actually authorize qualified reviewers to approve the relevant changes and enable release progress; advisory reviews waiting for the same sole approver may not increase the bottleneck's throughput. Quality checks can include independent review of security-sensitive patches and sampled regression outcomes. Debian's constitution is a primary governance instrument; it does not prove that this fictional project's capacities or decision process exist. Count observed completed reviews and downstream release work, not names added to a maintainer list.

Check your reasoning

  • Calculates backlog 44 and eleven-week clearance.
  • Identifies approval authority as a possible unchanged bottleneck.
  • Pairs additional authority with measurable review quality.

2. Policy interpretation and transfer · allow 25 minutes

Audit a claim of a freely maintainable commons

Under fictional policy P, recipients may inspect and modify source privately but may not redistribute any version. Under fictional policy Q, recipients may run, modify and redistribute source and binaries, but releases require no endorsement from the original author. A team says both are equivalent because both publish source. Compare whether a third party can distribute an urgent repair after the original maintainer disappears. Separate permission, technical capability and project authority. Do not treat either invented policy as the text of a named real license.

Get a starting hint

The ability to read a file does not answer who may send a repaired version to users.

Compare your reasoning with the worked solution

P allows a private patch but, as stipulated, forbids distributing that patch as a program version. Q permits the third party to distribute a repair, but supplies no signing keys, build knowledge, reviewer capacity or user trust. The original project's endorsement is also distinct from the right to publish a fork. A practical repair path needs reproducible builds, dependency knowledge, a separate trustworthy distribution identity and clear migration information. The GNU announcement is a primary statement of intent, while Debian's constitution and Social Contract are governing commitments of a particular project. They can be read to understand goals and authority, but neither substitutes for the actual license on a different package or evidence that a fork can maintain it successfully.

Check your reasoning

  • Distinguishes source inspection from redistribution permission.
  • Explains why permitted distribution does not ensure operating capability.
  • Keeps invented policies separate from actual license and governance documents.

Check your understanding

A project grants permission to fork but has one departing release maintainer. Which capability still matters?

  • Source code automatically reconstructs every signing credential.
  • Trusted release knowledge, infrastructure, review authority, and trained maintainers.
  • Permission guarantees an operational replacement exists immediately.
  • A fork requires no security maintenance.
Explanation

Legal exit rights are valuable but do not supply all operational resources for a dependable distribution.

Ten firms each avoid a 20-day repair by sharing a 30-day fix and spending two integration days each. What is the total shared effort?

  • 200 days.
  • 230 days.
  • 30 days.
  • 50 days.
Explanation

The shared development costs 30 and ten local integrations add 20; coordination and suitability assumptions still matter.

Sources and further reading