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

What's new in DALICC

This page is the short version, written for the people who use DALICC: what the platform can do now that it could not do before. The technical changelog, kept with the source code, records every change in full, including the ones only a developer or an administrator would notice. The license data has its own history in the public data repository.

DALICC 2026

The 2026 renewal, still in development, adds what the platform was missing: a reviewed and much larger license library, answers you can read at a glance, checks that tell a restriction from a conflict, license models you own and can publish, dependency graphs of your own, a review process with messaging, a second generation of the API and a Python client. Everything the API promised before still works, unchanged, at the same addresses. It is grouped below by who gets it; what a visitor gets, every member gets too.

What a visitor gets

A larger library, read against the texts.

  • The library holds about 580 records covering about 290 distinct licenses; the home page counts them from the data. They include every license approved by the Open Source Initiative, every license listed on choosealicense.com, the open data and open content licenses, and the licenses GitHub projects declare: the or-later forms of the GNU licenses, the SPDX exception combinations, the source-available licenses, the model licenses and the Creative Commons legal codes of versions 1.0 to 3.0.
  • Ports, translations and editions of a license, such as the many jurisdiction versions of Creative Commons, are grouped under the license they come from, with a switch to see them all. Variants are licenses of their own and listed like any other: the or-later form, an exception that lifts one condition, a rider that adds one. Each says which record it varies.
  • You can look a license up by the SPDX identifier you already use, including the identifiers the SPDX list has since deprecated, and by an identifier DALICC retired in 2023, which leads to the record that replaced it. A typo gets "Did you mean ...?".

A license page that answers first.

  • Under the title, three lines say whether commercial use is allowed, whether share alike is required and whether attribution is required. The permissions, prohibitions and duties follow, then everything else.
  • Every statement says where it comes from: from the text, with the sentence it rests on where the record keeps it, or by library convention, with the convention named.
  • "What applies by default" says what follows for the acts a license says nothing about. Most licenses are silent about most acts, and what follows from that is a question of law, so DALICC states it as a rule of the dependency graph, with the statute or principle beside it and by default rule on every finding that rests on one. One rule applies unless you choose otherwise: a license that says nothing about endorsement grants no right to use the licensor's name.
  • "Further terms" says what a license states about itself: automatic termination and its cure period, a patent grant, a compatibility test, the governing law and the rest.
  • Every record carries its version history and its review: when it was read against the legal text, by whom, what was found, and what a later version settled. A page that is superseded says that a newer version exists; one its publisher withdrew says so and from which date.
  • A badge and a machine readable summary for every license, to put in a repository, and the license written out as text, for anybody to download.
  • A glossary says in one place what the site means by record, port, variant, default rule, conflict, restriction and the rest.

Checks that say what you may do and what you must do.

  • The License Compatibility Checker and the GitHub License Compatibility Checker tell a conflict from a restriction. A conflict means the works cannot be combined; a restriction means they can, but the combined work may not do one thing. MIT code in a GPL-3.0 project is a restriction: the result stays under GPL-3.0. Under every answer, What you must do lists the duties of the combined work, and What the check cannot see says where to stop trusting it.
  • Two licenses that each keep the whole work under themselves are reported as a conflict, GPL-2.0-only with GPL-3.0-only for instance, unless an "or later" option or a compatibility the license grants by name leads from one to the other.
  • The checker can take a target license, and then reports the conflicts between the dependencies and those with your target separately. It resolves the licenses of a repository inside the service, which is why it is faster and no longer fails halfway.
  • The License Comparator answers the "Further terms" questions side by side, and the License Search asks what the license you need must allow.
  • Every tool says in a note under its introduction that it does not replace legal advice, and the footer of every page says the same.

Reasoning you can read and choose.

  • How reasoning works explains why the checks exist, what the reasoner does when it compares licenses and what the dependency graph is for, in five steps, and closes with why a graph is one legal reading among several.
  • The Dependency Graph Viewer shows a graph in full, Compare graphs puts two side by side, and the checks let you choose the graph they reason with.
  • DALICC ships one graph per big market, the European Union, the United States, China, the United Kingdom, Japan, India and Brazil, each the core graph plus the default rules proposed for that market: moral rights a license cannot waive, the database right, the mining exceptions, decompiling for interoperability, and selling on a copy you bought. Every rule names its statute, explains in plain words what it does, and says whether it is proposed or adopted. None of them is used unless you choose that graph, and nothing in any of them is legal advice.
  • The vocabulary grew from 41 terms to about 140, and every term has a page of its own at /ns with its definition, its kind and the records that use it.

Text tools.

  • Text-to-License reads the text of a license and proposes the DALICC model for it, with the exact quote each statement was read out of and a confidence value beside it, and the conventions the library adds marked as such. It asks for your consent before the text is sent, never stores the text, publishes nothing and shows the reading next to the curated record of the same license. It needs an account.
  • License-to-Text writes a license model out in plain English, section by section, and names anything the text left out. It needs an account unless the installation opens it to everybody; the text of a library license written from the vocabulary alone is a download on its page for anybody.
  • My Bookmarks keeps a shortlist in your own browser, and you can export it and read it back on another machine.

