Summary

  • Harald Welte repeatedly worked at operational boundaries that vendors expected users to trust but rarely allowed them to inspect, including Linux firewalls, embedded licensing, GSM network functions and subscriber-identity systems
  • His influence came from combining implementation, documentation, licence enforcement, community building and paid engineering, rather than from acting as the sole author of any one infrastructure stack
  • Netfilter, OpenBSC and Osmocom made packet handling and mobile-network behaviour easier to test, but they did not remove the hardware, spectrum, security and maintenance requirements of production telecom systems
  • The durability of Welte’s work now depends less on the founder than on whether knowledge, maintenance authority, hardware support and commercial responsibility can continue to spread across the wider community

He kept choosing the interfaces operators could not see

A useful way to understand Harald Welte’s career is to look past the sequence of project names and examine the kind of problem he repeatedly chose. The systems were usually important, widely deployed and difficult for outsiders to inspect.

A Linux firewall determined which packets entered, crossed or left a machine, but its internal decision-making was still being rebuilt. A commercial router could contain free software while its supplier withheld the corresponding source. A mobile phone could expose its operating system while leaving the baseband and radio stack closed. A network operator could buy a cellular system without being able to inspect how its components interpreted signalling standards. A SIM could determine whether a subscriber entered the network while its provisioning processes remained controlled by vendors and specialist institutions.

Welte’s response was normally practical. He wrote or helped write working implementations, documented behaviour, assembled communities and, where users needed operational responsibility rather than a public repository, helped create commercial support.

That pattern links projects which otherwise appear unrelated. Netfilter is part of the Linux kernel. gpl-violations.org was a licence-enforcement initiative. OpenMoko attempted to build a more open mobile handset. OpenBSC and Osmocom opened parts of cellular-network infrastructure. sysmocom created a company around engineering and support. pySim and osmo-remsim moved the same argument towards subscriber identity.

These projects were never one organisation, nor were they the work of one person alone. Rusty Russell initiated the packet-filtering work that became Netfilter. Holger Freyther, Andreas Eversberg and many others made major contributions to Osmocom. Standards bodies, operators and equipment makers built the wider systems in which the software runs.

Welte’s importance lies elsewhere. At several points, he helped convert an opaque operational boundary into something engineers could inspect, reproduce and argue about in public.

Netfilter made packet handling a framework rather than a collection of commands

Linux already supported firewalling before Welte joined Netfilter development in 1999. Tools such as ipfwadm and ipchains could express useful policy, and Linux systems were already being used as routers and gateways.

The architectural problem was how to connect packet movement inside the kernel with stateful functions and user-space control in a cleaner and more extensible way. Netfilter introduced hooks at defined points in the packet path. Code could inspect or modify packets as they entered a machine, crossed it or left it. User-space tools could install rules without turning each new policy requirement into a separate kernel design.

That separation changed the subsystem’s operating model. Packet traversal, state tracking, address translation, logging and policy expression could be reasoned about as related but distinct functions. Developers gained a common place to add capabilities, while administrators gained tools for describing and observing policy.

Welte became a member of the Netfilter core team and led it for a period. His work included code, user-space libraries, logging and technical explanation. The distinction between contribution and sole authorship matters. Netfilter became useful because a group combined kernel mechanisms with interfaces operators could understand and integrate.

The subsystem also showed how infrastructure software acquires consequences beyond its original environment. Linux packet filtering and network-address translation appeared in servers, home routers, gateways, mobile devices, security products and embedded appliances. A change made in an upstream community could eventually affect equipment sold under hundreds of brands.

That scale created two responsibilities. The first was technical: the code had to preserve performance, state and compatibility while remaining observable. The second was institutional: commercial users of the code had to comply with the licence that made reuse possible.

State made Linux useful as a gateway and harder to operate safely

A stateless firewall can inspect addresses, ports and protocol fields, but many network decisions depend on relationships over time. A reply belongs to an earlier request. A translated address must map consistently while a connection remains active. Some protocols create related flows that cannot be understood from a single packet.

Connection tracking gave Netfilter a way to classify packets according to flow state. Network-address translation could then modify addresses or ports while preserving the information needed for return traffic. These capabilities helped ordinary Linux systems function as practical gateways.

