# ZeroC Ice: a contract-first RPC framework across nine language mappings

> Ice is a 25 year old RPC framework where you describe the interface in the Slice IDL, compile it, and get client and server stubs in whichever language you want. This is what the repository actually contains and where the licensing split bites.

**zeroc-ice/ice** — All-in-one solution for creating networked applications with RPC, pub/sub, server deployment, and more.

- Repository: https://github.com/zeroc-ice/ice
- Website: https://zeroc.com
- Stars: 2,195 · Forks: 599
- Language: C++
- License: GPL-2.0
- Published: 2026-10-08 · Updated: 2026-10-08 · Language: en
- Canonical page: https://hysenlabs.com/projects/zeroc-ice-ice

## From a Slice file to a calling client

The first thing to understand about Ice is that you do not write the client interface by hand. You describe it in Slice, Ice's interface definition language, then run a compiler over it. The README calls this a two step process, and the first step is the contract.

```slice
// The contract specified using Slice.

/// Represents a simple greeter.
interface Greeter
{
    /// Creates a personalized greeting.
    /// @param name The name of the person to greet.
    /// @return The greeting.
    string greet(string name);
}
```

The second step runs the Slice compiler, which exists per target language. For C++ the binary is `slice2cpp`:

```shell
# Compile the Slice contract with the Slice compiler for C++ (slice2cpp)
slice2cpp Greeter.ice
```

What comes out is a proxy class and an abstract base class. The client calls the operation through the proxy, with the endpoint passed as a string that encodes the transport, host and port:

```cpp
GreeterPrx greeter{communicator, "greeter:tcp -h localhost -p 4061"};
string greeting = greeter.greet("alice");
```

The server side derives from the generated base class and overrides the operation, which means both sides are generated from one source of truth and neither can drift from the other.

## Why the contract has to come before the code

The ordering is not ceremony. In most RPC systems you define the interface in the target language, hand write the stubs, and hope the two sides match. Ice inverts that, and the payoff is stated plainly in the README: a Python client can call a C++ server, and neither side knows the programming language used by the other.

That claim rests on the protocol being fixed and compact rather than language specific, which is why the README describes RPCs over a compact binary protocol across TCP, SSL, UDP, WebSocket and Bluetooth. Encoding is generated from the same description on both sides, so there is no negotiated format step to debug and no reflection service to keep running. The `BLUETOOTH.md` file at the repository root and the transports listed for the protocol suggest Bluetooth support is a first class case rather than an afterthought, which is the sort of thing that comes from the framework having been built for embedded and mobile clients.

The cost sits on the other side of the ledger. Every change to an interface now means editing a `.ice` file and regenerating, so the interface becomes a versioned artifact. The repository tree shows that this is taken seriously: there is a `slice/` directory for the compilers themselves, `changelog.d/` for pending changelog entries, a `CHANGELOG.md`, and an `AGENTS.md` at the root. A build system that expects interfaces to move will need those regeneration steps wired in rather than run by memory.

## Nine language mappings from one protocol

The README lists supported languages with a link into each directory of the same repository: C++, C#, Java, JavaScript/TypeScript, MATLAB, PHP, Python, Ruby and Swift. Each has its own directory at the top level of the tree, and the presence of `Package.swift` and `Package.resolved` at the root means the Swift mapping ships as a Swift package rather than as source you vendor yourself.

What is worth noticing is the shape of the repository. This is one monorepo holding nine implementations, which means a fix to the protocol or the Slice compiler lands in all of them at once. It also means the build is not small. The top level `Makefile` pulls its language list from `config/Make.rules` and drives `srcs`, `tests`, `all`, `clean`, `distclean` and `install` across every language subdirectory in turn, which is what a nine language project needs in order to stay consistent.

That Makefile also reveals something the README does not mention: the install rules deliberately filter out lookup slice files. The rule excludes `%/Lookup.ice` from the installed set, with a comment saying it does not install the IceDiscovery and IceLocatorDiscovery lookup slice files. Those files are for dynamic lookup of objects by type and identity, so if you depend on IceLocator you should know before installing that those `.ice` files are not on disk and the lookup types are resolved in a different way. Details like this are exactly what the repository tells you and the README does not.

## IceGrid, IceStorm and Glacier2 are separate runtime pieces

The README's feature list is really a list of other systems, and reading it honestly changes how you evaluate the project. Pub-sub comes as IceStorm and DataStorm. Server deployment, replication and monitoring come as IceGrid. An application gateway for crossing a network boundary comes as Glacier2. Instrumentation and metrics come as IceMX. Configuration and logging are Ice Properties and the Ice Logger.

Each of those is a documented subsystem with its own page on docs.zeroc.com, not a feature toggle in the RPC library. So the honest description of Ice is a distributed systems suite that happens to include an RPC framework, and the repository's own description as an all-in-one solution for networked applications is accurate in that sense rather than in the sense of a single process. The tree supports that reading: `config/` holds configuration, `certs/` holds certificates for the TLS cases, `packaging/` holds packaging, `doxygen/` and `man/` hold generated documentation, and `scripts/` holds automation.

If you only need RPC and have no plan for service discovery, replication or a firewall-crossing gateway, you are reading documentation for a system you will deploy a fraction of. That is not a criticism of the framework, but it is a real factor in the adoption decision, and the README's compact list makes it easy to miss.

