¿Razones para NO abrir código de fuente sin fines de lucro? [cerrado]

Soy un gran fanático del código fuente abierto. Creo que entiendo la mayoría de las ventajas de ir a código abierto. Soy un investigador estudiantil de ciencias, y tengo que trabajar con una cantidad sorprendente de software y código que no es de código abierto (o es propietario o no es público). Realmente no puedo ver una buena razón para esto, y puedo ver que el código, y las personas que lo usan, definitivamente se beneficiarían de ser más públicos (si no otra cosa, en ciencia es vital que sus resultados puedan replicarse si es necesario, y eso es mucho más difícil si otros no tienen acceso a su código).

Antes de salir y comenzar a hacer proselitismo, quiero saber: ¿hay algún buen argumento para no publicar públicamente un código sin fines de lucro y con una licencia compatible con OSI?

(Me doy cuenta de que hay algunas preguntas similares , pero la mayoría se enfoca en situaciones en las que el código se usa principalmente para ganar dinero, y no pude tener mucha relevancia en las respuestas).

Aclaración: por "sin fines de lucro", incluyo motivos de beneficios posteriores, como el reconocimiento de marca de la empresa matriz y las expectativas de beneficios de los inversores. En otras palabras, la pregunta se relaciona solo con el software para el cual NO existe un motivo de ganancia vinculado al software.

Debe tener en cuenta que el código abierto puede requerir un esfuerzo adicional.

Como ejemplo, en esta entrada del blog, el ingeniero de Sun / Oracle describe los esfuerzos que tuvieron que hacer al abrir su código: ¿Código abierto o Servicio de lavandería sucio?

A medida que nos preparamos para sumergirnos en el mundo del código abierto, una de las muchas actividades que están ocurriendo es la preparación del código para ser de código abierto. Hay algunas cosas obvias que deben hacerse. Por ejemplo, nuestro código fuente incluye una mezcla de código que hemos escrito y código que hemos licenciado de otros. Tendremos que separar este último y de código abierto solo las piezas de código apropiadas.

Otra actividad de preparación es "depurar" el código de información patentada, menciones de clientes particulares, desarrolladores, tecnologías, etc. Esto es un poco menos obvio, pero considere el siguiente ejemplo:

/\*
 \* HACK - insert a time delay here because the stupid Intertrode
 \* Technologies framebuffer driver will hang the system if we
 \* don't. Those guys over there must really be idiots.
 \*/

Si bien todo lo anterior puede ser cierto, probablemente tengamos una relación de algún tipo con Intertrode Tech y tener comentarios como este en el código podría dañar nuestro negocio de alguna manera y, por lo tanto, debería eliminarse. Podría decirse que no debería haber estado allí en primer lugar, pero ahora es el momento de sacarlo.

Otra parte de la actividad de "depuración" es eliminar la blasfemia y otras palabras "indeseables" ...

Tenga en cuenta que todos los cambios anteriores tuvieron que realizarse en el código que se ha considerado perfectamente correcto como código cerrado, lo que lo convierte en un esfuerzo adicional puro, por así decirlo.

Seguridad.

Por ejemplo, supongamos que crea un marco web y usted mismo lo usa.

Como proyecto sin fines de lucro, no ha tenido tiempo para dedicar a inspeccionar cada fragmento de código en busca de vulnerabilidad a un ataque u otro:

• CSRF
• XSS
• inyección SQL
• Fijación de la sesión
• Uso de bibliotecas de terceros con errores o incluso idiomas

Ahora, habiendo abierto el proyecto, permite que los ojos amigables contribuyan, pero también permite que los ojos maliciosos tengan una visión completa de su trabajo y, si encuentran un servidor que ejecuta su código, ha eliminado su capacidad de ocultar su imperfecciones en la oscuridad.

Por supuesto, esto puede no aplicarse al tipo de software en el que está trabajando; y como siempre, la oscuridad no es excusa para la pereza en la seguridad.

Sin embargo, al igual que descubrí en los dos niveles por los que pasé en el juego de capturar la bandera de Stripe , saber que el código es una de las formas más fáciles de encontrar vulnerabilidades (y a veces puede ser la única forma).

Una buena razón para no abrir el código fuente es que parte de su código puede estar protegido por derechos de autor. ¿Con qué frecuencia no busca en la web una solución rápida a un problema y simplemente toma el fragmento de código que encuentra?

Bueno, esos pueden tener derechos de autor y no sé si al autor le gustaría encontrar su código bajo una licencia diferente.

Debe tener cuidado con la forma en que elige su licencia para evitar posibles problemas de responsabilidad.

Un abogado puede ser una mejor persona para hablar sobre esto, pero la idea general es ¿qué sucede si alguien usa (o usa mal) la aplicación y causa algún daño? ¿Eres responsable? Obviamente, esto dependerá del tipo de software que esté escribiendo, pero siempre debe tener cuidado con lo que dice su licencia sobre su responsabilidad. Esto puede ser algo difícil de entender, por lo que puede ser más fácil simplemente no liberar el código fuente.

Advertencia: no soy un abogado .

Bueno, si es una organización sin fines de lucro y su propiedad intelectual está fuertemente ligada al código del software, entonces algunos pueden desear protegerlo para que no se reutilice comercialmente, o incluso se explote de forma abusiva para crear copias de su software.

Algunas otras razones, que probablemente están profundamente arraigadas en la primera, en realidad, son que, en su caso, gran parte de la investigación de alto nivel se realiza con fondos privados y, por lo general, los inversores quieren ver el ROI. Y hasta ahora, no todos los actores de la industria del software (o los recién llegados) han sido persuadidos por completo de la viabilidad del modelo de código abierto (muy probablemente por falta de conocimiento y comprensión de las licencias, o por el simple temor de que las licencias no prevengan la malicia usos y copias).

Además, estas compañías no quieren ser demandadas por aquellos que intentaron obtener ganancias a sus espaldas, y las licencias también se consideran una salvaguardia en este sentido, por una buena razón o no.

Puede que no lo parezca, pero quizás las organizaciones sin fines de lucro SON rentables para sus fundadores o inversores. Los beneficios simplemente no son directos. Por lo tanto, tienen un gran interés en que los PFN se fortalezcan y no sean derrotados por los competidores (a pesar de que a menudo tampoco pensarías en "competidores" en el mercado sin fines de lucro), y quieren preservar su IP, incluso si es a costa de no obtener más globos oculares gratuitos para revisar su código para encontrar problemas y mejorarlo desde el principio.

Tenga en cuenta también que las leyes de copyright difieren de un país a otro. Muchos países europeos consideran que las leyes de derechos de autor de EE. UU. Y el sistema de patentes de EE. UU. Están bastante estupefactos, por ejemplo, por lo que hay un trasfondo cultural y un peso que es difícil de eliminar.

Solo mis 2 centavos sobre el tema.

(He trabajado mucho con universidades, y recientemente en bioinformática y atención médica ... Es una pregunta recurrente para mí y mis colegas :))

Hay al menos dos tipos diferentes de código abierto.

Si su actitud es "aquí hay algo útil, ya terminé" (y eso resulta ser exacto), entonces hay pocas desventajas.

Por otro lado, si su actitud es "Estoy realmente emocionado y quiero que algunos usuarios reales ayuden a impulsar el desarrollo futuro", entonces piense con mucho cuidado. Tendrá que pasar tiempo apoyando a los usuarios, muchos de los cuales no tienen idea. Tendrá que considerar solicitudes conflictivas de características y mejoras. Le resultará cada vez más difícil realizar cambios para preservar la compatibilidad con versiones anteriores.