They also created new failure modes. Connection tables consume memory. Timeouts affect application behaviour. Protocol helpers can enlarge the attack surface. Rule ordering can produce technically valid outcomes that conflict with what the operator intended. Logging can either clarify an incident or overwhelm the system with noise.

Welte’s work on logging infrastructure, including early development around ulogd, addressed part of that operational problem. A packet decision that cannot be observed is difficult to debug and difficult to audit. Moving selected events towards user space allowed operators to store, analyse and correlate information without turning the kernel itself into a reporting platform.

Libraries around connection tracking gave other programs structured access to state. That reduced the need for every management system to scrape command output or depend on private interfaces.

The lasting contribution was therefore not simply a faster or more capable firewall. Netfilter established clearer boundaries between packet processing, state, policy and observation. Those boundaries allowed later tools and maintainers to evolve the system, including the transition towards nftables.

Welte’s active role ended years ago, and Netfilter lists him as emeritus from October 2012. That transition is part of the project’s success. Infrastructure becomes durable when it can outlast an early leader.

GPL enforcement turned licence compliance into an operational duty

The spread of embedded Linux exposed a contradiction. Vendors benefited from shared software, shipped it inside routers, phones and appliances, and sometimes ignored the licence obligations attached to that code.

The GNU General Public License required distributors to provide corresponding source and preserve certain notices and rights. In practice, users often found that source offers were incomplete, build information was missing or the published code did not match the shipped binary.

Welte founded gpl-violations.org and pursued compliance through notices, negotiation and litigation in Germany. The importance of that work was not that every dispute reached court or that every enforcement decision was uncontested. It was that licence compliance acquired practical consequences.

For networking-equipment suppliers, this reached deep into the manufacturing chain. A product might combine a chip vendor’s board-support package, a contract manufacturer’s image, a brand owner’s interface and community networking code. Each organisation could assume another party had preserved the source and notices.

Enforcement made that assumption costly. Companies needed to know what software they shipped, which licence applied, whether their archives matched the released product and whether distributors could meet obligations inherited from upstream code.

That required more than placing a tarball on a website. It encouraged processes resembling a software bill of materials, source correspondence, reproducible builds and internal ownership of compliance.

The initiative also attracted disagreement over strategy, remedy and governance. Licence enforcement can consume maintainer time, create adversarial relationships and raise difficult questions about proportionality. It would be inaccurate to claim that Welte alone transformed global open-source compliance.

The narrower conclusion is stronger. He demonstrated that suppliers using shared infrastructure code could face real legal consequences when they withheld the rights that allowed the code to remain open.

This work connected directly to his later telecom projects. Publishing an implementation is not enough if downstream companies can absorb it into another closed appliance. Licence enforcement tried to preserve the return path from commercial product back to public source.

OpenMoko exposed the boundary between open software and closed hardware

Welte joined OpenMoko in 2006 as lead system architect. The project attempted to build a Linux-based smartphone before Android established the dominant model for the industry.

The attraction was clear. Developers could inspect the operating system, modify drivers and replace applications in ways that mainstream handsets did not permit. The limitation was equally clear: a mobile device is not only its visible software.

Baseband processors, radio firmware, chip documentation, certification, power management and manufacturing all remained separate control points. A handset could be open in one layer and closed in another.

OpenMoko demonstrated how quickly software freedom encounters supply-chain constraints. A component change can invalidate a driver. A chip vendor can discontinue a part. Power behaviour may depend on undocumented hardware. Radio functions remain subject to certification and carrier requirements. A small project has less leverage over suppliers than a high-volume manufacturer.

The project did not become a dominant consumer platform. Its significance lies in the questions it exposed. The source code of the application processor did not provide control over the baseband. Access to the operating system did not provide authority over the mobile network. Documentation did not remove certification or hardware dependence.

That experience helped redirect Welte’s attention towards the protocols and network functions surrounding the handset. If the visible Linux environment was open but the network remained a group of black boxes, independent experimentation would still stop at the radio boundary.

The move from OpenMoko to OpenBSC was therefore not a change of subject so much as a move deeper into the same system.

OpenBSC turned signalling specifications into an inspectable network

Welte began OpenBSC in 2008 as an open implementation of GSM network functions, initially centred on the base station controller.

