Harald Welte and the work of opening telecom’s closed interfaces

Summary

• Welte helped make Linux packet filtering inspectable and operable through Netfilter, iptables, connection tracking, logging and documentation, while later maintainers carried the subsystem beyond his active role.
• Through gpl-violations.org, he treated source-code obligations in embedded products as supply-chain requirements, showing that an open licence needed enforcement to preserve downstream access.
• OpenMoko, OpenBSC and Osmocom moved his work deeper into mobile infrastructure, where public implementations created laboratories, interoperability references and specialised production options rather than universal carrier replacements.
• sysmocom and later SIM or eSIM tools show the remaining bargain: open code improves auditability and exit options, but expert labour, hardware, keys, spectrum and regulation still govern deployment.

OpenBSC exposed the recurring choice behind Welte’s career

OpenBSC, which Harald Welte began in 2008, targeted the base-station-controller side of GSM: the layer that allocates radio resources and carries signalling towards switching and subscriber systems. Public specifications described the interfaces, but they did not provide an operating network that researchers could inspect, instrument or change. A working implementation converted standards text into state machines, logs and failure behaviour that could be tested against commercial equipment.

That project distilled a choice Welte had already made elsewhere. In 1999 he joined the Netfilter effort as Linux packet filtering was being rebuilt around kernel hooks and user-space policy. When embedded vendors shipped GPL-licensed networking code without meeting source obligations, he created gpl-violations.org and treated compliance as a supply-chain requirement. OpenMoko then exposed how much of a supposedly open phone remained controlled by basebands, component suppliers and certification.

The projects are institutionally separate. Netfilter is a Linux kernel community; gpl-violations.org was an enforcement initiative; OpenMoko was a handset project; Osmocom is a family of public mobile software; sysmocom is a commercial support company. The continuity lies in the interface Welte chose to open and in the tools he used: implementation, documentation, licence enforcement, community organisation and paid engineering.

Before those projects, Welte described operating bulletin-board and early internet systems, including routing, mail, news and leased connections. That experience helps explain why he treated infrastructure as something that had to be configured, observed, repaired and handed to another operator, rather than as a protocol implemented once.

The governing question is narrower than whether open source can replace telecom vendors. How far can a public implementation turn a closed operational dependency into something an operator can inspect, test and transfer, and which dependencies remain in hardware, keys, spectrum, regulation and specialist labour? Welte’s record is most useful where it answers both sides of that question.

His role also needs collective credit. Rusty Russell initiated the packet-filtering work that became Netfilter. Holger Freyther, Andreas Eversberg and many others made independent contributions to Osmocom. Standards bodies, operators and equipment companies built the larger systems in which the code runs. Welte’s influence lies in making several critical boundaries legible enough for other people to challenge and maintain.

Netfilter separated packet traversal from firewall policy

When Welte joined Netfilter development in 1999, Linux already had firewalling systems. ipfwadm and ipchains could express useful rules, and Linux machines were already serving as routers and gateways. The architectural problem was that the system needed a cleaner way to connect packet traversal inside the kernel with stateful functions and user-space control. Netfilter introduced hooks at defined points in the packet path. Code could inspect or act on packets as they entered a machine, left it, crossed it or moved through related stages. User-space tools could then install rules without turning every policy into a separate kernel design.

The distinction sounds routine now because hook-based packet processing and structured rule management are familiar. At the time, it changed the shape of the subsystem. A packet-filter rule no longer had to be understood only as a command-line entry. It became part of a framework in which packet paths, protocol state, address translation, logging and later extensions could be reasoned about separately. That made Linux more useful as a network appliance platform and gave developers a common place to add functionality.

Welte became a member of the Netfilter core team and led it for a period. His work covered code, user-space libraries, logging and extensive technical explanation. The attribution matters because the project was never one person’s firewall. The practical result came from a group that combined kernel changes with tools operators could actually use. A technically elegant hook is of limited operational value if administrators cannot describe policy, inspect counters, understand error conditions or integrate the system with other software.

Netfilter also illustrates the difference between creating a mechanism and governing its long life. Welte’s active involvement ended years ago; the project lists him as emeritus from October 2012. Current Netfilter and nftables work belongs to later maintainers and contributors. That transition is evidence of success rather than diminishment. Infrastructure code becomes an institution when the project can preserve knowledge, replace leaders and continue changing after an early developer has moved elsewhere.

Its broader significance came from Linux’s spread. Packet filtering and network-address translation were not confined to general-purpose servers. They appeared in routers, gateways, phones, firewalls and embedded appliances. As Linux became a substrate for commercial networking products, choices made in an upstream community acquired supply-chain consequences. A change in connection tracking could affect devices sold under hundreds of brands. A userspace library could become a dependency inside a management platform. A documentation gap could be reproduced across products whose buyers never knew Netfilter was present.

