Brew: Show a formula's licensing information with `brew info`

[zachwick]

A detailed description of the proposed feature

I have implemented a proof-of-concept of a license_info parameter in the Formula spec that functions similar to conflicts_with which can be found at https://github.com/zachwick/brew/tree/license_info.

As an example, this POC would be used like the following in the Erlang formula:

license_info "Apache License 2.0", :url => "https://github.com/erlang/otp/blob/master/LICENSE.txt"

For projects available under multiple licenses, these multiple directives can be used to specify each license that the project is available under:

license_info "GNU GPLv3+", :url => "https://github.com/sample-project/blob/master/LICENSE-GPLv3.txt"
license_info "GNU AGPLv3+", :url => "https://github.com/sample-project/blob/master/LICENSE-AGPLv3.txt"

The motivation for the feature

When deciding whether or not to install a particular formula, I use brew info to see the information about the formula that is used to either make my decision, or where to look elsewhere for more information (such as the homepage item). Often times, I'm interested in knowing the licensing of the project prior to installation as software licenses can be nuanced and impact how/when/where I can use the project itself. It would be useful to provide licensing information directly in the formula in order to alleviate the need to navigate to the project's homepage or code repository to determine the relevant license(s) that the project is licensed under.

How the feature would be relevant to at least 90% of Homebrew users

Any Homebrew user who wants to understand the license that the project installed by a particular formula uses would no longer need to navigate to the project's homepage or code repository and find any and all licensing options for the project. Instead, the formula's author/maintainer could simply list any and all licenses that the project is available under inside the formula's structure, and brew info would display this information.

What alternatives to the feature have been considered

• do nothing and maintain the current behavior of making interested Homebrew users find the licensing information on their own

[MikeMcQuaid]

We'd be interested in adding this to Homebrew/homebrew-core formulae but this would require the same process as was done when adding the desc DSL

1. an external command (https://docs.brew.sh/External-Commands) in a tap (https://docs.brew.sh/Taps, https://docs.brew.sh/How-to-Create-and-Maintain-a-Tap) are used to solicit community contributions for and allow querying licenses for Homebrew/homebrew-core formulae
2. when license data is available for all formulae (or at least the vast majority) we add a DSL in Homebrew/brew and we'd accept a PR in Homebrew/homebrew-core to add them to all formulae

[zachwick]

@MikeMcQuaid Thank you for the feedback. I'll work on a new proof-of-concept PR following the process that you outlined. When that PR is complete, should I comment on this issue again, or should I submit a new feature request issue?

[MikeMcQuaid]

@zachwick We'll need more than a proof-of-concept I'm afraid; I'm suggesting that you setup the relevant tap and start soliciting community contributions to populate it (or do it yourself). We can help promote that on e.g. our Twitter.

license_info "Apache License 2.0", :url => "https://github.com/erlang/otp/blob/master/LICENSE.txt"

My suggestion would be that this be simplified to the following (to help inform what metadata you gather):

license "Apache-2.0"

If there are multiple licenses I would suggest either of:

license ["Apache-2.0", "0BSD"]

or:

license "Apache-2.0"
license  "0BSD"

and these be values from https://spdx.org/licenses/.

In your tap you could just gather this data through e.g. JSON files for now.

[MikeMcQuaid]

Reopening this as help wanted so people know it's a desirable feature.

[colindean]

I might be interested in helping out with this. I've got some spare time in the next week or so.

@zachwick, I see you've got a start in https://github.com/zachwick/homebrew-license so I'll check that out and collaborate over there.

[MikeMcQuaid]

@zachwick suggestion: use https://developer.github.com/v3/licenses/ to mass-import all projects with GitHub homepages and/or tarballs and/or head URLs.

[zachwick]

@MikeMcQuaid We did this in https://github.com/zachwick/homebrew-license/pull/15/ and I suppose should do this again on regular intervals to pick up new additions.

[MikeMcQuaid]

@zachwick Cool!

[MikeMcQuaid]

@zachwick How are we looking in terms of numbers of packages with licenses/not?

[MikeMcQuaid]

I think we have sufficient formulae here that this could be added as a new DSL now and merged into homebrew-core. @igas, you mentioned you'd be interested in doing this?

[igas]

@MikeMcQuaid yes, that's right. I think what @zachwick have in his brunch is a good start. I'll adjust it to following DSL (license name, desc):

license "Apache-2.0", "https://github.com/some/project/blob/master/LISENSE.txt"
license "0BSD", <<~LICENSE
  The license file can be found in docs folder of the tarball.
LICENSE

When we have this DSL, next step will be adding audit for new formulas and start accepting it in core.

WDYT?

[MikeMcQuaid]

@igas Sounds good! I'd suggest we rely on https://github.com/licensee/licensee for audits and we use the spdx-id for the first attribute.

Another option would be something like:

license "Apache-2.0", :description => "https://github.com/some/project/blob/master/LISENSE.txt"

to allow it to be optional and/or allow for future expansion.

[MichelleNguy]

@MikeMcQuaid Licensee requires rugged (https://github.com/libgit2/rugged#use-the-system-provided-libgit2) as a dependency, which requires cmake as a dependency.

Would this be allowed?

[MikeMcQuaid]

@MichelleNguy "By default, Rugged builds and uses a bundled version of libgit2. " seems fine for our use-case 👍

[MikeMcQuaid]

Considering this done (enough) with the excellent work from @lionellloh and @whoiswillma. Well done, folks!

[colindean]

Great work everyone!