DALICC 2026

DALICC stands for Data Licenses Clearance Center. The idea behind it sounds simple: turn the terms of a license into a machine-readable model, so that software can work out what the license permits, what it requires, and whether it can be combined with another license in a derivative work.

In practice, that simple idea leads to harder questions.

What exactly did the license say, and what are we inferring from it? Where did a particular conclusion come from? What happens when two obligations do not actually conflict, but still restrict what the resulting work may do? Which assumptions about copyright law did the reasoner use? And if a model changes six months later, can you still see the version on which an earlier result was based?

Those questions have accompanied DALICC from its beginnings as a research project. DALICC 2026 takes another close look at them across the platform: at the library, the reasoning behind it, the tools that use it, and the evidence behind the answers they give.

We started with the library.

Reading the library again

DALICC already held 343 license records. Every one of them was read again against the legal text of the license it models.

That resulted in 621 corrections.

Just as importantly, what was found, what was decided and what remained open is now written down record by record. A model should not simply tell you what it believes a license means. You should be able to see why.

The library then grew in two directions.

First, 116 records were written from the SPDX texts. Then another 121 records were added from licenses that GitHub projects actually declare: the or-later forms of the GNU family, SPDX exception combinations, permissive variants, source-available licenses, model licenses, and the Creative Commons legal codes from versions 1.0 to 3.0.

The library now holds 290 distinct licenses, together with 289 ports and editions, and 276 records carry an SPDX identifier.

Finding them should not require knowing exactly how DALICC names things. You can search by license name, by the SPDX identifier you already use, including identifiers SPDX has since deprecated, or by an identifier DALICC itself retired in 2023. Old identifiers lead to the records that replaced them. A typo gets a "Did you mean ...?"

Relationships between licenses are also explicit. If several records model the same legal text with one thing changed, they are linked. A license page can show its jurisdiction ports, editions and variants: an or-later form, an exception that removes a condition, or a rider that adds one.

Each of those variants remains a license in its own right. It can be searched, counted and reasoned over like any other record, while still saying exactly what it varies.

A license page should answer before it explains

Machine-readable licensing can become abstract very quickly. Most people visiting a license page, however, begin with much simpler questions.

Can I use this commercially?

Do I have to share my derivative work under the same terms?

Do I have to give attribution?

Those answers now appear directly under the title of every license. The detailed permissions, prohibitions and duties follow.

But there is another distinction we wanted to make visible: where an answer came from.

A statement may come from the text, in which case DALICC can show the sentence on which it rests where the record contains it. Or it may come by library convention, in which case the convention is named.

And then there is silence.

Most licenses say nothing about most possible acts. What follows from that silence is often a question of law, not a statement made by the license itself. We did not want DALICC to quietly turn those two things into the same kind of fact.

So those conclusions live elsewhere.

They are expressed as default rules in the dependency graph, together with the statute or legal principle on which the rule rests. One such rule is currently adopted by default: if a license says nothing about endorsement, it grants no right to use the licensor's name for endorsement.

On the license page, conclusions of this kind appear separately under "What applies by default", marked as coming by default rule.

That separation is one of the principles behind DALICC 2026: the text, the model and the assumptions used for reasoning should remain distinguishable.

Nothing in the library changes silently

Once license models are used for reasoning, changing one is no longer just editing a database row.

Every record therefore carries its version history and its review.

You can open an earlier version, compare two versions, and see what changed and why. Recent changes across the library can be followed from one page. If a newer version replaced a record, the older one says so. If the publisher withdrew a license, the record says from which date.

Nothing in the library changes silently.

That same principle carries into the tools that use the library.

A conflict is not the same as a restriction

This sounds like a small distinction. In practice, it changes the answer you give someone.

The License Compatibility Checker checks several licenses together. The GitHub License Compatibility Checker does the same for the dependencies of a repository. Both now distinguish a conflict from a restriction.

A conflict means the works cannot be combined under the licenses involved.

A restriction means they can be combined, but the combined work loses some freedom.

For example, MIT-licensed code can be incorporated into a GPL-3.0 project. The result can still be distributed, but it remains subject to GPL-3.0.