That scale also produced the next problem Welte confronted. The licence that allowed vendors to use the code imposed obligations, and many suppliers treated those obligations as optional.

Connection tracking and NAT made state part of the operating model

A stateless packet filter can examine addresses, ports and protocol fields, but many network policies depend on relationships over time. A reply packet belongs to an earlier request. An FTP data connection may be related to a control session. A translated address has to map consistently while a flow is active. A firewall that cannot represent those relationships either becomes crude or pushes complexity into ad hoc rules.

Connection tracking gave Netfilter a way to classify packets according to a flow’s state and to share that state with network-address translation and other functions. NAT then altered addresses or ports while preserving the mapping needed for return traffic. These mechanisms helped turn ordinary Linux systems into practical gateways. They also created a new class of operational responsibility. State tables consume memory. Timeouts affect application behaviour. Protocol helpers can enlarge the attack surface. Logging must be useful without overwhelming a machine.

Rule ordering can produce outcomes that are correct according to syntax but wrong according to the operator’s intent.

Welte’s contribution to logging infrastructure, including early work around ulogd, is important in this context. A packet decision that cannot be observed is difficult to debug and impossible to audit at scale. Moving selected events toward user space allowed operators to store, process and correlate information without making the kernel a reporting system. Libraries around connection tracking similarly gave other programs access to state that would otherwise remain trapped behind command output or private interfaces.

The work therefore concerned more than speed or feature count. It created boundaries. The kernel handled packet traversal and protected state. User space expressed policy and consumed information. Libraries reduced the need for every management application to invent a parser. Documentation made the subsystem available to people who had not participated in the mailing-list discussion that produced it.

Those boundaries were not fixed forever. nftables later changed the user-space and kernel expression model, and current maintainers continue to revise the subsystem. Yet the operating problem remains recognisable: networking infrastructure has to expose enough state for an operator to make decisions while preserving the performance and safety of the packet path. Welte’s Netfilter period established his preference for solving that problem with open interfaces rather than with an opaque appliance.

It also supplied a direct lesson about collective credit. A sign-off, core-team role or prominent utility does not prove that one developer authored every mechanism. A responsible profile has to distinguish leadership, original implementation, maintenance, review and later redesign. Welte’s significance survives that distinction. In fact, it becomes clearer. He helped make a collective subsystem legible and usable, then moved on while the project continued under others.

GPL enforcement made source compliance a manufacturing obligation

The commercial success of embedded Linux revealed a contradiction. Vendors benefited from a common code base, shipped it inside routers, phones and appliances, and sometimes failed to provide the source or notices required by the GNU General Public License. The technical community could see its work in products, yet the practical means of obtaining the corresponding source were weak. A licence that existed only as a statement of principle offered little protection when a supplier ignored requests.

Welte founded gpl-violations.org and pursued compliance through notices, negotiation and litigation in Germany. The significance of that work was not that every dispute went to court or that enforcement became universally admired. It was that a free-software licence was treated as an enforceable part of the product supply chain. Suppliers had to identify which components they shipped, preserve licence information, make source offers meaningful and ensure that distributors could meet obligations inherited from upstream code.

For networking equipment, this was especially consequential. A router assembled from a system-on-chip vendor’s board support package, a contract manufacturer’s image, a brand owner’s interface and community networking code could pass through several organisations before reaching a customer. Each participant could assume someone else had handled compliance. Enforcement exposed that assumption. The cost was not limited to publishing a tarball. A company needed a software bill of materials, reproducible source correspondence, notices, build information and a process for responding when the shipped binary no longer matched an internal archive.

The initiative also generated controversy. Licence enforcement involves judgement about notice, remedy, settlement and public disclosure. Community members have disagreed over strategy and institutional governance. It would be inaccurate to present every action as uncontested or to claim that Welte alone transformed global compliance. The defensible conclusion is narrower: he demonstrated that vendors using GPL-licensed infrastructure code could face concrete legal consequences, and that demonstration helped make compliance an operational function rather than a voluntary courtesy.

This episode connects to his later telecom work in a way that is easy to miss. Opening an interface is not only a matter of publishing code. The terms under which code remains available determine whether downstream improvements return to the community or disappear into appliances. Enforcement sought to preserve that return path. Without it, an open implementation could become raw material for another closed product, leaving operators with the same dependency the project was meant to reduce.

There is no simple formula for when litigation is the right instrument. Cooperative remediation may solve many cases faster. Aggressive enforcement can consume scarce maintainer time and damage relationships. Yet the embedded-device record showed that goodwill was not enough. Welte’s institutional contribution lay in treating licence obligations as part of infrastructure maintenance: unglamorous, sometimes adversarial and necessary if the legal architecture was to match the technical one.

OpenMoko showed how far an open phone could reach

