addlicense does not modify files when the copyright year changes about addlicense HOT 6 CLOSED

addlicense does not modify files when the copyright year changes

That's by design. More generally, the program doesn't touch a file if it already contains a license. See the help text:

check whether the license text + copyright holder + year is actually present

At the moment it simply searches for "copyright" substring in

Suppose we add such check. What would be your expectation: that the program replaces present year(s) and holder(s) or adds them alongside existing entries? From "... not possible to switch to a new license" it seems like the former but from this issue title I'm guessing it's the latter?

Also, it's very common for a project to contain "vendored" or "third party" packages, typically containing different years, holders or even the license. When addlicense is run on a directory, it checks all source code regardless, which in this case would wipe everyone else's copyrights.

bump the copyright year

That sounds weird. I don't believe it's how licensing works. You might want to add a new year to a list instead of replacing it. What happens to the copiright of the previous year if you just "bump" it? Also, you typically never "bump" anything in the license headers in the source code files and use the a separate LICENSE file. See this very project for an example.

not possible to switch to a new license

As of this writing, the program bundles 3 licenses in https://github.com/google/addlicense/blob/c6b7f1e7f34a650f11d8767927d91e03bf32c5aa/tmpl.go - Apache 2, BSD and MIT. They all are just Go templates which the execution output of is simply insterted near the top of a file.

"Switching" to a new license, or in other words replacing license header with a new one would require some kind of license begin/end marks, I imagine, or some other sort of deterministic parser. Unless I misunderstood. The feature proposal isn't very clear tbh.

Feels like this would add a lot of complexity to the program. "Switching" to another license sounds like a big move. Most projects never change their license. Happens very rarely, once in a lifetime of a project maybe. Is the added complexity really worth it?

from addlicense.

In other words, a license header isn't structured. It contains arbitrary user input strings.
How would you implement a "license replacement" feature?

from addlicense.

check whether the license text + copyright holder + year is actually present

At the moment it simply searches for "copyright" substring in

addlicense/main.go

Line 220 in c6b7f1e

return bytes.Contains(bytes.ToLower(b[:n]), []byte("copyright"))

and assumes a license header is present if found.

Suppose we add such check. What would be your expectation: that the program replaces present year(s) and holder(s) or adds them alongside existing entries? From "... not possible to switch to a new license" it seems like the former but from this issue title I'm guessing it's the latter?

Well, initially I just wanted to bump the copyright year in all source files, so my expectation would be that if I provide a new year and/or copyright holder, that the old one will be replaced.

Also, it's very common for a project to contain "vendored" or "third party" packages, typically containing different years, holders or even the license. When addlicense is run on a directory, it checks all source code regardless, which in this case would wipe everyone else's copyrights.

There's an (imho) relatively nice workaround for that:

$ addlicense $(fd -E vendor/**/* . '.*\.c')

bump the copyright year

That sounds weird. I don't believe it's how licensing works. You might want to add a new year to a list instead of replacing it. What happens to the copiright of the previous year if you just "bump" it? Also, you typically never "bump" anything in the license headers in the source code files and use the a separate LICENSE file. See this very project for an example.

not possible to switch to a new license

As of this writing, the program bundles 3 licenses in https://github.com/google/addlicense/blob/c6b7f1e7f34a650f11d8767927d91e03bf32c5aa/tmpl.go - Apache 2, BSD and MIT. They all are just Go templates which the execution output of is simply insterted near the top of a file.

"Switching" to a new license, or in other words replacing license header with a new one would require some kind of license begin/end marks, I imagine, or some other sort of deterministic parser. Unless I misunderstood. The feature proposal isn't very clear tbh.

Feels like this would add a lot of complexity to the program. "Switching" to another license sounds like a big move. Most projects never change their license. Happens very rarely, once in a lifetime of a project maybe. Is the added complexity really worth it?

I agree, implementing switching to a new license is probably not worth it. However replacing the copyright year and/or the copyright holder could be in principle doable? Because then addlicense could be used to enforce that the copyright headers in all relevant source files are up to date.

from addlicense.

enforce that the copyright headers in all relevant source files are up to date

There's nothing to keep "up to date" really. You put the header once and that's it. Unless I misunderstand what this is about.

from addlicense.

Anyway, to implement a header replacement I guess a simple way would be to take all lines from 0 or 1 if it contains hashBang until first empty or non-comment line.

Not sure how well it would work. Other ideas?

from addlicense.

I don't think it makes sense to alter existing licenses. Something that's copyrighted 2019 is always copyrighted that year (although you might want to add additional years). Even if it made sense to change an existing license, it would open up a can of worms as x1ddos noted above (restricting scope to avoid inadvertently changing unintended files, non-deterministic parsing semantics of existing licenses, etc.).

Btw, the suggested work around:

$ addlicense $(fd -E vendor/**/* . '.*.c')

Solves one problem (go vendored src) but there are many other ways to inherit source files with embedded licenses. Also, I'd worry about someone who doesn't realize they need to filter out inherited artifacts and doesn't know to use a construct like that.

Given the above, I'm going to close this issue.

from addlicense.