How DALICC is licensed

Part of the documentation index.

This file is the authoritative overview of who owns what in this repository and under which terms it may be used. It is a description of the project's licensing, not legal advice. Questions that need a binding answer go to the association's legal counsel.

Contact for anything on this page: tassilo.pellegrini@ustp.at or giray.havur@ustp.at.

1. Source code: AGPL-3.0-only#

All first-party source code in this repository is licensed under the GNU Affero General Public License, version 3 only (SPDX: AGPL-3.0-only), with one exception: the Python client in sdk/, which is Apache-2.0 for the reasons given below. The full text of the AGPL is in LICENSE. "Only" means that the "or (at your option) any later version" clause is deliberately not granted.

Copyright notice:

Copyright (C) 2021-2026 DALICC - Verein zur Förderung der Rechtssicherheit in der Datenbewirtschaftung (ZVR 1249185710) and contributors. Principal author: Giray Havur.

The association:

• Name: DALICC - Verein zur Förderung der Rechtssicherheit in der Datenbewirtschaftung
• Register: ZVR 1249185710, Austria
• Seat: Vienna
• Delivery address: Campus-Platz 1, 3100 St. Pölten, Austria
• E-mail: tassilo.pellegrini@ustp.at or giray.havur@ustp.at

The AGPL matters here because DALICC is normally run as a network service. Section 13 of the AGPL requires that users who interact with a modified version over a network can obtain the source of that modified version. Running a modified DALICC as a public or internal web service therefore triggers the source offer.

Commercial licence#

The same code is also available under a commercial licence from the association, for organisations that cannot or do not wish to comply with the AGPL, for example because they want to keep modifications private while operating a network service. See COMMERCIAL-LICENSE.md.