Public standards described the relevant interfaces, but standards alone do not create a working network. They do not automatically provide complete state machines, operational databases, management tools, interoperable timing or useful failure diagnostics. They also leave optional behaviour and room for interpretation.

The base station controller sits between radio equipment and higher network functions. It manages radio resources, coordinates channels and carries signalling towards switching and subscriber systems.

Implementing that role created a testable point inside a system normally purchased as an integrated vendor stack. Engineers could connect equipment, trace messages and change behaviour without asking a supplier to reveal proprietary internals.

OpenBSC did not immediately become a replacement for carrier-grade mobile infrastructure. Large commercial systems brought redundancy, certification, hardware integration, support organisations and accumulated field behaviour.

The open implementation supplied something different: a reference that could be read, changed and used to test assumptions. An engineer could inspect a state transition, change a timer, add logging or reproduce a disputed exchange in a controlled environment.

That capability matters because telecom interoperability disputes are rarely as simple as one side following the standard and the other side violating it. Two vendors can cite the same specification while interpreting optional fields, error recovery or timer behaviour differently.

An open implementation does not automatically become the correct interpretation. It becomes an instrument for producing evidence.

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. Its later development into the wider Osmocom family depended on that transfer from personal initiative to shared maintenance.

Osmocom made network boundaries explicit

Osmocom now covers a broad family of open communications projects. Describing it as a single open mobile-network stack is convenient but incomplete. There is no one program that replaces every operator function.

OsmoBSC manages radio resources and base-station connections. OsmoMSC provides switching, mobility and call-control functions. OsmoHLR stores subscriber information and authentication-related data. OsmoSGSN and OsmoGGSN implement parts of the packet core used for GPRS. OsmoPCU handles packet-control functions close to the radio layer. OsmoBTS connects supported base-station hardware to the network software above it.

This modularisation was a major step beyond the earlier OpenBSC design. An all-in-one program is convenient for experimentation, but it hides boundaries that an operator eventually has to manage.

Separate processes make interfaces visible. They allow one function to be replaced, scaled, tested or isolated. They also create more operational work. Configuration must remain consistent. Versions must agree about interfaces. Logs must be correlated. Subscriber data must be protected and backed up. A process can appear healthy while a transaction fails elsewhere in the service path.

The value of this architecture varies by deployment.

A laboratory may prioritise visibility and the ability to change protocol behaviour. A private network may need only a limited range of functions. An interoperability lab may use Osmocom as a reference peer for commercial equipment. A specialised operator may value support for an older protocol or radio platform that a larger vendor no longer prioritises.

None of these uses proves that the same architecture is suitable for a nationwide public network.

OsmoBTS illustrates the remaining dependence on physical infrastructure. Software can implement base-station functions, but radio hardware determines timing, supported interfaces, bandwidth and RF characteristics. Ports to different platforms require knowledge of firmware, clocks, transport and regulatory limits.

A successful laboratory deployment therefore does not automatically become a maintainable commercial system. Hardware availability can end before the software loses its technical value.

Modularity reduces vendor dependence by increasing operator responsibility

The practical meaning of an open mobile stack becomes clearer when responsibility for one subscriber is followed across the network.

Radio resources are assigned near the base station. Mobility and call control sit in the switching layer. Subscriber data and authentication information live in a register. Packet services use another chain of functions and tunnels. Media may travel along a separate path.

Each transition creates an interface where behaviour can be observed and disputed.

This separation produces technical clarity. An engineer can capture messages at a defined boundary, compare them with the relevant specification and determine which side entered the wrong state.

It also creates organisational choice. A deployment can retain one component, replace another or use an open implementation as a test peer for a commercial product. Reduced vendor dependence does not require every network function to come from the same open project.

The cost is integration responsibility. An integrated appliance may hide internal boundaries and present one support contract. An open architecture makes those boundaries visible but forces someone to own compatibility, security, monitoring, upgrades and failure recovery between components.

That person or organisation needs more than access to source code. It needs telecom expertise, test equipment, documentation and a process for deciding which release combinations are safe.

This is why “open GSM stack” needs qualification. Osmocom implements a large part of the technical chain, but a production network still requires lawful spectrum, radio planning, transmission, subscriber operations, security, business systems, support and often interconnection with other networks.

The project opens important functions. It does not remove the organisation around them.