By contrast, two licenses that each require the whole resulting work to remain under themselves can genuinely conflict. GPL-2.0-only and GPL-3.0-only are a familiar example, unless an or later option or an explicitly granted compatibility provides a path from one to the other.

DALICC now explains the result rather than stopping at a compatibility label.

Under a check, you can see what the combined work must do: attribution, notices, share-alike obligations and other conditions. It also says what the check cannot determine.

If you give the GitHub License Compatibility Checker a target license, it separates conflicts among the dependencies from conflicts between a dependency and your chosen target. That makes it much easier to see what is actually blocking you.

The repository licenses are now resolved inside the service instead of through one public API call per dependency, which makes the checker faster and prevents a large analysis from failing halfway through.

And when the question is not compatibility but comparison, the License Comparator puts two licenses side by side, including things that are easy to miss in a simple permissions table: automatic termination and cure periods, patent grants, compatibility clauses and governing law.

From license text to model, and back again

The original direction of DALICC was mostly one-way: start with a license model and reason over it.

DALICC 2026 works much more deliberately in both directions.

The License Composer is where a model becomes a published license record. It runs a consistency check before publication, records the provenance of the license being modelled, and can start from any license already in the library. Pick one, load it, and change only what differs.

There are now two ways to work with the same underlying model.

The questionnaire follows the question tree DALICC has traditionally used. Expert mode shows every statement directly as a row, with a search box over the vocabulary that is valid at that point.

Switching between the two converts the model rather than resetting it. Nothing you already entered disappears.

The composer can also generate the license text into the form, where you can edit it before it is published alongside the model.

Then there is the opposite direction.

Text-to-License starts with the text itself.

Paste in a license and DALICC proposes a model for it. Each proposed statement comes with the exact quotation from which it was read and a confidence value.

The point is not to hide machine assistance behind a finished-looking answer. It is to give you something you can inspect.

Before the text is sent to the provider named on the form, DALICC asks for your consent. The text itself is not stored, and Text-to-License never publishes anything on its own.

If the library already contains a curated model of the same license, the generated reading can be placed beside it, with the differences shown in three columns.

License-to-Text travels in the other direction. Give it a library record, paste a model, or call it from the composer, and it writes the license out in plain English, section by section. It also names things that the model contains but the generated text has left out.

Together, the two tools make the boundary between legal text and machine-readable representation much easier to inspect.

The assumptions behind the answer are data too

There is still another layer we did not want to hide.

A reasoner does not operate on license statements alone. It also needs to know how concepts relate to each other.

Those relationships can easily disappear into the machinery. In DALICC 2026, they are objects you can inspect and work with in their own right.

The dependency graph on which the reasoning rests can be opened in full in the Dependency Graph Viewer. You can create graphs of your own in the editor, version them, publish them, share them and compare two graphs side by side.

You can also choose which graph the Composer and the License Compatibility Checker should reason with, both through the web interface and through the API.

The core graph was reviewed in the same way as the license records. It is now at version 2 and contains 46 statements describing how actions relate, each linked to the definition on which it rests.

It also contains the one currently adopted default rule, including its legal basis and the person who adopted it.

Beside the core graph, DALICC ships proposed graphs for several major markets: the European Union, United States, China, United Kingdom, Japan, India and Brazil.

Each begins with the core graph and adds proposed default rules relevant to that legal environment: moral rights that cannot be waived by a license, database rights, text and data mining exceptions, decompilation for interoperability, and rules around reselling a copy you bought.

Every one of these rules names its statute, explains in plain language what it does and makes clear that it is a proposal.

None is used unless you actively choose that graph.

And none of this is legal advice.

The documentation page "How reasoning works" explains why these checks exist and walks through a comparison in five steps. It ends with sublicensing, precisely because sublicensing illustrates an important limitation: a dependency graph represents one legal reading among possible readings.

That is why DALICC lets you inspect it and choose another.

Publishing also means being able to come back

The same concern with traceability shaped accounts and collaboration.

Accounts normally arrive by invitation. Where an installation permits it, you can also register yourself and confirm your email address, or sign in through your organisation.

A license you compose begins as a private draft. It appears nowhere else.

When you publish it, it receives its own permanent address. Publishing a later change creates a new version, while the old address continues to resolve and points to its successor.

