Как мне разделить мой код и данные между открытым репозиторием и дополнительными файлами статьи?

Я работаю над документом, который включает в себя некоторые данные и фрагмент кода для анализа данных.

Я хочу, чтобы результаты анализа были воспроизводимыми, а код открытым. Эта концепция «воспроизводимого исследования» практически не существует в моей области, и потенциальные журналы не имеют рекомендаций относительно кода. Кроме того, у меня нет требований относительно публикации моих данных и кода учреждением или финансирующим агентством.

Вопрос в том, как мне разделить данные и код между открытым репозиторием и дополнительными файлами статьи? Что я сейчас имею в виду, так это:

  • Сам код R( то есть функции) будет размещен в онлайн-репозитории, таком как figshare или github.
  • Данные и их анализ будут размещены, возможно, с использованием knitr, в качестве дополнения к статье.

Каковы плюсы и минусы этого подхода? Есть ли что-то, что я должен изменить?

Почему не полное дублирование? Таким образом, вы и издатель в определенной степени несете независимую ответственность за то, чтобы архивы сохранились для потомков.
Не вызовет ли это проблемы с авторскими правами, если данные и код будут опубликованы под разными лицензиями?
@Michael Вы сами написали код, верно? Если да, то не могли бы вы опубликовать CC или Apache C с GitHub, а затем полностью процитировать их в статье? Таким образом, код защищен открытым исходным кодом, и ваша статья, с вашего явного разрешения, может полностью его воспроизвести.
К вашему сведению: вы также можете публиковать данные и их анализ в GitHub, используя страницы GitHub .

Ответы (1)

Хороший способ подумать о различии заключается в следующем:

  • Код и/или данные в дополнении являются статичными, предоставляя моментальный снимок, который гарантированно будет работать в определенное время и в определенном месте. Архивное представление гарантировано, но оно не может поддерживаться и, таким образом, может со временем устаревать.

  • Код и/или данные в открытом репозитории можно обслуживать, и, таким образом, это может быть «живой» проект, который обновляется и продолжает выполняться. Однако по той же причине он также может быть уничтожен различными способами, включая повреждение обновлений, удаление и смерть репозитория. Скорее всего, это будет нормально, по крайней мере, в течение нескольких лет, но многолетнее сохранение гораздо более сомнительно.

Однако, как отмечает @Davidmh в комментариях, обычно нет причин, по которым вы не можете поместить все в оба места. Вопреки распространенному мнению, ничто не препятствует распространению кода под более чем одной лицензией . Это особенно верно, если вы сначала размещаете его в открытом репозитории, а затем размещаете снимок («форк») этого репозитория в дополнительной информации. Предоставление журналу контроля над форком не влияет на исходный репозиторий.

Однако во многих случаях открытая лицензия и авторское право журнала даже не будут взаимодействовать друг с другом. Многие журналы не будут претендовать на какие-либо авторские права на код или данные как на код или данные . Вместо этого журнал будет претендовать только на право распространять пакет в качестве дополнительной публикации , что не ограничивает использование информации в этом дополнении в качестве данных или кода.

Итог: сначала поместите его в открытый репозиторий, затем дайте журналу снимок в качестве дополнительного. В крайне маловероятном случае, если журнал не примет его, открытый репозиторий все еще является прекрасным местом для его хранения.

Важно проверить любое соглашение о передаче авторских прав, чтобы убедиться, что вы сохраняете авторские права на материалы, которые отправляются на «дополнительный» веб-сайт журнала.