Reference implementations change interoperability disputes

In a closed supplier relationship, an operator may receive two incompatible explanations from two vendors and have little evidence beyond packet captures and each company’s diagnosis.

An open implementation changes that negotiation. Engineers can reproduce an exchange, inspect the relevant state machine and alter one assumption at a time. They can add logging where a message is rejected, test a different timer or construct a minimal peer that sends the disputed sequence.

The open implementation does not become a final authority. It provides a way to isolate the disagreement.

This role can be more valuable than replacing the commercial system. A proprietary supplier may remain the right choice for scale, certification or support, while Osmocom supplies an independent test environment.

Equipment makers can test developing products against it. Researchers can construct controlled networks. Operators can preserve a test peer after a vendor withdraws an older platform.

Reference implementations still have limitations. They can contain bugs. Their interpretation of a standard can be idiosyncratic. They may support only part of a protocol or hardware family. Successful behaviour in a laboratory does not prove behaviour under load, failure or attack.

A credible interoperability programme therefore combines the open implementation with standards analysis, packet captures, device-specific testing and, where possible, several independent peers.

The institutional effect remains important. A supplier negotiates differently when the operator can show the failing sequence, identify the disputed state and demonstrate an alternative behaviour.

sysmocom created a commercial layer beside public code

Welte and Holger Freyther founded sysmocom in 2011. The company provides engineering, integration, products, training and support around Osmocom and related systems.

Its existence reflects a recurring model in infrastructure software. The core code can remain publicly available while customers pay for the work required to make it dependable in a specific environment.

That work can include deployment design, hardware, protocol changes, testing, migration, incident diagnosis and long-term maintenance. A customer may not want a private code branch. It may want a named organisation to take responsibility when a service fails.

Commercial support supplies an accountability relationship that a mailing list cannot guarantee.

The model can also fund upstream maintenance. Engineers solving a customer problem may add tests, document an interface or improve a shared component. Customer demand pays for work whose reusable parts return to the community.

The cycle is not automatic. A customer may require confidential or highly specific changes. Product deadlines may conflict with community review. A company with more paid maintainer time may gain disproportionate influence over the project.

Users therefore need to know which components are public, which patches are upstream, what the support contract covers and how easily another engineering provider could assume responsibility.

Public information does not provide a complete view of sysmocom’s ownership, revenue, staffing or customer concentration. It would be unsafe to infer commercial scale from conference activity or visible commits.

The supported conclusion is that sysmocom gives Welte and other specialists a way to sustain work that would otherwise rely more heavily on intermittent volunteer labour.

Open source does not eliminate the expert bottleneck

A network may escape dependence on one proprietary supplier and still depend on a small number of people who understand the open alternative.

Source access improves the customer’s options. It allows another engineer to inspect the implementation, commission a change or continue support after the original supplier leaves. Yet those options are meaningful only when the code can be built, the data can be exported, the hardware remains available and the system is documented well enough for another team to operate.

A legal right to fork is weak protection when the network depends on undocumented calibration, private subscriber data or one maintainer’s memory.

This is particularly important for older protocols. Much of Osmocom’s mature work concerns GSM, GPRS and other systems no longer at the centre of mobile-industry investment.

Infrastructure does not disappear when vendor attention moves elsewhere. Industrial systems, transport equipment, research facilities, regional networks and specialised users can remain dependent on older technologies for years.

That creates a maintenance market which ordinary growth metrics do not capture. The user base may be too small to support several large vendors, while abrupt replacement remains expensive or impractical.

Open code and documentation can become continuity insurance. They allow operators to inspect behaviour after the original supplier reduces support, migrate in stages or build interfaces between old and newer systems.

They do not make continued operation automatically sensible. Older mobile standards have security weaknesses, declining hardware availability and limited efficiency. Open implementations improve the ability to assess and manage those constraints; they do not remove them.

The durability of the ecosystem therefore depends on reproducible test environments, clear manuals, hardware knowledge, training and succession. Conference recordings and public issue histories matter because they reduce the cost for another engineer to enter the field.

Open hardware work showed where software control ends

Welte also worked on RFID, smart-card and open-hardware projects, including OpenPCD and librfid. These projects received less public attention than Netfilter or Osmocom, but they reinforced the same concern with interfaces that combine protocol logic and physical devices.

