Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Clarify how license tags should be used for tools #72

Open
elichad opened this issue Oct 10, 2022 · 5 comments
Open

Clarify how license tags should be used for tools #72

elichad opened this issue Oct 10, 2022 · 5 comments

Comments

@elichad
Copy link

elichad commented Oct 10, 2022

Following a conversation in muon-spectroscopy-computational-project/muon-galaxy-tools#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).

  1. 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

  1. 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
Copy link
Contributor

mvdbeek commented Oct 10, 2022

  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
Copy link
Contributor

peterjc commented Oct 10, 2022

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
Copy link
Author

elichad commented Oct 10, 2022

+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
Copy link
Member

@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.

nsoranzo added a commit to nsoranzo/tools-iuc that referenced this issue Oct 10, 2022
The `license` attribute refers to the wrapper's license, not the
license of the underlying tool(s), see

https://docs.galaxyproject.org/en/master/dev/schema.html#attributes

xref. galaxy-iuc/standards#72
@mvdbeek
Copy link
Contributor

mvdbeek commented Oct 10, 2022

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants