top of page

Why We Publish Under AGPL-3 | P3-006

Broadcasting Free Computation

When we think about open-source software, we often focus on the code itself—the functions, the features, the architecture. But there's a deeper pattern at work, one that becomes visible when you step back and look at how software actually moves through networks of people and machines.

Stylized white "Liberated" text on a black background, conveying a bold and freeing mood.

Software isn't just a static artifact. It's a transmission. A broadcast. And the license you choose determines whether that broadcast can propagate freely or whether it gets captured and silenced at certain nodes in the network.


That's why we've decided to publish all NTARI software exclusively under the GNU Affero General Public License version 3 (AGPL-3). Let's talk about why.


Software as Signal Transmission

Think about what happens when you release open-source software. You're not just making code available—you're broadcasting computation. You're transmitting the capacity to perform specific operations to anyone with a receiver (a computer, an organization, a community).


Proprietary software operates like an encrypted broadcast: the signal reaches you, but you can't decode it, modify it, or retransmit it. You're a passive receiver with no ability to participate in the transmission network.


Free software works differently. It transmits in the clear. Anyone can:


Decode the signal (read the source)


Modify the signal (adapt the code)


Become a broadcaster themselves (redistribute their version)


This creates what network theorists would recognize as a many-to-many broadcast network. Code doesn't just flow from a single source to multiple endpoints—it propagates through networks of developers, users, and organizations, each one potentially both a receiver and a transmitter.


This isn't metaphor. This is the literal topology of collaborative software development.


The Receive-Only Problem

Here's where GPL v3 has a gap.


Under GPL v3, if someone receives your broadcast, modifies it, and releases copies to others, they must retransmit with the same freedoms. The broadcast continues. But there's a loophole: if they modify your software and deploy it only on their own server, letting others interact with it remotely, they function as a receive-only node. They accept the broadcast but never retransmit.


For server-based software—which describes most of NTARI's cooperative infrastructure—this creates dead zones in the broadcast network. Improvements accumulate at server nodes but never propagate outward. The network topology fragments. Instead of a mesh where signals flow in multiple directions, you get hub-and-spoke patterns where servers absorb improvements without redistributing them.


This contradicts the purpose of broadcasting free computation.


AGPL-3: Eliminating Receive-Only Nodes

AGPL-3 adds one requirement: if you broadcast computation to users by running modified software on a server, you must also broadcast the source code to those users.


In network terms, AGPL-3 eliminates receive-only nodes. Every server that accepts the broadcast and provides computational services must also function as a transmitter, making its modifications available for download.


This maintains network symmetry:


Receive freedom → must transmit freedom

Accept improved code → must broadcast improved code

Benefit from the commons → must contribute to the commons


How Improvements Propagate

Consider two scenarios:


Without AGPL (receive-only nodes allowed):

  • NTARI broadcasts TOS protocol

  • 10 organizations deploy with private modifications

  • Community receives only NTARI's original signal

Improvements remain isolated at 10 nodes


With AGPL (broadcast required):

  • NTARI broadcasts TOS protocol

  • 10 organizations deploy and must rebroadcast modifications

  • Community receives NTARI's signal plus 10 variants

  • Each organization can incorporate others' improvements

  • Network intelligence compounds


The second scenario creates what network theorists call preferential attachment: nodes with more connections attract more connections. Unlike proprietary networks, the strengthened nodes broadcast their improvements back out.


Network Theory Principles in Practice

Transparency as Signal Clarity

AGPL-3 eliminates hidden operations. When you interact with an AGPL-licensed server, you have access to the source code generating that interaction. The computation you experience is the computation you can examine, modify, and rebroadcast. No gap exists between the service and its source.


Democracy Through Broadcast Access

Democracy requires informed participation. When computation happens on opaque servers, users cannot participate in decisions about the tools shaping their interactions. AGPL-3 ensures that server-side computation broadcasts its own source code, enabling users to:

  • Understand what operations are being performed

  • Audit for behaviors

  • Fork and establish alternative broadcasts

  • Participate as technical citizens


This is computational sovereignty: the right not just to use services, but to understand and operate the infrastructure providing them.


Public Benefit Through Unrestricted Propagation