Welte’s move to OpenMoko in 2006 took him from a kernel networking subsystem into a product whose openness depended on hardware, telephony, power management, user-space software and a manufacturing chain. As lead system architect, he worked on a Linux-based smartphone before Android established the market model that would dominate the next decade.

The attraction was clear. A phone that exposed its operating system and application stack could be studied and modified in ways mainstream handsets did not permit. Developers could inspect drivers, replace software and experiment with interfaces. The constraint was equally clear: a mobile device is not only its visible operating system. Baseband processors, radio firmware, certification, component documentation and network interoperability remain separate layers. A handset can be open in one part and closed in another.

OpenMoko therefore became a practical lesson in the limits of software freedom when the supply chain is not equally open. Component changes can invalidate drivers. Power-management behaviour can depend on undocumented hardware. Radio functions operate under regulatory and carrier requirements. Manufacturing volume determines which vendors will provide documentation or long-term support. A community can modify source code, but it cannot compel a chip supplier to continue a component or make a certification process disappear.

The project did not become the dominant mobile platform. That outcome should not be rewritten as a failure of the underlying questions. It exposed where the boundary of control actually lay. The experience helped redirect Welte’s attention from the application-facing phone toward the cellular protocols and network functions around it. If the handset’s Linux environment was open but the network side remained a collection of black boxes, independent experimentation would still stop at the radio interface.

OpenMoko also broadened his engineering frame. A firewall project can often assume a general-purpose machine and a known kernel. A phone forces coordination across boot loaders, power states, peripherals, user interaction, baseband communication and production hardware. That background mattered when he started working on network-side GSM. Telecom systems fail not because a protocol diagram is unavailable, but because timing, state, hardware and operational assumptions do not align.

The transition from OpenMoko to OpenBSC was therefore not an abrupt change of subject. It was a move deeper into the same problem: which parts of mobile communications could be made inspectable and which dependencies would remain outside the code.

OpenBSC turned standards documents into a network that could be examined

In 2008, Welte began OpenBSC, initially an open implementation of the base-station-controller side of GSM. Public specifications described many interfaces, but a specification is not an operating network. It does not automatically provide state machines that behave correctly under failure, interoperable signalling, management tools, databases, timing or a way to observe what commercial equipment is doing.

The base station controller sits between radio equipment and higher network functions. It manages radio resources, coordinates channels and carries signalling toward switching and subscriber systems. Implementing that role created a testable point inside a network that had usually been purchased as an integrated vendor stack. Researchers could connect equipment, trace messages and change behaviour without asking a supplier to expose proprietary internals.

OpenBSC’s importance was not that it instantly replaced carrier-grade networks. Early deployments and laboratories had different requirements from nationwide mobile operators. Commercial systems brought redundancy, certification, hardware integration, support organisations and years of field behaviour. The open implementation supplied something else: a reference that could be read, modified and used to test assumptions at interfaces where standards left room for interpretation.

That distinction matters in telecom. Standards are extensive, but they contain optional behaviour, version differences and dependencies on other documents. Vendors make choices, sometimes defensible and sometimes idiosyncratic. When two systems disagree, an operator needs more than a statement that both claim compliance. An open stack allows engineers to inspect the state transition, change a timer, add logging or reproduce the exchange in a controlled environment.

The project also made older mobile technologies accessible to people outside incumbent equipment companies. GSM remained widely deployed, and its security limitations were well known, but practical network-side experimentation required infrastructure. OpenBSC lowered that barrier. It became a foundation for training, security research, specialised networks and later modular components.

The attribution must remain precise. Welte initiated the project and was a major architect, but OpenBSC quickly became collective work. Holger Freyther and other contributors added substantial code and operational knowledge. The later Osmocom stack is not a personal product owned by its founder. Its legitimacy comes partly from the fact that people can challenge, modify and maintain it independently.

OpenBSC also marked a change in scale. Netfilter exposed packet processing inside a general operating system. OpenBSC exposed the control logic of a communications network with subscriber databases, radio management and signalling relationships. That broader system required the project to separate functions that had initially been convenient to run together.

Osmocom became a set of network functions rather than one replacement box

The name Osmocom now covers a broad family of open mobile and communications projects. It is tempting to describe the result as an open mobile network stack, but that phrase can conceal more than it explains. There is no single binary that replaces every operator function. The network is divided into components with distinct responsibilities and interfaces, and each component has its own maturity, maintainer history and deployment constraints.

OsmoBSC controls radio resources and coordinates base-station connections. OsmoMSC provides mobile-switching functions and call or mobility control. OsmoHLR stores subscriber information and authentication-related data. OsmoSGSN and OsmoGGSN implement parts of the packet core used for GPRS services. OsmoPCU handles packet-control functions closer to the radio side. OsmoBTS provides base-station software for supported hardware families. Signalling components, media gateways and management tools connect those functions into a working system.

