Tool and wrapper license info -> tool xml?

[bwlang]

@bgruening asked me to start a conversation about whether or not to add tool licenses to to galaxy's tool xml.

This is one of my least favorite topics, but I agree that it's important, and one does not just ignore @bgruening in good conscience ;)

As @nsoranzo points out, there are two license questions here: 1) the underlying tool license 2) the license of the tool xml itself

Regarding tool licenses: Should we add a license tag to tool xml? Could we discover / link to the license on conda dependencies?

Regarding wrapper licenses: Do the tool xml wrappers themselves have a license associated with them? (I could not quickly find out what it is if they do) Do they need one?

[bwlang]

IMHO, it's better to not add another fact to the tool xml about the licenses of dependencies. If we can link to conda instead I think that's simpler all around. Given that IUC has an open source policy, I feel safe installing IUC tools already.

I think it may make sense to add a tag to the tool xml that clearly only refers to the wrapper (nf-core's method might be an analogy). For that matter maybe workflows should too - sigh. I'd support adding a default permissive license (e.g. BSD or public domain) for future tool wrappers to planemo. It's fairly heavy handed, but maybe a check for wrapper license specification during toolshed upload is warranted?

I think most tool wrappers (e.g. IUC) are already licensed so it might be feasible to refer back to these somehow - not sure about how to do that exactly.

[bwlang]

@jmchilton also mentioned commoncwl's license implementation

[jxtx]

Not clear in the CWL example what the license applies to.

[nsoranzo]

Let's ask @mr-c

[bwlang]

Not clear in the CWL example what the license applies to.

Given that this is a workflow and many tools are used, i think it must be the workflow itself. I think it would be better named "workflow license" for clarity. In our case we could use an explicit name e.g. \MIT\

[nsoranzo]

@bwlang The CWL standard is also used to describe tools (class: CommandLineTool), and the example you linked above is indeed for a tool, not a workflow.

[mr-c]

The s:license (enabled the by the $namespaces: { s: https://schema.org/ } line) refers to the CWL file it is contained in. That file could be a single CommandLineTool description (analogous to a Galaxy tool wrapper), a single Workflow, a single ExpressionTool, or a collection of them in a single file wrapped up in a $graph.

[mr-c]

Since we used a third-party ontology (schema.org) as an extension we don't have control over the name. As you do have control I support the explicit marking of the license referring to the file itself vs. the underlying tool or tools.

I would ask that you re-use the SPDX identifiers for F/OSS licenses (with or without the URI prefix)

[bwlang]

I just ran across this bit of NF-core that prints all the licenses from conda. Maybe that could be repurposed here.

https://nf-co.re/tools#pipeline-software-licences