Proprietary server software creates asymmetric value extraction: operators benefit from user data and interaction while users remain dependent on opaque services. AGPL-3 inverts this. When operators must broadcast their source:

  • Value flows in multiple directions rather than one direction

  • Capabilities diffuse through networks rather than concentrating

  • Communities can operate their own instances rather than depending on providers

  • The benefit of computational improvements becomes public


Network Topology Reflects Values

Our organizational structure mirrors our technical architecture: distributed governance, transparent documentation, volunteers coordinating through networks. AGPL-3 ensures our code embodies the same topology. No authority can capture and privatize the broadcast; every deployer must function as both receiver and transmitter, maintaining the distributed, many-to-many network structure.


Implementation Across Roles

For NTARI Development (Broadcast Source)

All NTARI RAND projects transmit under AGPL-3:

  • Complete, documented source code

  • Public repositories with transparent development

  • Documentation encouraging deployment and modification


For Organizations Deploying NTARI Software (Broadcast Nodes)

When you deploy our software on a server, you become a broadcast node:

  • Receive: Download and understand the source code

  • Modify (optional): Adapt to your community's needs

  • Broadcast: Make your source available to your users

  • Amplify: Contribute improvements back upstream when possible (encouraged, not required)

This is reciprocity in practice. You benefit from our broadcast; your users benefit from yours.


For Users (Broadcast Recipients)

When you interact with AGPL-licensed services, you have rights:

  • Reception: Access to the source code powering your interactions

  • Decoding: Ability to understand how the service operates

  • Retransmission: Right to deploy your own instance

  • Modification: Freedom to adapt the broadcast to your needs

These rights transform users from consumers into potential operators—recipients who can become broadcasters.


What AGPL-3 Does and Doesn't Solve

The SaaSS Question

AGPL-3 doesn't address Software as a Service Substitute (SaaSS), where users send their data to external servers for processing. Even with source access, users don't control computation happening on someone else's hardware.


But AGPL-3 provides the prerequisite for escaping SaaSS traps: the ability to establish alternative broadcast nodes. When source code is available, communities can:

  • Audit server operations for data practices

  • Deploy their own instances with modified privacy protections

  • Migrate away from operators who misuse their position

Build federated networks of trusted nodes

Source access doesn't guarantee user control, but it makes user control possible.


The Path We Take

Our solution to SaaSS aligns with broadcast principles: operate your own receivers and transmitters. AGPL-3 ensures the capacity to do so remains distributed. We encourage:

  • Community-run instances rather than centralized providers

  • Federated architectures where multiple broadcasters cooperate

  • Local computational sovereignty supported by global code sharing


Why This Matters for Network Society

NTARI's mission centers on developing "systems, protocols and programs for online global cooperatives inspired by network theory." The license we choose determines whether that mission can succeed.


AGPL-3 is our commitment to maintaining many-to-many broadcast topology in digital infrastructure. We refuse to release software that could be captured at receive-only nodes, creating the hub-and-spoke extraction patterns that concentrate power and fragment cooperation.


By ensuring broadcast of source code at every server deployment, we create conditions where:

  • Technical improvements propagate like signal through networks

  • Cooperative capacity compounds rather than isolates

  • Communities can establish sovereign computational infrastructure

  • Network effects strengthen the commons rather than private monopolies


Building Broadcasting Infrastructure

When you deploy NTARI software, you don't just run a service. You become a broadcast node in a distributed network of free computation. We provide the initial signal; you amplify and adapt it; the network grows stronger with every transmitter added.


This is how we build an internet that serves cooperation rather than extraction: one broadcast node at a time, each transmitting to all who can receive.


The topology we build today determines the internet we inhabit tomorrow. Hub-and-spoke creates dependence. Mesh creates sovereignty. AGPL-3 ensures our code maintains mesh topology even as it scales across networks.


We invite you to join the broadcast. Deploy our software. Modify it for your community. Make your source available to your users. Contribute improvements upstream when you can. Become both receiver and transmitter.


The network theory is simple: more nodes broadcasting means stronger signals for everyone.


Your broadcast begins when you deploy the code. The network waits for your signal.


Comments

Rated 0 out of 5 stars.
No ratings yet

Add a rating
bottom of page