¿Cómo abordar la protección de mi código como asistente de investigación? ¿Debería preocuparme en primer lugar?

Soy un estudiante universitario que trabaja como asistente de investigación para una universidad, principalmente junto con un supervisor. Si bien tengo mi propio proyecto, mi trabajo aún me obliga a ayudar a mi supervisor en su investigación principal.

Recientemente, mi supervisor me asignó un pequeño proyecto de codificación que aceleraría el análisis de datos para experimentos, lo que nos beneficiaría a ambos. Con mucho gusto escribiría un código que simplifique su trabajo y el mío como lo es mi trabajo como su asistente. Sin embargo, estoy ansioso de que el código que he escrito se disperse y se use en todo el grupo de investigación. Este sentimiento se debe al hecho de que este proyecto de codificación surgió durante una conversación grupal en la que yo estaba, mi supervisor y otro investigador, quien señaló que dicho programa le ahorraría a él y a otros en el departamento tiempo y energía.

mis dos preguntas

¿Estoy justificado al sentir que el otro investigador me está explotando para escribir este código o estoy siendo egoísta?

¿Puedo proteger mi código de otros que lo usen sin crear tensión/enemigos?

Creo que mi energía y mi tiempo están reservados ante todo para el trabajo de mi supervisor y el mío propio. Este es un código que es relativamente fácil de escribir pero requiere mucho tiempo. Veo que si el otro investigador quiere tener este atajo en el análisis de datos, podría escribirlo él mismo. No me molestaría tanto si el proyecto viniera directamente de mi supervisor, ya que sería explícitamente para nosotros. Después, si se compartiera, no creo que estaría tan en conflicto. Más bien, el investigador que impulsó el proyecto está muy alejado de mi trabajo.

De lo contrario, si este código se difunde a otros investigadores, ¿cómo me aseguraría de recibir reconocimiento por él? Estoy buscando educación superior con este departamento y quiero mejorar mi reputación en las admisiones como miembro significativo del grupo de investigación. Quizás estoy siendo demasiado mezquino o egoísta con el impacto de este código. Esta es la primera vez que experimento escribir código para algo más allá del trabajo en clase y me gustaría abordar la situación de la manera correcta.

Editar

Gracias a todos por mostrarme que estaba siendo realmente idiota. La mayoría de estos comentarios tienen sentido o repartieron la bofetada en la cabeza que necesitaba. Ser capaz de mejorar otras industrias es un gran punto de mi interés en el campo, por lo que verlo desde afuera hizo obvio que estaba siendo un hipócrita. Me doy cuenta de que necesito cambiar mi forma de pensar si la investigación es algo que quiero seguir en el futuro. Mientras tanto, diversificaré el código tanto como sea posible para ayudar a tantos como pueda. Gracias a todos por sus comentarios.

¿Podría codificarlo para que solo funcione con sus datos y sus supervisores? Especialmente si lo proporciona en una versión compilada...
"Estoy ansioso de que el código que he escrito se disperse y se use en todo el grupo de investigación": ¿cuál sería la desventaja de que esto suceda?
AcademiaSE ( academia.stackexchange.com ) habría sido más adecuado para esta pregunta.
En tu edición: ¡no te rindas! Si bien su mentalidad inicial estaba fuera de lugar, era mejor que preguntara que continuar por el camino en el que estaba.

Respuestas (6)

¿Estoy justificado al sentir que el otro investigador me está explotando para escribir este código o estoy siendo egoísta?

No, no está siendo "explotado"; si lo entiendo correctamente, este código también lo beneficiaría a usted y a su supervisor. Que también beneficiará a otros es algo bueno .

¿Puedo proteger mi código de otros que lo usen sin crear tensión/enemigos?

Posiblemente puedas protegerlo, aunque esto es poco probable dado que trabajas para la universidad y es probable que ellos "posean" el trabajo de todos modos. Pero creo que incluso el intento de hacerlo probablemente causará "tensión/enemigos", como dices.

¿Por qué? Porque literalmente no tiene nada que ganar al ocultar este código a otros en el grupo de investigación; todo lo que hace es dañar a otros, lo que hará que parezca que esa fue su intención. Y eso es bastante probable que moleste a la gente.

Estoy buscando educación superior con este departamento y quiero mejorar mi reputación en las admisiones como miembro significativo del grupo de investigación.

