Apache 2.0 usage without preservation of copyright and license notices

Describe the feature or problem you’d like to solve

The GitHub CLI makes use of packages with the Apache 2.0 license, such as cobra, but does not credit them or make the Apache 2.0 license available

Proposed solution

Proper preservation of copyright and license notices from dependencies whose licenses require it will properly inform users of the GitHub CLI, especially those creating extensions, of licensing requirements.

Additional context

Cobra is just one example, the GitHub CLI depends on many packages. While I did not audit the licenses for all of them, it should be done and any other licenses that require attribution included in a solution.

@ataylorme

@ataylorme : I couldn't agree with you more. 🙌 I'd like to explore your thoughts a little deeper in order to raise this discussion internally and shape this work:

How do you see GitHub CLI extensions' licenses incorporated into the extension lifecycle and use?

licenses require it will properly inform users of the GitHub CLI, especially those creating extensions, of licensing requirements.
What approaches have you seen in other CLIs you'd imagine incorporated into GitHub CLI?

Some projects like GCP application integration mgmt toolkit use tools like https://github.com/google/go-licenses to generate this information that is hosted within the repository, updated whenever dependencies change.

Going further, I can also see these are embedded within the release artifact that can be printed with a command.

Hi Andy, thanks for following up.

1

Disclaimer: I am not a lawyer. Since GitHub extensions themselves requite the GitHub CLI I am not sure of implications there. While I opened this issue on the cli/cli repo other cli repos have the same issue.

I am looking to write my first extension and using gh extension create --precompiled=go EXTENSION-NAME from the GitHub docs on creating a CLI extension generates go.mod with packages such as golang.org/x/term that have the BSD-3-Clause license, which also require attribution/copyright notice.

If someone wrote an extension in Bash for example with no dependencies perhaps it wouldn't be an issue.

If I publish an GitHub CLI extension, I would expect the GitHub CLI README or GitHub.com documentation to outline license responsibilities/requirements.

2

go-licenses looks like a great tool. I haven't worked a lot in Go but I have seen similar tools used in other ecosystems

If I publish an GitHub CLI extension, I would expect the GitHub CLI README or GitHub.com documentation to outline license responsibilities/requirements.

There is a lot more in this sentence than the words used can capture! 😆

Would you say the GitHub CLI documentation might highlight extension authors responsibility to understand and fulfill license requirements, providing examples of how this could be done with extension repositories?

The challenge I've run into while trying to satisfy license requirements like this is deciding exactly how attribution must be made:

is the approach used by go-licenses where these licenses and information are captured within a GitHub repository for an OSS project sufficient?
for example: GoogleCloudPlatform/application-integration-management-toolkit
must CLIs package and distribute these licenses and necessary source code in the actual CLI artifact?
how should the GitHub CLI extension management logic deal with changes in licenses between installing and upgrading a given extension?

As you can see, this is a bit of a rabbit hole depending on the scope of this issue:

Ensure the GitHub CLI is satisfying license compliance requirements
Provide guidance for GitHub CLI extension authors regarding satisfying license compliance requirements
Enhance the GitHub CLI extension manager to highlight license involvement when installing or upgrading extensions

Would you say the GitHub CLI documentation might highlight extension authors responsibility to understand and fulfill license requirements, providing examples of how this could be done with extension repositories?

Maybe in an ideal state but just including the licenses and making a note the CLI and other packages have dependencies that use them would be a nice start with further, incremental improvements later

I wanted to add an example of a project that shows dependency license information in a nice way: https://github.com/neutralinojs/neutralinojs?tab=readme-ov-file#licenses-and-copyrights

@ataylorme

I wanted to add an example of a project that shows dependency license information in a nice way: https://github.com/neutralinojs/neutralinojs?tab=readme-ov-file#licenses-and-copyrights

Really appreciate that, @ataylorme! Also, we Andrews have to look after each other. ❤

I'm going to take a look at this, but let me share thoughts on various approaches:

Capture current licensing and attributed source code within the repository

One common example even with the various Google repositories was using go-licenses to generate all of this information, which was then committed and pushed to the remote GitHub repository.

Honestly, this approach was never personally satisfying as it doesn't handle historical licensing. As we've seen over the past year, there have been substantial changes in the OSS licensing landscape, so this would be a solution but a poor one.

This appears to be the approach taken by https://github.com/neutralinojs/neutralinojs?tab=readme-ov-file#licenses-and-copyrights 🤔
Embed licensing and source code within the release binary

I have not seen any common CLIs go this route, meaning it would allow us to readily provide this information to users at the drop of the hat through something like gh licenses.

The problem is that licensing and source code downloaded for gh currently comes out to 8+ MB, which will affect ALL of the various distributions per release.
Attaching licensing and source code within the release artifacts

An alternative to Reimagine how the app determines its context #2 of embedding this information within the binary would be our release process zipping this information up and uploading it to the release as an artifact. Then we could have a command like gh licenses that attempts to download the information from the release artifact.