The Python client: sdk/** is Apache-2.0#

The Python client and the dalicc command line tool in sdk/ are licensed under the Apache License, Version 2.0 (SPDX: Apache-2.0). The text is in sdk/LICENSE and the notice that ships beside it in the distributions is sdk/NOTICE.

The association decided this on 2026-09-23. A client that only talks to a public API has no reason to carry the service's terms with it: it holds no license data, it runs on the caller's machine and it never becomes part of a DALICC deployment. A permissive licence is also what people expect of an API client, and it is what lets them link the client into their own tooling. The service is unaffected and stays AGPL-3.0-only, and the commercial licence has nothing to say about the client, because Apache-2.0 already grants what it would be bought for.

The client is developed here and mirrored to a public repository of its own at https://github.com/dalicc/python-sdk, which is the address a reader of the package on a package index follows and which scripts/publish_sdk.sh copies sdk/ into.

2. Data: licensedata/** is CC-BY-4.0#

The license library (licensedata/licenses/*.ttl and the generated licensedata/licenselibrary/licenselibrary.ttl), the dependency graph (licensedata/dependencygraph/dg_default.ttl) and the DALICC vocabulary (licensedata/vocabulary/dalicc-ns.ttl) are published under the Creative Commons Attribution 4.0 International licence (SPDX: CC-BY-4.0). The legal code is in licensedata/LICENSE.

Attribution line to use when you redistribute or build on the data:

DALICC License Library, DALICC - Verein zur Förderung der Rechtssicherheit in der
Datenbewirtschaftung, https://dalicc.net, CC BY 4.0
(https://creativecommons.org/licenses/by/4.0/)

This is not a new decision. The licence is already declared inside the data itself:

• every license record carries cc:license dalicclib:CC-BY-4.0;
• the vocabulary declares dct:license <http://creativecommons.org/licenses/by/4.0/> on the https://dalicc.net/ns# ontology resource, and repeats it in the file header.

licensedata/LICENSE records the same thing at the file-system level. The RDF statements and the file are two views of one licence, and they must stay in agreement: if the data licence is ever changed, all three places change together.

Note that the content of a license record describes a third-party licence (MIT, Apache-2.0 and so on). CC-BY-4.0 covers the DALICC description of that licence, not the licence it describes, and it grants no rights in the third-party licence text itself.

3. Archived site content: app/content/**#

app/content/pages/*.md, app/content/blog/*.md and app/content/publications.yaml reproduce texts and blog posts from the original dalicc.net website. They are not relicensed by this repository. Copyright remains with their respective authors and with the association. They are kept here so the site can be served, and so the project's own history is not lost a second time.

Do not assume the AGPL or CC-BY-4.0 applies to this material. If you want to reuse a text or a blog post, ask at tassilo.pellegrini@ustp.at or giray.havur@ustp.at.

The same applies to the DALICC name, the DALICC logo (app/static/DALICC_full_logo_RGB.svg and the older ..._beta.svg that the legacy /web/* templates still load) and the other brand assets: no trademark or branding rights are granted by any licence in this repository.

4. Third-party components#

Vendored front-end assets, fonts, the Tumult Hype runtime, the Python dependencies, the Virtuoso image and the answer-set solver keep their own licences. The inventory, with the licence of each item and the items whose licence could not be verified, is in THIRD_PARTY.md. NOTICE is the short form that ships with a distribution.

5. SPDX headers in source files#

Every first-party source file carries two SPDX tags, so that the licence of a file travels with the file. The identifier follows the directory: a file under sdk/ carries Apache-2.0 and every other file carries AGPL-3.0-only, which scripts/add_spdx_headers.py applies and tests/unit/test_spdx_headers.py proves. The convention itself, the tag each kind of file uses and the exclusions are in docs/DEVELOPMENT.md, where the people who add files to the repository read it.

6. Contributing#

Every contributor signs the contributor licence agreement in docs/legal/CLA.md before their first change is merged. The CLA grants the association the exploitation right it needs in order to offer both the AGPL and the commercial licence, and licenses the contribution back to the contributor for their own use. Contributors keep their moral rights, including the right to be named.

Without a signed CLA a pull request cannot be merged, however good it is. See CONTRIBUTING.md and docs/legal/README.md.

7. Legal prerequisites still open#

Dual licensing only works if the association actually holds the rights it licenses. The following items are open and are for review by the association's legal counsel. They are listed here as a checklist, not as an opinion on whether any of them is required in a given case.

• [ ] Written exploitation-rights grant (Werknutzungsrecht) from each author to the association, exclusive, worldwide, unlimited in time, covering every existing contribution. Template: docs/legal/RIGHTS_GRANT_TEMPLATE.md. Without it the association cannot grant a commercial licence that departs from the AGPL.
• [ ] Employer consent where code was written in the course of employment. Austrian copyright law (UrhG section 40b) gives the employer an exploitation right in computer programs created by an employee in the performance of their duties, unless agreed otherwise. Each author states their employer at the time of writing and, where applicable, obtains a confirmation or waiver. The rights-grant template has a field for this.
• [ ] Consent of the authors of the pre-2026 code, that is everyone who contributed during the funded research project, and of the project partner USTP, University of Applied Sciences St. Pölten, for the parts developed there and for any rights arising from the funding contract.
• [ ] Check the funding conditions. The project was funded by the Austrian Research Promotion Agency (FFG). The funding contract and any consortium agreement are checked for exploitation, publication and open-source obligations before the commercial licence is offered.
• [ ] Statutes (Statuten) that permit licensing as an economic activity. Selling commercial licences is an economic activity of the association and has to be covered by its stated purpose and means, with the tax treatment settled.
• [ ] An up-to-date register extract (ZVR) for the association's representatives. The extract on file shows a board term from 06.05.2022 to 05.05.2024, which has expired. Whoever signs a licence agreement must be a currently registered representative with authority to sign.
• [x] Settle the copyright year range. Settled on 2026-09-15: the range is 2021-2026, because the first commit in the history is from 19 February 2021 and the work it covers is part of the same program. Every notice, SPDX header and template in the repository now reads 2021-2026; there is nothing left that reads
  2022. The range end moves with the next release, not with the calendar.
• [ ] Decide how signed documents are stored. Signed CLAs and rights grants are kept by the association, not in this repository. See docs/legal/README.md.

Until the first two items are complete for all existing code, the AGPL publication stands on its own (it is the licence the copyright holders grant), but a commercial licence should not be signed.