I am working on a paper that involves some data and a piece of code to analyse the data.

I want the results of the analysis to be reproducible and the code to be open. This concept of "reproducible research" is essentially non-existent in my field, and potential journals have no guidelines regarding code. Also, I have no requirements as to how to publish my data and code by an institution or a funding agency.

The question is, how should I split the data and code between an open repository and and the article's supplementary files? What I currently have in mind is this:

  • The R code itself (i.e. the functions) will be posted in an online repository, such as figshare or github.
  • The data and its analysis will be posted, possibly using knitr, as a supplementary to the article.

What are the pros and cons of this approach? Is there something I should modify?

  • 3
    Why not a full duplication? This way you and the publisher are independently responsible, to certain extent, that the archives survive for posterity.
    – Davidmh
    Dec 17, 2014 at 10:28
  • 1
    Would this cause copyright issues, with the data and code published under difference licenses?
    – Gimelist
    Dec 17, 2014 at 10:55
  • @Michael You wrote the code yourself, right? If so, couldn't you publish CC or Apache C from GitHub, then cite it fully in the article? That way, the code is open-source protected, and your article, through your express permission, is able to duplicate it in full.
    – Compass
    Dec 17, 2014 at 13:59
  • 1
    FYI: you can publish the data and its analysis in GitHub as well, using GitHub pages.
    – Trylks
    Dec 17, 2014 at 17:08

1 Answer 1


A good way to think about the distinction is this:

  • Code and/or data in a supplementary is static, providing a snapshot that was guaranteed to work in a particular time and place. Archival presentation is assured, but it cannot be maintained and thus is likely to eventually become obsolete.

  • Code and/or data in an open repository is maintainable, and thus can be a "live" project that is updated and continues to be executable. For the same reason, however, it is also subject to possible destruction through a variety of means, including corrupting updates, deletion, and death of the repository. It will likely be fine for at least a few years, but multi-decade preservation is much more questionable.

However, as @Davidmh points out in the comments, there is generally no reason that you can't put everything in both places. Contrary to popular belief, there is nothing that prevents code from being distributed under more than one license. This is particularly true if you first post it in the open repository, then place a snapshot ("fork") of that repository in the supplementary information. Giving the journal control of a fork does not affect the original repository.

In many cases, however, the open license and the journal's copyright will not even interact with one another. Many journals will not claim any copyright over the code or data as code or data. Instead, the journal will claim only the right to distribute the bundle as a supplementary publication, which does not restrict the use of the information in that supplementary as data or code.

Bottom line: first put it in an open repository, then give the journal a snapshot as supplementary. In the extremely unlikely case that the journal won't take it, the open repository is still a fine place for it to stay.

  • 3
    It is important to check any copyright transfer agreement to make sure that you retain copyright to material that gets submitted to the journal's "supplementary" web site. Dec 17, 2014 at 15:52

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .