Repository navigation
Apache 2.0 usage without preservation of copyright and license notices #9422
Description
Activity
@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/clirepo otherclirepos have the same issue.I am looking to write my first extension and using
gh extension create --precompiled=go EXTENSION-NAMEfrom the GitHub docs on creating a CLI extension generatesgo.modwith packages such asgolang.org/x/termthat have theBSD-3-Clauselicense, 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-licenseslooks like a great tool. I haven't worked a lot in Go but I have seen similar tools used in other ecosystemsIf 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-licenseswhere 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
- is the approach used by
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
Reacted by Andy FellerI 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-licensesto 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
ghcurrently 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 licensesthat attempts to download the information from the release artifact.I feel this is the best approach as
ghcould 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
ghlicense compliance work via release artifacts?-
During the
releasejob in our deployment workflow:- Install
go-licenses - Compile dependency licenses and related source code via
go-licenses save - Bundle this information into a tarball / zip and attach to the release as an artifact
- Install
-
Have a new command — something like
gh licensesorgh credits— that will take version information aboutghand 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 licenseextension 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
ghis not redistributing the source code, so wouldn't it therefore be under much less strict requirements? As a side-note, if you added avendor/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).Reacted by Andy Fellerreadily 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:-
-
.github/workflows/licenses.ymlname: 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 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 }}
Reacted by Spenser BlackReacted by Kynan Ware-
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.