Made licensing guideline more neutral

[ghost]

• Made licensing guideline more neutral
  I think CWL should not prescribe a particular license. We should simply raise the issue that, like all software, CWL documents need a license to avoid problems and confusion for users.

[mr-c]

https://www.commonwl.org/user_guide/rec-practices/ is a list of recommended practices, the point is to give people good defaults to work from, so that is why we recommend a specific license.

Mentioning SoftwareRequirement here doesn't seem helpful.

As of right now I'm not motivated to merge this PR. Other perspectives are welcome.

[ghost]

Yes, we shouldn't :) It's like the C++ committee saying all C++ code should be released under MIT. It's not our place to do that. Which is why I linked to a published paper with guidelines for licensing for our intended audience. :)

[mr-c]

Yes, we shouldn't :) It's like the C++ committee saying all C++ code should be released under MIT. It's not our place to do that.

The CWL committee is over at https://github.com/common-workflow-language/common-workflow-language/

This is the CWL community :-)

[ghost]

This is is a list of recommendations for writing a program. It should be neutral as to political points. I'm happy to advocate with you on another forum for political points like pushing the Apache 2.0 license. My current personal favorite for hobby projects is MIT (almost the same as Apache 2.0) but that is a separate issue. But to advocate for a particular license in a site devoted to educating people about the use of a software specification is misleading. It is important that users educate themselves about software licenses, understand the intent of all licenses and decide for themselves what matches their goals.

[stain]

Our recommended practices (not the specification!) should rightfully be opinionated on this.

I think it's a good idea from our recommended practices to link to other recommended practices like A Quick Guide to Software Licensing for the Scientist-Programmer

I think we should still recommend a default license and keep it at Apache 2.0 - as CWL workflows are likely to be mixed and merged we don't want a big flora of licenses as this just causes combinatorics problems.

Perhaps we can word it a bit more positive, like "to encourage re-use, re-purposing and combinations of the workflow across the CWL community if the workflow is made public, assign it an open source license like Apache 2.0".

It might be worth pointing out that the license of the CWL workflow and its tool descriptions often will differ from the license of the tool it invokes (or even more complicated - the docker image that is distributed in).

In https://view.commonwl.org/about#licensing we say

Include a OSI approved open source license in your workflow and tool descriptions

For example, the following two statements at the top level of a workflow or tool description licenses it under the Apache V2.0 License:

$namespaces: { s: "http://schema.org/" }
s:license: "https://www.apache.org/licenses/LICENSE-2.0"

A permissive open source license allows others to remix and use your tooling and workflows to prevent the community from repeating development effort, allowing everyone to benefit

CWL Viewer is designed to allow people to locate and make use of the workflows developed by others as well as to share and demonstrate work, and open source licenses promote this goal

In the rendering we try to pick up the s:license field, and fall back to looking for LICENSE files in the github repo, and then say:

This workflow is Open Source and may be reused according to the terms of: https://raw.githubusercontent.com/Duke-GCB/bespin-cwl/qiime2-workflow/LICENSE
Note that the tools invoked by the workflow may have separate licenses.

(That is making an unfair assumption that anything with a LICENSE file must be open source :))

[ghost]

@stain @mr-c thanks for commenting

Our recommended practices (not the specification!) should rightfully be opinionated on this.

I agree to the extent that we should point users to educate themselves and think about consequences. I linked to a PLoS paper in the P-R but a website is fine too. Advocacy as to legal things, like licenses, I'm not comfortable with in an official document.

It might be worth pointing out that the license of the CWL workflow and its tool descriptions often will differ from the license of the tool it invokes (or even more complicated - the docker image that is distributed in).

Oh yes, that's a hairy point. Whether you can actually run the CWL also depends on the license of the container or other software you depend on. This is why I included a statement about softwareRequirements and have modified it to match what I intended, which is "any other pieces of software."

[mr-c]

@stain I agree that we could/should expand on our reasoning. However I want to keep this closer to a checklist, so maybe we should split off the justification/background to footnotes or another document (same structure, but more verbose)

[tobyhodges]

Did you reach a conclusion on this? My summary is that you agree on adding a link to some resource where users can learn more about choosing a license (I too like the PLOS paper that Kaushik linked to) but disagree on how opinionated the language should be around recommending a permissive license.

May I suggest a compromise? (emphasis added to distinguish my suggested changes)

A CWL document (in conjunction with any external components like docker files) is software code. Workflow developers should be aware that the usual rules of software licensing apply to this document. For example if the workflow is shared publicly, licensing terms have to be clear so that a future user can understand under what conditions they can run the workflow, modify it and/or combine it with other workflows. For this reason please consider including a license field in the document. The authors of this guide urge you to choose a pre-existing license rather than trying to write your own (see the link below to learn more about choosing a license), and our recommended practice is to choose a license that allows for re-use by anyone, e.g. [Apache 2.0][apache-license].

If possible, the license should be specified with its corresponding [SPDX identifier][spdx]. Construct the metadata field for the licence by providing a URL of the form https://spdx.org/licenses/[SPDX-ID] where SPDX-ID is the taken from the list of identifiers linked above. See the example snippet below for guidance. For non-standard licenses without an SPDX identifier, provide a URL to the license.

Useful reading: "[A Quick Guide to Software Licensing for the Scientist-Programmer][sci-license]"
[sci-license]: https://journals.plos.org/ploscompbiol/article?id=10.1371/journal.pcbi.1002598

[netlify]

❌ Deploy Preview for trusting-gates-d1169f failed.

Name	Link
🔨 Latest commit	9332038
🔍 Latest deploy log	https://app.netlify.com/sites/trusting-gates-d1169f/deploys/6347c8dedd1a8d00087a53c7