Support multiple licenses on a repo

[ashleywolf]

GitHub UI to support multiple licenses on a repo. Please share your use cases or feedback here. Especially if there's any current pain points you experience.

[caniszczyk]

I would love to be able to specify a "Documentation license" and a "Code license" as sometimes these are different things, which is common in LF/CNCF projects where we default to Apache 2.0 for code and CC BY 4.0 for docs We sometimes have repos where there is a "LICENSE" file for code and "LICENSE-DOCS" for documentation, it would be nice if GitHub somehow supported this natively via UI/API

…

On Mon, Jul 26, 2021 at 4:08 PM Ashley Wolf ***@***.***> wrote: GitHub UI to support multiple licenses on a repo. Please share your use cases or feedback here. Especially if there's any current pain points you experience. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#72>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAAPSIKKHPC5VGQWTY4XG6DTZXFD5ANCNFSM5BA4NUZQ> .

-- Cheers, Chris Aniszczyk https://aniszczyk.org

[hyandell]

Apologies if some of if this off the mark for how it works today.

Today my assumption is that licensee is spotting a file in the default branch called LICENSE, COPYING, or very similar and attempting to id. It then states this as the project license across the project-repo site.

Pains I've seen:

• It's delayed in updating; so if the license changes it takes a little while for the site identifier's license to change.
• It's for the default branch. If you're on a branch, for example an older release, it still says the latest license which is REALLY confusing if you're trying to explain to a lawyer that this code is not under that license :)

+1 for Chris' point above. At AWS we often have two licenses on our documentation repos.

Feature requests:

• I'd love it to expose the SPDX codes as well as just as the human readable so folk are thinking more in those codes.
• It ought to be looking at metadata packages for spdx license information. It may be doing that today; I've not looked at licensee code in a good few years.
• I'd love to be able to simply set the spdx code for the project. Why make licensee figure it out when I could state it. A .github/SPDX file could contain SPDX-License-Identifier
• It should support each branch separately.

[tsteenbe]

+1 on Chris and Henri's comments above, I wish GitHub would support SPDX license expression and possibly support for a SPDX file in report or API for uploading SPDX files for Marketplace tools. This would allow maintainers to use a tool like ORT to generate software bill of material to exactly specify which licenses apply.
Based on the SPDX file GitHub could then create a "one-liner SPDX expression for code only" (as most devs care only about the code) and upon a click show an "in-depth licensing" UI with the licensing for build tools, docs, examples and dependencies.

OSS licensing is a complex topic, especially as build tools are made to build code and not for license compliance. From my experience maintaining license information is not on the top of mind of most developers and there are lot of misunderstandings. As an SPDX and ORT core contributor I working towards making the specification and tooling to generate as easy as possible but still be able to generate a high quality SPDX file.

For Henri's case of knowing the license for a past code revision why not provide an option to on-demand recompute licensing? Know it not the best UX but people who care about licensing are probably more than willing to wait a minute.

[juliaferraioli]

+1 to everything said here already, especially what @tsteenbe has said. In addition to being able to transparently surface multiple licenses and/or licenses that apply to different parts of the project, being able to surface licenses for transitive dependencies of a project is important for people looking to make technology decisions.

A license tree that reflects all the licenses needed to make a project work would be nice to see, even if the code for the dependencies is not located in the project's repository (which hopefully it is not).

[byjrack]

Agree with all the above around enhancing the dep graph view for licenses

• visualize possible risks, conflicts, or variance from the text that might expose material changes
• native SPDX export from a repo from that graph data
• helping to promote SPDX short codes and expressions to reduce ambiguity in the statements from the author
• Making the graph data available for Policy type controls detective/protective style

[gyehuda]

I'll point to github.com/tauri-apps/tauri as a good example of a project that looks like they are being as clear as they can about licenses, but the license detection on GitHub (as of today) is not really tuned to pick up on the subtlety.

[silverhook]

May I suggest taking a look and hopefully just implementing REUSE.software? (also CC @mxmehl)

A REUSE compliant repo has:

• all license texts in LICENSES/ folder, with SPDX IDs as their base names
• in all source files the license header must include the SPDX tags for licenses and copyright; or if that is not possible, globbing is also possible (see Define syntax and format of REUSE.yaml fsfe/reuse-docs#81 for WIP improvement of that)

That makes the repo both human and machine readable to easily parse which licenses apply to the repo (ls LICENSES/) as well as to which specific files in the repo (grep -r SPDX-License-Identifier *).

[mxmehl]

May I suggest taking a look and hopefully just implementing REUSE.software?

Full agreement. The LICENSES/ directory is an elegant way to store license texts. It's not only REUSE that stipulates that, it's also used by the Linux Kernel, the Core Infrastructure Initiative (coreinfrastructure/best-practices-badge#1547) or the KDE community – and 650+ projects registered to the REUSE API.

[byjrack]

So I don't think GitHub changes the git repo for any feature in the product, but could be wrong here. Even things like the .github code of conduct is just surfaced in Issue/PR UI and not as a reference in the repo content view.

So is the suggestion that GitHub nudge the community by making the multi license UI and repo metadata be restricted to those who have adopted REUSE schema? I would guess that GitHub have increased consistency in the LICENSE.md by the repo create flow and how licensee surfaces it in the UI/metadata which is a net benefit for the community I think.

For the scope of a work I think that could apply, but for the dependency tree including those terms as references in the repo probably wouldn't be the best option?

[pombredanne]

Using scancode-toolkit for license detection would nicely detect and report all the multiple licenses as SPDX license expressions. It is used at scale mostly everywhere including in ClearlyDefined (which GitHub reuses too?)

[anthonyronda]

I'd like to prevent uncertainty introduced by a new input field for an SPDX expression string, or by scanning package metadata. We've all encountered packages on npm or PyPI that declare a license string but don't include the license text, or the SPDX-ID and LICENSE don't match. If it were to ever accept an SPDX expression with a new field or metadata, it would hopefully fail to validate if all matching license texts aren't discoverable.

I think @silverhook and @pombredanne's suggestions of leveraging existing SBOM specs and scancode-toolkit are least susceptible to this uncertainty, and the various GitHub product teams won't have to negotiate over adding a new field.

[CsatariGergely]

I think the support for several type of licenses in a repo is very mutch needed. Lots of projects have a separate documentation license or have different licenses in different modules. REUSE is a good way collect the licenses and to assign the licenses to paths while SPDX id-s are a good method to identify the licenses.
I think providing SPDX documents with the licenses of the dependencies is a bit overkill, especially when the dependencies are not in the given repo. On the other side this feature would be needed in GitHub Packages.

[gkunz]

In general, yes, I'd very much like to see support for multiple licenses in the Github UI. I like the approach of REUSE to handle (multiple) licenses, so this is a good basis.

[ashleywolf]

Support for displaying multiple licenses has been released. See https://github.blog/changelog/2022-05-26-easily-discover-and-navigate-to-multiple-licenses-in-repositories/ for more info.

[silverhook]

It’s great to see GitHub is finally taking into consideration that many repos carry more than one license.

I find it very disappointing though that instead of leaning on an existing community best practices it continues pushing for amassing LICENSE.* files and relying on a very opinionated tool.