Show package licenses - Githubissues

LiberalArtist commented 2 years ago

Here's a first step toward adding a UI for package license information.

As @sorawee points out, this code might be better in https://github.com/racket/pkg-index, instead, since an ill-formed license S-expression might not survive convert-to-json, but then we'd need to come up with an encoding.

Also, should we try to distinguish #f from "absent"?

Maybe we put this in https://github.com/racket/pkg-build and treat it like documentation, logs, etc?

LiberalArtist commented 2 years ago

Answer: use the foundation @sorawee laid in https://github.com/racket/pkg-index/pull/33.

LiberalArtist commented 2 years ago

I've added some UI, though I haven't tested this locally yet.

countvajhula commented 2 years ago

Hello! I'm not familiar with the context, but just noticed this on Discord and wanted to check that this would support public domain work? Such works don't include a license, since they aren't copyrighted. Would there be a way to indicate this via e.g. info.rkt? Maybe this is related to your question about re: distinguishing #f from absent.

LiberalArtist commented 2 years ago

Hi! The license field in "info.rkt" files supports arbitrary SPDX license expressions. As you probably know, copyright and the concept of "public domain" are different in various jurisdictions. The SPDX project assigns identifiers to concrete statements about how materials are licensed: they explicitly aim to avoid making legal judgements, such as how some statement might be applied in a particular jurisdiction. There are SPDX identifiers for a number of different statements people use to place work in the public domain or to inform recipients they believe the work is in the public domain, such as CC0-1.0, blessing (used by SQLite), SAX-PD, libselinux-1.0, NIST-PD, and NIST-PD-fallback.

The question about distinguishing #f from absent is really about error reporting: #f is not well-formed in the grammar of license S-expressions, so the warning should be different if someone writes (define license #f) than if they simply don't have a definition for license.

Does that answer your question?

LiberalArtist commented 2 years ago

Oh, and I've also written this code not to reject as invalid identifiers matching

#px"^(?i:(?:DocumentRef-[-.[:alpha:][:digit:]]+:)?LicenseRef-[-.[:alpha:][:digit:]]+)$"

which are part of the SPDX mechanism for handling arbitrary license statements that haven't been assigned an identifier (e.g. DocumentRef-spdx-tool-1.2:LicenseRef-MIT-Style-2 or LicenseRef-MIT-Style-1). I'd expect them to have only limited support in tools generally, though. For example, we can't automatically link to the license text in those cases.

(For code you write, I'd strongly recommend choosing some well-known statement like CC0-1.0, though.)

countvajhula commented 2 years ago

I see, those seem to be reasonable affordances for public domain projects. Thank you for those clarifications @LiberalArtist !

sorawee commented 2 years ago

@LiberalArtist do you think it makes sense to move the license parsing to its own package (which racket-pkg-website will require)? That way, when I add more functionalities to license-audit so that it can validate licenses, it can simply reuse, instead of duplicating the code.

LiberalArtist commented 1 year ago

@sorawee I definitely think it would make sense to make a package to parse license S-expressions and ultimately use it here. To me, it would make most sense to first get this feature working, then make an spdx package, and finally change racket-pkg-website to use spdx.

To me, it would make sense to put the spdx package somewhere under the Racket GitHub organization. While, as I said in response to https://github.com/racket/racket/issues/4276#issuecomment-1146323545, I agree with @samth that the scope of what license-related functionality is developed by Racket as a project should be carefully limited, Racket defines the license S-expression grammar, so it would make sense for Racket to provide basic utilities for parsing and validating license S-expressions. It also seems like a good way to help multiple community-developed tools really be interoperable in terms of the license S-expressions they accept.

I think there are some design considerations that would be worth thinking through before committing to a stable interface for an spdx package, which is why I'd propose to work on that this feature is done. A few that come to mind:

What are the pros and cons of using the JSON files via define-runtime-path vs. embedding the data at compile time, e.g. with include/reader?
Presumably we'd want something like a set of opaque types to encapsulate issues like case insensitivity and the + operator. How do we organize the interface? Do we need a type hierarchy?
How should we handle deprecated license identifiers?
For some purposes, we probably want to be able to reconstruct the license S-expression as the user wrote it (maybe even with source locations?), but for other purposes we might want to make dealing with chained OR expressions easier.
What should equal? mean?

LiberalArtist commented 1 year ago

I think this is ready to go as soon as https://github.com/racket/pkg-index/pull/33 is merged! I've put an un-squashed version of these changes at https://github.com/LiberalArtist/racket-pkg-website/tree/hist/license-metadata-0.

sorawee commented 1 year ago

One potential improvement, possibly as a separate PR, is to make "This package needs license metadata" an element that can be hovered over, which will pop up a tooltip with content like "If you are a package author, consider adding license in info.rkt".

LiberalArtist commented 1 year ago

Yeah! I've pushed a simple version. It should be possible to style the tooltip with jQuery UI, but it looks like that would require writing some Javascript.

LiberalArtist commented 1 year ago

@samth, could you take a look at this and https://github.com/racket/pkg-index/pull/33 when you have a chance?

jryans commented 1 year ago

@LiberalArtist Sorry for the radio silence here! I've added this to my review queue, and I'll take a look soon. 🙂

jryans commented 1 year ago

I have verified this is working well locally. Once the backend side is deployed, I'll then merge and deploy this side as well.

jryans commented 1 year ago

This has now been deployed and the static pages are being regenerated. 🎉 It will take a bit of time before all of them are updated.

Here are few examples that are already updated:

Has valid license: https://pkgs.racket-lang.org/package/sauron
Missing license: https://pkgs.racket-lang.org/package/phc-toolkit

sorawee commented 1 year ago

Very nice!

A minor nit: the blank field in https://pkgs.racket-lang.org/package/phc-toolkit doesn't look pretty. I personally would prefer some italicized text that indicates that there's no information.

jryans commented 1 year ago

All packages and the index page appeared to be updated now.

jryans commented 1 year ago

A minor nit: the blank field in pkgs.racket-lang.org/package/phc-toolkit doesn't look pretty. I personally would prefer some italicized text that indicates that there's no information.

Agreed, it would be good improve that. I'm happy to review and deploy a PR to tweak this. 🙂

LiberalArtist commented 1 year ago

On Thu, Oct 13, 2022, at 1:18 PM, J. Ryan Stinnett wrote:

A minor nit: the blank field in pkgs.racket-lang.org/package/phc-toolkit doesn't look pretty. I personally would prefer some italicized text that indicates that there's no information.

Agreed, it would be good improve that. I'm happy to review and deploy a PR to tweak this. 🙂

I did it that way to match how the documentation field is treated in packages without any, e.g. https://pkgs.racket-lang.org/package/1d6, but I think it would be better to change both.

racket / racket-pkg-website

Show package licenses #83