Since this project is licensed under GPL3 (which refers to the developer's copyright), we should have a header in each file similar to the one at the top of each of the Go Standard Library's files (see https://github.com/golang/go/blob/54182ff54a687272dd7632c3a963e036ce03cb7c/src/fmt/print.go#L1-L3 for an example).

This header should contain a copyright statement as well as a reference to the project's top-level LICENSE file. Sub-tasks are:

• Add a workflow "check" to verify headers are present in all files.
• Add the header to all files.
• Add a COPYRIGHT file to the project root.

Licensing does confuse me, but could you explain why that is necessary? What's wrong with the license file at the root? Also why a copyright file is necessary?

On a different direction, maybe a contributor license agreement would be useful, to make sure the contributed code conform to our license, and that we can re-license it if necessary (to a pre-defined subset of license). But that's a whole other can of worms...

IANAL - my understanding comes from working with the lawyers in the university's IP office.

The GPL states that we've protected this software in certain ways (https://github.com/MichaelMure/git-bug/blob/896d7cb1b03d449f399bd835693188c3910866a5/LICENSE#L29), one of which is copyright (https://github.com/MichaelMure/git-bug/blob/896d7cb1b03d449f399bd835693188c3910866a5/LICENSE#L40 and https://github.com/MichaelMure/git-bug/blob/896d7cb1b03d449f399bd835693188c3910866a5/LICENSE#L105). This is a defensive strategy that keeps someone else from asserting copyright and denying its use a priori.

The GPL3 recommends putting a header in each source file with the copyright, as-is notice and license assertion - https://github.com/MichaelMure/git-bug/blob/896d7cb1b03d449f399bd835693188c3910866a5/LICENSE#L630.

Regarding the CLA, GPL3 covers that too: https://github.com/MichaelMure/git-bug/blob/896d7cb1b03d449f399bd835693188c3910866a5/LICENSE#L665. It is a good idea!

This bot triages untriaged issues and PRs according to the following rules:

• After 90 days of inactivity, the lifecycle/stale label is applied
• After 30 days of inactivity since lifecycle/stale was applied, the issue is closed

To remove the stale status, you can:

• Remove the lifecycle/stale label
• Comment on this issue

github-actions (github-actions) added label lifecycle/stale 2 years ago

This bot triages issues in order to help the maintainers identify what needs attention, according to the following lifecycle rules:

• After 90 days of inactivity, lifecycle/stale is applied
• After 90 days of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied

This bot will not automatically close stale issues.

To remove the stale status, you can:

• Remove the stale label from this issue
• Comment on this issue
• Close this issue
• Offer to help out with triaging

To avoid automatic lifecycle management of this issue, add lifecycle/frozen.

github-actions (github-actions) added label lifecycle/rotten 1 year ago

github-actions (github-actions) removed label lifecycle/stale 1 year ago

sudoforge removed label lifecycle/dormant 10 months ago