This modularisation was an important development from the earlier OpenBSC design. An all-in-one program is convenient for initial experiments, but it hides boundaries an operator eventually needs to manage. Separate processes make interfaces explicit. They allow a function to be replaced, scaled, tested or isolated. They also introduce operational work: configuration consistency, service discovery, version compatibility, logging, security and failure handling between components.

The stack’s value varies by use case. A research laboratory may prioritise visibility and the ability to change protocol behaviour. A private network may need a limited set of services and known radio coverage. A specialised production environment may value support for older equipment or protocols that a large vendor no longer prioritises. An interoperability lab may use Osmocom as a reference implementation against commercial devices. None of those examples proves that the same architecture is suitable for a national public network.

OsmoBTS illustrates the relationship between open software and physical infrastructure. Software can implement base-station functions, but radio hardware still determines timing, bandwidth, RF characteristics and supported interfaces. Ports to different platforms require detailed knowledge of firmware, clocks, transport and regulatory limits. A laboratory success does not automatically become a maintainable commercial deployment. Hardware availability can also outlast or end before the software’s usefulness does.

OsmocomBB extended experimentation toward the handset side of GSM. It allowed researchers to examine parts of the mobile-station protocol stack that were normally embedded in baseband firmware. The work helped expose security and interoperability behaviour, but it did not make ordinary consumer phones fully open or safe. Radio transmission remains regulated, and 2G protocols retain structural weaknesses that software transparency cannot erase.

The broader Osmocom ecosystem includes TETRA research, software-defined-radio components, protocol libraries and tools beyond the core GSM network. This breadth has turned the community into an archive of communications knowledge as well as a software supplier. Older systems often remain in operation after commercial attention has shifted elsewhere. Open code and documentation can preserve the ability to test, migrate or maintain them.

That preservation function is strategically important but financially awkward. Legacy protocols may be vital to a small number of users without producing the revenue of a mass-market platform. Maintainers need laboratories, hardware and time. A volunteer-only model can struggle to sustain specialised expertise. The formation of sysmocom was one answer to that problem.

sysmocom created a commercial layer beside the community

Welte and Holger Freyther founded sysmocom in 2011. The company provides engineering, integration, products, training and support around Osmocom and related open systems. Its existence demonstrates a hybrid model common in infrastructure software: the core code can remain publicly available while customers pay for the work required to make it reliable in a specific environment.

That paid work can include hardware, deployment design, protocol changes, testing, migration, troubleshooting and long-term support. A customer does not necessarily want ownership of a private code branch. It may want a known engineer to take responsibility when a network fails. Commercial support supplies an accountability relationship that a public mailing list cannot guarantee.

The model can also fund upstream maintenance. Engineers solving a customer problem may improve shared components, add tests or document an interface. That is the constructive cycle: commercial demand pays for work whose general parts return to the community, and the public project reduces duplicated engineering for later customers.

There are tensions. A customer may request a feature too specific or sensitive for upstream publication. A company may possess more maintainer time than unaffiliated contributors. Product deadlines can conflict with community review. The boundary between company hardware, customer deliverables and community code must be clear if users are to understand what support they are buying and what governance applies.

Public information does not provide a complete picture of sysmocom’s ownership, revenue, staffing or customer mix. It would be irresponsible to infer scale from conference visibility or project activity. The supported conclusion is that the company gives Welte and other specialists a commercial vehicle for sustaining work that would otherwise depend on sporadic volunteer time.

This arrangement also complicates the simple claim that open source eliminates vendor dependence. A network may avoid one proprietary stack and still depend on a small group of experts who understand the open alternative. Source access improves exit options, auditing and the ability to recruit another engineer, but it does not instantly create a large support market. The resilience of the model depends on documentation, contributor breadth and whether knowledge is distributed beyond the founding team.

The interfaces between functions make the mobile stack legible

A list of Osmocom component names can make the system sound like a catalogue. The more useful way to understand it is to follow the responsibility for one subscriber as that responsibility moves through the network. Radio resources are assigned close to the base station. Mobility and call control sit higher in the switching layer. Subscriber data and authentication information live in a register. Packet service requires a different chain of functions and tunnels. Media may take another path again. Each transition is an interface at which an implementation can be inspected, tested or replaced.

On the radio side, OsmoBTS connects supported base-station hardware with the network software above it. It has to translate between hardware-specific timing and radio behaviour and the more general control expected by the BSC. OsmoPCU handles packet-data scheduling and radio resources for GPRS. OsmoBSC coordinates cells, channels and signalling toward the switching layer. Even in a small network, those responsibilities are not interchangeable. A timing defect near the radio cannot be fixed by changing the subscriber database; a mobility problem in the switching layer cannot be diagnosed from RF power alone.

