¿Cómo debo dividir mi código y datos entre un repositorio abierto y los archivos complementarios del artículo?

Estoy trabajando en un documento que involucra algunos datos y una pieza de código para analizar los datos.

Quiero que los resultados del análisis sean reproducibles y que el código sea abierto. Este concepto de "investigación reproducible" es esencialmente inexistente en mi campo, y las revistas potenciales no tienen pautas con respecto al código. Además, no tengo requisitos sobre cómo publicar mis datos y código por parte de una institución o agencia de financiación.

La pregunta es, ¿cómo debo dividir los datos y el código entre un repositorio abierto y los archivos complementarios del artículo? Lo que tengo en mente actualmente es esto:

  • El Rcódigo en sí ( es decir , las funciones) se publicará en un repositorio en línea, como figshare o github.
  • Los datos y su análisis se publicarán, posiblemente utilizando knitr, como complemento del artículo.

¿Cuáles son los pros y los contras de este enfoque? ¿Hay algo que deba modificar?

¿Por qué no una duplicación completa? De esta manera, usted y el editor son responsables de forma independiente, hasta cierto punto, de que los archivos sobrevivan para la posteridad.
¿Causaría esto problemas de derechos de autor, con los datos y el código publicados bajo diferentes licencias?
@Michael Escribiste el código tú mismo, ¿verdad? Si es así, ¿no podría publicar CC o Apache C desde GitHub y luego citarlo completamente en el artículo? De esa manera, el código está protegido como código abierto y su artículo, con su permiso expreso, puede duplicarlo en su totalidad.
FYI: también puede publicar los datos y su análisis en GitHub, utilizando las páginas de GitHub .

Respuestas (1)

Una buena manera de pensar en la distinción es esta:

  • El código y/o los datos en un complemento son estáticos, lo que proporciona una instantánea que se garantiza que funcionará en un momento y lugar determinados. La presentación de archivo está asegurada, pero no se puede mantener y, por lo tanto, es probable que eventualmente se vuelva obsoleta.

  • El código y/o los datos en un repositorio abierto se pueden mantener y, por lo tanto, pueden ser un proyecto "en vivo" que se actualiza y continúa siendo ejecutable. Sin embargo, por la misma razón, también está sujeto a una posible destrucción a través de una variedad de medios, que incluyen actualizaciones corruptas, eliminación y muerte del repositorio. Es probable que esté bien durante al menos algunos años, pero la conservación durante varias décadas es mucho más cuestionable.

Sin embargo, como señala @Davidmh en los comentarios, generalmente no hay razón para que no pueda poner todo en ambos lugares. Contrariamente a la creencia popular, no hay nada que impida que el código se distribuya bajo más de una licencia . Esto es particularmente cierto si primero lo publica en el repositorio abierto y luego coloca una instantánea ("bifurcación") de ese repositorio en la información complementaria. Darle a la revista el control de una bifurcación no afecta el repositorio original.

En muchos casos, sin embargo, la licencia abierta y los derechos de autor de la revista ni siquiera interactuarán entre sí. Muchas revistas no reclamarán ningún derecho de autor sobre el código o los datos como código o datos . En cambio, la revista solo reclamará el derecho de distribuir el paquete como publicación complementaria , lo que no restringe el uso de la información en ese complemento como datos o código.

En pocas palabras: primero colóquelo en un repositorio abierto, luego proporcione a la revista una instantánea como complemento. En el caso extremadamente improbable de que la revista no lo acepte, el depósito abierto sigue siendo un buen lugar para quedarse.

Es importante verificar cualquier acuerdo de transferencia de derechos de autor para asegurarse de conservar los derechos de autor del material que se envía al sitio web "suplementario" de la revista.