RFID and smart-card systems cannot be understood from software alone. Timing, modulation, antennas, analogue behaviour and proprietary readers affect what can be observed.

An open reader or protocol library gives researchers more control over the exchange. It also reveals where that control stops. A chip may still contain secret keys, undocumented behaviour or manufacturing constraints.

Open hardware has a different sustainability problem from software. A repository can be copied, but a circuit board depends on components, fabrication files, assembly and testing. A discontinued chip can make a published design difficult to reproduce.

Documentation therefore needs bills of materials, hardware revisions and known substitutes, not only source files.

The practical lesson carried into cellular work. Base stations and SIMs interact with timing, electrical interfaces, cryptographic boundaries and specialised hardware. Software openness is necessary, but the surrounding device and trust chain determine how much independent operation is actually possible.

SIM and eSIM tooling moved openness towards identity control

Subscriber identity is one of the most consequential control points in a mobile network. A SIM or eSIM profile contains identifiers, applications and cryptographic material used to determine whether a device can authenticate and receive service.

Provisioning and lifecycle management therefore combine technical standards with organisational authority.

Welte’s later work has focused increasingly on this layer. pySim provides tools for inspecting, programming and managing SIM-family cards where the user has the required authorisation and keys. osmo-remsim implements a specialised architecture that makes physical SIM resources available through remote clients and SIM banks.

His talks and documentation have also examined eUICC profile formats, GlobalPlatform mechanisms, over-the-air administration and the infrastructure hidden behind simplified consumer descriptions of eSIM.

The value of open tooling is observability. Engineers can inspect files, identifiers and command exchanges. They can automate legitimate provisioning, reproduce failures and compare implementation behaviour with the relevant specifications.

The authority boundary remains strict. Open software does not provide cryptographic keys an operator has not supplied. It does not permit arbitrary profile installation. Remote provisioning systems rely on certificates, secure channels, trusted roles and contractual rights.

osmo-remsim should not be confused with ordinary consumer eSIM. It is a remote-SIM architecture for specialised environments where SIM access is deliberately centralised. That may support laboratories, device farms and controlled deployments, but it creates its own dependencies on availability, latency and access control.

The pattern is the same as in Netfilter and OpenBSC. The implementation becomes visible, while the party holding keys, hardware and legal authority still determines what actions are permitted.

Security research gains a laboratory, not freedom from consequences

Open cellular implementations have supported security research because they allow investigators to construct controlled networks, generate unusual signalling and observe protocol state.

Researchers can compare device behaviour with the standard, instrument the code, introduce malformed inputs and reproduce failures. That is difficult with production equipment designed to hide its internal logic.

The capability carries ethical and legal obligations. Radio transmissions can interfere with live networks. Subscriber identities and keys are sensitive. Remote-SIM systems can create unauthorised access if controls fail.

A profile of this work should therefore describe the technical capability without treating open tooling as permission to ignore spectrum rules, contracts or consent.

It is also important to distinguish protocol weaknesses from implementation vulnerabilities. GSM contains design limitations that affect conforming systems. An Osmocom defect may affect only a particular release or configuration. A commercial handset may behave differently because of a vendor extension.

Good research identifies the layer and avoids turning one laboratory observation into a universal claim.

Openness improves review because other researchers can inspect the method, reproduce the setup and challenge the conclusion. It does not guarantee correctness, particularly in a small specialist community where blind spots may persist.

The research value extends beyond vulnerability discovery. Open systems train engineers to recognise normal signalling, support conformance work and provide a controlled environment for incident reconstruction.

Documentation is part of the infrastructure

Source code rarely captures every assumption required to operate a telecom system.

A repository may show what a timer is set to without explaining why. It may implement a vendor workaround without recording how common the deviation is. It may expose a failure branch without showing what the failure looks like on the wire.

That knowledge often survives in mailing lists, conference talks, manuals and the memory of maintainers.

Welte has invested heavily in public technical explanation. Osmocom meetings, development calls and recorded presentations have covered architecture, signalling, SIM systems, eSIM formats, GlobalPlatform and performance tracing.

This material lowers the barrier for later contributors. It is particularly valuable for technologies that remain operationally important after universities and large vendors have shifted attention elsewhere.

