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

How reasoning works

DALICC does not compare licenses word by word. It reads each license as a list of rules over named actions, and it keeps what it knows about those actions in a separate, editable file: the dependency graph. Put the two together and the service can answer two questions: does this license contradict itself, and can these licenses hold for one work at the same time.

Both questions come up before anything is published, and neither is easy to settle by reading the license text. The License Composer asks the first one for you: it checks a license against itself and names what it finds before you publish. It also runs a test that only makes sense inside a single license, that a license requiring share alike for the whole work does not at the same time permit changing the license without a duty to pick a compliant one, because the work could then leave the license that requires it to stay. The License Compatibility Checker asks the second one over a whole bundle, lists every pair it finds, direct and derived, with the chain behind it, and tells a conflict from a restriction: what no combined work can meet from what the combined work may merely not do. The API answers both, so a program gets what these pages get. Every one of these checks reasons with a dependency graph, and you choose which graph that is.

A walkthrough

Two made up licenses, called A and B, and the actions they talk about. The licenses are invented; every relation drawn between the actions is a real statement of the dependency graph DALICC ships with.

Two license models with the action graph between them License A permits distributing, printing and keeping the work exclusive, and requires attribution. License B prohibits distributing and prohibits use, permits commercializing and requires the license notice. Between the two, arrows from the dependency graph show that printing is a kind of presenting, that presenting and distributing are kinds of use, and that keeping a work exclusive contradicts commercializing it. print distribute present use exclusivity commercialize LICENSE A distribute print exclusivity attribution LICENSE B distribute use commercialize notice CONFLICT CONFLICT CONFLICT

A check mark is a permission, a cross a prohibition, a dot a duty. An arrow between two actions is a statement of the dependency graph, and a red mark is a conflict the checker reports.

  1. Step 1 of 5

    The rules of a license

    Read by a machine, a license is a list of rules. Every rule says one of three things about one action: it is permitted, it is prohibited, or it is a duty the user takes on. The actions are not free text. They come from a shared vocabulary, so two licenses written years apart by different people still name the same things. The two cards are the two licenses of this example, one rule to a line.

  2. Step 2 of 5

    The dependency graph

    Actions are not independent of each other, and no license says how they relate. That knowledge sits in a file of its own, the dependency graph, and it comes in four kinds. One action can be a kind of another: printing is a kind of presenting, presenting is a kind of use. One action can bring another with it: asking for attribution brings a notice with it. Two names can mean one action: the Creative Commons attribution term and the ODRL one. And two actions can contradict each other, so nobody can be allowed both: keeping a work exclusive and commercializing it. A chain of statements is followed to its end, which is how printing turns out to be a kind of use. Two names for one action are that action throughout, so a statement written about one name holds of the other. Contradicting is never chained with a second contradiction.

  3. Step 3 of 5

    A direct conflict

    The plainest conflict needs no graph at all. License A permits distributing. License B prohibits distributing. One action, one yes and one no, so the two licenses cannot both hold for one work. This is a direct conflict, and the answer names both statements and the licenses they come from.

  4. Step 4 of 5

    A conflict through a chain

    Now nothing matches by name. License A permits printing; License B says nothing about printing, it prohibits use. The graph closes the gap: printing is a kind of presenting, and presenting is a kind of use. Follow the two steps and the permission and the prohibition meet on the same action. This is a derived conflict, and the answer carries the statements of the graph that produced it, so you can see why it was reported.

  5. Step 5 of 5

    Two permissions that contradict

    A conflict does not need a prohibition. The graph says that keeping a work exclusive contradicts commercializing it: no one work can be both. License A permits the first, License B permits the second, and the two permissions cannot stand together, although neither license forbids anything. This one is reported even when both permissions come from the same license, which is how a license is caught contradicting itself. All three conflicts are marked in the picture now, because these two licenses collide in more than one place and a real answer lists every pair it finds, not the first.

One graph is not the only graph

DALICC ships with a core graph A core graph is curated by the project. It is what everybody reasons with unless they choose another graph. that says how the actions of the vocabulary relate. It is one reading, and not the only defensible one. A second graph can hold a different legal reading of the same actions, the reading of another jurisdiction, or a reading that fits the work of one organisation inside a single jurisdiction. Whichever graph a check runs with, the answer follows that graph and no other.

Here is a statement worth disagreeing with. The core graph says that sublicensing and granting use are one act: dalicc:sublicense owl:sameAs odrl:grantUse. A legal team that treats granting use under the same terms and sublicensing under new terms as two different acts takes that statement out of a graph of their own, in both directions, because the core graph writes it both ways round. From then on a license that permits granting use, next to one that prohibits sublicensing, is no longer reported to them as a conflict. The edit runs the other way as well: a graph that adds a statement the core graph leaves out reports pairs the core graph lets through.

You do not have to start from nothing. Copy the core graph, change the statements you read differently, and you have a graph of your own with a version behind every save, which you can share with the people you work with and publish once it has settled. The Dependency Graph Editor is where that happens, and the manual describes the whole life of a graph under Dependency graphs. A graph records a reading of the law; it does not make that reading correct, and nothing here is legal advice.

The jurisdiction graphs DALICC ships work the same way. Each one is a complete graph: the core graph's statements, and on top of them what the law of one market says differently. A jurisdiction graph can add default rules, leave out a statement of the core graph that its law does not support, or replace one of the core graph's rules, and it names the legal reason every time, with a plain explanation beside the citation. A check under it reads that one graph and nothing else. To see exactly what one graph does to another, compare the two: the comparator lists what the second graph adds, what it does not have and what it holds in a different form.

What a license does not say

A record in the library states what its text states, and most license texts are silent about most acts. What follows from that silence is a question of law rather than of the text, and the answer can differ from one country to the next, so a dependency graph carries a second kind of statement for it: a default rule A default rule names one action, what applies to it when the license says nothing, the territory it holds in, and the statute or principle it rests on. . The core graph adopts one: a copyright license that says nothing about endorsement grants no right to use the licensor's name, which rests on trademark law and the protection of names. A check under that graph therefore reads a silent license the way it read a record that carried the prohibition, and every finding says which side came from the text and which from the rule.

Seven further graphs hold the rules proposed for the European Union, the United States, China, the United Kingdom, Japan, India and Brazil: moral rights a license cannot waive, the database right, the mining exceptions, decompilation for interoperability and exhaustion after a first sale. Each rule names the statute it rests on, explains in two or three plain sentences what it does and why, is marked as a proposal, and reaches no reader who chooses nothing. The graphs themselves are published under plain names such as "European Union default rules"; the status belongs to each rule, and every finding a rule supplied says "by default rule (proposed)" or "(adopted)". Choosing one of those graphs is a request to see what its rules would do. They are questions for a legal reviewer and nothing in them is legal advice.

The same thing in the vocabulary

The four kinds of statement have names, and so do the two kinds of answer. This is what you will see in a graph file, in the reported chains and in the API.

Relation Reads as A statement of the default graph
odrl:includedIn the first action is a kind of the second odrl:print odrl:includedIn odrl:present
odrl:implies the first action brings the second with it cc:Attribution odrl:implies cc:Notice
owl:sameAs two names for one action cc:Attribution owl:sameAs odrl:attribute
dalicc:contradicts the two cannot both be allowed of one work odrl:ensureExclusivity dalicc:contradicts odrl:commercialize
  • A rule of a license is an odrl:permission, an odrl:prohibition or a duty, and it carries its odrl:action. Actions come from the ODRL, Creative Commons and DALICC vocabularies.
  • odrl:includedIn, odrl:implies and owl:sameAs are followed through chains, so odrl:print odrl:includedIn odrl:use follows from two statements without being written anywhere. A chain may cross from one of them into another: owl:sameAs gives an action a second name, and everything said about the one name is said about the other. dalicc:contradicts is never chained with a second contradiction, but a synonym of either side counts as that side.
  • A permission against a prohibition over the same action is reported as direct. A permission against a prohibition that the graph relates, and two permissions the graph says contradict each other, are reported as derived, with the statements of the graph that produced them.
  • Each pair is reported once, whichever order the licenses are given in, and the two may be the same license: that is what makes the consistency check possible.
  • A duty of one license against a prohibition of another, and two licenses that each keep the whole work under themselves (share alike of the whole work, or of every derivative with changing the license forbidden), are reported as direct too. The second is weighed only when nothing links the two: not the same license text, not an "or later" option that reaches the other version, not a compatibility clause. GPL-2.0-only with GPL-3.0-only is such a pair; GPL-2.0-or-later with GPL-3.0-only is not.
  • The License Compatibility Checker and its GitHub use case read every pair as one of three kinds. A conflict is one no combined work can meet. A restriction is a permission against a prohibition: MIT permits changing the license and GPL-3.0-only forbids it, so the combined work may not change its license, and MIT code can still go into a GPL-3.0 work. A finding about one license alone is a license that contradicts itself. The verdict names the worst kind, and under it the pages list the duties of the combined work, which the reasoner does not weigh against each other.
  • Nothing here knows what kind of asset a license covers. The License Compatibility Checker checks that on its own, when you name the license you want to publish the result under, and reports a mismatch next to the conflicts.
  • The graph DALICC ships with holds 46 statements. The Dependency Graph Viewer prints them, the file itself is a download, and the Dependency Graph Editor is how you write your own.

What the check cannot see

  • Compatibility nobody states. Some licenses name the licenses a work may move to: CC BY-SA 4.0 lets an adaptation go under GPL-3.0, the LGPL lets its code be relicensed under the GPL, and GPL-3.0 and AGPL-3.0 allow each other in their section 13. Where a record states such a license, the check sees it in the direction it is granted and says the combined work has to be released under the named license. Where no record states it, two licenses that each keep the whole work are reported as a conflict.
  • Clauses the vocabulary cannot express. A ban on selling the software (the Commons Clause) or on production use (the Business Source License) has no action of its own, so nothing is weighed against it.
  • The texts themselves. The check reads what a record states, not the license text, and a record can miss a clause. Read the license texts before you combine the works.

Try it

  • License Compatibility Checker Put two or more licenses in a bundle and read the verdict: the conflicts, the restrictions, what you must do and what the check cannot see.
  • License Composer Write a license of your own and check it against itself before you publish it.
  • Dependency Graph Viewer Read the statements the answers are derived from, grouped by relation.
  • Dependency Graph Editor Disagree with a statement? Start from the core graph, change what you disagree with and reason with your version.
  • The reasoner, in detail The reasoner's own documentation, in the public data repository: the logic program, the external atoms, the request and answer shapes, and the limits.