Cómo y cuándo citar código de MATLAB File Exchange

¿Cuáles son las reglas o la etiqueta para citar envíos de intercambio de archivos de MATLAB en publicaciones en papel?

Hay diferentes escenarios en los que tengo curiosidad por saber qué es lo mejor:

  1. La presentación de FEX es claramente un código de un documento escrito por la misma persona.
  2. El código es de un artículo, pero el autor del código no es el mismo autor que el artículo.
  3. El código es una buena herramienta, pero no tiene citas disponibles. Por ejemplo inpaint_nans, una buena herramienta para completar los datos "faltantes".
  4. Código que es una buena herramienta, alguien lo codificó, pero es poco esfuerzo reescribirlo ya que no es una herramienta compleja. Aún así, alguien lo escribe y, time==gold!
  5. Código que es una buena herramienta, requiere poco esfuerzo para reescribir, pero su código hace referencia a más de un documento. Por ejemplo 3D Shepp-Logan Phantom, hace referencia a 2 artículos y es una función breve.

MATLAB usa la licencia BSD en FEX, lo que significa que todo el software se puede usar y redistribuir siempre que se mantengan los derechos de autor y se mantenga el descargo de responsabilidad.

Esto significa que, legalmente, uno puede simplemente copiar y pegar el código y usarlo sin preocupaciones, siempre que se conserve el archivo de licencia. Pero al margen de la ley, ¿cómo se debe actuar en los casos mencionados?

Creo que esto se puede generalizar a "¿cómo y cuándo citar paquetes externos en una publicación"?
@Davidmh no realmente, ya que no todo el software funciona de la misma manera. Si estaba usando bibliotecas de python o paquetes R, no tenía preguntas.
¿ En qué se diferenciaría esta biblioteca de Python de inpaint_nans ?
De hecho, MATLAB FEX tiene una política escrita al respecto: blogs.mathworks.com/community/2010/12/13/…
@Davidmh sobre la política de MATLAB: mi pregunta es principalmente cuestionar si ese es siempre el enfoque correcto. Para la sacudida de un ejemplo, supongamos que quiero trazar cubos y uso plotcubede FEX. Esta función es ridículamente simple y "copiable". Si tuviera que escribir un artículo, estoy bastante seguro de que no haría referencia a FEX, ni los revisores estarían de acuerdo en una referencia a eso. Por lo tanto, mi opción sería probablemente escribir la mía (o evitar una reverencia). Pero esto es una lástima, porque alguien hizo el esfuerzo de escribir una función, no importa su simplicidad.

Respuestas (1)

Esta respuesta es de mi propia experiencia personal en la academia y puede o no ser estrictamente SOP, sin embargo, haré todo lo posible para responder. La mayor parte de esto es asumiendo que no ha alterado drásticamente el código original para su trabajo.

1) El envío de FEX es claramente un código de un documento escrito por la misma persona.

En este caso, comuníquese con la persona y hágale saber que está usando su código en su trabajo, cite su artículo y reconozca su código en el artículo. Esto es especialmente importante si su código fue fundamental para su trabajo.

2) El código es de un artículo, pero el autor del código no es el mismo autor que el artículo.

Cite el documento original, ya que proporciona la base del código que está utilizando. Póngase en contacto con el autor del código y reconózcalo.

3) El código es una buena herramienta, pero no tiene citas disponibles. Por ejemplo, inpaint_nans, buena herramienta para completar los datos "faltantes".

Este es un ejemplo de cuando el código no logra el objetivo de la investigación y, por lo tanto, no se mencionará en el documento. En este caso, puede reconocer al autor en su propio código/software, pero no en su trabajo.

4) Código que es una buena herramienta, alguien lo codificó, pero es poco esfuerzo reescribirlo ya que no es una herramienta compleja. Aún así, alguien lo escribe y, ¡tiempo == oro!

En este caso, probablemente ni siquiera valga la pena mencionarlo. Creo que todos en el intercambio entienden en algún momento que las contribuciones están diseñadas para promover la programación en sí mismas, no en sí mismas.

5) Código que es una buena herramienta, requiere poco esfuerzo para reescribir, pero su código hace referencia a más de un documento. Por ejemplo, 3D Shepp-Logan Phantom, hace referencia a 2 artículos y es una función breve.

En este ejemplo, este código está protegido por derechos de autor pero también se publica bajo GPL. Siga el procedimiento para GPL y en caso de duda, póngase en contacto con el autor. Si el código es fundamental para su trabajo, reconozca al autor al final de su artículo.

Resumen: si el código es fundamental para su tema de investigación, comuníquese con el autor. Si el código es una herramienta que 'llena los espacios en blanco', no es necesario que aparezca en el documento, pero debe mencionarse en su código.