OsmoMSC handles mobility and call-control functions that historically lived inside a mobile switching centre. OsmoHLR maintains subscriber records used by other network elements. Media gateways separate voice media handling from signalling control. The packet chain adds OsmoSGSN and OsmoGGSN, reflecting the GPRS architecture in which mobility and session state are coordinated while user traffic is carried toward external packet networks. The project has also developed signalling-transfer and management components that let these functions communicate in a more explicit architecture.

This separation has two consequences. The first is technical clarity. An engineer can place traces at a specific boundary, compare the messages with the relevant standard and decide which side violated the expected state. The second is organisational choice. A deployment can keep one component, replace another or use an open element as a test peer for commercial equipment. That choice is the practical meaning of reduced vendor dependence. It does not require every element to come from the same open project.

Modularity also creates failure modes that an integrated appliance may hide. Versions can disagree about an interface. Certificates, subscriber data and configuration may be inconsistent. A process can be healthy while the service path is broken elsewhere. Operators need monitoring that follows a transaction across components, not only a collection of process counters. They need backup and restoration procedures for subscriber state, controlled upgrades and an understanding of which data can be recreated after a failure.

The architecture is especially instructive for smaller or specialised networks because it reveals how much work is bundled into a commercial mobile core. Buying a single system can make procurement simpler, but it can also obscure the boundaries that matter during an incident. Building from open components exposes those boundaries and transfers more integration responsibility to the operator or support company. The resulting freedom is real, and so is the labour required to use it.

That is why the phrase “open GSM stack” needs qualification. Osmocom supplies implementations across a remarkable number of functions, yet a production network still needs planning, lawful spectrum, radio design, transmission, subscriber operations, security, charging or business systems, support and often interconnection with other networks. The project opens a large part of the technical chain. It does not remove the organisation around that chain.

Reference implementations change the terms of interoperability disputes

Telecom interoperability is often described as a standards-compliance question, but operational disputes rarely arrive in that clean form. Two products may both cite the same specifications and still disagree about optional information elements, timer behaviour, error recovery or an interpretation carried from an older release. Each supplier can claim the other side is at fault. An operator without access to either implementation may have little evidence beyond traces and vendor assertions.

An open implementation changes that negotiation. Engineers can reproduce the exchange, identify the state transition and alter one assumption at a time. They can add a log at the point where a message is rejected, test an alternative timer or construct a minimal peer that sends the disputed sequence. The open system does not automatically become the judge. It becomes an instrument for producing evidence.

That role is sometimes more valuable than replacing the commercial product. A vendor may remain the right supplier for scale, certification or support, while an Osmocom component provides an independent test environment. Equipment makers can use it during development. Security researchers can build controlled networks. Operators can compare releases or preserve a test peer after an old vendor platform is withdrawn.

The same principle applied earlier in Netfilter. A public packet-processing framework allowed users to inspect where a decision occurred instead of accepting an appliance’s summary. In cellular systems, the state is more distributed and the standards more extensive, but the method is similar: expose the interface, build a reproducible implementation and make disagreement visible at the level of messages and code.

Reference implementations have limits. They can contain bugs, and their reading of a standard can be idiosyncratic. They may support only a subset of features or hardware. A successful exchange in the lab does not prove behaviour under load, failure or hostile traffic. A responsible interoperability programme therefore uses the open implementation alongside packet captures, standards review, device-specific testing and, where possible, multiple independent peers.

The institutional effect is nevertheless important. Vendors negotiate differently when an operator can demonstrate the failing sequence and show a working alternative. A closed interface makes the customer dependent on the supplier’s diagnosis. An inspectable one gives the customer a basis for escalation and a way to distinguish a standard defect, an implementation defect and a configuration error.

Legacy protocols create a maintenance market that ordinary growth metrics miss

Much of Osmocom’s most mature work concerns GSM, GPRS and other systems that are no longer the centre of mobile-industry investment. That can make the project look backward-looking if relevance is measured only by the newest radio generation. Infrastructure ages differently from consumer products. Networks remain in service because devices, industrial systems, transport equipment, laboratories or regional operators still depend on them. A technology can be commercially unfashionable and operationally difficult to retire.

The resulting maintenance market is unusual. The user population may be too small to support several large vendors, but the cost of abrupt replacement can be high. Documentation and open code become a form of continuity insurance. They allow an operator to diagnose behaviour after the original supplier has reduced support, to migrate in stages or to build a gateway between old and new systems.

This does not mean every legacy network should be preserved. Older cellular standards have security weaknesses, limited efficiency and shrinking hardware options. The decision has to compare the risk of continued operation with the cost and feasibility of migration. Open implementations improve that decision by making current behaviour visible and by providing tools for controlled transition. They should not be used to disguise an unsafe system as modern.

The economics also explain why commercial support matters. A small group of users may each need specialised expertise only occasionally. A company such as sysmocom can pool that demand, maintain test equipment and retain engineers whose knowledge would be uneconomic for any one customer to employ full time. The public project then captures at least some of the resulting improvements.

