by Michael Hollister
Exclusive published at Michael Hollister on October 25, 2026
Part 1 read here:
Terafab – Part 1: The Factory for AI in Space
Part 2 read here:
Terafab – Part 2: Why Space? The Physical Wall
Part 3 read here:
Terafab – Part 3: Escape Upward
5.354 words * about 28 minutes readingtime
Why the Data Center in Space Must Not Be a Data Center
Part 3 ended not with an answer, but with a design question. Assume the entire construct is established exactly as the legal order permits: registered in the United States, under the jurisdiction of a favorably disposed state, and physically beyond European reach. The question then leads back from jurisprudence to hardware. How do you build a data center in orbit so that no one can switch it off? What does the architecture of a structure look like if it must not only dispose of its own heat, but also survive an attack, evade debris, and continue computing when any individual component fails?
This part provides the answer, and it can be condensed into a single sentence that also serves as the thesis of the entire installment: The data center in space must not be a data center. It must be a swarm. Not one enormous station with the computing power of half a continent, whose loss would be catastrophic, but thousands, tens of thousands, perhaps millions of standardized modules, none of which is important on its own.
At first, this may sound like one of several conceivable designs. It is not. The central finding of this installment is more stringent: The swarm is not one option among many; it is the only one that works at all. It is so compelling because it solves 5 problems at once, each of which could otherwise doom the entire undertaking by itself. The physics of low Earth orbit already dictates this architecture. That the same architecture also eases the cooling problem, withstands debris, renders an attack ineffective, absorbs individual failures, and permits scaling is not a fortunate coincidence. It is the convergence examined in this installment. Everything points to the same design principle.
Let us begin where the decision is made: with the choice of orbit.
The Choice of Orbit Determines Everything-and It Determines Multiplicity
Before discussing the number of nodes, one must discuss their altitude. Orbit is not one setting among many that can be adjusted later. It is the fundamental choice from which almost everything else follows-and the answer is surprisingly clear.
Four regions are possible in principle, and 3 fall away under closer examination. Medium Earth orbit, ranging from a few thousand to more than 12,000 miles above Earth, practically rules itself out. This is where the Van Allen belts lie: zones of trapped charged particles in which radiation exposure is so intense that sensitive computing technology would age faster than it could perform useful work. Geostationary orbit, at an altitude of just under 22,400 miles, has a different but equally severe disadvantage. A signal traveling from there to Earth and back takes approximately a quarter of a second-240 milliseconds-which is an eternity for interactive computing workloads. Resupplying an installation at that altitude would also be extraordinarily difficult; every delivery flight would cost many times as much as a launch into low orbit. And the region beyond the Moon-cislunar space-may be strategically interesting, but it is not the place for a data center intended to serve customers on Earth. That belongs to a different story, one this installment deliberately does not tell.
That leaves low Earth orbit and, within it, one particular trajectory that seems almost tailor-made for this undertaking: a dawn-dusk sun-synchronous orbit. It follows the boundary between day and night, allowing the Sun to shine almost continuously-the very advantage Part 2 identified as the key to the energy equation. Latency to Earth is low because the orbit is close. Resupply is affordable because the journey is short. And the Sun remains in view almost continuously because the orbit follows the terminator. On paper, the decision has effectively been made before the debate even begins. Google’s published design for a scalable, space-based AI infrastructure likewise centers on a compact formation in sun-synchronous orbit.
The crucial point, however, is not the advantage of low orbit but the constraint it imposes. Low Earth orbit demands many nodes; it does not permit just a few. An object circling Earth at that altitude moves quickly, covers only a narrow band of sky at any given moment, and needs companions in neighboring orbital planes merely to maintain continuous contact with the ground. A single node above Central Europe will be over the Atlantic a few minutes later and over North America soon afterward. If the data connection to Earth is never to break, the next node must already be rising above the ground station as the first drops below the horizon. That requires many nodes. The residual atmosphere, still present as a faint drag even hundreds of miles above Earth, slows every object and forces it to use propulsion to avoid gradually sinking and ultimately burning up. Traffic is also dense, requiring room to maneuver and redundancy. Any one of these factors would argue against a solitary megastation. Together they reverse the entire debate: In low orbit, the swarm is not a design preference freely chosen by an engineer. It is a consequence of physics. Anyone who chooses the obvious altitude has already chosen multiplicity. The orbit selects the swarm, not the builder.
The dawn-dusk version intensifies this constraint rather than relaxing it. Precisely because it follows the line between day and night and therefore keeps the Sun from setting, it occupies a narrow and especially desirable band. Many operators want this exact orbit because it delivers the energy advantage described in Part 2. Anyone entering it must share the space and design the constellation to fit, maneuver, and coordinate with others. This, too, argues against the solitary colossus and in favor of a distributed formation capable of adapting elastically to a narrow, contested orbital band. The choice of orbit therefore provides not only the energy advantage and low latency; it also provides the first reason to conceive of the data center not as one object, but as a multitude-long before cooling, debris, or failures even enter the discussion.
Convergence I: The Cooling Wall Dissolves Once You Think Small
This brings back a familiar problem, the one Part 2 identified as the hardest physical constraint on the entire project: heat. Space does not cool; it insulates. In a vacuum, no air or water can carry heat away. The only remaining option is slow radiation across large surfaces. The larger and more compact the station, the more devastating the problem becomes, because heat accumulates in its interior while the required radiator area grows to astronomical proportions. A single megastation delivering the computing power under discussion would be a thermal nightmare whose cooling equipment would weigh many times more than the computing hardware itself.
That wall now dissolves without changing a single law of physics. What changes is not the physics, but the size of each individual object. The explanation is a simple geometric law: As a body grows, its volume-and therefore the amount of computing hardware and waste heat inside it-increases with the cube of its dimensions, while its surface area increases only with the square. The larger the structure, the worse the ratio between heat-radiating skin and heat-generating core becomes. The colossus suffocates under its own mass because its surface area cannot keep pace. A small node reverses the relationship in its favor. A device processing only a few kilowatts has abundant surface area relative to the heat it produces. That heat does not have to travel far from a densely packed interior to the outside; it is generated close to the radiating surface, and a suitably sized radiator is sufficient to release it. What was impossible for the megastation becomes a solved problem for a small unit-and one backed by decades of experience, because spaceflight has used orbital radiators to reject heat since the first large stations were placed above Earth. Each node must dispose only of an amount of heat familiar from decades of human activity in orbit, not the output of an entire power plant at once.
There is also the leverage described in Part 2, which becomes fully effective only in a small node. The amount of heat a surface radiates does not increase linearly with temperature, but with the fourth power. Allow the chips to run hotter than they do on Earth, and every square foot of radiator releases dramatically more heat, reducing the required area accordingly. That is precisely what Terafab’s space chip is designed to do from the outset. In a large, densely packed colossus, that heat would be almost impossible to control without cooking neighboring components. In a free-standing small node whose hot radiator faces the open vacuum, it becomes the very characteristic that allows the unit to operate with little surface area. The thermal leverage and the small design reinforce one another.
The approximate size of these nodes can now be specified with some precision because the figures no longer appear only in rough calculations; they are present in regulatory filings and academic papers. Public discussion of SpaceX’s application for 1 million satellites refers to data-center nodes weighing approximately 4.4 US tons-not a station filling an urban district, but a device that a single rocket could deploy by the dozen. The academic literature works on a similar scale. One tether-based architecture for solar-powered orbital AI data centers arranges computing nodes along a chain, calculates sustained power of between 2 and 20 megawatts per structure, and explicitly relies on radiative cooling and integrated shielding that allows the same mass to perform 2 functions. These are not fantasy figures. They are the design to which a sober assessment of the thermal problem leads in any case.
The first strand thus fits into the larger picture. Cooling was never a problem inherent in the concept. It was a problem of scale. Break one enormous structure into many small ones, and the wall disappears-not through a trick, but because small bodies shed heat more easily than large ones. The megastation was the problem. The swarm is the solution, even before attack, debris, or component failure has entered the discussion.
Convergence II: The Real Adversaries Are Small and Fast
When people imagine dangers in orbit, they first think of the large, dramatic image-the impact that destroys everything. That image should be taken seriously and then corrected, because it identifies the wrong adversary. The asteroid, the meteor, the catastrophic object arriving from nowhere is not the threat model that determines the architecture of an orbital swarm. Such events are so rare that no design could sensibly protect against them, and they strike orbit no more frequently than they strike the ground. Anyone who solves the cooling and computing problems only to despair over meteorites has mismeasured the threat.
The real adversaries are small, and that is precisely what makes them dangerous. At orbital velocities-several miles per second-a particle only a fraction of an inch across carries the force of a projectile. Mass is not what makes it lethal; speed is. There are 2 populations, and each requires a different response. The first consists of micrometeoroids and tiny fragments of debris smaller than a fingernail. They cannot be tracked individually because they are too small for ground-based sensors to detect, and modeling estimates put their number in the hundreds of millions. Evasion is useless because no one knows where they are. The only defense is robustness. Spaceflight has known the answer for decades: a multilayer shield in which a thin outer wall does not attempt to stop the particle, but deliberately shatters it and disperses it into a cloud of fine dust. The impact is then spread harmlessly across a second wall. What the armor cannot accomplish through thickness, it accomplishes through spacing. A few inches of this construction are sufficient to intercept the great majority of these tiny projectiles. For a small node, that is manageable. The shield is not a crushing burden, but a controllable addition-and in the tethered academic design, the shielding already required against radiation performs this task at the same time.
The second population is larger and tracked individually, shifting the response from endurance to evasion. The latest European Space Agency assessment shows how dense orbital traffic has become, and its numbers have increased again since Part 2. Depending on the counting method, more than 34,000 cataloged objects or over 40,000 regularly tracked bodies now move through Earth’s orbital regions. Models that include untracked debris estimate approximately 54,000 objects larger than 4 inches-each large enough to destroy a satellite in a collision. Below that are more than 1 million fragments measuring between roughly 0.4 and 4 inches and about 140 million even smaller objects. The collision risk has risen by one-fifth since 2024 alone, and specialists identify the altitude around 340 miles as a particular hotspot. In October 2026, observers recorded a fresh satellite breakup in this already crowded zone. The ESA Space Environment Report 2026 documents the worsening debris environment, while a separate review of NASA and ESA tracking figures details the growing number of hazardous objects.
This is where low-orbit physics gives the swarm its defense at no additional conceptual cost. Every node at that altitude already requires propulsion simply to resist the braking effect of the residual atmosphere. The same maneuverability that prevents it from falling also allows it to evade a tracked piece of debris. This is not a theoretical promise. The large satellite constellations already in orbit collectively perform hundreds of thousands of such avoidance maneuvers every year-automatically, routinely, as part of normal operations. What would require elaborate additional equipment for a solitary colossus is built into every swarm node. Its ability to maneuver comes as a by-product of the need to remain in orbit at all. The second strand therefore points in the same direction as the first: The architecture that eases the cooling problem already includes its own defense against debris.
Convergence III: Whatever Fails Is Allowed to Burn Up
The natural hazards have now been placed in context, but one question remains, and it is the most uncomfortable of all. What happens if a node is nevertheless struck? What if debris hits it, a component fails, or a module simply dies? For a single megastation, this would be the catastrophe toward which every risk converges: one strike, one total loss, billions destroyed in a single orbit. That vulnerability is precisely why the megastation will never be built.
The swarm answers the question with a composure that is initially unsettling. If a node fails, let it fall. Do not repair it, recover it, or mourn it. Drag from the residual atmosphere gradually lowers its orbit until it burns up during reentry, while the network distributes its workload among the remaining nodes and continues computing without any noticeable interruption. The individual node is not precious; only the network is. What would be inconceivable for a conventional supercomputer-a component fails and is simply written off-is the swarm’s built-in mode of operation. A loss is not a disruption that must be prevented, but an anticipated normal event absorbed by the mass of the system.
This is the same principle on which today’s large orbital communications networks already operate: Scale, standardization, and redundancy replace a small number of expensive, irreplaceable individual assets. No single device has to last for a long time; there merely have to be enough devices at all times. Existing satellite networks demonstrate that the model works. Failed or obsolete units are continuously replaced without any perceptible interruption for users on the ground. The real, currently operating infrastructure described in Parts 1 and 2 provides proof of the principle-not that the computing swarm already exists, because it remains a proposed project, but that its intended operating model is already practiced in orbit on a massive scale. The swarm transfers a proven logic from communications to computing.
Whether that logic is economically viable depends on one condition, however, and intellectual honesty requires drawing the boundary as sharply as the advantage itself. Replenishing the swarm works only as long as transportation into orbit becomes cheap enough-and it becomes cheap enough only when the launch vehicle is fully reusable. The technology is still in the middle of development at precisely this point. In September 2026, the heavy rocket intended to provide the resupply capability reached orbit for the first time and deployed a real payload. That was a genuine milestone, but it was the first. At the time of writing, the decisive capability-recovering the upper stage intact and flying it again-had not been demonstrated even once. The flight intended to test it was still pending. An October 2026 report noted that Starship Flight 15 was expected to attempt recovery of the upper-stage spacecraft. This point must be stated clearly because the entire logic of allowing nodes to burn up and replacing them depends upon it. The logic is sound, but it rests on a step that has not yet been completed. Resilience is built into the swarm’s architecture; its economics are not-at least not yet.
With that qualification, the third strand fits seamlessly into the others. What makes the individual node vulnerable makes the network resilient, provided replacements can be launched. The individual failure that would have destroyed a megastation becomes background noise for the swarm. Once again, no clever trick solves the problem. It is solved by the same multiplicity that already released the heat and maneuvered around debris.
Convergence IV: Growth Means Launching More, Not Rebuilding
The fourth strand is the shortest because it is essentially a consequence of the third. Yet it closes the arc back to the beginning of the series and therefore belongs here. If the swarm consists of many identical, replaceable nodes, expanding it is not a new construction project but an addition. More computing power does not require building a larger installation. It simply means placing more nodes into orbit. You do not rebuild; you launch more.
This connects the present installment directly to what Part 1 established about demand and Part 2 established about launch cadence. Part 1 calculated that the hunger for computing power is not growing linearly but exponentially-that a fleet of autonomous vehicles, billions of robots, and artificial intelligence’s own appetite will create demand beyond ordinary comprehension. A monolithic station could never keep pace with that growth. It would already be too small when completed because demand would have continued to expand during the years required to build it. This is precisely the planning error Part 1 described using undersized facilities as an example: Anyone building for today’s demand will be equipped for the day before yesterday by opening day. Placing a second megastation beside the first would mean repeating the same enormous, years-long undertaking merely to double capacity.
The swarm, by contrast, grows with demand-node by node, flight by flight. It need not be fully planned before it becomes useful. It begins operating with the first node and continues growing while in operation. If demand rises, launch more. If it falls, allow older nodes to age out without replacing them. Scaling, maintenance, and initial deployment are all the same operation: sending another standardized component into orbit. Whether the swarm is being established, a burned-up node is being replaced, or its performance is being doubled, the action is always the same-place one more module into orbit. The fourth strand therefore points in the same direction as all the others. The architecture produced by physical necessity happens to be exactly the architecture capable of keeping pace with exponentially growing demand-or, more accurately, this is not coincidence at all, because both follow from the same decision in favor of multiplicity.
Proof It Is Not Merely Musk’s Idea: The Entire Industry Is Building It This Way
At this point, a misunderstanding must be dispelled before it takes root. The swarm might sound like a peculiarity, a daring idea conceived by one man while the rest of the world has yet to understand it. The opposite is true, and the evidence is in plain sight. Look at the other actors working on orbital data centers and the same architecture appears everywhere-not because they copied one another, but because physics dictates the same answer to all of them.
The clearest evidence comes from a competitor with no connection to Musk. Starcloud, a company closer to Nvidia’s ecosystem than SpaceX’s, has applied to the US regulator for a constellation of 88,000 satellites-not one station, but a network of tens of thousands. That sits alongside the SpaceX application for 1 million satellites discussed in Part 3, and the 2 numbers must be kept distinct: The 1 million belong to SpaceX and describe the computing factory itself, not the communications network; the 88,000 belong to Starcloud. Two different companies, 2 different applications, the same basic form-many small nodes instead of one large station. An overview of the competitive landscape for orbital data-center startups shows that this distributed approach extends well beyond a single company.
What Google’s Project Suncatcher has published is even more revealing because its figures are public and precise. Its computing satellites are intended to fly in a dawn-dusk sun-synchronous orbit at a mean altitude of approximately 404 miles and in a compact formation. One example configuration uses 81 satellites within a radius of about 0.6 miles, with distances between them varying from roughly 330 to 660 feet. They are connected by free-space optical laser links intended to provide aggregate bandwidth in the tens of terabits per second. An initial laboratory test bench has already reached 800 gigabits per second in each direction-a combined 1.5 terabits-through a single transmitter pair. Logically, these many separate bodies operate as one distributed machine. The same form appears in the academic literature, including the tethered architecture with its 2 to 20 megawatts per structure. Three independent actors, the same answer.
That 3 such different actors arrive at the same form is the real evidence. They use different chips, have different backers and timelines, and possess no incentive to imitate one another. One is a multibillion-dollar internet corporation, another a startup associated with a chipmaker, and the third a group of university researchers. What unites them is not a common fashion but a shared boundary condition: the same physics of low Earth orbit, forcing the same answer upon each of them. When independent minds using different methods arrive at the same solution, that solution is rarely a matter of taste and usually a matter of necessity.
This is the point that reinforces Part 1’s thesis. If a startup, an internet corporation, and academic researchers independently arrive at the swarm, then it is not a stroke of genius but the consensus of an entire field. Musk’s distinction is not that he alone conceived the idea. As Part 1 showed, it is that he alone owns all 3 components: in the future, the chips from his own factory; the rocket that carries them into orbit; and the network that returns the results to Earth. The others must obtain at least one of those components elsewhere-and the largest provider of launch capacity from whom they may have to purchase it is also their competitor in the same race. Musk shares the architecture with the entire industry. What sets him apart is not the idea but the completeness of his position.
Bringing the Argument Back to Earth: The Case Against Swarm Euphoria
Up to this point, the swarm may appear to be an elegant solution to every problem-an architecture with no remaining obstacles. That impression would be wrong, and allowing it to stand would turn an analysis into advertising. Serious objections exist. They come from specialists and identify real vulnerabilities. They must be presented prominently and fairly before any findings are drawn.
The most important objection comes from an astronomer who has spent years studying the sustainability of orbital activity. Aaron Boley, co-director of the Outer Space Institute, counters the enthusiasm with one sober figure. In his words, every ton placed into orbit requires 10 to 30 times its weight in fuel. That means enormous quantities of exhaust are deposited in the upper atmosphere, with consequences that remain poorly understood. Extrapolate that ratio to the millions of tons that constructing such a swarm would require over the years, and it becomes an environmental cost absent from the polished architectural diagrams. Boley’s warning about the fuel ratio and poorly understood atmospheric effects addresses the project’s foundation rather than a minor detail. A more recent academic study reaches in the same direction by calculating the full life cycle of an orbital data center-from manufacturing and launch to reentry-and concluding that its emissions may be up to an order of magnitude higher than those of a terrestrial data center. The study, Dirty Bits in Low-Earth Orbit: The Carbon Footprint of Launching Computers, makes clear that the swarm may solve thermal management in orbit without settling the environmental bill on Earth.
A second objection challenges the claim that cooling has been solved. It has-but only for each individual small node, which is not the same as solving it for the system as a whole. Distribution across many units relocates the heat problem; it does not make it disappear. Thousands of radiators must deploy reliably, survive years of uninterrupted operation, withstand micrometeoroid impacts, and function without ever being touched by a human hand. Significantly, Google-the company that has developed the concept in greatest detail-still explicitly identifies thermal management as one of Project Suncatcher’s unresolved challenges. Solved at small scale does not mean solved at large scale. It means only that the problem has changed form.
A third objection approaches the asteroid question from an unexpected direction. It is true that the large object is not the swarm’s relevant threat model-but the swarm may itself become a threat model for others. Astronomer Samantha Lawler has noted that observers use twilight to detect near-Earth asteroids and that extensive solar arrays in precisely the dawn-dusk sun-synchronous orbit favored by the swarm could seriously interfere with that search. Her criticism of space-based data centers and their effects on asteroid observations produces a revealing reversal: The celestial object does not threaten the swarm; the swarm threatens the view with which we find celestial objects. An honest assessment of risk must also count the risks created by the project itself.
A fourth objection leads directly to the boundary of this installment. The swarm’s redundancy, the argument has maintained, makes it nearly invulnerable to the loss of individual nodes. That is true-but only against failures that strike one node after another. Redundancy offers little protection against threats that operate across an entire area: disruption of laser links over broad regions, attacks on ground stations, or a deliberately created debris cloud rendering an entire orbital segment impassable. This boundary will be named here, but not explored, because it leads out of engineering and into a different question.
Findings
Let us record what this installment has established. The choice of orbit clearly favors a low, dawn-dusk sun-synchronous trajectory-and that orbit imposes multiplicity rather than permitting a single station. Everything else follows from that one constraint. Cooling, still the hardest wall in Part 2, dissolves once the large installation is divided into small nodes capable of radiating their heat with relative ease. The swarm answers the debris threat in 2 ways: robustness against tiny, untracked projectiles and evasion of larger, tracked objects. The necessary maneuverability is already built in because each node must use propulsion against atmospheric drag. The swarm absorbs the loss of individual nodes by allowing them to burn up and replacing them-provided cheap resupply becomes possible, which still depends on a launch system whose decisive upper stage has yet to be recovered intact. Its method of scaling is the same as its method of maintenance: launch more instead of rebuilding.
The decisive point is not the enumeration of these 5 advantages, but the fact that they are not truly 5 separate advantages. They are one finding viewed from 5 directions. Every answer to every problem is the same: many small nodes instead of one large station. Cooling requires it. Debris requires it. Failure requires it. Scaling requires it. And low-orbit physics had already required it before any of these problems appeared on the table. The swarm is therefore not one of several conceivable designs. It is the only one that works-and it does so with an almost uncanny inevitability because so many independent lines of reasoning converge on the same point. That half the industry has independently arrived at the same form is not a coincidence but confirmation: Where physics permits only one answer, everyone finds the same one.
And yet one thread remains loose at the end, and it is the most disturbing of all. It is the fourth boundary that was just identified but not explored. The very characteristics that make the swarm resilient for civilian purposes-its distribution, its redundancy, its replaceability, and the absence of any worthwhile single target-are, word for word, the same characteristics one would want in an infrastructure intended to survive an attack. The civilian advantage of resilience and the military quality are not 2 separate things that happen to coexist. They are one and the same, viewed from 2 sides. As long as the adversaries against which the swarm must prevail are micrometeoroids and unthinking debris, the matter remains an engineering question. But anyone creating an area-wide threat-anyone disrupting the laser links, attacking the ground stations, or deliberately producing a debris cloud-is no longer a micrometeoroid. That is an intentional actor. From the moment an intentional actor confronts such a swarm, the question is no longer technical. Part 5 will examine it.
About the Author
Michael Hollister
is a geopolitical analyst and investigative journalist. He served six years in the German military, including peacekeeping deployments in the Balkans (SFOR, KFOR), followed by 14 years in IT security management. His analysis draws on primary sources to examine European militarization, Western intervention policy, and shifting power dynamics across Asia. A particular focus of his work lies in Southeast Asia, where he investigates strategic dependencies, spheres of influence, and security architectures. Hollister combines operational insider perspective with uncompromising systemic critique-beyond opinion journalism. His work appears on his bilingual website (German/English) www.michael-hollister.com and in investigative outlets across the German-speaking world and the Anglosphere.
Stay informed without having to work through the daily flood of news – the most important developments and connections summarized for you.
Sources
Swarm Architecture and Orbital Geometry-Primary Academic Sources
- Google Research. “Exploring a Space-Based, Scalable AI Infrastructure System Design.”
- Tether-Based Architecture for Solar-Powered Orbital AI Data Centers. arXiv:2512.09044.
Life-Cycle Emissions of Orbital Data Centers
- Dirty Bits in Low-Earth Orbit: The Carbon Footprint of Launching Computers. arXiv:2508.06250.
Fuel Requirements and Sustainability Criticism-Boley and Lawler
- KALW. “Google’s Project Suncatcher Aims to Put Data Centers in Space.”
- Scientific American. “Data Centers in Space Aren’t as Wild as They Sound.”
Orbital Debris and the Kessler Environment-2026 Status
- European Space Agency. “ESA Space Environment Report 2026.”
- New Space Economy. “What Does NASA’s September 2026 Orbital Debris Report Reveal About the Future of Crowded Orbits?”
Starship Status-Flight 14 Orbital, Flight 15 Pending
- New Space Economy. “Starship Flight 15 Will Attempt to Recover Its Upper-Stage Spacecraft in November.”
Orbital Data-Center Competitors-Starcloud’s 88,000 Satellites
© Michael Hollister – Republishing is expressly encouraged.
I am pleased when my articles, essays, and analyses attract interest and are shared more widely. The complete or partial reproduction, distribution, and publication of my texts on other websites, blogs, or in other publications is expressly permitted and encouraged. Prior authorization is not required.
<u>Sole requirement:</u> Michael Hollister must be named clearly and prominently as the author. In addition, a clearly visible, clickable link to the original website www.michael-hollister.com must be provided.
Reuse without author attribution and a link is not permitted.
If this work helps you understand what lies behind the headlines, consider supporting it. Membership starts at $5 per month, includes access to all supporter-only analyses, and can be cancelled at any time.
