webarkit / webarkit/jsfeatNext
chore(license): add a third header variant for OpenCV-derived sources
Nobody has claimed this yet.
- Dominant language
- TypeScript
- Stars
- 12
- Forks
- 4
- Avg merge
- 16h 24m
- Merged PRs (30d)
- 34
Description
Summary
scripts/check-license-headers.mjs currently knows two header variants:
derived (LGPL + the upstream jsfeat MIT attribution) and original (LGPL
only). Code ported from OpenCV fits neither. Add a third variant before the
first such file lands.
Why
The script treats ORIGINAL_SRC as a short allowlist and documents the rest as:
Everything else under
src/is a port of the corresponding jsfeat code.
That was true until now. It stops being true with the incoming features2d
work: TEBLID, GMS and FREAK are ported from OpenCV's xfeatures2d, not from
jsfeat. Under the current rules a new src/teblid/teblid.ts would automatically
receive the MIT attribution to Eugene Zatepyakin.
That is a false credit — precisely the failure the two-variant policy exists
to prevent, in the opposite direction. AGENTS.md already spells out the
principle:
adding the jsfeat attribution here would be a false credit, and licence
scanners would report MIT content in files that have none.
The same reasoning applies symmetrically: OpenCV-derived files must carry the
OpenCV notice and must not carry jsfeat's.
Proposed change
Add a third case producing the LGPL base without the jsfeat attribution,
plus the upstream OpenCV notice — the same shape as the hand-extended headers
already tracked in EXTENDED for src/orb/bit_pattern_31.ts (OpenCV/ORB) and
src/math/math.ts (*BSD qsort).
Mechanically this can be either a new template variant or an explicit path set
checked like EXTENDED; the implementer should pick whichever keeps the licence
wording composed from the single template in
.agents/skills/license-header-adder/resources/, so the text cannot drift.
Verify the upstream licence per file — do not assume
opencv_contrib/modules/xfeatures2d mixes 3-clause BSD and Apache-2.0 file
headers depending on the file and its contribution date. Both are one-way
compatible with LGPL-3.0-or-later, so relicensing is fine, but the notice text
differs and must match the file actually ported. Check the header of each
upstream source before writing the notice.
Acceptance criteria
- A new file under
src/teblid/(or any path designated OpenCV-derived)
passesnode scripts/check-license-headers.mjs. - The applied header contains no reference to jsfeat or Eugene
Zatepyakin, and does contain the upstream OpenCV notice. -
--fixapplies the correct variant automatically, chosen by path. - The existing hand-extended notices in
src/math/math.tsand
src/orb/bit_pattern_31.tsare untouched and still pass. - The policy is documented in
.agents/skills/license-header-adder/SKILL.md, including the "verify the
upstream licence per file" rule.
Out of scope
- Any algorithm implementation.
- Revisiting the licence of existing files.
tests/vendor/**andexamples/js/third-party scripts, which are never
stamped.
Related
- Header policy: #112
- First consumers: #135 (TEBLID), #134 (GMS) and #80 (FREAK)
- Plan:
docs/features2d-expansion-plan.md
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start with scripts/check-license-headers.mjs, the single template in .agents/skills/license-header-adder/resources/, and .agents/skills/license-header-adder/SKILL.md. Inspect the upstream headers for each OpenCV-derived source before defining path-based selection, then run node scripts/check-license-headers.mjs and --fix against the listed existing and new paths. Done means the OpenCV notice is applied without jsfeat attribution, documentation is updated, and existing extended notices still pass.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- node.js, typescript
- Domain
- documentation, tooling
- Issue type
- Feature
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Quiet
- Clarity
- Clearly specified
- Newbie friendliness
- 68/100