There is a risk of concentration. When only a few engineers understand a protocol and its surviving hardware, open source can still depend on a narrow labour market. The remedy is not simply more code. It is reproducible test environments, clear manuals, training and deliberate succession. Conference recordings and public issue histories become assets because they lower the cost for a new engineer to enter the field.

The legacy role also gives Osmocom a broader cultural value. Communications history is often preserved as documents while the executable systems disappear. A working stack retains knowledge about timing, state and implementation choices that a specification alone cannot convey. Researchers studying cellular security or protocol evolution can test hypotheses against running code rather than relying only on historical descriptions.

That archival value should be kept separate from production claims. A project can be technically and historically important without holding a large current market share. For Welte’s profile, the distinction matters because it prevents two opposite errors: dismissing the work as obsolete, or inflating specialised deployments into evidence that open GSM has displaced mainstream vendors.

Open hardware experiments widened the same argument beyond software

Between his best-known networking and cellular projects, Welte also worked on RFID, smart-card and open-hardware efforts including OpenPCD and librfid. These projects are smaller in public visibility than Netfilter or Osmocom, but they reinforce the same concern with interfaces that combine protocol logic and physical devices.

RFID and smart-card systems are difficult to understand from software alone. Timing, modulation, antennas, analogue behaviour and proprietary readers influence what can be observed. An open reader or protocol library gives researchers control over the exchange and lets them inspect layers that a consumer device abstracts away. It also exposes the point at which openness stops: a chip may still contain secret keys, undocumented behaviour or manufacturing constraints.

The hardware work provided useful preparation for cellular systems. Base stations and SIMs are not generic files processed by a normal application. They interact with precise timing, electrical interfaces and security boundaries. A developer who has only worked above those layers may underestimate how much an implementation depends on the physical platform.

Open hardware also has a different sustainability problem from software. A repository can be copied indefinitely, but a board depends on components, fabrication files, assembly and testing. A discontinued chip can make a design hard to reproduce. Documentation therefore has to include the bill of materials, hardware revisions and known substitutes, not only source code.

These experiments did not create a universal open-hardware supply chain. Their relevance lies in making the dependency visible. They strengthened the practical argument that inspectability requires control of enough of the system to reproduce the behaviour under study. That argument later shaped the way Osmocom treated radio platforms and SIM hardware: software openness is necessary, but the surrounding device and trust chain determine how much independent operation is actually possible.

SIM and eSIM work moved openness toward the identity control point

Subscriber identity is one of the most consequential control surfaces in a mobile network. A SIM or eSIM profile contains identifiers, applications and cryptographic material that help determine whether a device can authenticate and receive service. Provisioning, remote administration and lifecycle management therefore combine telecom operations with security, standards and organisational authority.

Welte’s later work has increasingly focused on this layer. pySim provides open tools for inspecting, programming and managing SIM-family cards where the user has the necessary authorisation and keys. osmo-remsim implements a specialised architecture for making physical SIM resources available through remote clients and banks. His presentations and writing have examined eUICC profile formats, GlobalPlatform mechanisms, over-the-air administration and the practical structure behind terms that are often reduced to consumer marketing.

The technical benefit of open tooling is observability. Engineers can inspect files, applications, identifiers and command exchanges. They can automate legitimate provisioning, reproduce failures and compare implementation behaviour with published specifications. A private or laboratory network can understand how subscriber data moves rather than treating the card as an unexplained token.

The security boundary is strict. Tools do not grant access to keys an operator has not provided. Remote provisioning does not mean arbitrary profile installation. GlobalPlatform and GSMA-related systems rely on trust relationships, certificates, secure channels and authorised roles. An open implementation can reveal how those mechanisms work, but it cannot make the legal and cryptographic controls optional.

osmo-remsim should also not be confused with ordinary consumer eSIM service. It is a remote-SIM architecture designed for specialised environments, test systems and operational arrangements where SIM access is deliberately centralised. Its value comes from separating the physical card from the radio device while preserving the protocol interaction. That can help laboratories, device farms and controlled deployments, but it introduces latency, availability and security dependencies of its own.

The move toward SIM and eSIM work continues the pattern visible in Netfilter and OpenBSC. The target is a layer where operators depend on a protocol but often receive only a vendor interface. Publishing code and explanation makes the control point inspectable. It also reveals that technical openness and operational authority are different. The party holding keys, certificates and contractual rights still determines what actions are permitted.

That helps explain why Welte’s work should not be described as an attempt to abolish telecom institutions. Standards bodies, operators, regulators and security authorities remain necessary. His contribution is to reduce the amount of trust placed in undocumented implementation and to give engineers a reference against which institutional claims can be tested.

Conferences and documentation preserve knowledge that code alone cannot