One more detail about versions. The README's download link points at `NIGHTLY.md`, while the repository also has three tagged releases, with v3.8.3 published on 2026-09-10 and v3.8.1 on 2026-03-03. So the documented download route is nightly builds and the tagged releases are the conservative choice. The last push was on 2026-09-28 and the repository is not archived.

## Where GPLv2 stops and a paid agreement starts

Ice is a single copyright project. The README states that all the source code in the repository is copyright ZeroC, Inc., with very few exceptions, and that as copyright owner ZeroC can license the same software under different terms. GPLv2 is the default open source license, and commercial or closed source licenses are offered alongside it.

The part that catches people out is the sentence about what does not change: the Ice software itself remains the same, and the only difference between an open source Ice and a commercial Ice is the license terms. So the feature comparison between a free and a paid Ice is not a comparison you need to make, only a licensing conversation. The README is also clear that there is no license fee or signed agreement under GPLv2, only compliance with its terms and conditions.

Two license files sit at the repository root, `LICENSE` and `ICE_LICENSE`, and they are not redundant. The README says ZeroC grants a few exceptions to the GPLv2 terms and conditions and points at `ICE_LICENSE` for them. A reader who opens only `LICENSE` therefore sees the copyleft text without the exceptions, and a reader who assumes the presence of an exceptions file means the code is permissively licensed has it backwards. GitHub's own license field for the repository reads GPL-2.0, which is a third partial view. This is not a legal opinion, and the practical point is only that the license question for this project is answered by more than one file and none of them is a substitute for reading all of them.

## What the repository tells you that the README does not

The README is a short, confident overview with six documentation links and eight language links. It is good at the two step idea and bad at operational detail, so the repository is where the actual shape of the project shows up.

Beyond the language directories and the build system, the tree has a `SECURITY.md`, a `CONTRIBUTING.md`, a `RELEASE_PROCESS.md`-style workflow implied by `changelog.d/`, and tooling files that say a lot about how the project is policed: `.clang-format`, `.clang-format-ignore`, `.clang-tidy`, `.editorconfig`, `.swift-format.json`, `.markdownlint.json`, `.lychee.toml` for link checking, and `ruff.toml` plus `pyrightconfig.json` for the Python mapping. That last pair is a detail that answers a practical question. `ruff` and `pyright` in one repository means the Python mapping is type checked and linted in CI, so a Python-only consumer of Ice is relying on a mapping that is held to a stricter standard than most third party bindings.

There is also `allTests.py` at the root, which suggests cross language test runs rather than per language testing, and `doxygen/` plus `man/` for generated API documentation in two formats. For a project this size and this age, the honest summary is that the README undersells the engineering infrastructure and the documentation site carries the design decisions. If you evaluate Ice, read the IceGrid and Ice protocol pages on docs.zeroc.com after the README, not before, and decide on the license question before you write the first interface.

## Conclusion

Ice is worth serious consideration when you need clients and servers in different languages to agree on one interface, and when the deployment story matters as much as the wire format, because IceGrid, IceStorm and Glacier2 are already written. It is a poor fit for a small service where adding an IDL, a compiler step and a generated code tree costs more than the RPC saves, and it is a poor fit if GPLv2 copyleft is a blocker without a commercial agreement. The concrete first step is the Slice compiler against a single interface file, because that is the whole commitment: if `slice2cpp` produces stubs you can call from two languages and the deployment story on the IceGrid docs page fits your setup, the rest follows from that. Read the GPLv2 exceptions in `ICE_LICENSE` before assuming the license terms of the `LICENSE` file are the whole picture, and pin a tagged release such as v3.8.3 rather than tracking the nightly builds the README points at.

## FAQ

### What does ICE stand for in the ZeroC framework?

The Internet Communications Engine. Google returns a different meaning for the acronym, which is about interactive connectivity establishment in WebRTC, so the two should not be confused when you search for this framework.

### How do I write a client and server with ZeroC Ice?

Define the interface in a Slice file, then run the Slice compiler for your language, for example `slice2cpp Greeter.ice` for C++. The compiler emits a proxy class for clients and an abstract base class for servers, and both sides come from that one description.

### Which languages does ZeroC Ice support?

The README lists C++, C#, Java, JavaScript and TypeScript, MATLAB, PHP, Python, Ruby and Swift, each with its own directory in the repository. A Python client can call a C++ server because both sides are generated from the same Slice contract.

### Is ZeroC Ice free to use in a commercial application?

The default license is GPLv2, which carries strong copyleft conditions and requires no license fee or signed agreement, and ZeroC also grants a few exceptions recorded in the ICE_LICENSE file. Commercial and closed source licenses are offered separately, with GPLv2 terms not applying to those, while the software itself is identical.

### What are IceGrid, IceStorm and Glacier2 used for?

IceGrid handles server deployment, replication and monitoring. IceStorm and DataStorm provide pub-sub. Glacier2 is an application gateway for crossing a network boundary. They are separate subsystems with their own documentation rather than options inside the RPC library.

## Sources

- [License: GPL-2.0](https://github.com/zeroc-ice/ice/blob/main/LICENSE)
- [Project website](https://zeroc.com)
- [README](https://github.com/zeroc-ice/ice/blob/main/README.md)
- [Releases](https://github.com/zeroc-ice/ice/releases)
- [zeroc-ice/ice on GitHub](https://github.com/zeroc-ice/ice)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/zeroc-ice-ice