Skip to content

Decide the conjunctive licence expression, and name Unicode-3.0 in the set - #275

Merged
iderex merged 1 commit into
mainfrom
decide-the-conjunctive-licence-expression
Sep 1, 2026
Merged

Decide the conjunctive licence expression, and name Unicode-3.0 in the set#275
iderex merged 1 commit into
mainfrom
decide-the-conjunctive-licence-expression

Conversation

@iderex

@iderex iderex commented Sep 1, 2026

Copy link
Copy Markdown
Contributor

The issue this belongs to

Closes #268

What changed

One decision record, docs/decisions/0268-a-conjunctive-licence-expression.md,
and its line in docs/decisions/README.md. Nothing else in the tree moves: no
manifest entry, no check, no workflow.

The record answers two questions that arrived together and are not the same
question.

The first is about the set rather than about any licence. 0103's licence set is
an enumeration written for a single term and for a dual offer, and it has no rule
for a conjunction. The record states one: a conjunction is admitted only where
every member is admitted, and a member the set names in neither half leaves the
expression UNDECIDED rather than admitted. So the enumeration is total in three
states instead of two, and an unnamed term is a question nobody has answered
rather than a permission nobody wrote out.

The second is the term itself. Unicode-3.0 is named admitted, so
unicode-ident, offered as (MIT OR Apache-2.0) AND Unicode-3.0, is admitted
member by member. The third answer the issue offers, admitting the package
because it reaches no client binary, is refused, on 0103's own reasoning about
the test tree rather than on a new one.

No pointer is added to 0103. 0001 permits that edit only for a case the earlier
record already names, and a conjunction is not a case 0103 names at all, so an
edit pointing here would be adding the case and the route in one move. The
residual that leaves is stated in the record rather than softened.

What failure it prevents

A reader meeting (MIT OR Apache-2.0) AND Unicode-3.0 with no rule for a
conjunction has two quiet ways out. Reading the dual offer and stopping admits
the package on a term nobody examined. Reading the conjunction as a choice admits
it on MIT. Both produce a manifest line citing a clause of 0103 that does not
reach the expression, nothing in this repository reads that line, and the first
reader to notice would be whoever assembles the notices for a release, after
eleven clients have shipped the graph.

It has not happened here. 0243 met the expression, declined to place it, and said
so by name, which is why this is a decision written before the manifest entry
rather than a correction after one.

Evidence

Every block pasted in the record was re-run against origin/main at the commit
this branch is based on before the record was committed, and four line ranges
were corrected because they did not reproduce.

The base:

git rev-parse origin/main
2ed77e65c0c2b144dd3ef4befb7c63aa23c6ac31

The term is named in neither half of 0103's set:

git show origin/main:docs/decisions/0103-what-admits-a-dependency-and-what-is-refused.md | grep -c 'Unicode-3.0'
0

The expression, read from the package's own manifest rather than from a
resolver's summary of it:

gh api repos/dtolnay/unicode-ident/contents/Cargo.toml --jq '.content' | base64 -d | grep '^license'
license = "(MIT OR Apache-2.0) AND Unicode-3.0"

0103 refuses every licence whose terms cannot be satisfied inside a work
distributed under AGPL-3.0-or-later. That is the test, and it is answered out
of this repository's own licence file rather than out of a judgement about
whether the terms read as permissive:

git show origin/main:LICENSE | sed -n '349,365p'
  Notwithstanding any other provision of this License, for material you
add to a covered work, you may (if authorized by the copyright holders of
that material) supplement the terms of this License with terms:

    a) Disclaiming warranty or limiting liability differently from the
    terms of sections 15 and 16 of this License; or

    b) Requiring preservation of specified reasonable legal notices or
    author attributions in that material or in the Appropriate Legal
    Notices displayed by works containing it; or

    c) Prohibiting misrepresentation of the origin of that material, or
    requiring that modified versions of such material be marked in
    reasonable ways as different from the original version; or

    d) Limiting the use for publicity purposes of names of licensors or
    authors of the material; or

The licence asks three things and nothing else - a notice carried with the copies
or in the documentation, a warranty and liability disclaimer, and a bar on using
a copyright holder's name to promote - and the three land on (b), (a) and (d).
The full text the record reads that out of:

gh api repos/spdx/license-list-data/contents/text/Unicode-3.0.txt --jq '.content' | base64 -d | sed -n '36,39p'
Except as contained in this notice, the name of a copyright holder shall
not be used in advertising or otherwise to promote the sale, use or other
dealings in these Data Files or Software without prior written
authorization of the copyright holder.

The package is not in this tree's graph today, so nothing here has to carry a
notice yet:

git grep -n 'unicode-ident' origin/main -- Cargo.lock Cargo.toml ; echo "exit=$?"
exit=1

The two checks that judge a document ran on this branch and passed:

bash .github/doc-paths/doc-paths.sh check | tail -3
-- names-a-path-that-resolves
ok    71 document(s), 262 named path(s) resolved, 0 excused as examples

bash .github/invariants/invariants.sh check ; echo "exit=$?"
exit=0

What this does not cover

Nothing in this repository reads a licence expression, so the rule this record
states is refused by no check. It is carried by the review and by whoever writes
the line beside a manifest entry, which is what 0103 already says of itself. No
guard is added here and none bites.

No graph was resolved for this change. The expression is read from the package's
manifest and from the licence texts, and the per-triple counts the record refers
to are 0243's readings taken on another machine, cited as that record's rather
than re-taken here.

0103 is left one term short and carrying a rule for two of the three shapes an
expression takes, with nothing routing a reader from it to this record. That is
deliberate, for the reason stated above, and it makes the residual 0243 recorded
larger rather than repairing it. Issue 267 is where the shape of a partial
supersession is asked for and this change does not invent one.

The notice this record admits has to reach an operator eventually. Where the
assembled notices for a release live is not decided here.

No manifest entry is added. The package arrives with the transport and the
certificate work, and the clause line 0103 requires beside an entry is written
then.

Nothing was run that needs a network beyond the reads pasted above, and nothing
needing elevation was attempted.

Who has read it

Nobody but the author. The evidence above stands in place of a second reader:
every pasted block is a command with its output, re-run at the base commit rather
than in a working tree, and the four ranges that did not reproduce were corrected
before the commit was made.

…e set

0103's licence set is an enumeration written for a single term and for a dual
offer, and it has no rule for a conjunction. Every conjunction the board had met
until now had all its members inside the admitted half, so the gap cost nothing.
unicode-ident is offered as (MIT OR Apache-2.0) AND Unicode-3.0, and 0243 could
place neither the shape nor the term; it left that collision open by name and
left the Android half of the means it decides unlicensed.

0268 decides both halves. A conjunction is admitted only where every member is
admitted, and a member the set names in neither half leaves the expression
undecided rather than admitted, so the enumeration is total in three states
instead of two. Unicode-3.0 is named admitted, on the ground that its three
conditions - a notice, a warranty disclaimer, and a bar on promotional use of a
name - are each a term AGPL-3.0-or-later enumerates in its own section 7 as one
that may supplement it, which is 0103's own test for the refused half answered
out of this repository's LICENSE. Admitting the package because it reaches no
client binary is refused, because 0103 already applies the licence set without
relaxation to a test tree that ships to nobody, and a build-time node of the
shipping tree ships further than that.

What it prevents: a reader meeting that expression with no rule for a conjunction
has two quiet ways out - reading the dual offer and stopping, or reading the
conjunction as a choice - and both produce a manifest line citing a clause of
0103 that does not reach the expression. Nothing in this repository reads that
line, so the first reader to notice would be whoever assembles the notices for a
release, after eleven clients have shipped the graph.

No pointer is added to 0103. 0001 permits that edit only for a case the earlier
record already names, and a conjunction is not one; the residual that leaves is
stated in the record and belongs to #267.

Refs #268

Signed-off-by: Nils Lehnen <30603423+iderex@users.noreply.github.com>
@iderex iderex added this to the M1 Decisions of record milestone Sep 1, 2026
@iderex iderex added decision An architecture decision that must be written down with its reasons legal Licensing, data protection, and the intended-use position labels Sep 1, 2026
@iderex iderex self-assigned this Sep 1, 2026
@iderex
iderex merged commit f42f4e2 into main Sep 1, 2026
24 checks passed
@iderex
iderex deleted the decide-the-conjunctive-licence-expression branch September 1, 2026 09:35
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

decision An architecture decision that must be written down with its reasons legal Licensing, data protection, and the intended-use position

Projects

None yet

Development

Successfully merging this pull request may close these issues.

A conjunctive licence expression carries a term 0103's set names in neither half

1 participant