Babel Licensing Tool ★Server

What the Package Contains

Babel.Licensing.Tool is a .NET tool  package that installs the lic command. It is the same command line tool shipped in the Babel zip packages, with the same options, and it comes with the Babel Licensing editions, Server and Data Center. The package ships one build of the tool for each supported runtime, .NET 6.0 through .NET 10.0, and the dotnet CLI picks the build that matches the SDK on the machine.

Like the other Babel packages, the tool package is not on nuget.org: host it on your own feed as described in Hosting the Package, or add it to a local folder feed as shown in Client Components.

When to Use the Tool

Use the tool wherever licenses are produced by a process rather than by a person in Babel Desktop:

• Issuing licenses from an order pipeline, a support script or a build, on any operating system.
• Generating and rotating signing key pairs, and exporting the public key to embed in an application.
• Verifying licenses that customers send back, and updating them without re-creating them.
• Computing the hardware key of a machine, to issue a hardware-locked license for it.
• Agent-driven automation through the AI-friendly mode, which the lic tool shares with the obfuscator.

Installing the Tool

Global tool

A global tool is installed once per user and available from every terminal:

dotnet tool install Babel.Licensing.Tool -g

When the feed is not listed in a NuGet.config file, pass it explicitly. The source can be a feed URL or a local folder:

dotnet tool install Babel.Licensing.Tool -g --add-source ~/NuGet

On Linux and macOS make sure the tools folder is on the path, or the lic command is not found:

export PATH="$PATH:$HOME/.dotnet/tools"

Local tool

A local tool is pinned to a repository through a tool manifest, so every developer and CI agent runs the same version:

dotnet new tool-manifest
dotnet tool install Babel.Licensing.Tool

This records the tool in .config/dotnet-tools.json, which you commit. On any other machine, dotnet tool restore installs the pinned version. A local tool is invoked through the dotnet CLI:

dotnet lic --version

Updating and removing

dotnet tool update Babel.Licensing.Tool -g
dotnet tool list -g
dotnet tool uninstall Babel.Licensing.Tool -g

Drop -g for a local tool. dotnet tool list shows the installed package, its version and the lic command it provides, next to babel when the obfuscator tool is installed too. The same commands are described in Install.

Licensing the Tool

The tool needs a Babel Licensing license. A dotnet tool has no installation folder you can copy babel.licenses into, so give lic the license in one of these ways:

• Set the BABEL_LICENSE_PATH environment variable to the full path of the license file. This is the recommended setup on developer machines and build agents:

export BABEL_LICENSE_PATH=~/Babel/babel.licenses

• Pass --license on each invocation, with the path of the license file or of a folder to search.
• Pass --license env:BABEL_LICENSE, where the variable holds a license key: the right choice on build servers, where the key lives in a secret.

lic --license with no argument prints the license in use. A license file is valid for one product version: use the file that came with the same version as the tool, and update both together.

Using the Tool

The lic command accepts the syntax and the switches documented in Command Line Tools and in the Reference. A typical invocation names the assembly to license, the key, the license content and the output file:

lic MyApp.dll --keyfile keys.pem --sign --licensee name="Contoso" --product name="MyApp" --expiredate 365 --feature Pro=1 --trial days=30 --output MyApp.licenses --encoding utf-8

With a local tool, prefix the command with dotnet.

Scripting and automation

Since version 11.8 the lic command line has an AI-friendly mode designed for scripts and agents:

lic MyApp.dll --keyfile keys.pem --sign --licensee name="Contoso" --expiredate 365 --format json --quiet --strict-exit

--format json or ndjson turns the output into a machine-readable stream and routes human diagnostics to standard error, --quiet removes the banner and makes any interactive prompt fail fast, and --strict-exit returns a distinct exit code for invalid arguments, missing input, license processing, licensing and signing failures. The exit codes are the same as the obfuscator’s, so one script can drive both tools with a single table.

Running on a build server

The tool fits pipelines that issue licenses as a step, for example to license the test build of an application before its integration tests run. With a tool manifest committed to the repository and the feed configured in NuGet.config (see the GitHub Actions example for a configuration that authenticates against GitHub Packages), a GitHub Actions job looks like this:

steps:
  - uses: actions/checkout@v4
  - uses: actions/setup-dotnet@v4
    with:
      dotnet-version: '10.0.x'
  - name: Restore tools
    run: dotnet tool restore
    env:
      PACKAGES_TOKEN: ${{ secrets.PACKAGES_TOKEN }}
  - name: Write the signing key
    run: echo "$SIGNING_KEY" > keys.pem
    env:
      SIGNING_KEY: ${{ secrets.LICENSE_SIGNING_KEY }}
  - name: Issue the test license
    run: dotnet lic artifacts/MyApp.dll --license env:BABEL_LICENSE --keyfile keys.pem --sign --licensee name="CI" --expiredate 7 --output artifacts/MyApp.licenses --quiet --strict-exit
    env:
      BABEL_LICENSE: ${{ secrets.BABEL_LICENSE_SECRET }}

Keep the private key in a secret and never in the repository: whoever holds it can issue licenses for your product.

Troubleshooting

• lic: command not found — the global tools folder is not on the path; add ~/.dotnet/tools to PATH, or use a local tool and run dotnet lic.
• A message asking to install .NET — the selected build of the tool needs the matching .NET runtime, from 6.0 to 10.0. Install that runtime, or set DOTNET_ROLL_FORWARD=Major to run the tool on a newer runtime.
• A valid license could not be found — check BABEL_LICENSE_PATH or the --license argument, then run lic --license to see what the tool loaded. A license file for a different version is reported as not valid.
• The license is reported as not valid by the application — the license was probably written without --sign, or signed with a key pair whose public key does not match the one embedded in the application. Run lic <file> --verify --keyfile <key> to check the signature with the key you expect.
• Unrecognized option — an older lic on the path is answering; run dotnet tool list -g and lic --version to check which build you are invoking. --format json, --quiet and --strict-exit need version 11.8 or later.