DEVELOPMENT VERSION: This is an experimental DALICC environment. Features, data and APIs may change or be reset without notice. A stable version of this service, with a potentially different feature set, will be made available soon at dalicc.net.

2026

DALICC in a Nutshell

The problem

Modern applications retrieve, store and process data, software and content from many sources. Each source comes with a license, and every derivative work inherits all of them. That raises two questions that are expensive to answer by hand: is this combination allowed, and what does the result have to say about itself?

Clearing rights by hand is slow, needs specialist knowledge and is easy to get wrong. Most of the effort goes into three things:

  1. reading and comparing license terms one by one,
  2. having the expertise to spot a conflict between two or more licenses,
  3. resolving the conflict once it is found.

The approach

DALICC stands for Data Licenses Clearance Center. It makes the content of a license machine readable and then reasons over it.

License models. A license is described as a set of statements: the actions it permits, the actions it prohibits, and the duties attached to them, such as attribution, keeping the license notice, sharing alike or providing the source. The license as a whole also says what it applies to (software, dataset, creative work), its jurisdiction and its validity. The warranty and liability clauses are kept word for word. The terms come from ODRL, Creative Commons REL, Dublin Core, schema.org, SPDX and the DALICC vocabulary.

The dependency graph. Actions do not stand on their own. Displaying is a kind of presenting, requiring attribution implies requiring a notice, copying and reproducing are the same thing, and requiring share alike implies requiring the source. These relations are data rather than code. They live in a dependency graph that you can read, edit and replace, because one jurisdiction may read the same action differently from another.

Reasoning. One reasoner answers two questions, working over the license models and a dependency graph. A consistency check asks whether one license contradicts itself. A compatibility check asks whether a set of licenses can hold at the same time. It returns the conflicting statements, both the direct ones and the ones derived through the dependency graph. How reasoning works walks through both checks step by step.

Composition. When no standard license fits, the composer builds one out of the same vocabulary. It checks the result for internal contradictions and keeps it as a private draft until you publish it under a stable address of its own, so that a dataset can point at it.

What you can do with it

  • Find a license that matches what you want to allow and require: the License Library and the faceted License Search.
  • Read a license in structured form: permissions, prohibitions, duties, clause texts, version history and downloads in JSON-LD, Turtle and RDF/XML.
  • Check whether a bundle of licenses works together with the License Compatibility Checker, and, if you have one in mind, whether the result may be released under a target license. The GitHub License Compatibility Checker runs the same check over the dependencies of a repository. To read two or more licenses next to each other, use the License Comparator.
  • Create a custom license: the License Composer, which also writes the license out as a text you can edit and keeps it with the model.
  • Work between a text and a model in either direction: Text-to-License drafts a model from a license text with the quote behind every statement, and License-to-Text writes a model out in plain English. Both produce a draft for you to check, and neither publishes anything.
  • Attach the result to your work in machine readable form: every license page offers a ready made JSON-LD sidecar and a badge for your repository or dataset.
  • Do all of it from a program: the documented API and the Python client.

How it works

The framework grew out of the four modules the research project started with, and each of them lives on in today's tools:

  • License Library: the curated, machine readable models of standard licenses, plus the licenses members publish.
  • License Composer: writes a license as a model, in a questionnaire or an expert view, checks it for contradictions and publishes it. What the project called the License Annotator, which produced the machine readable and the human readable form of a license to attach to a work, is now the composer's downloads as Turtle, JSON-LD and RDF/XML, the "Use this license" snippets on every record page, and License-to-Text.
  • License Compatibility Checker: what the project called the License Negotiator. It checks several licenses together, tells a conflict from a restriction, lists what the combined work must do and points at the statements behind each finding. The GitHub License Compatibility Checker runs the same check over the dependencies of a repository.
  • License Comparator: puts two or more licenses side by side.

The other tools are the License Search, Text-to-License, and the dependency graph viewer, editor and comparator.

Under them sit three things: the license data as RDF in a triple store, the dependency graph, and a reasoner that evaluates both. The website and the API are two faces of the same service, so anything you can click you can also call. The vocabulary is documented at /ns. The data model and the curation rules are in the documentation.

Who it is for

  • data and software suppliers, and the platforms that aggregate them
  • application developers and service providers
  • legal departments and law firms
  • open source and open data initiatives
  • research infrastructures that have to keep provenance and licensing straight

What it is not

DALICC is experimental and gives no legal advice. It tells you what the model of a license says and where two models collide. Whether that answer holds in your jurisdiction and your case is a question for your legal advisor. Models can also be wrong or incomplete: every license page offers a correction request when you are signed in and a mail link when you are not, and the association reviews what comes in.