Skip to content

Add required phrases to lgpl-3.0_16.RULE - #5251

Open
Eljees wants to merge 2 commits into
aboutcode-org:developfrom
Eljees:agent/lgpl-3.0-16-required-phrases
Open

Add required phrases to lgpl-3.0_16.RULE#5251
Eljees wants to merge 2 commits into
aboutcode-org:developfrom
Eljees:agent/lgpl-3.0-16-required-phrases

Conversation

@Eljees

@Eljees Eljees commented Jul 28, 2026

Copy link
Copy Markdown

Fixes #4995

Problem

lgpl-3.0_16.RULE is an LGPL-3.0 notice, but none of its text is required, so a partial sequence match reports LGPL-3.0 for an LGPL-2.x notice of the same shape that never mentions version 3.

The reporter's file, KDE/libqzeitgeist/src/logbrowser.cpp, says:

...under the terms of the GNU Lesser General Public License as published by the Free Software Foundation; either version 2 of the License, or (at your option) any later version.

and is detected as LGPL-3.0-only.

This follows @pombredanne's suggestion in the issue that the rule should get required phrases.

Change

The two version-bearing phrases are marked as required:

it under the terms of the {{GNU Lesser General Public License version 3}} as
...
You should have received a copy of the {{GNU Lesser General Public License version 3}}

Nothing else in the rule changes.

Verification

Measured with scancode-toolkit 32.5.0, rebuilding the license index (scancode-reindex-licenses) between runs.

input before after
the reported logbrowser.cpp LGPL-3.0-only — lgpl-3.0_16.RULE, score 88.68 LGPL-2.0-or-later AND LGPL-2.1-or-later — lgpl-2.0-plus_1.RULE (100.0) + lgpl-2.1-plus_113.RULE
a genuine LGPL-3.0 notice of this rule's own shape LGPL-3.0-only, score 100.0 LGPL-3.0-only — lgpl-3.0_16.RULE, score 100.0

So the false positive resolves to the license the file actually carries, and the rule still matches real LGPL-3.0 notices at full score — the second row is there because required phrases can easily turn a false positive into a false negative, and I wanted that pinned down rather than assumed.

One methodology note that cost me an hour and may be worth knowing: editing a rule inside an installed scancode and rescanning changes nothing — the index is cached. I only caught this because a control run with the rule file deleted entirely still produced the identical match at the identical score. All numbers above are from runs with an explicit reindex.

I have not run the full tests/licensedcode suite; if there are expected-detection fixtures that reference this rule, they'd want a look.

@Eljees
Add required phrases to lgpl-3.0_16.RULE
226d6cd 
The rule is an LGPL-3.0 notice, but nothing in it was required, so a
partial sequence match reported LGPL-3.0 for LGPL-2.x notices of the same
shape that never mention version 3. Mark the two version-bearing phrases
as required.

Reported in aboutcode-org#4995.

Signed-off-by: Eljees <[email protected]>
@pombredanne

pombredanne commented Jul 28, 2026

Copy link
Copy Markdown
Member

Did you run tests and add new tests?

@pombredanne

pombredanne commented Jul 28, 2026

Copy link
Copy Markdown
Member

And we are evolving our policy for the use of LLMs. Was this entirely AI-generated? Please join our Slack for discussion.

@pombredanne

pombredanne commented Jul 28, 2026

Copy link
Copy Markdown
Member

Especially when I see this comment:

@Eljees

Eljees commented Jul 28, 2026

Copy link
Copy Markdown
Author

Yes — I use an LLM assistant for drafting, and I should have said so up front. Sorry for that, and sorry if my earlier comments read as if every word was mine.

What I'm doing here isn't PR farming. My day job is AppSec false-positive triage of SAST/SCA findings; I'm preparing a conference talk and collecting data on how well models actually do on that kind of work. That only works if the contributions hold up, so I run the tools myself before opening anything.

For this rule specifically:

  • current rules: the KDE header matches LGPL-3.0-only, score 88.68
  • with the required phrases added: LGPL-2.0-or-later AND LGPL-2.1-or-later
  • control: a genuine LGPL-3.0 notice still matches at 100.0

Both runs after scancode-reindex-licenses — without the reindex the license index stays cached and rule edits silently do nothing, which cost me an hour before I caught it by deleting a rule entirely and seeing the same match survive.