Aquí es donde tienes las cosas al revés: si creas algo significativo en el contexto del grupo de investigación, quieres que otros se beneficien de ello. Cuantos más miembros se beneficien de él, mayor será el impacto. Cuantas más personas intentes ocultárselo, más gente tendrás que decirle a la gente (como los involucrados en las admisiones) que eres un niño egoísta que no sabe jugar en equipo.

Además, si el código es realmente tan útil, considere hacerlo ampliamente público. Entonces te arriesgas a ser conocido por ello, lo que no te perjudicará ni un poco en las entrevistas, tanto en la industria como en el mundo académico...
@FábioDias, si bien no estoy en desacuerdo con que podría ser un buen anuncio para las habilidades del OP, me sorprendería si no hubiera restricciones sobre si el OP realmente puede hacer eso con el código desarrollado durante el empleo.
En la industria sí, en la academia no tanto. De cualquier manera, debe ser aprobado por el supervisor/asesor...
@FábioDias sí, con el supervisor/asesor detrás de la idea, ¡es una historia completamente diferente!
No olvides poner tu nombre en algún lugar del resultado para que la gente reconozca que lo escribiste. Algo tan simple como User107622 Versión 1.01 Agosto 2019
@JanDoggen mejor, haz que sea realmente útil. Si tiene un git o cualquier instancia y el código está allí, incluya un enlace para que otros puedan contribuir. De lo contrario, incluya su dirección de correo electrónico con una nota como "Contacto en caso de errores o solicitudes de funciones". Del mismo modo, si hay una licencia asociada con el programa, inclúyala allí.
Estoy de acuerdo. Con toda probabilidad, el trabajo realizado como asistente de investigación para una universidad es propiedad de la universidad, no del asistente de investigación, como es habitual. No pagan para que los estudiantes puedan mejorar su perfil personal, sino para ganar dinero con la investigación o para beneficiar objetivos científicos (o ambos).
Si se trata de una pieza de software más compleja y no solo de un montón de secuencias de comandos simples que todos los que tienen una inclinación por la automatización pueden armar, entonces hay una buena posibilidad de que realmente pueda obtener citas de todos los que lo usan.
En general, estoy de acuerdo con esta respuesta, pero solo me gustaría señalar que mantener algo beneficioso para uno mismo no es equivalente a lastimar a los demás.

Como esta es la primera vez que está "escribiendo código para algo más allá del trabajo de clase", creo que es importante aprender algunos de los principios básicos de lo que significa escribir software por dinero, ya que creo que una vez que los entienda, la respuesta a su las preguntas fluyen con bastante naturalidad.

Primer principio: cuando alguien te paga por escribir código, implica dos cosas: primero, que estás escribiendo algo para resolver un problema o llenar una necesidad que tiene; segundo, que son de su propiedad y pueden hacer lo que quieran con él. Este principio se conoce legalmente como Work-For-Hire en los Estados Unidos.

Segundo principio: el código que escribió no es especial: hay literalmente millones de personas que podrían haber producido el mismo código, o mejor, para resolver el mismo problema.

Si los junta, se dará cuenta de que, en primer lugar, no es su código (pertenece a su supervisor, al laboratorio, a la universidad o a quien sea) y que el código no es particularmente valioso (todas lo que vale es el costo de pagarle a alguien para que lo reescriba). Como su proyecto era un "pequeño proyecto de codificación" escrito por un asistente de investigación, el valor de reemplazo es bastante mínimo.

Entonces, ahora que ve que el código en sí tiene un valor limitado, debe comprender dónde agrega valor real al proceso (para que pueda aprender cómo agregar más valor y recibir más compensación a cambio).

Un desarrollador agrega valor a una organización al poder:

  1. Comprender correctamente el problema real que debe resolverse (ya que a menudo la organización/persona que solicita el software no tiene una comprensión clara y es necesario trabajar con ellos para refinarlo);
  2. Implemente una solución que sea estable y escalable, de modo que se dedique menos tiempo a corregir defectos y que la solución pueda funcionar con problemas cada vez más grandes;
  3. Implemente una solución que sea extensible, de modo que a medida que cambien las necesidades del propietario, o el propietario decida compartirla con otros, sea fácil agregar esas nuevas características. Esto permite que ese fragmento de código resuelva más de un problema.

