[Bug] skyWalking-eyes checks header should not require to match this year

[tisonkun]

Search before asking

• I had searched in the issues and found no similar issues.

Apache SkyWalking Component

License Tools (apache/skywalking-eyes)

What happened

Now we're in 2023 and it exposes a bug in the skywalking eyes header checks for license that have a year placeholder: https://github.com/korandoru/zeronos/actions/runs/3815180690/jobs/6490013554

After running the fix step locally, I notice that it's because the tool require the year placeholder to be resolved as "this year":

func (config *ConfigHeader) GetLicenseContent() (c string) {
	owner, name := config.License.CopyrightOwner, config.License.SoftwareName

	defer func() {
		c = strings.ReplaceAll(c, "[year]", strconv.Itoa(time.Now().Year()))
		c = strings.ReplaceAll(c, "[owner]", owner)
		c = strings.ReplaceAll(c, "[software-name]", name)
	}()

	if c = strings.TrimSpace(config.License.Content); c != "" {
		return config.License.Content // Do not change anything in user config
	}
	c, err := readLicenseFromSpdx(config)
	if err != nil {
		logger.Log.Warnln(err)
		return ""
	}

	return c
}

What you expected to happen

Check succeeds. Because we should be able to accept license headers to replace the [year] with inceptionYear that <= this year.

How to reproduce

See the CI report above. I think all projects using skywalking eyes with license that has a year placeholder will report more cases later.

Anything else

license-maven-plugin provides a series of year predefines:

• license.git.copyrightLastYear - the year of the last change of the present file as seen in git history
• license.git.copyrightYears - the combination of project.inceptionYear and license.git.copyrightLastYear delimited by a dash (-), or just project.inceptionYear if project.inceptionYear is equal to license.git.copyrightLastYear
• license.git.CreationAuthorName and license.git.CreationAuthorEmail - the name and email of the author of the first commit of the present file as seen in git history.
• license.git.copyrightCreationYear - the year of the first commit of the present file as seen in git history
• license.git.copyrightExistenceYears - Similar to license.git.copyrightYears but using license.git.copyrightCreationYear for the first year

This can be an alternative before license-eye fixes the issue. Or users can update the year to this year.

Are you willing to submit PR?

• Yes I am willing to submit a PR!

Code of Conduct

• I agree to follow this project's Code of Conduct

[wu-sheng]

What is your proposal to change? Adding a new variable to represent a year range?

[tisonkun]

@wu-sheng I don't have a clear solution yet. It can have multiple solutions.

The issue is whether it's by design that users should update "year" in the license header every year. If not, it's a bug.

According to the solution part, the first thing to decide is whether we analyze the license header in file, or we keep the way to generate content and do a string match. license-maven-plugin-git follows the latter one, which provides some variables to represent a year range or per-file creation year.

[wu-sheng]

Let's wait for @kezhenxu94 to explain the design. He is still recovering.

[kezhenxu94]

I personally think the users should update the year in license every year, checking the year according to something like git modification time doesn't make much sense to me.

But if for any reason the license is not applicable to the work since a year, say 2020, I agree we can have a configuration similar to copyright-owner, let's call it copyright-years for now and users should set copyright-years to the fixed year(range).

In short, my thought is: if the license is still applicable to the work, the year should be updated annually

[tisonkun]

In short, my thought is: if the license is still applicable to the work, the year should be updated annually

OK. Then we can close this issue as won't fix (by design).

[tisonkun]

While in another aspect that header fix will add a brand new header instead of modifying in place, which make the "update annually" quick complex to do (UPDATE: Global find-and-replace in editor can help). But it should be another issue.

[wu-sheng]

While in another aspect that header fix will add a brand new header instead of modifying in place, which make the "update annually" quick complex to do. But it should be another issue.

This seems like a new command parameter, like mvn setversion.

[kezhenxu94]

While in another aspect that header fix will add a brand new header instead of modifying in place, which make the "update annually" quick complex to do (UPDATE: Global find-and-replace in editor can help). But it should be another issue.

Yes agree. That deserves a fix to the header fix command.

[fuyufjh]

I personally think the users should update the year in license every year, checking the year according to something like git modification time doesn't make much sense to me.

But if for any reason the license is not applicable to the work since a year, say 2020, I agree we can have a configuration similar to copyright-owner, let's call it copyright-years for now and users should set copyright-years to the fixed year(range).

In short, my thought is: if the license is still applicable to the work, the year should be updated annually

I did some googling and it turns out the year in the license header should be the year of publication, legally.

See

• https://softwareengineering.stackexchange.com/a/130479
• https://web.archive.org/web/20111127204440/http://www.contentious.com/2007/01/07/copyright-notice-is-the-year-really-necessary/