A repository records implementation, but it rarely records all the assumptions needed to operate a telecom system. Why was a timer chosen? Which vendor deviation is common? What does a failure look like on the wire? How should a base station be connected to a test network? Those answers often live in conference talks, mailing-list threads and the memory of maintainers.

Welte has invested heavily in technical presentations and community events. Osmocom gatherings, remote development calls and recorded talks have covered architecture, protocol behaviour, SIM systems, eSIM formats, GlobalPlatform and performance analysis. This material is part of the infrastructure. It gives later contributors a route into systems whose formal standards are large and whose commercial implementations are hard to inspect.

The educational role is particularly important for older cellular technologies. A protocol can remain operationally relevant after universities and vendors have shifted attention to newer generations. Without open documentation, the pool of people able to diagnose a failure narrows. A community that records experiments and design decisions can extend the useful life of deployed systems and make migration less dependent on one supplier.

Documentation does not solve succession by itself. A recorded talk cannot review a security patch, maintain hardware or answer an incident at three in the morning. It does, however, reduce the amount of tacit knowledge that disappears when a specialist leaves. The health of the Osmocom ecosystem will depend partly on whether this knowledge continues to be converted into manuals, tests and maintainable interfaces rather than remaining attached to a few individuals.

That lesson also applies to Welte’s own profile. His public archive is strong evidence of continuing technical activity through recent years, including work on eSIM, SIM over-the-air systems and performance tracing. It is not a complete census of his workload or the community’s priorities. Public output shows what he chose to explain, not every customer engagement or maintainer decision.

Open implementations transfer responsibility to operators and support teams

An operator evaluating an open telecom component can be tempted to frame the choice as licence cost versus vendor price. That is too narrow. The more consequential change is the redistribution of responsibility. A proprietary supplier normally bundles architecture, integration, upgrades, security response and escalation into a contractual relationship, even when the customer cannot inspect the implementation. An open project exposes the implementation and allows several support arrangements, but the customer must decide who owns each operational duty.

That decision begins with system integration. Someone has to select compatible releases, qualify hardware, design redundancy, protect management interfaces and maintain configuration. In a community project, there may be no single release train covering every component. A support company can assemble one, but the resulting system is then partly defined by that company’s choices. Operators need to know which patches are upstream, which are maintained privately and how quickly they can move to another integrator.

Security response is another test. Public code permits independent review, yet disclosure and patching require maintainers who understand the subsystem and users who can deploy the fix. A vulnerability in a protocol library may affect several network functions. A flaw in SIM tooling may be dangerous only when combined with exposed keys or weak access control. The operational question is not whether the code is open but whether advisories, affected versions, mitigations and upgrades are handled with enough discipline for the deployment’s threat model.

Procurement also changes. Traditional carrier buying often values certifications, long support periods and a supplier’s financial capacity to absorb failure. Open infrastructure may offer stronger technical control while lacking the same procurement signals. A buyer can respond by separating the stack into risk classes. A laboratory system may accept community support. A revenue-critical private network may require a commercial maintainer, spare hardware, tested rollback and contractual response. A public operator may need additional assurance that an open component can fit regulatory and interconnection obligations.

The ability to inspect code can improve bargaining power even when the operator buys support from one company. It reduces the supplier’s exclusive control over diagnosis and gives the customer a path to commission another expert. That option has value only if the code can be built, the data can be exported and the hardware can be obtained. A nominal right to fork is weak protection when the deployment depends on undocumented calibration or a private provisioning database.

Welte’s projects repeatedly make this distinction visible. Netfilter allowed appliance makers and users to work from a shared upstream subsystem, but products still required integration and updates. GPL enforcement tried to ensure that vendors did not close the return path. Osmocom allows network functions to be assembled from public code, while sysmocom supplies the specialised labour needed by customers. SIM tools expose identity mechanisms, while keys and authorisation remain institutional controls.

For engineering teams, this redistribution can be productive. Problems can be investigated at their source, and improvements can be shared. For leadership, it demands an honest inventory of capabilities. An organisation that lacks telecom protocol expertise may be less independent with an unsupported open stack than with a well-governed vendor contract. The point is not to maximise the amount of code operated internally. It is to keep critical control surfaces transferable and to place responsibility where it can be exercised competently.

A laboratory expands research without suspending legal or safety limits

Open cellular implementations have supported important security research because they let investigators build controlled networks, generate unusual signalling and observe protocol state. That capability is difficult to reproduce with production equipment designed to hide internal behaviour. It also carries ethical and legal obligations that should be stated plainly.

A test network can reveal weaknesses in authentication, cipher negotiation, location procedures or message handling. Researchers can compare a device’s response with the standard and with other implementations. They can instrument code, introduce malformed inputs and reproduce failures. These experiments improve understanding of both protocol design and implementation quality.

