Clarify how `license` tags should be used for tools

[elichad]

Following a conversation in https://github.com/muon-spectroscopy-computational-project/muon-galaxy-tools/pull/96.

The license tag can be used/understood in multiple ways:

1. the license for the tool XML file itself and associated scripts (edit: shipped with the tool)
2. the license only for associated scripts, and the tool XML itself is covered by some overarching repo license
3. the license for the software that it wraps

--

1. The tool XML docs on license suggests that option 1 is the intended meaning:

   This string specifies any full URI or a a short SPDX identifier for a license for this tool wrapper. The tool wrapper version can be indepedent of the underlying tool. This license covers the tool XML and associated scripts shipped with the tool. This is interpreted as schema.org/license).

2. But a conversation with @bgruening implies that some people are interpreting it with the second meaning:

   My understanding is that MIT [the overarching license of the tools-iuc repo] is for the tool-XML files. The license annotation in the XML file might indicate the license of additional scripts associated with the XML tools.

My opinion is that it's totally counterintuitive to have such a deliberately self-contained XML document be licensed partially by something outside it, especially if the license tag is explicitly set. (Not to mention the license displayed in the UI might then not be accurate?) One example of where this conflict exists in tools-iuc would be SpyBOAT

3. I don't see any documentation that implies the third meaning, but this is an easy misinterpretation for a new developer.

--

The license tag is also not mentioned anywhere in the Planemo Tool Best Practices or the IUC Standards. (The fact that there are two best-practice-for-tools documents is another, separate issue...)

It would be useful to:

• include licensing in all best practice documents
• explain how the license tag should be used in repos containing many tools

[mvdbeek]

1. the license for the tool XML file itself and associated scripts

This is the correct meaning IMO. I believe 2 is pretty close, I don't think @bgruening meant additional scripts as in scripts that are coming in via conda, but scripts that we ship with the tool wrapper. We may have a license on the github repo, but completely lose that when the tool is installed and used in Galaxy, that's where the license field comes in handy.

My opinion is that it's totally counterintuitive to have such a deliberately self-contained XML document be licensed partially by something outside it, especially if the license tag is explicitly set. (Not to mention the license displayed in the UI might then not be accurate?)

💯

[peterjc]

Perhaps we need separate tags for wrapper license (XML file and any scripts with it, usually MIT for the IUC's work), and the underlying tool license (which could even be commercial)?

In comparison, conda-forge and bioconda have a license field for the license of the tool being packaged (but given their setup there is no reason to track the conda package licensing at the level of each package).

[elichad]

+1 @peterjc, I think that would be useful. Especially if we could add to the UI somehow 'X software is licensed under Y license.' A lot of tools already write this in the help text & it might be nice to standardise it.

[nsoranzo]

@elichad I agree with the sentiment, but what about the licenses of the requirements' dependencies? Where do you stop? That's not something we can manually maintain.

[mvdbeek]

That's not something we can manually maintain.

and there's ideally the bio.tools link which should list the license, at least for the main tool dependency