What Does Open-Source Mean?

Listen to this article on Spotify after Jan. 5, 2026: Listen

The Party Line Problem

Before World War II, rural telephone service worked through "party lines"—shared circuits where eight or ten families overheard each other's conversations. The system was crude but democratically transparent: everyone heard the same information at the same time, and no single entity controlled access. When AT&T consolidated American telephony, party lines disappeared. The company owned the network, owned the switches, owned the phones. You couldn't modify the system, couldn't see how it worked, couldn't build your own telephone. You rented access to infrastructure you could never examine or improve.

Software followed the same arc. Today, when your city contracts with Tyler Technologies for fire department dispatch software, the city cannot see the code, cannot modify it for local needs, cannot share improvements with other cities, and certainly cannot escape vendor lock-in without starting from scratch. Private equity buys the software company, raises prices, and cities pay—because the alternative is rebuilding systems that run emergency response.

Open source software reverses this trajectory. It returns to party line principles with 21st-century infrastructure.

What Open Source Software Actually Means

Open source software provides four essential freedoms that proprietary software denies:

1. The freedom to run the program for any purpose - No restrictions on who uses it or how

2. The freedom to study how the program works and modify it - Source code must be accessible, readable, and changeable

3. The freedom to redistribute copies - Share exact copies with neighbors, cities, cooperatives

4. The freedom to distribute modified versions - Share your improvements back to the community

These freedoms sound abstract until you see them in practice. When Linux powers most web servers, smartphones run Android (Linux underneath), and cities deploy open-source 911 systems, you're watching cooperative infrastructure outcompete proprietary alternatives. The source code flows like water—anyone can access it, anyone can improve it, improvements propagate freely.

But a gap appeared when software moved to network services.

The Cloud Loophole That AGPL-3 Closes

In the early internet, sharing software meant sharing source code—not because programmers were generous, but because you couldn't run the software otherwise. You received code, compiled it, ran it on your machine. If someone modified the GNU compiler, the GPL license required them to share modifications when they distributed the software.

Then cloud computing created a loophole. Companies could:

1. Download open-source software

2. Modify it extensively for their purposes

3. Run it on their servers as a network service

4. Sell access to users

5. Never share a single line of modified code

Users clicked buttons on screens, never seeing the code underneath. The GPL didn't trigger because the company never "distributed" the software—you just accessed it remotely. Google could modify open-source tools, run them as services, and keep all improvements private. Your city could do the same: take open municipal software, modify it, run it as a service for residents—and never contribute improvements back.

AGPL-3 (GNU Affero General Public License version 3) closes that loophole with one crucial requirement:

If you run modified AGPL-3 software as a network service—letting others interact with it over a network—you must provide them with the source code of your modified version.

Every server becomes transparent. Every improvement becomes shareable. The cooperative software ecosystem stays intact even when software moves from desktop to cloud.

NTARI's Municipal Counter-Automation Strategy: AGPL-3 as Economic Weapon

NTARI's Municipal Counter-Automation Strategy weaponizes AGPL-3 licensing against corporate platform monopolies through a mechanism they call "resource starvation."

Here's how it works:

The Three-Layer Architecture

Cities face accelerating corporate automation that concentrates wealth while displacing labor. Self-driving vehicles, AI-powered services, and platform monopolies extract billions from local economies. The municipal counter-automation strategy responds with three cooperative infrastructure layers:

Layer 1: Municipal Broadband - Fiber networks owned by residents as public utilities, not rented from Comcast or AT&T

Layer 2: Platform Cooperatives - Transportation, housing, food systems where workers own the platform (5-15% fees instead of corporate platforms' 40% extraction)

Layer 3: Distributed Manufacturing - Fab labs and maker cooperatives coordinating through open protocols, producing goods locally

The strategy requires releasing everything under AGPL-3: municipal broadband management systems, platform cooperative coordination tools, distributed manufacturing protocols, agricultural data networks. All code becomes commons.

The Resource Starvation Mechanism

When cities develop this infrastructure and release it under AGPL-3, corporations face three losing options:

Option 1: Contribute to the Commons

• Use the AGPL-3 tools cities have built

• Release all modifications as open source

• Lose competitive advantage as improvements spread freely

• This costs them control

Option 2: Develop Parallel Proprietary Systems

• Avoid AGPL-3 tools entirely

• Rebuild municipal broadband management from scratch

• Duplicate thousands of developer-hours already in the commons

• This costs them resources

Option 3: Stay Away from Markets Where AGPL-3 Tools Dominate

• Decline to compete in municipal infrastructure

• Cede markets to cooperatives

• This costs them market access

All three options weaken corporate positions. The licensing structure creates a strategic trap where corporations cannot win.

Why This Works: Commons Network Effects

Normally, network effects favor large platforms—Facebook grows stronger as more users join. AGPL-3 creates commons network effects in reverse:

• The first city pays full development costs

• The second city downloads working software

• The hundredth city deploys proven tools

• Development costs distribute across all adopters

• Each contribution strengthens shared infrastructure

Corporate competitors cannot achieve this cost structure. Their proprietary code cannot spread freely, so each deployment bears full development burden. Meanwhile, cities implementing AGPL-3 systems face asymmetrically lower costs.

A transportation cooperative in Austin improves the routing algorithm under AGPL-3. A fab lab in Baltimore optimizes manufacturing protocols. A municipal broadband network in Cincinnati enhances the management interface. All improvements flow back to commons. The ecosystem strengthens through distributed contribution—exactly like Linux kernel development, except now it's applied to municipal infrastructure and economic coordination.

The Historical Pattern

This follows infrastructure transitions we've seen before:

• Telegraph monopolies → telephone competition → AT&T monopoly → 1984 breakup → competitive landscape

• Proprietary Unix → GNU/Linux → corporate Unix decline

• Closed web browsers → Mozilla → Chrome (built on open-source) → Firefox resurgence

• Proprietary version control → Git → GitHub/GitLab dominance built on open infrastructure

When communities build commons-based alternatives with strong copyleft licensing, corporate monopolies either adapt or decline. NTARI applies this pattern to economic infrastructure itself.

Economic Impact: Capital Flow Reversal

The numbers make the strategy tangible. Cities currently extract wealth toward distant shareholders:

• Louisville example: $400-650 million community wealth retention over seven years

• New York City scale: $20-58 billion over the same period

• Regional economy ($50B): $10-15 billion redirected annually, compounding to $100-150 billion over ten years

This capital doesn't require taxation or redistribution—it stays local because residents own the infrastructure. Platform cooperative surplus funds fab labs. Manufacturing cooperative surplus funds housing. Each layer generates capital for the next. Growth becomes self-sustaining.

Why AGPL-3 Is Non-Negotiable

The strategy fails catastrophically if cities use weaker licenses:

• MIT/Apache licensing → Corporations adopt and enclose. Amazon runs your fab lab protocols in fulfillment centers without contributing back

• Proprietary partnerships → Cities give away the commons to corporate "innovative" solutions

• Mixed licensing → The commons fractures and corporations enclose profitable pieces

AGPL-3 prevents enclosure while enabling federation. Cities, cooperatives, and communities modify software for local needs, then improvements flow back to commons. Every line of code, every protocol specification, every management interface must use AGPL-3. Early adopters set the standard.

Implementation: Organic Growth, Not Coordinated Deployment

Here's what makes this practical: physical infrastructure can't deploy simultaneously (hardware doesn't exist in sufficient quantities, capital requirements exceed available resources), but software replicates freely.

Year 1-2: Early adopters develop and release AGPL-3 tools

Year 3-5: Mainstream adoption as 50+ cities download proven infrastructure

Year 6-10: Scaled ecosystem with 500+ cities operating cooperative infrastructure

The Urgency Problem

Every month without AGPL-3 alternatives allows corporate proprietary standards to entrench:

• Self-driving vehicles reach commercial scale ~2027-2030

• Manufacturing automation expands ~2028-2032

• Platform monopolies grow stronger through data accumulation

• Political influence of tech corporations increases with wealth

The window for establishing commons-based alternatives closes as corporate systems become entrenched. This is why NTARI emphasizes immediate open source release over delayed coordinated action.

Learn More

Open Source and Licensing:

• Free software definition

• GNU Affero GPL explanation

• History of copyleft

• AGPL-3 full license text

Platform Cooperatives and Municipal Infrastructure:

• Platform cooperativism

• Municipal broadband

• Community network resilience

Distributed Manufacturing:

• Fab lab networks

• RepRap open-source hardware

Join the Work

You now understand why AGPL-3 isn't just a license choice—it's an economic weapon that starves corporate monopolies while enabling cooperative alternatives to scale. The municipal counter-automation strategy depends on developers, researchers, and organizers who see this possibility and want to build it.

Join the community developing these systems in NTARI's Slack workspace, where we're working on municipal broadband management tools, platform cooperative coordination systems, and distributed manufacturing protocols—all under AGPL-3: https://ntari.org/sds

Or support the research and development that makes cooperative infrastructure viable: https://ntari.org/donate

Every city that implements cooperative infrastructure strengthens the commons. Every line of AGPL-3 code makes corporate enclosure harder. The transformation doesn't require revolution—it occurs through construction of parallel systems that outcompete extractive platforms through superior ownership structures and freely available implementation tools.