Feature request: updating license text on files that already has a license header

[tomasaschan]

In case license headers have already been generated, but with incorrect content, or in cases where e.g. copyright owner should change (say, in the event of a handover of a project from one owner to another), it would be very useful to be able to rewrite the headers instead of just adding them where they are missing.

I propose a flag -force to enable this - so the default behavior stays the same, but if one passes -force one also gets changes in any file (matching selectors in other parameters, of course) where the current license headers do not match whatever parameters were passed.

If this sounds like something you'd accept, I can whip up a PR, but given that e.g. #60 (which was justified differently, but worked similarly) was closed without merging, I'd like some indication that it'll be accepted before I start working on the feature.

[flwyd]

Do you have an example where this feature is needed, e.g. guidance from a lawyer that you should change existing copyright notices? The reasoning in this comment on #60 still seems sound to me; do you have a different opinion?

The first use case of intellectual property changing hands sounds like the sort of thing that's likely to happen just once per project, and might be better handled by a tool like sed. If ownership is changing from A Corp to B Corp, but there's also some files that are owned by C Corp, it sounds like your proposed force option would rewrite all the C Corp copyrights to B Corp, but that's probably not the appropriate thing to do. A sed script can do a more specific job of matching the text which needs to change.

[tomasaschan]

The reason I propose this is not to be able to change the copyright year, but rather to enable ensuring consistent and correct headers in projects where files have had the headers added in a somewhat arbitrary way.

The concrete use case in question was for kro, where we ended up using nwa instead precisely because we were missing this feature. There's more discussion about this in a few other places, but the gist of it is that license headers were inconsistent (and sometimes incorrect) for a few different reasons:

• sometimes it was just whitespace differences, which is annoying but not strictly important
• sometimes it listed the wrong copyright holder, because some code had been lifted over from other projects with ownership signed over to this project
• sometimes it was incomplete but in ways that still matched the "has existing header" detection, which made it impossible to use this tool to ensure correct wording etc

This feature would allow for correcting all those cases.

[flwyd]

Thanks for the concrete example. I think the copyright assignment scenario is an important use case, but I wonder if sed might be a better tool choice, particularly since copyright assignment is generally a one-time action. Something like find some/path -name '*.go' -exec sed -i -e '1s/Copyright Acme Inc/Copyright The Code Foundation/' '{}'. This would update the specific files which are being assigned without changing files which are copyright by a different entity which hasn't assigned copyright.

I appreciate the desire to fix the license header text to match exactly, as done in that kro PR. But it seems to me that the "not exactly right" license text was still valid; it conveyed the same information in slightly different words. That particular PR looks like sed would've worked as well; the change was from a single old template to a new template.

My underlying concern here is that changing an existing license header in a file isn't obviously the right thing to do (unlike adding a license header to a file which doesn't have one), so it would be risky for addlicense to do so automatically: a human should be in the loop.

[tomasaschan]

This feature would be behind a flag to explicitly enable it. Furthermore, it's basically only relevant in the case when the files are under version control, which so a preview/review step will almost certainly follow (e.g. git add -p and/or a pull request review). What more is required to qualify as having "a human in the loop"? :)

[flwyd]

By "human in the loop" I mean a human deciding exactly what changes need to be made to the license statement in a file. Running addlicense --update-existing . on a large repository could generate a change with thousands of files. I'm skeptical that someone would review such a PR carefully enough to notice that three of those files have a different copyright holder, and that holder shouldn't change. I also worry that someone would add the flag to a pre-commit hook and quietly change the copyright and license of a file being copied from elsewhere.

The advantage of the sed solution is that a human has explicitly chosen to change X to Y, rather than changing everything indiscriminately to Y. Is there a reason sed doesn't work for your use case?

[tomasaschan]

In general, while I understand your concern, I don't see how the risk of changing owners is the tool's responsibility you manage; it's still the responsibility of the user (of course) to not set or add copyright headers which "lie".

What if there were two options, --update-existing and --reassign-ownership where files with a different current owner would only be touched if the latter is specified?

Is there a reason sed doesn't work for your use case?

Yes, since a large part of the rewrites are cosmetic, to harmonize and ensure the header looks the same everywhere, the "from" has enough variance for sed to be impractical. I would think this is common in projects adopting a tool like this that have not used one before.

[flwyd]

Can you link to code where sed is impractical? The PR link earlier in this issue looks to me like sed would be straightforward: the changes are cosmetic, but there are only a few cosmetic variations to change.

addlicense doesn't currently have logic to detect which license a file has, and currently has a pretty simple check for a "copyright" phrase or a SPDX identifier. Detecting all and only the text of a license which is almost—but not quite—a known open source license doesn't sound like a trivial feature. If this code gets it wrong, it risks deleting additional important comments which should be preserved. Since I believe the legal value of cosmetic fixes to a license comment is low, I'm inclined to be risk-averse with such a change.

Reassigning copyright ownership without changing license text seems more tractable, and probably more useful e.g. when an open source project transitions to being supported by a foundation or if a company transfers its intellectual property rights in an acquisition. As a safety measure, I think it would be wise to specify which entity one is reassigning from so that code with other ownership isn't affected. This could be a multi-flag, e.g. addlicense -c "The Foo Foundation" --reassign-copyright-from "Foo Project Contributors" --reassign-copyright-from "Alfred E. Neuman" . What do you think about that?

This also raises the question of whether reassigning copyright ownership should also update the copyright year. I would love to hear input on this.

[blozano-tt]

I would also like this feature.

I wanted to use this tool as part of a pre-commit check to verify that developers have added the correct license header.

They often misspell the company name , put the wrong year because of copy paste, use Inc instead of ULC.

I need a copyright header validator essentially.

Seems like all related tools just check for existence.

[tomasaschan]

@flwyd

Can you link to code where sed is impractical?

I think sed would be impractical on the PR I linked. Yes, sure, the set of variations to change is bounded, but consider that making the corresponding change with sed would require not only writing all the commands to make the changes, but also finding all variations - and knowing that all variations have been found.

Using a tool like this one to blanket rewrite the license headers of all files, and then discard any undesired changes, is a much easier way to accomplish the same thing, IMO, which is why I would value the feature.

And just to repeat an earlier argument, phrased a little bit differently: I don't think it's possible to build a tool that uses tech to ensure legal requirements are met. There is, after all, no tech that prevents me from using sed to change the license of some code file in ways the license does not legally allow. Therefore, I disagree that it should be the responsibility of this tool to try to enforce anything like that when a user explicitly asks for changing the license text.

However, making it easy to make license texts homogeneous, also makes it easier to detect precisely what license is currently set, and to implement checks that eg ensure license texts are present and valid (eg stay homogeneous, or matches known formats, or no changes, etc.), which in the long run probably protects against, at least, accidental changes.

[maximkosov]

I would also like this and update year option. Currently addlicense will allow anything that has "copyright" year somewhere close to the beginning of the file, not even necessary in the header.