Probablemente conozca la lista de licencias de código abierto aprobadas oficialmente por el OSI. En particular, supongo que sería la GPL, MIT, [inserte su licencia favorita aquí].
Recientemente me encontré con un proyecto que, aunque era de código abierto (el creador hizo que todo el código fuente estuviera disponible), no era oficialmente de código abierto bajo una de esas licencias oficiales.
Lanzó la fuente, pero no prometió lanzar la fuente en el futuro.
Permitió sugerencias de modificación, pero no prometió aceptar parches y no permitió la distribución externa de versiones con parches externos.
Permitió el uso del software en proyectos comerciales o pagos, pero no permitió la venta del software en sí.
Supongo que podría llamarse "fuente disponible", no fuente abierta, ya que nos gusta pensar en ello.
Puedo ver por qué el equipo de administración de una empresa no querría hacer negocios con este software. No pueden bifurcarlo, no pueden venderlo, no pueden crear su propia versión del software y distribuirlo o venderlo.
¿Pero le importaría como parte de un equipo de ingeniería de software que solo está usando este software? Todavía puedo hacer mi trabajo con él, puedo usarlo en un proyecto por el que me pagan (pero no puedo vender el software en sí, que de todos modos no estoy en el negocio), y puedo realizar cambios en el código para que se comporte de manera diferente para mis necesidades (pero no puedo hacer públicas esas modificaciones), y si quiero que esas modificaciones estén oficialmente disponibles para otros, la aprobación depende del proyecto en sí y ellos eligen si para incorporarlos en un lanzamiento oficial o no.
Entonces, sabemos que una empresa que quiere basar su negocio en este software de "fuente disponible" no puede hacer eso, pero como alguien del equipo de ingeniería de software, ¿esas diferencias le importarían o parecerían menos relevantes?
Curioso lo que otros piensan de esto.
Respuestas:
Para los proyectos que habrían tenido que desarrollar desde cero la funcionalidad proporcionada por este software, es definitivamente una conveniencia no hacerlo.
Pero si un paquete de código abierto comparable sería mejor depende de otros factores:
Responder no a ninguno de estos factores indica que el OSS es una mejor opción.
La mayoría de las veces, el código en sí no es el factor determinante. Uno necesita examinar la imagen más grande.
Los proyectos OSS de SIDEBAR no pueden prometer legalmente que mantendrán abiertas futuras versiones o que habrá versiones futuras. Esa es una de las razones por las que tener una licencia abierta es tan ventajoso. Además, los proyectos OSS no están obligados a aceptar parches de los contribuyentes (particularmente sin una transferencia de propiedad o derechos).
fuente
La pregunta para esta y cualquier otra biblioteca externa es el mantenimiento .
¿Cuál es la vida útil de su aplicación y cuál es la vida útil aparente de esta biblioteca? El tuyo debería ser el más corto.
¿Quién hará las correcciones de errores para esta biblioteca? Como se ve a partir de aquí, su empresa debería asignar explícitamente recursos en el futuro para mantener este software, ya que no puede confiar en ningún otro error de reparación para usted. No puede compartir la carga de mantenimiento con nadie más ya que no puede compartir la fuente. ¿Desea buscar un error esquivo de condición de carrera en un código que no conoce?
Este pensamiento solo podría hacer que la biblioteca sea demasiado costosa para usar.
Esto podría ser irrelevante si la biblioteca es muy sólida y robusta y es fácil trabajar con ella en el nivel de origen, pero mi experiencia es que la presión de los verdaderos proyectos de código abierto simplemente mejora el código porque entonces tienden a hacerlo lo mejor posible.
Personalmente, pensaría con mucho cuidado si adoptaría este o cualquier otro código externo, ya que la razón por la que se usa el código de otras personas es que no tiene que lidiar con eso usted mismo . También piense en los futuros mantenedores: debe hacer simulacros de incendio cambiando el código en la biblioteca para ver si se puede hacer. Puede haber algunas sorpresas MUY desagradables aquí.
¿Está en libertad de discutir la biblioteca en cuestión?
fuente
Para ser honesto, no veo por qué el equipo de administración de una empresa tendría problemas al usar una biblioteca de "fuente disponible". En lo que respecta a la integración en su propio producto, solo pueden considerarlo como una biblioteca de código cerrado.
Para mí, como programador, no importa si una biblioteca es "fuente abierta" o "fuente disponible". Prefiero no hacer modificaciones locales a una biblioteca externa, porque eso significa una carga de mantenimiento adicional. No solo cuando se encuentran errores en mis modificaciones locales, sino también en integrar las modificaciones una y otra vez cuando sale una nueva versión de la biblioteca.
Las únicas situaciones en las que, en mi humilde opinión, la "fuente abierta" supera la licencia de "fuente disponible" descrita en la pregunta es cuando
fuente
Es por eso que la Free Software Foundation utiliza los términos 'gratis' o 'no libre' para describir el software. No se refieren al precio, sino a restricciones que se aplican al uso o distribución del software.
Parece que ha llegado a uno de los raros casos en los que tiene acceso completo al código fuente de algo, pero el software no es "Open Source" según la definición OSI .
Cualquiera de los términos tiene la capacidad de convertirse en un nombre inapropiado. Pagué $ 50 por mi primera copia de emacs (en cinta QIC), pero emacs es software libre . Tengo el código fuente de algunas aplicaciones propietarias que mi empresa usa internamente, pero no son de código abierto.
Lo que levanta la bandera roja más grande (al menos para mí) no es garantía de acceso al código fuente de futuras versiones. Si depende en gran medida de poder modificar esta herramienta, tendría cuidado. Incluso si tiene un acuerdo verbal con el proveedor de que siempre tendrá un código, a menos que esté en forma de contrato ... ese acuerdo nunca sucedió.
Como CTO, hago todo lo posible para garantizar que no dependamos de software no libre. He estado en el extremo malo del bloqueo de proveedores en varias ocasiones en el pasado, un error que me gusta evitar. Si bien utilizamos algunas cosas patentadas, nuestro negocio no sufriría dificultades indebidas si de repente no pudiéramos usarlo por más tiempo.
Me parece que estás construyendo cosas en torno a tener este software y acceder al código, por lo que te recomiendo obtener algo por escrito que diga que siempre tendrás acceso. ¿Qué sucede si se compra al vendedor?
fuente
Esto importa bastante. Principales problemas con el enfoque de "fuente disponible" que ha descrito:
Mi sugerencia: intente persuadir al creador para que libere el software bajo una licencia de código abierto. Eso debería ser ganar / ganar para todos: usted porque obtiene el software que desea bajo licencia de código abierto, el creador porque hacer que el proyecto de código abierto haga que el software sea mucho más exitoso a largo plazo.
fuente