Drafts have history too. Every save is kept, so you can return to an earlier revision, download it or restore it.

Licenses and dependency graphs can be shared with another account as owner, editor or viewer. Ownership can be transferred. A record can be submitted to the curated library or reported as incorrect.

Reviews do not have to happen as a silent accept-or-reject operation. A reviewer works through submissions and correction requests while an inbox carries the discussion.

A review is a conversation rather than a silent verdict.

Where email delivery is configured, the same notifications can reach you by email, and you can turn that off.

Published work also has a clear publisher. Each published license names its publisher through a stable public profile containing the name, the month the account was created, and the licenses and graphs that account has published. Nothing else appears there.

Bookmarks remain local. My Bookmarks lives in your browser, and you can export the list and import it on another machine.

One service, two generations of API

DALICC 2026 also brings the website and API together as one service.

The API now has two generations.

Version 1.1 keeps the ten previously documented operations exactly as they were, so existing integrations do not have to be rewritten. New operations sit beside them: license comparison, consistency checking, review records, version histories, dependency graph operations, SPDX mappings and a health check.

Version 2, under /v2, works with the versioned world that the rest of the platform now exposes.

It serves every published version of a license record, dependency graphs and the vocabulary. Responses include a content hash that clients can recompute themselves. It can list data releases, report what changed since a particular release or date, and describes the service through a discovery document.

API tokens are created and withdrawn by the account that owns them. The same page shows usage and limits, while every response reports how much of the allowance remains.

The API reference lives beside the service and can be tried directly in the browser.

For Python, the dalicc package is available on PyPI under the Apache License 2.0. It includes a command-line client and wraps the same operations for use in scripts and pipelines.

Being explicit about what "reviewed" means

A system that talks about legal texts should also be clear about its own limits.

Every correction to the library becomes a version, accompanied by a summary of what changed and the finding or decision behind it.

But the current review has an important limitation: one person read the records for the association. There has not yet been a second reader or a lawyer checking each record.

So when DALICC says that a record is Reviewed, it means that the model has been read against its license text.

It does not mean that the model is a legal opinion.

That distinction matters, and we would rather state it directly.

Privacy should be inspectable too

The same applies to privacy.

The privacy notice explains, for each thing you can do in DALICC, what information is processed, how long it is kept, who else receives it and on what legal basis.

The notice itself has versions. If a member previously agreed to an older wording, DALICC shows what changed.

Where an action requires agreement, consent is requested on the form where the action happens and is recorded together with what you did.

Publishing is different because it is permanent and public. That is why the confirmation that says so appears immediately before anything is written.

The site also avoids unnecessary third-party requests. Pages, stylesheets, scripts, images and fonts are all served by DALICC itself, so simply visiting a page does not tell another company what you were reading.

The exception is the automated submission check that an installation may enable for the Composer or sign-up page. Where it is enabled, the page says so before you use it.

Where this leaves DALICC

DALICC 2026 changes a great deal of the platform, but not the idea at its centre.

The goal is not simply to store machine-readable licenses and return a compatibility result.

We want the path to that result to be inspectable.

If DALICC says that an obligation applies, you should be able to ask where it came from.

Was it written in the license text? Was it introduced by a library convention? Did it follow from a default rule? Which dependency graph was used? Which version of the license record produced the result? What changed afterwards?

The answer should lead back through that chain rather than disappear inside the software.

There is still plenty to build, and the platform remains in development.

If you find a license model that is wrong or missing, or something in the reasoning is unclear, write to Tassilo Pellegrini at tassilo.pellegrini@ustp.at or Giray Havur at giray.havur@ustp.at.

The license data, vocabulary, dependency graphs and reasoner are available at github.com/dalicc/dalicc. The Python client is at github.com/dalicc/python-sdk. Issues and pull requests are welcome.

DALICC is operated by the association behind it, with USTP, University of Applied Sciences St. Pölten, as project partner and host. The platform code is licensed under AGPL-3.0-only, with a commercial license available from the association where AGPL-3.0-only is not suitable. The Python client is Apache-2.0, and the license data is CC BY 4.0, as recorded in the RDF itself.

DALICC is still developing. If you find something that is wrong, unclear or missing, tell us. We want the platform to improve through use, scrutiny and contribution.