---
config:
look: classic
---
flowchart TB
A("**Manuscript Draft
Preprint v.0.0**") -- community feedback --> B("**Submitted Manuscript
Preprint v.1.0**")
B -- journal peer review --> C("**Revised Manuscript
Preprint v.2.0**")
C -- journal acceptance --> D("**Postprint
Preprint v.3.0**")
D -- "journal copy-editing and formatting" --> E("**Published Article**")
4. Preserve & Share
Make your research outputs accessible, reusable, and citable
Data Sharing
Code Publishing
Open Access
Persistent Identifiers
Checkpoint: Manuscript submission with DOIs for preregistration, data, and code
4.1 FAIR Data Sharing
4.1 FAIR Data Sharing
Sharing your data allows others to verify your findings, build on your work, and increase the impact of your research. But sharing does not always mean making everything publicly available. What you can share depends on the consent you obtained, the sensitivity of your data, and your ethics approval.
In 1. Plan & Design, you wrote a Data Management Plan, in 2. Collect & Manage, you created documentation for yourself, and in 3. Analyze & Collaborate you updated that documentation for your collaborators. Now you prepare that documentation for people who have no prior knowledge of your project and reassess you plan:
- Make a final decision on how openly your data will be shared.
- Select an appropriate repository for publishing your data type.
- Apply a license that tells others how they may reuse your work.
These steps are straightforward if you followed previous recommendations: by this stage, you should already have a README, a data dictionary (codebook), organized files, and clear metadata.
Not all data can or should be shared openly. Your sharing options depend on what consent participants gave and what your ethics approval permits (see 1.2.3. Ethics).
Open data can be downloaded by anyone without restrictions. This maximizes reuse but is only appropriate when data contains no personal information or has been fully anonymized.
Restricted access means the metadata is available on a professional repository and clear instructions of the conditions of access to the data are provided. Requesting the data often requires describing the purpose of reuse (sometimes in the form of a preregistration, see 1.4.1. Pre-analysis planning), signing a Data Use Agreement, and agreeing to further conditions. This can be organized automatically through the repository or through contacting the authors. This balances reuse with protection.
Metadata only describes what data exists without sharing the data itself. Others can discover your work and contact you to discuss access. This is appropriate when data cannot be shared due to legal or ethical constraints. Making your data Findable by sharing your metadata on a professional repository is the first step to making your data FAIR, as emphasized by the LMU Guidelines for Safeguarding Good Scientific Practice (see also 1.2. Legal Requirements)
When deciding whether data should be shared, consider the following:
- Ensure that data sharing is compatible with the informed consent provided by participants.
- Check what your ethics approval allows.
- Consider whether the data can be anonymized without losing scientific value (see 2.3.2. Anonymization).
- If you work with sensitive data, you may consult the University’s data protection officer.
- If your research outputs could have dual-use implications (e.g. that could also be applied for military or malicious purposes), consult the relevant regulations (e.g. European Commission’s policy (Dual-Use Regulation 2021/821)) and contact the University’s Export Control service.
- If your research may lead to patents or commercialization, contact the the University’s IP Management team before sharing data. Early consultation helps ensure that intellectual property rights are not compromised.
LEARN MORE
TOOLS & RESOURCES
During the course of data collection and analyses, you created a README and data dictionary for yourself and collaborators. Before sharing publicly, review them from the perspective of someone who knows nothing about your project.
Expand your README to include the research context (who created the data, what it contains, when and where it was collected, why it was generated, how it was produced), how to cite the dataset, and any access conditions.
Review your data dictionary to ensure every variable is fully described. What was obvious to you during analysis may need explanation for others.
Confirm you follow community standards. Many fields have established formats for sharing data (e.g., BIDS for neuroimaging, see FAIRsharing and RDMkit to review discipline specific organizational and metadata standards). Using these makes your data immediately usable with existing tools (see also 2.2.5. Standards).
Verify anonymization. Check that no personal information remains in the data files, metadata, or filenames.
LEARN MORE
TOOLS & RESOURCES
Choose a repository that suits your data type, your field’s expectations, and your access requirements.
Discipline-specific repositories are often the best choice. They use metadata standards your community expects, making your data findable by researchers in your field. Search re3data to find repositories for your domain.
General-purpose repositories like Zenodo or OSF accept any data type. They provide DOIs and long-term preservation, but may lack the specialized metadata fields of discipline-specific options.
Institutional repositories may be required by your funder. Choosing the LMU repository Open Data LMU also ensures you can get the support of the Research Data Management team of the University Library.
Whichever you choose, ensure the repository provides a DOI (Digital Object Identifier) so your data can be cited and tracked.
A license tells others what they can do with your data. Licensing your data consists in adding a file called LICENSE.txt next to your data, that contains the appropriate legal text. Without one, or equivalent statements, others cannot legally reuse your research outputs, even if it is publicly available.
Common open licenses for data are:
- CC0 (Public Domain) places no restrictions. Anyone can use, modify, and redistribute without attribution. Recommended for factual data where maximum reuse is the goal.
- CC BY (Attribution) requires users to credit you. A good default when you want recognition while enabling broad reuse.
- CC BY-NC (Non-Commercial) adds a restriction against commercial use. Consider whether this limitation actually serves your goals.
Learn more about open licenses for data and code in our code publishing tutorial.
For restricted-access data, a Data Use Agreement specifies conditions beyond a standard license: approved purposes, security requirements, publication terms, and data destruction timelines.
in construction
- Description of what it is, when it is needed, what the process to create one is (Team SOP for handling access requests (who receives them, how decisions are made, what must be documented, and response timelines))
- LMU contact for legal department
- Examples DUA
4.2 Open Source Code
4.2 Open Source Code
Making code publicly available demonstrates the reproducibility of your results and enables others to understand, verify, and build upon your analytical methods.
So far, your code was either backed up on the secured LRZ Gitlab (e.g. if your data and/or code are sensitive), or on GitHub (see 3. Analyze & Collaborate). Before the submission of a manuscript to a journal and/or upon the acceptance of a manuscript, there are small additional steps that need to be done to publish your code.
- verify the structure of your repository, the readability of your scripts, the completeness of the documentation (see Analyze & Collaborate Checklist).
- make a clean version public e.g. to GitHub
- add a license
- get a DOI through e.g. Zenodo
If you work with sensitive data that cannot be anonymized and shared:
- generate a simulated random dataset to allow for the published code to run (which you may have already done if you simulated data in order to prepare a preregistration, see 1.4. Study Design & Analysis Plan), or
- create a synthetic dataset with the same properties as the original dataset to allow others to re-derive an approximation of the original results and conduct further exploratory analyses.
During the course of data analyses, you created scripts and documentation such as README and data dictionary for yourself and collaborators. Before sharing publicly, review them from the perspective of someone who knows nothing about your project.
- Expand your README to include a description, involved data, computational requirements and dependencies (i.e. what software, packages, and their version, need to be installed to run the analyses), list of results.
- Document your code from an external perspective, using literate programming (e.g. Quarto) or comments.
- Double check that no sensitive information remains in your repository (e.g. code comments, history of sensitive data)
See our code publishing tutorial for more information on how to prepare your code repository for sharing.
Important
If you work with sensitive data, you must not include the raw or processed data in the version-controlled repository to be shared.
Instead, explicitly exclude the data directory using the .gitignore file from the start, or create a new local repository that contains all project files except the data.
Importantly, if data are removed from an existing repository, they may still remain accessible in the repository’s history, since previous states of the project can be restored. If sensitive data are accidentally committed and pushed, it is possible to rewrite the repository history to remove them retrospectively. However, this process is complex and error-prone, so it is best avoided by ensuring that sensitive data are excluded from version control from the outset.
Sharing your code allows for other researchers to clearly see which analytic methods were applied to the data. Ideally, they should also be able to rerun the code and verify the reproducibility of the reported results.
You can provide the data required to run the code in several ways:
- The real (anonymized) data. This can be done either (1) by including the dataset in the repository so that the code can access it locally and run directly, or (2) by configuring the code to retrieve the data from an external source, such as a database, API, or external data repository.
- Simulated random data. This option mainly demonstrates that the code runs without errors. However, the original results cannot be verified and further analyses are not meaningful. See our data simulation tutorial.
- Synthetic data that mimic key properties of the real data. When privacy-sensitive data cannot be shared, synthetic datasets can provide a useful alternative. Compared with purely random simulated data, synthetic data can resemble the structure and characteristics of the original dataset, allowing other researchers to rerun the analyses and assess whether the main results can be reproduced. In addition, openly shared synthetic data enable exploratory analyses that may generate new hypotheses, and in some cases analyses conducted on synthetic data can approximate results obtained from the real data.
LEARN MORE
A license tells others what they can do with your code. Licensing your code consists in adding a file called LICENSE.txt next to your code, that contains the appropriate legal text. Without one, or equivalent statements, others cannot legally reuse your code, even if it is publicly available e.g. on GitHub. Common open licenses for code are:
- CC0 (Public Domain) places no restrictions. Anyone can use, modify, and redistribute without attribution. Recommended for factual code where maximum reuse is the goal.
- MIT is a simple license that requires users to credit you when they reuse, modify, and redistribute your code.
- Apache 2.0 is a safer license (covering more legal cases) that requires users to credit you and state the changes you made to the code.
Learn more about open licenses for data and code in our code publishing tutorial or using the tool ‘Choose an open source license’.
To publish you code on Zenodo, we recommend to
- Push your clean repository to GitHub (see GitHub tutorial).
- Create an account on Zenodo.
- Link your GitHub account to Zenodo. Navigate to your profile > account settings > link external accounts > GitHub > authorize Zenodo to access your GitHub account > a list of your GitHub repositories should appear. Enable the repository by toggling the switch next to it; refresh the page to check to see if the visual indicator that the repository is connected appears
- Go to GitHub and create a release. Zenodo will automatically download a .zip-ball of each new release and register a DOI.
- Add DOI badge to your README. After your first release, a DOI badge that you can include in GitHub README will appear next to your repository in the your list of GitHub repositories on Zenodo. This allows others to easily find and cite your archived code
- Create new release when needed. If you make a new release, it will create a new version on Zenodo, under the same overall DOI, with a ‘sub-DOI’ to identify a specific version.
TipTip for research groups:
Create a Zenodo “community” for the team. After team members connect their repositories from their personal GitHub account to Zenodo, and archive releases with a DOI, these records can be added to a shared Zenodo community. A community provides a central space where all software and other research outputs produced by the group can be collected and displayed, making them easier to find, cite, and showcase at the team level.
4.3 Open Materials
4.3 Open Materials
Any material needed to reproduce or replicate your study should also be shared openly unless there are dual-use, patent, or privacy concerns.
For instance, you can share your:
- Share wet-lab protocols on e.g. protocols.io, see 2.1.1. Lab Protocols.
- Share survey text, instructions, or scoring sheets on e.g. OSF
We recommend to use a creative Common license such as CC.-BY 4.0 to allow reuse, modification and redistribution, while getting attribution, or one of its derivative (see tool to select a creative common license)
Repositories for physical research materials (e.g., biological samples, chemicals, specimens, hardware, or other tangible resources) are usually called biobanks, material repositories, or research infrastructure collections and are domain specific or specialized to one kind of material (e.g. DNA).
For instance, Addgene is a nonprofit plasmid repository deposited by thousands of research labs around the world, while ARIADNE’s mission is to create a sustainable infrastructure for archaeological data sharing across institutions and nations.
Regardless of your discipline:
- Use repositories that assign persistent identifiers for proper citation.
- Provide detailed metadata, including provenance, storage conditions, and usage restrictions.
- Check legal and ethical requirements (biosafety, export control, patient consent).
- Document links between materials and associated datasets or publications.
4.4 Open Access Articles
4.4 Open Access Articles
Publishing open access articles (i.e. which are free to readers) increases the visibility, citation, and impact of research by removing paywall barriers, enabling scholars, practitioners, and policymakers worldwide to access and build upon the work without restriction. It also accelerates knowledge dissemination and promotes equity in scholarship by providing institutions and researchers - especially in low-resource settings - free and immediate access to scientific findings.
They are several pathways to make your your articles free to read, e.g.:
- Diamond Open Access: journals that provide immediate open access without charging authors any Article Processing Charges (APCs), as publication costs are covered by institutions, consortia, or public funding. Visit the Directory of Open Access Journals (DOAJ) to find them.
- Gold Open Access: the publication of the final version of record as immediately open access on the publisher’s platform, against payment of an Article Processing Charges (APCs) by the authors.
- Green Open Access: self-archiving of a preprint or postprint in an institutional or disciplinary repository, either immediately or after an embargo period imposed by the publisher, without cost to the author. Visit the Open Policy Finder to know whether and where your publishers allow you to publish preprint or postprints.
Depending on the contract negotiated by the University and each publisher (see 4.4.2. Contract with Publishers), the payment of APCs can also be requested by publishers regardless of the article’s accessibility status.
NoteDefinitions
preprint: article, book chapter, book, or other scholarly work that is deposited in a repository with unrestricted access (i.e. available to the public to view online, or download, without registration, payment, or approval) ahead of peer review. Equivalent terms used in some disciplines are ‘working paper’ and ‘unpublished manuscript’.
postprint: accepted version of an article, book chapter, book, or other scholarly work that is released by the author(s) on a repository with unrestricted access (i.e. available to the public to view online, or download, without registration, payment, or approval)
Until 2024, authors publishing in legacy (subscription-based) journals were required to pay an Article Processing Charge (APC) to make their work immediately open access upon publication, the model commonly referred to as ‘gold open access’. To avoid these fees while still ensuring public accessibility, authors were encouraged to disseminate a preprint and/or postprint, or to deposit the publisher’s version in an institutional repository after the embargo period had expired. These procedures, which are free to the authors, are collectively known as ‘green open access’.
Since 2025, however, at LMU Munich and other universities that are part of the DEAL Konsortium in Germany, the agreements with Elsevier, Wiley, and Springer Nature, stipulate that the authors publishing in hybrid journals (i.e., journals offering both subscription-based and open access options) incur an Article Processing Charge (APC) regardless of whether the article is published closed or open access. Consequently, authors who elect to publish in these venues and pay the APC are generally advised to opt for immediate open access through the publisher. Although preprinting remains possible and may expedite dissemination, it no longer constitutes a cost-free alternative for hybrid journals operating under these uniform APC conditions.
The current contract conditions for LMU Munich can be accessed on the University Library Publication Fees Webpage (in german). To get support with Article Processing Charges and open access policies, contact the University Library Open Access team.
To increase the accessibility and impact of your article we recommend you to:
Check what your target journal’s open access policies are. Jisc’ Open Policy Finder provides clear information about whether you are allowed to archive various versions of manuscripts. For instance, your target journal may, or may not, allow you to deposit:
- the version submitted to the journal (preprint)
- the accepted manuscript version (postprint)
- the published version
- on a specific location (e.g. preprint repository, institutional repository, funders repository, author’s personal website)
- after a specific amount of time (e.g. 6 or 12-month embargo)
- under a specific license (e.g. CC.BY. (recommended for maximum reuse), CC.BY-NC-ND)
Disclose the state of peer review on each preprint version. Use watermarks such as ‘Draft’ and ‘Revised Draft’ for your preprint, with a statement on the title page highlighting that the work has not been peer reviewed. For postprints, indicate that the version was accepted through peer review, and link to the DOI of the official journal version.
Get a DOI for each public version of your manuscript. When updating your preprint through the revision cycle, get a citable DOI (as provided by the repository).
Maintain as much rights to your own work as possible.
- Prior to submitting your manuscript, deposit your manuscript’s conceptual figures on a repository (e.g. Zenodo, OSF), under an open license (e.g. CC.BY 4.0 allowing reuse and modification while requiring authors to get credited), and get a DOI for it to cite your own figure in your manuscript. This way, you (and possibly other researchers), can reuse them in future manuscripts without asking permission from the publisher, by indicating the DOI and license in the figure legend.
- When given the choice, request your publisher to publish your manuscript under a CC.BY 4.0 license, so your right to distribution is included. It is possible that your publisher will request a CC.BY. NC (Non-Commercial) license which means you cannot deposit it on commercial platforms, but you would typically still be allowed to deposit it on preprint servers or institutional repositories (see Jisc’ Open Policy Finder for the policy of your specific journal)
In practice, we recommend to follow the process of version releases illustrated in the figure, starting with a manuscript draft, should you wish to obtain feedback from your community, or preprinting the submitted version, should you want to e.g. accelerate dissemination of findings that are unlikely to change during revision, or postprinting the accepted version to have a free peer-reviewed version available to anyone.
To get support for Open Access LMU, the LMU Munich institutional repository for articles and books, contact the University Library Open Access team.
TOOLS & RESOURCES
4.5 Attributions & Persistent Identifiers
4.5 Attributions & Persistent Identifiers
All research outputs and their specific versions should be linked to their authors, organisations, and funders through persistent identifiers.
Authorship
According to §14 of the LMU Guidelines for Safeguarding Good Scientific Practice, an author must:
- make a genuine, verifiable contribution to the content of a scientific publication, data, or software, and not solely have a managerial or supervisory position in the project;
- agree to the final version of the work to be published and bear joint responsibility for the publication unless explicitly stated otherwise.
We recommend to start discussions on authorship, roles, and responsibilities as early as possible. First discussions can for instance take place at the end of 1. Plan & Design, e.g. during the presentation of the study plan to the research group (see Plan & Design Checklist).
Contributorship
- Use the Contributor Role Taxonomy (CRediT) to increase transparency and accountability, and acknowledge what contribution to a research project each person has made: ‘Conceptualization’, ‘Data curation’, ‘Formal analysis’, ‘Funding acquisition’, ‘Investigation’, ‘Methodology’, ‘Project administration’, ‘Resources’, ‘Software’, ‘Supervision’, ‘Validation’, ‘Visualization’, ‘Writing—original draft’, and ‘Writing—review & editing’.
- Include the CRediT statement in the acknowledgement section of your manuscript if your publisher is not a formal CRediT adopter and does not otherwise prompt you upon submission of your article.
- Use the Method Reporting with Initials for Transparency (MeRIT) when relevant. This consist in adding initials to the Methods section, identifying with greater transparency who did what when several team members contributed to e.g. data curation or software.
ORCID
- Create an Open Researcher and Contributor ID (ORCID), a free, unique, persistent identifier for individuals, to distinguish yourself and claim credit for your work automatically, no matter how many people have your same (or similar) name.
- Associate your ORCID to all your research outputs. The vast majority of publishers, funders, and data and code repositories prompt for authors and contributors’ ORCID. You can also sign in to many academic and institutional services with your ORCID (e.g. Zenodo, OSF, RDMO).
- Disclose your institutional affiliations and funders as part of the metadata of all your research outputs. To be machine-readable and automatically connected to people’s profile or their organization, this must include the official name of the organization and ideally (one of) its persistent identifier.
- Use your institution and funders’ ROR. The Research Organization Registry (ROR) is a global, community-led registry of open persistent identifiers for research and funding organizations.
Note
The official names of LMU Munich are Ludwig-Maximilians-Universität München in german, and LMU Munich in english. This university’s ROR ID is https://ror.org/05591te55.
LMU Munich is mostly funded by the German Research Foundation, whose ROR ID is https://ror.org/018mejw64
The LMU Open Science Center is one of the many child organizations of LMU Munich; it’s ROR ID is https://ror.org/029e6qe04. The funder of this handbook’s project is the Volkswagen Foundation, https://ror.org/03bsmfz84.
- Request a Digital Object Identifiers (DOI) for each of your research outputs (data, code, preprint, preregistration)
- you automatically get a DOI from professional repository for outputs you make public
- for a code repository you first want to keep private on e.g. Zenodo, you can request a DOI (by ticking a box) to reserve a DOI link and already cite it in your manuscript.
- for a preregistration you first embargoed (i.e. kept private for a set period of time) on e.g. the OSF, you must first make it public to obtain a DOI to include in your manuscript.
- Add persistent identifiers of connected outputs in their reciprocal metadata to connect all parts of a project.
- include the DOI of your data, code, and preregistration in your manuscript and in the metadata field provided by your publisher if prompted.
- add the DOI of your code repository in the metadata of your published data and reciprocally, either in the description text or in the metadata fields provided by repositories like Zenodo.
- Add the persistent identifier of a published version of an output to all public versions of that output