Review inconsistent go file license headers

[jpmcb]

Problem

Today, we have wildy inconsistent license headers in our go source files.

• I notice that many of the go files do not have a license header.
• Others have one that declares a copy-write under @spf13 and the Apache 2.0 license
• Some contributors may be confused and attempt to add different headers (example: Added asciidoc generation and associated tests. #1698)

Expectation

From my understanding of the Apache 2.0 license, source files should have the license header, otherwise, it seems that only some of the source code is under the Apache 2.0 license and the others are ... unlicensed?

We should be consistent.

Further, we should set up a CICD job to fail if someone commits something without the license header.

---

@spf13 - can you advice here? Should the expectation be that we have:

// Copyright © 2022 Steve Francia <spf@spf13.com>.
//
// Licensed under the Apache License, Version 2.0 (the "License");
// you may not use this file except in compliance with the License.
// You may obtain a copy of the License at
// http://www.apache.org/licenses/LICENSE-2.0
//
// Unless required by applicable law or agreed to in writing, software
// distributed under the License is distributed on an "AS IS" BASIS,
// WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
// See the License for the specific language governing permissions and
// limitations under the License.

in all go source files?

[spf13]

This isn't quite right. I can't hold a copyright on other peoples contributions without a copyright assignment agreement (which we don't have in place and I don't want to do this anyway).

I added that header when all the contributions were mine (a very long time ago).

The better approach is to make all of the headers consistent as follows.

// Copyright © 2022 The Cobra Authors. All rights reserved.
//
// Licensed under the Apache License, Version 2.0 (the "License");
// you may not use this file except in compliance with the License.
// You may obtain a copy of the License at
// http://www.apache.org/licenses/LICENSE-2.0
//
// Unless required by applicable law or agreed to in writing, software
// distributed under the License is distributed on an "AS IS" BASIS,
// WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
// See the License for the specific language governing permissions and
// limitations under the License.

The Cobra Authors can be obtained by running git shortlog -nse but this isn't perfect because some copyright holders are corporations not individuals. It's probably good enough to seed an Authors file.

Speaking of Authors files, we should probably add one. See https://github.com/golang/go/blob/master/AUTHORS for an example of this.

This is the only approach I've seen work. Otherwise files become very messy with everyone trying to add their own copyright to each file.

[marckhouzam]

Steve's approach sounds right to me.
I found the CNCF's copyright notice policy: https://github.com/cncf/foundation/blob/main/copyright-notices.md which confirms the "Cobra authors" approach. This is what the Helm project does for example.

By the way, the CNCF doesn't seem to ask for an "authors" file and Helm doesn't use one. So we may prefer to avoid having one just to avoid having to keep it up to date. But if @spf13 prefers to have one, that's fine with me.

[github-actions]

The Cobra project currently lacks enough contributors to adequately respond to all issues. This bot triages issues and PRs according to the following rules:

• After 60d of inactivity, lifecycle/stale is applied. - After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied and the issue is closed.
  You can:
• Make a comment to remove the stale label and show your support. The 60 days reset. - If an issue has lifecycle/rotten and is closed, comment and ask maintainers if they'd be interseted in reopening

[umarcor]

FTR: golang/go@774fa58

In 2009, Google's open-source lawyers asked us to create the AUTHORS
file to define "The Go Authors", and the CONTRIBUTORS file was in
keeping with open source best practices of the time.

Re-reviewing our repos now in 2022, the open-source lawyers are
comfortable with source control history taking the place of the
AUTHORS file, and most open source projects no longer maintain
CONTRIBUTORS files.

To ease maintenance, remove AUTHORS and CONTRIBUTORS from all repos.