The same tools can be misused. Radio transmissions can interfere with real networks. Subscriber identifiers and keys are sensitive. Remote-SIM systems can become a route to unauthorised service if access controls fail. A profile of Welte’s work should therefore describe capability without presenting open tooling as a licence to operate outside spectrum rules, contracts or consent.

The distinction between a protocol weakness and an implementation vulnerability is especially important. GSM has design limitations that affect every conforming system. An Osmocom bug may affect only specific versions or configurations. A commercial handset may behave differently because of a vendor extension. Good research identifies the layer and does not turn one laboratory result into a universal claim.

Openness helps because other researchers can inspect the method. They can reproduce the setup, challenge an interpretation and propose a fix. That review is a stronger foundation than a demonstration whose equipment and code remain secret. It does not guarantee correctness, and the small size of the specialist community can still leave blind spots.

The research value also extends beyond finding vulnerabilities. Open systems help train engineers to understand normal signalling, which is necessary before abnormal behaviour can be diagnosed. They can support conformance testing, incident reconstruction and migration planning. In this sense, the laboratory is part of infrastructure resilience: it gives operators a place to learn how a system behaves before a production failure forces the lesson.

Welte’s current interest in eSIM, GlobalPlatform and over-the-air administration continues this security-research tradition at a newer control point. The questions have moved from radio messages toward profiles, certificates, secure channels and remote lifecycle management. The same discipline applies: expose the state machine, distinguish specification from implementation, and keep authorisation and operational consequence visible alongside technical possibility.

Radio, regulation and protocol age remain outside the code

The strongest case for open mobile infrastructure is also the one most damaged by overclaiming. Osmocom demonstrates that important network functions can be implemented and supported outside a vertically integrated vendor stack. It does not demonstrate that software alone is a complete telecom network.

Radio systems require spectrum authority, RF design, timing, antennas, power, interference management and compliant hardware. A lawful private network may have a narrower regulatory path than a public carrier, but it still operates inside national rules. Open source does not grant a licence to transmit or guarantee that a deployment meets safety, emergency-service or lawful-interception obligations.

Security has similar boundaries. Transparency makes review and testing possible, yet GSM and other 2G systems contain weaknesses that no implementation can fully repair while remaining interoperable. An open stack can help an operator understand the risk, isolate a use case or plan a migration. It cannot turn an old standard into a modern security architecture by declaration.

Interoperability also remains difficult. Standards leave options and ambiguities. Commercial devices contain deviations. Timing behaviour depends on hardware. An open reference implementation may reveal a disagreement without proving that its own interpretation is the only correct one. Production engineering requires tests against the actual devices and networks in scope.

Maintenance concentration is another constraint. Osmocom’s breadth is impressive, but specialised expertise is held by a relatively small community and a few companies. If key maintainers leave or commercial demand declines, releases, hardware support and security response can slow. The code remains available, but availability is not the same as maintained capability.

Finally, deployment scale is not well measured. Public references show laboratories, private networks, research systems and specialised production use, but there is no complete audited census. It would be misleading to infer global market share from project downloads, conference talks or a handful of deployments. The responsible conclusion is qualitative: the software has made real network functions accessible outside proprietary stacks, with maturity and scale varying by component and use case.

These limitations do not weaken the core achievement. They define it. Open infrastructure is valuable precisely because it exposes the remaining dependencies. A closed system can hide the fact that hardware, keys, support and regulation are separate control points. An open one makes those boundaries available for scrutiny.

Welte’s influence is central without being exclusive

Welte’s name is attached to enough projects that profiles can easily turn into a sequence of invention claims. That would misrepresent both his work and the communities that made it last. Netfilter grew from earlier Linux firewalling and the work of Rusty Russell and many others. Current nftables direction belongs to later maintainers. Osmocom includes major contributions from Holger Freyther, Andreas Eversberg and a wider international community. sysmocom is a company with its own staff and customers, not a synonym for Welte.

The more accurate measure of his influence is institutional. He repeatedly identified a closed or weakly inspectable interface, built enough working code to make independent experimentation possible, documented what he learned and helped create a structure for continued work. In the GPL period, the structure was legal enforcement. In Osmocom, it was a project family and conference community. In sysmocom, it was paid engineering beside open code.

That model also creates a succession test. A project centred too heavily on its founder may remain open in licence while becoming practically dependent on one person. The evidence of resilience is not the founder’s visibility but the number of maintainers who can review code, release components, support hardware and teach the next group. Welte’s emeritus status in Netfilter shows one successful transition. Osmocom’s long-term strength will be judged by similar transfers of responsibility.

His durable argument is therefore narrower and more useful than the claim that he opened telecom. He showed that closed operational interfaces can be converted into inspectable systems, and that doing so requires more than publication. Code needs legal protection, documentation, community governance, test equipment and a way to pay for specialised labour. Those conditions do not abolish vendor power, but they give operators and researchers alternatives to accepting it without evidence.