What a member gets

  • An account, by invitation, or on the sign-up page or with your organisation's sign-in where the administrators have opened them. Two roles on the platform and three on each license (owner, editor, viewer), so a license can be shared, handed over or kept private.
  • The License Composer publishes for real. It runs a consistency check first, takes the provenance of the license you model, can start from any license in the library, and offers two views of the same license: the questions, or an expert view with every statement as a row. It can write the license text into the form for you to correct.
  • A license you compose starts as a private draft. Every save is kept and can be restored. Publishing gives it an address that keeps resolving, publishing a change mints a new version and leaves the old address in place, and Withdraw this license says from which date you no longer offer it.
  • Your own dependency graphs: edit them in a table of statements, start one from a Turtle file, share and publish them, and reason with them in the composer and the License Compatibility Checker, drafts included.
  • You can offer a license or a graph for the curated library and report a mistake in a curated record. A reviewer works through both, an inbox carries the conversation, and the same notifications reach you by mail where the site sends mail.
  • The name you publish under is yours alone, and every published license names you by a public profile page with your name and your published work, and nothing else.
  • A privacy notice says, for each thing you can do here, what is processed, how long it is kept and who else sees it. When it changes, you are shown what changed the next time you sign in. Your account page hands you a copy of everything the site holds about you, and it can delete the account.

What an administrator gets

  • Administration pages grouped the way the work is: accounts, review, content, reports and settings, each with an overview card.
  • The choice of how people get an account: invitation only, which stays the default, or sign-up with address confirmation and approval, a list of allowed domains, and sign-in with an identity provider.
  • The look of the site, chosen from nine palettes, seven font sets and four type scales, with the contrast of every pair printed as a number and a preview before anything is applied. Every font is served by the site itself.
  • The two assistants: up to three providers with failover, their keys, models and daily caps, a switch and an allowance for License-to-Text, and the figures of both.
  • Usage statistics counted without any personal data, per-account API limits, the curated records editable from the site with every correction a version, a blog with an image library that can be moved to another installation in one file, and an audit log of every administrative act.
  • Destructive actions ask before they act, and the answer to a form appears next to the button that sent it.

What a developer gets

  • The ten documented operations are unchanged. Nothing you call today has to be rewritten. Beside them sit comparing licenses, the consistency check, the review record and the version history of a record, the dependency graph operations, the SPDX mapping and a health check.
  • A second generation of the API under /v2: every published version of a record, a dependency graph and the vocabulary, each with a content hash anybody can recompute, the releases of the data and a feed of what changed since a date or a release, one discovery document that says what the service offers, and errors in one standard shape. Answers can be cached and revalidated, and read from any origin.
  • API tokens you create and withdraw yourself, with your limits and your usage on the same page. Every answer says how much of the allowance is left.
  • A Python client with a command line tool, published on PyPI as dalicc under the Apache License 2.0 (a release candidate until the release), covering the library, the graphs, both reasoning checks, composing and both assistants.
  • The license data, the vocabulary, the dependency graphs, the reasoner and the checks that keep them honest are public at github.com/dalicc/dalicc, under CC BY 4.0 for the data.

How the library was reviewed

  • Every one of the 343 records the library held was read against the legal text of the license it models, and 621 corrections were applied. 116 records were then written from the SPDX texts, and another 121 from the licenses GitHub projects declare. What was found and what was decided is written down, record by record.
  • Every correction is a version. The record keeps what it said before, next to a summary of what changed and the finding or the decision behind it, so nothing in the library changes silently.
  • One person read the records for the association, and no second reader or lawyer has checked them yet. A record marked Reviewed has been read against its text; it is not a legal opinion.

The platform

  • The website and the API are one program, at the addresses they always had.
  • The menu is grouped into About, Licenses, Tools, Reasoning, Blog, Documentation and API, each with a page that introduces what sits under it, and the home page covers everything the site offers in six cards.
  • DALICC is operated by the association behind it, with USTP, University of Applied Sciences St. Pölten, as project partner and host. Write to Tassilo Pellegrini (tassilo.pellegrini@ustp.at) or Giray Havur (giray.havur@ustp.at), or use the contact form, which reaches both.
  • The documentation on the site is the user guide: the introduction, the manual for every page and tool with its glossary, the administration handbook, the API reference, the Python client, what stays compatible between releases and how DALICC is licensed.
  • The blog starts again with one post, DALICC 2026: what the renewal brings, and how to take part.
  • The code is AGPL-3.0-only with a commercial alternative from the association, the Python client is Apache-2.0, and the license data is CC BY 4.0.

Before 2026

  • 1 November 2016 to 31 March 2019: DALICC is built as a research project funded by the Austrian Research Promotion Agency (FFG) and led by USTP, University of Applied Sciences St. Pölten, with four partners. The information model, the dependency graph and the four modules of the framework come out of it.
  • 2019 to 2021: the library and the reasoning are published as a web service.
  • 2021: netidee Call 16 funds the step from a prototype to an operated, open service, and awards DALICC the special prize for "Data Understanding".
  • 2022: the association behind DALICC appears publicly for the first time, at a tutorial in Vienna, and gives the community from business and science a home.
  • 12 December 2023: the framework, its services and the license data are released as open source.
  • 4 November 2025: the host institution is renamed USTP, University of Applied Sciences St. Pölten.

The About page tells that story in full, with a source for every date.