Open carmenbianca opened 6 months ago
I like this.
Two changes I’d like to propose though:
<
and >
) optional©
(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 ;)
Presently, copyright lines are stringly typed in the tool. The whole thing
SPDX-FileCopyrightText: 2016, 2018--2020, 2023--present Carmen Bianca BAKKER <carmenbianca@fsfe.org>
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:SPDX-FileCopyrightText
2016
,2018--2020
, and2023--present
. Or, if that all is too over-engineered, just the string2016, 2018--2020, 2023--present
Carmen Bianca BAKKER
carmenbianca@fsfe.org
If implemented well, this could heavily simplify date-range merging, which is currently spaghetti code.