`merge_copyright_lines()` should honor `--copyright-style` parameter

[BigBlueHat]

Currently, the code guesses from the existing copyright claims: https://github.com/fsfe/reuse-tool/blob/00a8d949b245218541fd0ece8a64c5480a9e84d7/src/reuse/_util.py#L366-L371

If it "misses", it uses the spdx format even if --copyright-style is set to some other style.

My expectation was that providing --copyright-style would force any existing copyright claim into that style (vs. replacing it with one I didn't select).

This is especially important for licenses such as the Apache-2.0 which come with their own requirements for applying the license via a per-document preamble comment: https://www.apache.org/licenses/LICENSE-2.0#apply

[BigBlueHat]

This is actually strangely irregular. One run will default to the spdx style while another run (same command, same file) will result in the specified style...

[carmenbianca]

Oof. Can you provide an example file @BigBlueHat ?

[BigBlueHat]

Using --merge-copyrights --copyright-style=string

Before:

/*!
 * Copyright (c) 2020-2022 Digital Bazaar, Inc. All rights reserved.
 */

After:

 * Copyright 2024 Digital Bazaar, Inc.
 * SPDX-FileCopyrightText: 2020 - 2022 Digital Bazaar, Inc. All rights reserved.

I'm also using a template that starts with...

/*!
{% for copyright_line in copyright_lines %}
 * {{ copyright_line }}
{% endfor %}
 *

[BigBlueHat]

Rerunning it this time had no effect. So it seems it may be that SPDX-FileCopyrightText is being injected into the template even when it's not chosen as the format.

Also, I can't seem to replicate the irregular behavior. It's just consistently ignoring --copyright-style=string when using --merge-copyright.

[BigBlueHat]

Found it!

It's treating "All rights reserved." as part of the copyright owners name...so since I'm trying to remove that by setting --copyright="Digital Bazaar, Inc." it's adding a new copyright line in the requested format and changing the old one (unexpectedly) to use the SPDX format.

Neither behavior was expected, so still some bugs here--but they probably need new issues.

[BigBlueHat]

Closing in favor of #929