Documentation does not solve succession by itself. A recorded talk cannot review a security patch or respond to an incident. It can, however, convert some tacit knowledge into a form another engineer can use. The long-term health of Osmocom will depend on whether knowledge continues to move from individuals into manuals, tests, release processes and maintainable interfaces.

Open implementations redistribute responsibility

An organisation evaluating an open telecom component can reduce the decision to licence cost versus vendor price. That misses the most important change.

A proprietary supplier normally bundles architecture, integration, upgrades, security response and escalation into one contractual relationship, even when the customer cannot inspect the implementation.

An open project exposes the code and permits several support arrangements. The customer must then decide who owns each operational responsibility.

Someone must select compatible releases, qualify hardware, design redundancy, protect management interfaces and maintain configuration. There may be no single release train covering every component. A support company can create one, but the resulting system partly reflects that company’s choices.

Security response presents the same challenge. Public code permits review, but advisories, patches and upgrades still require maintainers and users capable of acting on them.

Procurement signals also differ. Traditional carrier buying values certification, long support periods and a supplier’s financial capacity to absorb failure. Open infrastructure may provide more technical control without offering the same institutional assurances.

The appropriate model depends on the deployment. A laboratory may accept community support. A revenue-critical private network may require commercial maintenance, spare hardware, tested recovery and contractual response times. A public operator may need additional assurance around regulation and interconnection.

The ability to inspect the code can improve bargaining power even when one company supplies support. It reduces that supplier’s exclusive control over diagnosis and gives the customer a possible route to another expert. That option matters only when the organisation has prepared to use it.

Open telecom cannot remove radio, regulation or age

The strongest case for open mobile infrastructure is also the one most damaged by exaggeration.

Osmocom demonstrates that important network functions can be implemented, studied and supported outside a vertically integrated vendor stack. It does not show that software alone constitutes a complete telecom network.

Radio systems require authorised spectrum, RF design, antennas, timing, power, interference management and compliant equipment. Open source does not grant permission to transmit or guarantee compliance with emergency-service, safety or interception obligations.

Security has similar boundaries. Transparency makes testing possible, but it cannot repair every weakness in an older standard while preserving compatibility.

Interoperability remains difficult because standards contain options and ambiguities, devices contain vendor-specific behaviour and timing depends on hardware. An open implementation may reveal a disagreement without proving that its interpretation is the only correct one. Maintenance concentration is another constraint. Osmocom covers many functions, but specialised knowledge remains concentrated in a relatively small community and a small number of companies.

Public evidence also does not provide a complete, audited picture of deployment scale. Laboratories, private networks, research systems and specialised production use are documented, but project activity and conference visibility should not be converted into unsupported claims about global market share. These limitations define the achievement rather than diminish it. Open infrastructure is valuable because it reveals the remaining dependencies instead of hiding them inside one product.

His influence is institutional, not solitary

Welte’s name is attached to enough projects that a profile can easily become a sequence of invention claims. That would misrepresent both his contribution and the communities that made the work durable.

Netfilter grew from earlier Linux firewalling and the work of Rusty Russell and many others. nftables is maintained and developed by later contributors. Osmocom includes major work from Holger Freyther, Andreas Eversberg and a wider international community. sysmocom is a company with its own staff and customers, not another name for Welte.

The more accurate measure of his influence is the pattern of institution-building.

He repeatedly identified an interface that users could not inspect, wrote or helped create enough code to make independent experimentation possible, documented the behaviour and helped establish a structure through which the work could continue.

For GPL enforcement, that structure was legal action and compliance practice. For Osmocom, it was a family of projects and a technical community. For sysmocom, it was paid engineering alongside public code. Each structure now faces the same test. A project can carry an open licence while remaining practically dependent on one founder. The stronger evidence of openness is whether several maintainers can review changes, release software, support hardware and teach the next group.

Netfilter has already passed one version of that test by continuing long after Welte’s active involvement ended. Osmocom’s future durability will be judged by whether responsibility can continue to move in the same way. Welte did not open all of telecom. His more defensible contribution was to show that closed operational interfaces can be turned into inspectable systems, and that publication is only the beginning.

Code needs documentation, legal protection, test equipment, maintainers and a way to pay for specialised work. Those conditions do not abolish vendor power. They give operators and researchers an alternative to accepting it without evidence.