I did not add a test file. Tell me where you want it (tests/licensedcode/data/...) and I'll add it in this PR.

And for what it's worth — humans have been shipping bad code for decades without any help from models, mine included. :) The disclosure point is fair, though, and I'll state it in my PRs from now on. Happy to join the Slack discussion.

@Eljees
test: add regression test for lgpl-3.0_16 required phrases
bf999f7 
Add a lic4 datadriven fixture with the LGPL-2-or-later notice header
from KDE libqzeitgeist src/logbrowser.cpp (issue aboutcode-org#4995): it must detect
as lgpl-2.0-plus only and no longer match lgpl-3.0_16.RULE now that the
rule requires its GNU Lesser General Public License version 3 phrases.

Signed-off-by: Eljees <[email protected]>
@Eljees

Eljees commented Jul 28, 2026 via email

Copy link
Copy Markdown
Author

@Eljees

Eljees commented Jul 28, 2026 via email

Copy link
Copy Markdown
Author

@Eljees

Eljees commented Jul 28, 2026 via email

Copy link
Copy Markdown
Author

@Eljees

Eljees commented Jul 28, 2026

Copy link
Copy Markdown
Author

Concretely, on both questions.

New test. Added in bf999f7: tests/licensedcode/data/datadriven/lic4/4995-lgpl-2.0-plus-not-lgpl-3.0.cpp plus its .yml, picked up automatically by test_detection_datadriven4. The fixture is the license header verbatim from the reporter's file in #4995 (KDE/libqzeitgeist/src/logbrowser.cpp), and it pins the invariant this PR is about: a notice that never mentions version 3 must not resolve to lgpl-3.0. It currently detects two exact 100.0-score matches, lgpl-2.0-plus_1.RULE (lines 4-14) and lgpl-2.0-plus_451.RULE (lines 14-16). No existing fixture needed regeneration, and all the license-data-sensitive suites are green on this PR: datadriven1_2, datadriven3_4, datadriven_ext, every license_validate_*, license_cache, additional_license_combined, and all Windows jobs.

One correction to my own PR description while I am here: it claimed lgpl-2.0-plus AND lgpl-2.1-plus based on a manual check on 32.5.0. Against current develop the result is the two lgpl-2.0-plus matches above. I inspected the match trace rather than papering over the difference; the version-3 invariant holds either way.

The red CI is not this PR. The latest develop build, 18996, ran on 6ba5908 - the exact parent commit of this PR - on 2026-06-25, and fails with the same seven job kinds:

  • core_tests cluecode_license_base: only test_match_has_correct_line_positions_in_automake_perl_file, a +12 token-position shift (Span(998, 1061)/Span(1371, 1393) vs expected). Build 18996 fails it with bit-identical spans, so it dates to the June update-licenses merge (4e8d711, Add new licenses from dejacode #5112) adding rule tokens - the case that test's own docstring warns about. I deliberately did not update those expectations here; that is develop's breakage, not mine, and fixing it in this PR would misattribute the cause.
  • posix all jobs: test_scan_info_returns_full_root and test_scan_info_returns_correct_full_root_with_single_file, a missing leading / in the expected path. Posix-only, Windows green, failing on 18996 as well. A .RULE text edit cannot affect path rooting.
  • core_tests misc_and_scancode: test_interrupt.py and the no_multiprocess ignore test dying on ValueError: signal only works in main thread of the main interpreter - SIGALRM under pytest-xdist on Python 3.14.6 on the agents.

I reproduced the first two classes locally at this commit in a python:3.10-slim container built with the exact configure --dev steps, and got the same numbers as CI. Happy to file the automake spans and the posix full_root cases as separate issues if that is useful.

On the LLM question - fair to ask, and you were right to. Yes, I use an assistant for drafting, and I said so above rather than let you find out. My own unaided code and English are worse than what I produce with it, so I use it and then check the result myself; the tests I run and the evidence above are mine. I am happy to take this to Slack for the policy discussion. If your evolving policy ends up not wanting contributions produced this way, say so and I will close this PR without argument.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Reviewers

No reviews

Assignees

No one assigned

Labels

None yet

Projects

None yet

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.

LGPL 3 false positive (should be LGPL 2 or 2.1)

2 participants

@Eljees @pombredanne