No longer make copyright lines stringly typed
Presently, copyright lines are stringly typed in the tool. The whole thing SPDX-FileCopyrightText: 2016, 2018--2020, 2023--present Carmen Bianca BAKKER <[email protected]> is one string.
I think it might make sense to write some kind of CopyrightLine class that can parse elements from such strings. For example, the above properties of the above example:
- copyright_prefix -
SPDX-FileCopyrightText - date_range - some DateRange object that can encode the concept of
2016,2018--2020, and2023--present. Or, if that all is too over-engineered, just the string2016, 2018--2020, 2023--present - name -
Carmen Bianca BAKKER - contact -
[email protected]
If implemented well, this could heavily simplify date-range merging, which is currently spaghetti code.
I like this.
Two changes I’d like to propose though:
- make contact (or at least the usage of
<and>) optional - include a
©(or(c)or(C)) sign at the beginning, in order to make sure that the copyright notice actually complies with how it is defined in pretty much all jurisdictions (I wrote about this some time ago)
@silverhook all fields (except name) will be optional :)
for the formats, see the annotate documentation on what will be supported at the very least:
spdx: SPDX-FileCopyrightText: <year> <statement>
spdx-c: SPDX-FileCopyrightText: (C) <year> <statement>
spdx-symbol: SPDX-FileCopyrightText: © <year> <statement>
string: Copyright <year> <statement>
string-c: Copyright (C) <year> <statement>
string-symbol: Copyright © <year> <statement>
symbol: © <year> <statement>
Personally I’d limit it down to:
spdx-symbol: SPDX-FileCopyrightText: © <year> <statement>
spdx-c: SPDX-FileCopyrightText: (c) <year> <statement>
spdx-C: SPDX-FileCopyrightText: (C) <year> <statement>
Maaaybeee include:
spdx: SPDX-FileCopyrightText: <year> <statement>
…but you know my thoughts on this ;)