Is the licences functionality still desired/needed?

[fabianegli]

Description of feature

As of #1689 there are too many commented out tests with the following note:

# TODO nf-core: Assess and strip out if no longer required for DSL2

This comment should be in the code or even better here in the issues.

The tests moslty work, but require the environment.yml and mostly fail with

LookupError: No `environment.yml` file found. (Note: DSL2 pipelines are currently not supported by this command.)

Is this functionality wholly deprecated? Should it be retained for DSL 1 backwards compatibility? Or can it be scraped from the codebase?

[ewels]

The licenses should probably be scrapped entirely, as it only works for DSL1 pipelines and we have fewer and fewer of those.

[ewels]

See almost-duplicate issue (with different spelling of licenses) here: #1155

[fabianegli]

So that would then mean to have the licences command deprecated. Should we add a deprecation notice for 2.5 and drop it in 2.6?

[ewels]

Yeah or come up with a new strategy. This isn't tracked well in the issues, but it has been in the back of my mind for a while now.

Checking the modules meta.yml files, it seems that we collect licence information for each tool (from bioconda) - I think I probably suggested this with the idea of updating this command.

Should be fairly easy to scrape all installed modules meta.yml files to look for this?

meta.yml

tools:
  - fastqc:
      licence: ["GPL-2.0-only"]

[fabianegli]

This is an interesting example. The meta.yml is actually not a reliable source, because the license may changes over time like in the case of fastqc. The meta.yml reports a GPLv2-only license wile the linked official website says it is licensed under GPLv3.

I think there should be some more thought about where to source the license information from.

[fabianegli]

The fact that the GitHub repo of FastQC contains multiple license files might explain the GPLv2 in the meta.yml

How was the license chosen for the meta.yml? Is there some automation that is not sophisticated enough to handle multiple license files?

See also s-andrews/FastQC#101

[ewels]

I thought that it came from Bioconda (http://bioconda.github.io/recipes/fastqc/README.html#package-fastqc) but that says something different.

It was probably the single worst example I could have chosen though, as it was the first ever module and so likely written entirely by hand. Hopefully if you look through more modules you'll find that they correspond to bioconda.

This is something that we could lint for at nf-core/modules level too..

Phil

[pbiology]

I can add that this would be very helpful from a regulatory point of view. To easily be able to extract license types for a given pipeline would identify needs to aquire licenses in a non-academic setting

[pbiology]

To just add some other piece of information to this.
Right now there seem to be license type information in the meta.yml for a given module.

However, it would be very nice if a link to a versioned lincense file also was included. This of course would mean that the version used of the software would be needed.

[mashehu]

removed with #3012