Como su objetivo es "recibir reconocimiento" y "mejorar [su] reputación", y como esas son formas de compensación, debe concentrarse en agregar valor real.

Para agregar valor en su situación, debe abrazar a todos los usuarios potenciales. Como cada uno de ellos tendrá un problema visualmente diferente para resolver, ambos desarrollarán una experiencia en la resolución de este tipo de problemas (n.° 1) y producirán una pieza de software que puede resolver muchos problemas diferentes (n.° 3), incluidos los de usuarios que aún no ha identificado. Cada uno de ellos también ejercitará su código de manera diferente, lo que conducirá (con suerte) a un software que es más estable y escalable que si hubiera sido desarrollado para un solo usuario (#2).

Como desea continuar su educación con este departamento, imagine lo útil que sería para su solicitud si 2 o 3 (o más) investigadores describieran cómo produjo una aplicación que les ayudó a ahorrar una cantidad significativa de tiempo, cómo pudo rápidamente comprender su problema y traducirlo en una pieza de software que funcione y funcione. Eso parece algo valioso para que usted obtenga de este proceso.

"ahora que ve que el código en sí tiene un valor limitado, debe comprender dónde agrega valor real al proceso": excelente respuesta, ¡gracias!
"Segundo principio: el código que escribiste no es especial; hay literalmente millones de otras personas que podrían haber producido el mismo código, o mejor, para resolver el mismo problema". Boooo. Puso trabajo y energía en ello, eso no es inútil. También requiere habilidad práctica y conocimiento para escribir un buen código. Parece que subestimas el valor de un buen código.
@Andrew: tal vez no estaba claro. No quiero decir que el código no tenga valor, es solo que el valor del código es exactamente el costo de reescribirlo. Mi punto es que los desarrolladores nuevos piensan que están produciendo algo muy especial (porque es su bebé) y no se dan cuenta de que lo que están produciendo en realidad no es tan especial. Si a un desarrollador promedio le toma 1 mes producir, a un desarrollador promedio le tomará 1 mes reproducirse. Mi punto es que no es como un Picasso: es el trabajo de un artesano. Y esto no es un ataque. Yo mismo soy un desarrollador profesional.
@Andrew - (continuación). Como desarrollador profesional, debe aprender a desbloquear el valor que realmente aporta y comprender que está separado de la "máquina" que construye.
Estoy de acuerdo con su opinión, pero ¿los puntos 2 y 3 no prueban que el código en sí tiene valor? El código estable, escalable y extensible es más valioso que el código que no lo es. "el código no es particularmente valioso (todo lo que vale es el costo de pagarle a alguien para que lo reescriba)" parece una declaración un poco tonta, podría reducir cualquier producto a esto: "el automóvil no es particularmente valioso (todo lo que vale es el costo de pagarle a alguien para que lo fabrique)".
^ Exactamente. Y no soy nuevo, tal vez el OP lo sea. Los desarrolladores proporcionamos valor por lo que creamos, incluso si es promedio, pero especialmente si no lo es. Lo que realmente estás argumentando aquí es que no proporcionamos valor. "Cualquiera puede hacerlo": hablas de ello como si fuera chocolate caliente instantáneo. No, grandes franjas de personas no pueden hacerlo, es por eso que nos pagan una prima. Tal vez no lo seas, no lo sé. Pero ustedes sigan adelante y tomen todos los votos aunque estén equivocados.
@JShorthouse: el punto que estoy tratando de señalar es que una pieza de software es exactamente un producto fabricado, a diferencia de algo como un Picasso. Los desarrolladores nuevos tienden a pensar que están produciendo Picasso y no se dan cuenta de que solo están produciendo automóviles.
@Andrew: nunca dije "cualquiera puede hacerlo", dije que hay "millones" de personas que pueden hacerlo, lo cual es cierto: hay millones de desarrolladores de software en el mundo. Mi punto, que supongo que me pareció demasiado torpe, fue que el valor de una pieza de software no está en su existencia, sino en los problemas que resuelve. Para ser valioso como desarrollador de software, creo que debe ser valioso como solucionador de problemas.
Creo que estás haciendo esto demasiado blanco y negro, cuando en realidad está en algún punto intermedio. Sí, su principal valor como desarrollador es poder comprender y resolver problemas de manera eficiente, pero eso no significa que el código que produce no sea valioso en sí mismo.
@JShorthouse La redacción precisa en la respuesta es "el código no es particularmente valioso", no "el código no es valioso". El código no tiene un valor especial por el hecho de haber sido producido por un desarrollador específico. No tiene un valor intrínseco o especial: solo tiene valor porque resuelve un problema (que incluye la futura extensibilidad, la claridad de la arquitectura, etc.), y no es más valioso que el código escrito por un desarrollador diferente que resuelve los mismos problemas igualmente bien. , que no es difícil de conseguir. La redacción de la respuesta es precisa para todos los sentidos de la palabra "particular".
Dependiendo de lo que hizo OP, el extremo del n. ° 2 es "por qué no buscaron el código fuente abierto que ya existe y lo modificaron". Si bien los puntos son ciertos, creo que esto podría editarse mejor. Además, si bien el código podría valorarse considerando el costo de reescribirlo, también podríamos valorarlo de manera diferente: ¿cuánto tiempo/dinero se ahorra manteniéndolo frente a reescribirlo desde cero? ¿podríamos encontrar el código fuente abierto y modificarlo, ahorrando finalmente tiempo en la reescritura? y cuánto tiempo llevará volver a capacitar a los usuarios (también conocido como: tiempo de los usuarios, también conocido como: pago de los usuarios para volver a capacitarse)
Por supuesto, también diré que estos comentarios (incluido el primero) están debatiendo cómo mejorar una pequeña parte tangencial de una respuesta realmente sólida.

También soy un programador de investigación que trabaja en el mundo académico. Tenemos suerte de estar en un campo donde el intercambio de datos y métodos es la norma. Yo, todos mis compañeros, y apuesto a que usted también, nos hemos beneficiado de décadas de investigaciones anteriores que se han hecho públicas y están disponibles para nosotros. Impulsa el progreso científico.

Sin embargo, es perfectamente razonable querer algún reconocimiento por su trabajo. Sugeriría crear una cuenta de Github y publicar su trabajo allí, con un pequeño artículo sobre cómo usarlo. Hacer que su trabajo sea utilizado por otros investigadores será mucho mejor para su carrera que simplemente recibir una palmadita en la espalda de su IP. Se verá muy bien poder hablar sobre el impacto de una herramienta de análisis de datos que lanzó en las cartas de solicitud a las escuelas de posgrado.

Sugeriría que el OP obtenga la aprobación de su profesor antes de publicarlo públicamente, ya que esto podría considerarse IP de la Universidad. También puede ser una situación en la que publicarán el código, pero solo después de que se complete la investigación, por lo que el tiempo también puede ser un problema. Especialmente si están compitiendo por una subvención. A pesar de que eventualmente compartirán el código, no hay razón para darles a las agencias de la competencia una herramienta gratuita para ayudarlas a obtener la subvención, en lugar de usted.

No creo que puedas proteger tu código de tus compañeros. Las universidades normalmente tienen algunas cláusulas de propiedad intelectual bastante estrictas en sus contratos de trabajo. Pero esto también puede depender del país en el que se encuentre.

Pero al final creo que eres un empleado de la universidad y tu supervisor te ordenó que produjeras algo. Este algo al final probablemente pertenecerá a la universidad. Probablemente tendrá que enfrentarse al hecho de que algo creado por usted en lugar de su trabajo para otra persona no le pertenece.

Podría argumentar que esta tarea está fuera del alcance de su contrato, pero realmente no creo que esto funcione aquí y podría dañar seriamente la relación con su supervisor.

A menos que el código ya exista bajo alguna licencia y usted convenza a su supervisor para que use este código, no veo ninguna forma de proteger su código.

En primer lugar, si solo trabaja como RA por el dinero, no tiene nada de qué preocuparse porque su empleador es dueño de su código de todos modos, como se explica en profundidad en las respuestas anteriores.

Pero asumo que también está interesado en la investigación y tiene el deseo de construir una reputación como investigador. En este caso, es importante entender que la moneda principal en la comunidad investigadora es la reputación y la visibilidad. La coautoría y la presentación de trabajos de investigación es una excelente manera de mejorar su reputación académica, pero la publicación de un código fuente que sea útil y ampliamente utilizado es otra.

Es posible publicar su código bajo una licencia que obligue a otros a reconocerlo si usan su código, pero no recomiendo este curso porque antagoniza innecesariamente a sus usuarios y reduce la probabilidad de adopción. Poner su nombre en un comentario en la parte superior de los principales archivos fuente e incluir una nota amistosa en el código/LÉAME como "si usa este código, reconozca a la persona XXX y cite el artículo YYY". suele ser suficiente.

Por lo tanto, por defecto, ¡ debería querer que su código sea lo más difundido y utilizado posible!

Dicho esto, a veces hay buenas razones para mantener el código en privado:

  • su supervisor siente que publicar el código corre el riesgo de eliminar su investigación o la investigación de otros miembros de su laboratorio;
  • su supervisor quiere "extorsionar" a otros laboratorios por la coautoría de artículos o subvenciones a cambio de acceso al código (no apruebo este comportamiento, pero sucede);
  • la investigación está patrocinada por una empresa u organización gubernamental que requiere mantener el código en secreto;
  • el código contiene datos privados protegidos por HIPPA, FERPA, etc.;
  • su supervisor/universidad quiere patentar los algoritmos utilizados en el código, lo que en algunas jurisdicciones requiere limitar la divulgación pública hasta después de presentar la solicitud;
  • etc.

El resultado final: debe querer que su código sea utilizado por tantas personas como sea posible, pero hable con su supervisor sobre sus inquietudes y solicite permiso antes de publicar el código en un GitHub público o regalarlo a otros.

Además de los comentarios que solicitan coautoría/cita/agradecimiento en la parte superior del código fuente y/o en un archivo LÉAME, considere también imprimir ese mensaje exacto como parte de la salida. Si la salida textual del programa está destinada al consumo humano, stdoutestá bien; si es malo para el consumo de software posterior, escríbalo astderr

Debería estar contento de tener la oportunidad de incluir un proyecto de este tipo en su CV (currículum vitae); si lo usa, definitivamente será un tema de conversación para cualquier perspectiva laboral en el futuro cercano. En el gran esquema de las cosas, dentro de cinco años ni siquiera estarás pensando en el proyecto.

Para responder realmente a su pregunta, los proveedores protegen su código distribuyendo el archivo binario del código (por ejemplo, un archivo ejecutable), que no se puede interpretar en un editor de texto.

Para demostrar el punto, si el programa está escrito en Go y distribuye myProgram.go, su código se compartirá, si envía myProgram como un archivo ejecutable o exe de Unix, entonces no se puede interpretar.

Para Javascript, la ofusticación se puede hacer minificando su archivo. Esto presenta todas sus funciones y variables en un formato más difícil de leer. Ejemplo: "myFunctionToSendOutAnEmail()" se cambiaría a "a()". Los archivos JS minificados tienen la extensión myProgram.min.js en lugar de myProgram.js

Esto está totalmente en desacuerdo, no solo con todo el ámbito de la investigación académica, donde la necesidad de que los resultados sean replicables significa que el código se suele publicar en apoyo de los artículos, sino también con el hecho mismo de ser un empleado y parte de un equipo colaborativo . La institución puede decidir mantener algo internamente, pero ocultarlo a los compañeros de trabajo no es viable.
El propósito de mi respuesta no fue responder a la pregunta ética, sino a otro método para proteger su trabajo. No es mi obligación hacer que OP sea ético, pero puedo compartir el conocimiento para hacer algo poco ético.
El problema no es la ética, el problema es que su propuesta es totalmente inviable en la situación de la pregunta o algo parecido. La persona no es una empresa que interactúa con los clientes, es un empleado y colaborador de un equipo.
Eso no significa que no puedan distribuir binarios si quisieran, siempre y cuando los archivos del programa estén almacenados localmente en su máquina.
Parece que no tiene idea de cómo funciona un lugar de trabajo colaborativo o cómo funciona el desarrollo de software que no es de la edad de piedra. Ningún supervisor responsable permitiría que un empleado o miembro del equipo mantenga en secreto el código fuente crítico de aquellos con una necesidad real y probable de revisarlo, mantenerlo, extenderlo y preservarlo.
¿Tenía la impresión de que no estaba trabajando con otros desarrolladores? Pero era solo un analista que puede querer aprender software. Naturalmente, en cualquier equipo de desarrollo adecuado nunca harías esto