- Upon publication of your article, you must share publicly any code that you created and that directly relates to the results described in your article, unless you claim an exemption to the policy.
- If you have legal or ethical restrictions on public sharing of your code, please include details of your exemption in your Data Availability Statement, and your request will be passed to the Editor for consideration.
- A statement about where and how your code can be accessed must be included in the Data Availability Statement in your manuscript.
- We recommend ways for you to share your code publicly but are not prescriptive about how code is shared.
- You are strongly encouraged to follow best practices for code sharing, such as:
- Deposition of your code in public repositories
- Citation of publicly-available code that is assigned a persistent identifier in your reference list
- Use of open source definition licenses for your code
- You are responsible for the quality of your code. Peer reviewers will be asked to assess if you have complied with this policy and are able to review the code at their discretion.
- This policy applies to all manuscripts submitted to the journal from 30 March 2021.
We aim to increase the amount of code that is shared with articles published in PLOS Computational Biology because doing so supports open, reproducible research. Sharing computer code assists other researchers to assess, reuse and replicate published work, and is good research practice.
In alignment with our data availability policy, PLOS Computational Biology requires authors to make all author-generated code directly related to their study’s findings publicly available without access restriction at the time of publication unless specific legal or ethical restrictions prohibit public sharing of code. In these cases, authors must indicate how others may request access to the code. Access to code must be described in the Data Availability Statement. Relevant code should be available to editors and reviewers at the time of submission and throughout the editorial process, but does not need to be publicly shared prior to acceptance.
PLOS recognizes that authors may not be able to make code publicly available for legal or ethical reasons. This code sharing policy does not overrule contractual obligations, local regulations, legislation or ethical frameworks. Acceptable restrictions on code distribution may include dual use concerns of the code or other legal limitations, such as export restrictions. Any limitations on code sharing must be made clear in the Data Availability Statement at the time of submission and will be subject to editorial assessment.
When author-generated code cannot be publicly shared for these reasons, PLOS Computational Biology will allow authors to make their code available upon request. Authors must identify the contacts to whom requests should be submitted and must include in the Data Availability Statement all necessary contact information where an interested reader would need to apply in order to obtain the code. A third party should be named for distribution of the generated code, such as an institutional access committee. It is not acceptable to only list the authors as contacts for requests for access.
Refusal to share code, or lack of details of how to request access to the code, in accordance with this policy, may be grounds for rejection. If restrictions on access to code come to light after publication, we reserve the right to post a correction or editorial expression of concern, to contact the authors' institutions and funders, or in extreme cases to retract the publication. Any exemptions to code sharing as outlined in this policy must be approved by an Editor, and must be requested at submission.
Shared code needs to be made accessible for free and should be easy to locate and download. We strongly recommend that all code be deposited in a permanent, public repository that issues citable digital object identifiers (DOI) or other persistent identifiers, for example using Zenodo to archive GitHub packages, CodeOcean, or the Software Heritage archive. Ideally, the repository should allow for versioning so that the version of the published record is permanently documented and assigned its own DOI. Code deposited in repositories should be cited in the reference list of the manuscript as a software citation using the DOI or other persistent identifiers wherever possible. Code can also be provided as Supporting Information files with manuscript. PLOS deposits published Supporting Information files in figshare.
Code executed within commercial software packages (e.g., Matlab, SPSS, office software), where directly related to the study’s findings, also needs to be shared. Details of the version of the commercial package should be included in the Data Availability Statement.
PLOS Computational Biology does not require code to be shared using any specific license, only that a license is clearly specified. However, to support reusability of the code we strongly encourage authors to license code so it conforms with the Open Source Definition. We also encourage authors to use complete open source solutions where possible.
For studies that describe software for end-user applications, deposition either in a repository that enables remote code execution or instructions for installing and using the software are a prerequisite. For software libraries, instructions on how to use the application program interface should be provided. Version numbers, system requirements and other dependencies must be mentioned. Where feasible, results from standard test data sets should be included with software for end-user applications. Ideally test data should not have any dependencies.
This policy was launched on 30 March 2021 and applies to all new manuscripts submitted to PLOS Computational Biology.
This policy complements the existing Data Sharing and Software Sharing policies. PLOS Computational Biology already requires that any underlying data that is needed to replicate the studys’ findings should be made openly available and has previously strongly encouraged authors to make their code and software openly available. We now require all author-generated code directly related to their study’s findings to be made available. The Software Sharing policy is specifically for manuscripts describing new software and it remains a requirement to share software described in Software submissions.
This policy does not change the way reviewers will assess your manuscript. As before, code central to the findings should be shared either publicly or privately with the reviewers and editors for their assessment as necessary. In addition, reviewers will be asked to comment on whether the code has been (or will be on publication) shared in line with this policy. It is the authors’ responsibility to ensure that the code has been shared in a way that facilitates reuse.
You are expected to share the code that is directly related to findings presented in your manuscript. These are often referred to as analysis scripts but there may be other scripts that are directly related and should be shared. You are strongly encouraged to share the code for any preprocessing of the data as this contributes to the reproducibility of the research.
If you have produced a tool or software you should follow the Software Sharing policy (which is mandatory for software submissions).
Alongside the code you should also be sharing any documentation that would be necessary for another researcher to run your code. For example, details of dependencies such as the environment it needs to be run in and any packages or software needed.
My code has many dependencies and I think this will make sharing it meaningless. What do you suggest I do?
If you want to go further than describing your code’s dependencies, and render your code reusable for a longer period of time then you could consider using a container to package your code along with any dependencies in the environment it was created to run in. Examples of container technology are Code Ocean, Binder and Docker. You will need to ensure that any dependencies allow for redistribution in this way.
You are free to choose where to share your code, although we strongly recommend archiving it somewhere that provides persistent identifiers (e.g., DOIs). Commonly used options for sharing code are Github and Bitbucket but neither issue DOIs. Github integrates with Zenodo so you can archive snapshots of your code and assign it a DOI, which can be useful to help point others to the version referenced in your article. You are also able to put your code in the Supporting Information section of the article and this will be archived in figshare after publication.
You are free to choose whatever license you wish, although PLOS Computational Biology strongly recommends a license that supports open, reproducible research. If you chose to apply an open source license to your code and need help deciding on which license to use, you might find the Choose a Licence website useful. Please note, Creative Commons licenses are not recommended for code or software.
Before selecting a license for your code, be sure to take into consideration any third party obligations that may apply, for example: any license that may apply to third party code used by you (if applicable), the policies of your institution, funder and collaborators.
Your code must be available at the time of publication of the article and available for peer review; however, it does not need to be publicly available at the peer review stage. Some repositories, such as Github, figshare or Code Ocean, will allow you to share your work with others privately. You can use the journal email address (email@example.com) to share the link with if you need to specify the person with whom you are sharing.
If the code is uploaded to a repository that issues DOIs only at publication, authors may submit their manuscript and include placeholder language in their Data Availability Statement indicating that the DOI will be made available after acceptance. The journal office will contact authors prior to publication to ask for this information and will hold the manuscript until it is received.
Providing private code access to reviewers and editors during the peer review process is acceptable. Many repositories permit private access for review purposes, and have policies for public release at publication.
Your code should be well described and documented in order to facilitate others reusing it or running it. Repositories will usually require certain information to be entered when you submit your code but the more information you add the more useful your code becomes. You should ensure that you describe the environment in which your code should be run and any dependencies there are. You should also state the version of the code you are sharing and a link to live code so users can check for any updates. Within your code, annotation is very important as it helps others understand what you are aiming to achieve. For more information on describing your code see The Software Sustainability Institute’s guide Software deposit: how to describe a software deposit.
The Data Availability Statement must give details of both the data and code that supports the results presented in the article. For both the code and data you must list the name of the repository or repositories as well as digital object identifiers (DOIs), accession numbers or codes, or other persistent identifiers.
All human data, statistical analysis code, stimuli, network training sets, and trained networks are available on Zenodo at link http://doi.org/10.5281/zenodo.3534568.
All relevant data are within the paper, its Supporting Information files, and on Zenodo at https://doi.org/10.5281/zenodo.2640689. The REMI code is available on GitHub at https://github.com/EPFL-LCSB/remi.
All data and code used for running experiments, model fitting, and plotting is available on a GitHub repository at https://github.com/wtadler/confidence. We have also used Zenodo to assign a DOI to the repository: 10.5281/zenodo.1422804.
The source code and data used to produce the results and analyses presented in this manuscript are available from Bitbucket Git repository: https://bitbucket.org/alexeyg-com/irespredictor.
All code written in support of this publication is publicly available at https://bitbucket.org/pkhlab/pkh-lab-analyses. Simulation input files and generated data are available from https://doi.org/10.5281/zenodo.3711649.
If there are ethical or legal restrictions on sharing code, authors should provide the following information within their Data Availability Statement upon submission and should contact the journal editorial office (firstname.lastname@example.org):
Explain the restrictions in detail (e.g., code could potentially identify or reveal sensitive patient information)
Provide all necessary contact information needed for others to make access requests for the code, including a third party contact.
Any data that cannot be shared due to ethical or legal restrictions should follow the guidelines set out in the Data Availability guidelines.
The location of both your data and code should be stated in your Data Availability Statement. In addition you can add information to both the data and code repository records detailing the associated article and other supporting outputs (data or code). If the repository does not have a dedicated field to add this information to, then you should cite the data or code using citation best practice guidelines.
There is no requirement for your data and code to be in the same place. It is possible that they are more suited to different repositories and you should use domain specific repositories whenever possible.
My institution/funder retains the IP of the code I produce. Can I publish in PLOS Computational Biology?
Please check the policy of your institution/funder carefully as some may make exceptions for sharing code or software for scientific advancement. PLOS Computational Biology does not require you to use a certain license and applying an “all rights reserved” license may satisfy your institutional/funder requirements.
This policy does not prohibit you from commercialising your code.
Software Sustainability Institute - UK based organisation that facilitates “the advancement of software in research by cultivating better, more sustainable, research software to enable world-class research”. They have produced Software Deposit Guidance for Researchers.
Open Source Initiative - A USA based organization with comprehensive information on open source licensing options.
Software Citation Checklist for Developers - this provides a minimal, generic checklist that developers of software can use to ensure they are following good practice around software citation.
Katz et. al. (2021) Recognizing the value of software: a software citation guide [version 2; peer review: 2 approved]. F1000Research 9:1257 DOI: https://doi.org/10.12688/f1000research.26932.2 - this article describes the best practice for citing software.
- For a discussion on how to make code findable, accessible, interoperable and reusable (“FAIR”) see Lamprecht, Anna-Lena et al.(2020) Towards FAIR Principles for Research Software Data Science 3(1): 37–59 DOI: 10.3233/DS-190026.
- Resources on license compatibility can be found here: combining licenses of different types, combining Apache 2.0 and GNU GPLv3, combining GNU licenses.
PLOS includes external links in this policy as a convenience and for informational purposes only; they do not constitute an endorsement by PLOS of any of the products, information or opinions found on those links. Please contact the external site for answers to questions regarding its content.