Los desarrolladores de software tienen la opción de elegir una licencia apropiada de acuerdo con los objetivos del trabajo.
¿Alguien puede dar algunas recomendaciones / experiencias sobre qué licencia elegir para el software?
¿Cuáles son las ventajas y desventajas de "regalar" todo el trabajo codificado como código fuente abierto?
¿Cómo tratar con actores industriales que desearían beneficiarse del código de investigación?
Respuestas:
La licencia que elija dependerá de qué tan libre quiera que sea su código, pero gratis significa diferentes cosas para diferentes personas.
Cuanto más permisiva sea una licencia, más personas podrán usarla, pero menos control tendrá sobre ella. Sin embargo, cuanto más restrictivo sea, más probable es que desanimes a las personas que usan tu software en primer lugar.
Existen varias licencias gratuitas y de código abierto, incluidas GPL <= 2, GPL 3 , LGPL , BSD , Eclipse , etc. Hay ventajas y desventajas para cada uno, así que lea sobre las restricciones que imponen al código y decida a quién quiere usar. Advertencia , cualquiera que elija, alguien se quejará: este es un territorio de guerra santa .
En general, es un acto de equilibrio sutil, y depende mucho del público objetivo de su software.
En mi opinión, tanto las licencias permisivas como las copyleft son apropiadas para el código científico; lo importante es que el código es de código abierto en primer lugar. Creo que la Ciencia debería ser abierta, y también el código utilizado para apoyar esa ciencia.
La idea de regalar su software es que si otros lo encuentran útil, lo usarán.
Si lo usan, encontrarán, informarán y, a menudo, corregirán errores, ahorrando su esfuerzo de hacer lo mismo.
Si les gusta y su software hace casi lo que quieren, podrían mejorar su software y contribuir con esas mejoras.
Eso es un montón de ifs sin embargo.
En primer lugar, si desea prohibir el uso comercial de su código, puede seleccionar una licencia sin una cláusula de reutilización comercial.
En segundo lugar, si cree que alguien podría usar su software para alimentar un servicio, sin distribuir el código a nadie más, entonces podría considerar la Affero GPL que conecta esa laguna de copyleft en particular.
En tercer lugar, puede hacer lo anterior y ofrecer una opción de doble licencia. Ofrecer licencias GPL o AGPL para descarga pública, y licencias comerciales por una tarifa, le brinda lo mejor de ambos mundos, y significa que incluso podría generar algunos ingresos de las ventas comerciales de su software que pueden ayudarlo a respaldar sus actividades científicas.
Tenga en cuenta que si va a hacer esto, ofrézcalo desde el principio; es probable que eso cause menos fricción a sus colaboradores de código abierto que comenzar a ofrecer licencias comerciales más adelante. Si su comunidad se vuelve popular, no quiere que las personas lo acusen de venderse si no fue directo sobre la posibilidad de explotación comercial más tarde. Idealmente, debe configurar un Acuerdo de licencia de contribuyente (CLA) adecuado antes de comenzar a aceptar contribuciones de terceros en su base de código.
Esta respuesta a esta pregunta también proporciona buena información sobre esta opción.
fuente
PETSc utiliza esta licencia , que es una forma menos restrictiva de BSD . La diferencia crucial de GPL, es que el software se puede usar comercialmente. Muchas personas tienen una objeción de principios al software cerrado, sin embargo, en mi experiencia, ningún negocio se acercará a su código si tiene una licencia GPL. Además, los usuarios industriales de PETSc han sido increíblemente valiosos. Tienden a tener problemas bastante complejos, que la mayoría de los académicos encontrarían más difíciles de lo que se justifica para una publicación. También han contribuido con una gran cantidad de código a PETSc, para que ingrese a la cadena de soporte normal. Aconsejaría contra cualquier licencia sin potencial de uso comercial, y de hecho abogaría por la licencia menos restrictiva posible (definitivamente podría grabar PETSc en un CD e intentar venderlo a los crédulos).
fuente
Utilizo GPL, principalmente debido al sentimiento del movimiento original de código abierto (y por lo tanto espero que ayude a su difusión). Además, esta es, paradójicamente, la mejor manera de proteger sus posibles ganancias de los capitalistas inmorales: como autor, siempre puede distribuir el código en una licencia diferente en paralelo y, por lo tanto, mantener una versión patentada para un uso comercial de marca blanca.
Sin embargo, esto también puede ser una desventaja: su fuente de financiación podría hacer una declaración de que todo su trabajo debe ser de dominio público, lo que va más allá de esta licencia.
De todos modos, lo más importante en ese tema es que cualquier licencia es mejor que ninguna, lo que desafortunadamente es bastante frecuente en el mundo del desarrollo científico, y simplemente odio todo eso / * Robado del programa de John Smith que nunca ha publicado * / o ¿Creo que vi esto en la publicación de Jane Smith sobre algún grupo en 1995 ... o tal vez en 1993?
fuente
Primero, los pros / contras de ir a código abierto:
Pro: más personas usarán su código, proporcionarán comentarios, correcciones, mejoras, etc. Terminará teniendo un mejor código y más personas que confían en él.
Con: si alguna vez quiere basar un negocio en su código, tiene menos opciones (pero todavía hay algunas, como vender servicios de consultoría)
En cuanto a elegir una licencia, procedería en el siguiente orden:
fuente
La mayor parte de mi investigación está financiada por fondos públicos, por lo que siento la obligación de utilizar la licencia menos restrictiva posible. Si otras personas en mi país están ayudando a pagar esta investigación, ¿realmente tengo derecho a decirles que no pueden integrar mi código en una fuente cerrada y / o distribución de software comercial? Espero que la mayoría de las personas que usan mi código sean científicos académicos, pero no tengo problemas filosóficos con las empresas que mejoran mi software al integrarlo con otro software (posiblemente comercial), ponerle una GUI, etc., para entregar un producto eso les ayuda a obtener ganancias.
Dicho esto, trato de usar licencias que requieren una atribución adecuada. Por ejemplo, si una empresa no doblar mi código en un producto comercial más grande, quiero que dejar claro que mi código se puede obtener libremente de mí. Pero aparte de eso, quiero establecer la menor cantidad posible de requisitos para los usuarios de mi código.
Para el desarrollo de software que no está financiado por el dinero de los contribuyentes, entiendo que otras licencias pueden ser más apropiadas.
fuente
Nadie lo ha explicado muy claramente, así que creo que vale la pena decir:
Algunas de las licencias de código abierto (en particular: la GPL) son "virales" en el sentido de que cada vez que se utiliza el código en un nuevo proyecto, el nuevo proyecto debe tener la misma licencia. Además, el código no puede vincularse (de cierta manera) a un código con licencia diferente.
Una consecuencia práctica es:
Si implementa un nuevo método numérico en C, la licencia no permitirá llamarlo desde un software tan común como MATLAB o Mathematica
Si implementa un nuevo algoritmo de procesamiento de imágenes, la licencia no permitirá hacer un complemento de Photoshop.
y así ...
Esto no solo evitará la reutilización comercial, sino también la reutilización conveniente por parte de otros académicos (si usan software cerrado), y si alguien construye sobre su código, evitará que entreguen su trabajo en un "hacer" "lo que quieras" con él.
Esto es algo que debe considerar antes de terminar de formular su licencia.
Lo expresé de esta manera porque conocí a personas (no muy familiarizadas con las licencias de código abierto) que no estaban al tanto de esto o que no lo habían considerado desde este ángulo.
(Esta es solo una opinión personal, pero creo que aplicar tales restricciones al trabajo que proviene de la academia (financiada con fondos públicos) no es apropiado. Por lo tanto, guardo el código o lo regalo.)
fuente
Independientemente de la licencia que elija, recuerde revisar detenidamente todos sus acuerdos de financiación para asegurarse de que no haya cláusulas en ellos que dicten o restrinjan cómo puede obtener la licencia de su software.
Sé que, en mi caso, muchos de mis proyectos se construyen a partir de varias capas de financiación, un poco aquí y un poco allá, y haciendo un seguimiento de cómo las personas que mantienen las luces encendidas y me permiten registrar mis cosas Las máquinas en funcionamiento son bastante complejas.
fuente
Para grandes cuerpos de código, busco una de las licencias descritas en las otras respuestas, y generalmente LGPL. Sin embargo, aunque por lo general no se recomienda para el software , para los pequeños guiones independientes que puedo enviar a un colega en la industria, a menudo opto por una licencia Creative Commons . Esto se debe a que tienden a ser más claros para la persona a la que le envío el código, lo que detiene cualquier problema potencial de malentendido. Esto me ha funcionado bien en el pasado.
fuente
A diferencia de la mayoría de las personas que responden aquí (que trabajan en organizaciones académicas y / o públicas), yo estoy trabajando en la esfera comercial.
Para mis productos, el código está cerrado y sigue habiendo importantes ventajas comerciales para hacerlo. Pero, por supuesto, hay otras formas de hacerlo (por ejemplo, como lo demuestra MySQL, entre otros). A menudo veo el enfoque de licencia comercial LGPL + para bibliotecas. Todavía tengo que usar dicha biblioteca en un sistema comercial, pero no la descartaría (hasta ahora solo he usado tales bibliotecas, por ejemplo, ALGLIB, en un nivel de I + D). Esto contrasta con un producto GPL, que podría usar internamente pero nunca usaría en un producto, principalmente debido a la naturaleza viral.
Cuando publico el código fuente (ejemplos de procedimientos, programas gratuitos, etc.), normalmente uso la licencia de Berkeley. Esto parece estar mucho más en el espíritu del código "libre", con atribución pero sin las cadenas y la política de la GPL. Quizás es por eso que (o licencias similares como la licencia MIT) son tan populares entre las universidades y las organizaciones públicas. El código fuente se entrega en el verdadero significado de 'gratis' (aquí hay algo de código, haga lo que quiera con él) pero el autor aún obtiene crédito / atribución.
fuente
Esta es una vieja pregunta, pero creo que vale la pena mencionar la Licencia Pública de Mozilla como un punto medio entre las licencias permisivas (BSD, MIT) y las licencias fuertes de copyleft (GPL). El código MPL se puede usar y redistribuir, pero el código MPL y cualquier modificación debe estar disponible. Por ejemplo, una compañía puede tomar un código MPL, hacer sus propias mejoras y distribuirlo en un paquete de software de código cerrado patentado, siempre que tengan disponible su versión modificada del código MPL original. No están obligados a liberar todo su propio código fuente, como lo harían con GPL.
Con la licencia BSD, existe el temor de que una corporación pueda tomar su código y mejorarlo sin devolverle estas contribuciones a usted o a la comunidad en general, bajo el argumento de que las mejoras que le otorgan le otorgan una ventaja competitiva. (La respuesta de Matt Knepley sugiere que no todos actúan de esta manera). Por otro lado, muchas personas podrían evitar el código GPL por completo. El MPL evita estos dos peligros potenciales, al menos en principio.
fuente