Example: https://github.com/open-feature/go-sdk-contrib/blob/abb76571c373582f36837587400104eb754c01b9/.github/workflows/release-please.yaml#L44-L68

I feel this is the best approach as gh could transparently guide users who are looking for the information while not complicating the release artifacts themselves. It would also avoid time and effort to try programmatically parsing the various ways a given Go module repo would reflect their licensing information.

How might `gh` license compliance work via release artifacts?

During the release job in our deployment workflow:
1. Install go-licenses
2. Compile dependency licenses and related source code via go-licenses save
3. Bundle this information into a tarball / zip and attach to the release as an artifact
Have a new command — something like gh licenses or gh credits — that will take version information about gh and look up the release remotely, finding the attached release artifact for licenses and other information
- If its found, the command can guide the user to the release artifact including a url and leave it to the user to download and consume the information as needed. There could probably be some flag that the user specifies that downloads the artifact rather than making the user figure it out.
- Otherwise, the command would call out the information is missing, encouraging the user to upgrade to a newer version.

readily provide this information to users at the drop of the hat through something like gh licenses.

Oh man, that and the gh license extension would really confuse me TBH 😆

I'm not a lawyer, but it looks like neutralinojs is providing that notice because they're redistributing those projects in their repo. AFAICT gh is not redistributing the source code, so wouldn't it therefore be under much less strict requirements? As a side-note, if you added a vendor/ folder to this project, you'd have to source code, and therefore the license, of every dependency (unless the author forgot to commit their license file).

readily provide this information to users at the drop of the hat through something like gh licenses.

Oh man, that and the gh license extension would really confuse me TBH 😆

Fair! I believe Enterprise Server uses the term "credits" for similar license compliance, so happy to stick with that.

That said, I'm also not a lawyer, however I don't think the idea of generating this bundle as part of the release process and adding it to the release artifacts is that onerous.

Experimenting on my fork of cli/cli, you can see what the workflow automation piece looks like and results:

README.md

.github/workflows/licenses.yml

name: Licensing
on:
  push:
    tags:
      - "v*"
env:
  LICENSE_DIR: licenses
  LICENSE_ARCHIVE: licenses.tgz
jobs:
  go-licenses:
    runs-on: ubuntu-latest
    steps:
      - name: Checkout
        uses: actions/checkout@v4

      - name: Set up Go
        uses: actions/setup-go@v5
        with:
          go-version-file: 'go.mod'

      - name: Generate Go license notices
        run: |
          go install github.com/google/go-licenses@latest
          GOROOT=$(go env GOROOT) go-licenses save ./... --stderrthreshold=ERROR --logtostderr=false --save_path "$LICENSE_DIR"
          GOROOT=$(go env GOROOT) go-licenses report ./... --template=.github/licenses.tmpl --stderrthreshold=ERROR --logtostderr=false > "$LICENSE_DIR"/README.md

      - name: Upload Go license notices
        env:
          GH_TOKEN: ${{ secrets.GITHUB_TOKEN }}
        run: |
          tar czf "$LICENSE_ARCHIVE" "$LICENSE_DIR"
          gh release upload "$GITHUB_REF_NAME" --clobber -- "$LICENSE_ARCHIVE"

          if gh release view "$GITHUB_REF_NAME" >/dev/null; then
            echo "uploading assets to an existing release..."
            gh release upload "$GITHUB_REF_NAME" --clobber -- "$LICENSE_ARCHIVE"
          else
            echo "cannot upload as something else should create the release first..."
            exit 1
          fi

.github/licenses.tmpl

# GitHub CLI dependencies

The following open source dependencies are used to build the [GitHub CLI _(`gh`)_](https://github.com/cli/cli).

## Go Packages

Some packages may only be included on certain architectures or operating systems.

| **Module** | **Version** | **License** | **License File** | **Package Docs**
| ---------- | ----------- | ----------- | ---------------- | ----------------
{{- range . }}
| {{ .Name }} | {{ .Version }} | {{ .LicenseName }} | {{ .LicenseURL }} | [pkg.go.dev](https://pkg.go.dev/{{ .Name }}@{{ .Version }}) 
{{- end }}

Navigation Menu

Repository navigation

Apache 2.0 usage without preservation of copyright and license notices #9422

Describe the feature or problem you’d like to solve

Proposed solution

Additional context

1

2

How might `gh` license compliance work via release artifacts?

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Apache 2.0 usage without preservation of copyright and license notices #9422

Description

Describe the feature or problem you’d like to solve

Proposed solution

Additional context

Activity

andyfeller commented on Aug 7, 2024

ataylorme commented on Aug 7, 2024

1

2

andyfeller commented on Aug 8, 2024

ataylorme commented on Aug 8, 2024

ataylorme commented on Aug 16, 2024

andyfeller commented on Aug 18, 2024

How might gh license compliance work via release artifacts?

spenserblack commented on Aug 19, 2024

andyfeller commented on Aug 21, 2024

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions

How might `gh` license compliance work via release artifacts?