Define plugin requirements

[Stratus3D]

We need to specify the licenses we permit. It seems reasonable to me to only permit open source licenses for plugins, but I don't think we've ever had that as a hard requirement.

[canterberry]

License Restrictions

Figured I'd throw in my $0.02 here, since this issue has been stagnant for a while and it's a good prompt.

TL;DR: The only relevant clause in a license for this repo, I imagine, would be a grant to execute the plugin software and to redistribute its source code. This should already be granted in most software licenses.

Concerning licenses and license restrictions generally:

1. A plugin's license may differ from that of the tool it manages. For example, the Java plugin may use the MIT license, but manage, amongst other things, the Oracle JDK, which has its own proprietary license. The Ruby plugin manages several different implementations of Ruby, each with its own license. If this asdf plugins directory has a license requirement of any kind, would that requirement be on the plugin or on the software it manages?

2. If there is some licensing restriction for listing in this plugins directory, then it might also be a good idea to communicate to end-users which license each plugin uses. This could be included in the output of asdf plugin-list-all, along with the plugin name and repo URL. It could also be communicated with a license badge in this repo's README, like so: ![License](https://img.shields.io/github/license/twuni/asdf-yarn.svg)

3. If communicating the license information per (2) above, there is a risk that end-users may mistakenly assume the license presented is the license for the tool being managed (not the plugin itself). This could be mitigated (but not alleviated) using a "Plugin License" column label, which would help to distinguish that the listed license is for the plugin itself.

4. The status quo of not presenting any specific license information, but just providing the repo URL for each plugin, is probably the most correct approach to communicating license information. It provides end-users with a way to verify this for themselves, as needed, and is guaranteed to be up-to-date because it is the definitive source of truth for that plugin's license. With this option, there's no risk of miscommunicating a plugin's license if it changes upstream.

The prompt isn't about how license information is communicated, though. That's more of a tangential path.

[canterberry]

Quality Requirements

Some ideas on items for a plugin quality checklist:

• Plugin scripts should be run through a static analysis tool like ShellCheck, and this analysis should be wired into the CI build.
• Plugins should only use HTTPS for downloading artifacts (not HTTP).
• Plugins should not make system-wide changes to the host, such as installing global executables or libraries.
• Where possible, plugins should include integrity checks for all downloaded artifacts using a strong cryptographic hash (SHA256 or better; not MD5 or SHA-1, which are no longer secure).
• Where possible, plugins should include authenticity checks for all downloaded artifacts using cryptographic signature verification (typically using GPG with a statically hosted public key).
• If a plugin performs authenticity checks using GPG, it should not pollute the user's default keychain with these keys, and instead use a dedicated GPG keychain (example).
• Plugin scripts should be human-readable (not obfuscated and/or minified).
• Plugins should have a CI build that executes in a Linux environment.
• Plugins should have a CI build that executes in an OS X environment.
• Plugin authors should run asdf plugin-test <plugin-name> <plugin-directory> to run the standard asdf plugin tests for their plugin, and incorporate this command into the CI build.

[Stratus3D]

1. A plugin's license may differ from that of the tool it manages. For example, the Java plugin may use the MIT license, but manage, amongst other things, the Oracle JDK, which has its own proprietary license. The Ruby plugin manages several different implementations of Ruby, each with its own license. If this asdf plugins directory has a license requirement of any kind, would that requirement be on the plugin or on the software it manages?

That's a good question. For security reasons we absolutely have to have the plugin code be open source (otherwise we might not be able to legally read it), but I guess requiring them to be free (e.g. MIT license) isn't strictly necessary.

2. If there is some licensing restriction for listing in this plugins directory, then it might also be a good idea to communicate to end-users which license each plugin uses.

Possibly, although the way asdf uses plugins I think most users would never have any issues with the various open source licenses (most users won't be packaging plugins into commercial products). But maybe showing the licenses is a good idea.

3. If communicating the license information per (2) above, there is a risk that end-users may mistakenly assume the license presented is the license for the tool being managed (not the plugin itself). This could be mitigated (but not alleviated) using a "Plugin License" column label, which would help to distinguish that the listed license is for the plugin itself.

Good point. I'm open to anything here. As far as we are concerned the tool itself can have any license.

Another thing to consider is cruft in the list. We've got quite a few Kubernetes plugins on the list. I'm not a user of Kubernetes so I'm not totally sure why there are some many different plugins for the software around Kubernetes, but we don't want the list to grow so large that it no longer is useful to end users.

I like everything on your checklist! Some of those things are easier to automate than others. Feel free to implement some of those things if you like!