Apply file.copyright from early 2026 check

[AndreiDurlea]

#177

[AndreiDurlea]

@neatudarius is this ok to merge?

[coveralls]

Pull Request Test Coverage Report for Build 21914486666

Details

• 0 of 0 changed or added relevant lines in 0 files are covered.
• 2 unchanged lines in 1 file lost coverage.
• Overall coverage decreased (-0.1%) to 99.038%

---

Files with Coverage Reduction	New Missed Lines	%
include/beman/optional/optional.hpp	2	98.99%

Totals
Change from base Build 21907778507:	-0.1%
Covered Lines:	309
Relevant Lines:	312

---

💛 - Coveralls

[neatudarius]

Thanks for contribution Andrei! It seems we havr an unexpected case here, I didn't anticipate these files need to be updated.

We need to remove these lines to be Beman Standard compliant with include/. I'm not sure if we can legally do this with the this header which was copied from @tzlaine . @steve-downey ?

v1: directly remove the copyright line
v2: move stl interfaces into a special whitelisted directory (e.g., external/, deps/)

[steve-downey]

It's actually somewhat worse, it looks like the SPDX block at the top of the iterator headers is wrong.
This is essentially vendored in from @tzlaine 's iterator support proposal that he put on hold to reexamine after reflection.
I don't think it's a terrible problem with respect to the license. We should be clearer about the provenance and license.
Also I'll check on the symbol names and namespace. I wouldn't want this to collide with a different usage if the facility by accident.

[steve-downey]

It's actually somewhat worse, it looks like the SPDX block at the top of the iterator headers is wrong.
This is essentially vendored in from @tzlaine 's iterator support proposal that he put on hold to reexamine after reflection.
I don't think it's a terrible problem with respect to the license. We should be clearer about the provenance and license.
Also I'll check on the symbol names and namespace. I wouldn't want this to collide with a different usage if the facility by accident.

[neatudarius]

It's actually somewhat worse, it looks like the SPDX block at the top of the iterator headers is wrong. This is essentially vendored in from @tzlaine 's iterator support proposal that he put on hold to reexamine after reflection. I don't think it's a terrible problem with respect to the license. We should be clearer about the provenance and license. Also I'll check on the symbol names and namespace. I wouldn't want this to collide with a different usage if the facility by accident.

Agree, we should remove SPDX lines from these 3 files.

I propose the following approach:

1. Remove SPDX from these 3 files NOW. That can be a seperate PR attach to same issue - we can merge that ASAP.
2. Add a way to ignore these files and NOT BE REPORTED by the tool.

===================================
I see 2 ways to ignore files: 1) having a special ignore folder or 2) having a beman-tidy config in your repo, with an ignore section.
v1) It's simpler to implement in the tools, but more inconvenient for the library developer (is it?).
v2) Generic approach, similar to all linters.

I propose to do #2, e.g., .beman-tidy.yml

ignored_paths:
    - include/beman/optional/detail/stl_interfaces/config.hpp
    - include/beman/optional/detail/stl_interfaces/fwd.hpp 
    - include/beman/optional/detail/stl_interfaces/iterator_interface.hpp
# or add support for regex
    - include/beman/optional/detail/stl_interfaces/  

@steve-downey @AndreiDurlea , what do you think?

[AndreiDurlea]

I think approach 2 sounds right, I'll get to implementing it if everyone's on board with the idea.

[AndreiDurlea]

1. Remove SPDX from these 3 files NOW. That can be a seperate PR attach to same issue - we can merge that ASAP.

@neatudarius to clarify, I'm removing SPDX but reverting the commit that removed the Copyright notice. Is that ok?

[neatudarius]

LGTM for spdx changes

[steve-downey]

I think approach 2 sounds right, I'll get to implementing it if everyone's on board with the idea.

The ignore list sounds good to me.