👷 🧑🏻‍🤝‍🧑🏻 ☪️ Comercialización de mejoras de software libre bajo licencias Copyleft 😟 ⛹🏽 🔺

Planeé comenzar este artículo con información de que siempre hay dificultades significativas al tratar de comercializar las mejoras del software libre y citar la situación con el proyecto Redis como un ejemplo ilustrativo.

Pero luego me di cuenta de que la situación con Redis ( Redis está cambiando su licencia nuevamente ) como ejemplo no es muy adecuada. Y no solo por la mezcla infernal de varias licencias utilizadas en el proyecto, sino también por la confusión adicional que surge de la interpretación de los términos de código abierto y software libre.

Además, a juzgar por los resultados del trabajo de los proveedores de la nube para el último trimestre de 2019, y este negocio se basa principalmente en software libre, esto cierra la cuestión de al menos una forma realmente efectiva de comercializar software libre.

Después de todo, los números hablan por sí mismos. Los ingresos totales de los proveedores de la nube para el último trimestre de 2019 excedieron los $ 30 mil millones . Entre ellos, el líder es Amazon (32.4% del mercado), Microsoft Azure es casi la mitad (17.6%), seguido de Google Cloud (6%) y Alibaba Cloud (5.4%).

Sin embargo, para las empresas más pequeñas, tal negocio generalmente no se puede lograr. Por lo tanto, para ellos, el tema de la comercialización de mejoras de software libre bajo las licencias de Copyleft (como la GPL) puede ser bastante relevante.

Les traigo a su atención una forma práctica de comercializar modificaciones de software libre bajo las licencias de Copyleft, incluso con respecto a la legislación de la Federación de Rusia.

¿De qué licencias estamos hablando?

Este artículo trata sobre el software libre, en el sentido que la Free Software Foundation (FSF) le pone.

Sus principios están formulados por 4 libertades:

Libertad 0: ejecuta el programa para cualquier propósito.
Libertad 1: Estudiar el programa y cambiar su trabajo para que se ajuste a sus necesidades. *
Libertad 2: distribuir copias del programa. **
3: .*

*) Las libertades 1 y 3 requieren la disponibilidad del código fuente del programa, que debe estar disponible para su estudio y cambio. Es precisamente por esto que a menudo surge la confusión, ya que Open Source precisamente significa código fuente abierto, mientras que el concepto de Software Libre se refiere a los derechos de software, y para los cuales la presencia del código fuente de un programa es obligatoria, pero no el único requisito.

**) Freedom 2 permite la distribución gratuita del programa y debido a esto también existe confusión con el término Freeware , que solo significa un programa gratuito, pero puede referirse a cualquier programa, no necesariamente gratuito.

Por lo tanto, la idea del software libre es proporcionar al usuario la información adecuada.derechos sobre el software que el titular de los derechos de autor garantiza a cada usuario.

Un principio similar se llama Copyleft , que requiere la preservación de las libertades en trabajos derivados y prohíbe su reducción en comparación con el producto de software original.

En lenguaje legal, está formulado en la GPL (GNU General Public License), que requiere que el autor de un trabajo derivado conserve (no reduzca) las libertades en comparación con el programa original.

Es debido a la preservación de las libertades originales que tales licencias se llaman "adhesivas" o "virales".

¿Cuál es el problema de comercializar la GPL?

Problema 1

El principal problema con la comercialización de software bajo la GPL es que el primer cliente que recibe el programa o sus fuentes tiene el derecho de convertirse en el distribuidor de este programa y el desarrollador no puede detenerlo de ninguna manera: www.gnu.org/licenses/gpl-faq. ru.html # DoesTheGPLAllowNDA , www.gnu.org/licenses/gpl-faq.ru.html#DoesTheGPLAllowModNDA

Y dado que cualquier usuario oficial puede obtener la fuente, cualquier usuario puede publicar el software recibido o su fuente para acceso libre y gratuito Eso sin duda creará problemas con el retorno de las finanzas invertidas en el desarrollo de dicho producto de software.

No hay tal problema para los permisoslicencias como BSD, MIT o Apache. Permiten la reducción de libertades en productos derivados, por lo que es suficiente cambiar la licencia gratuita original a propietaria (propietaria) y no abrir el código fuente del software al usuario (cliente).

Problema 2

La segunda dificultad para construir un negocio en software de código abierto con licencias virales es que la total libertad para administrar los derechos de un producto de software pertenece solo a su propietario, lo cual es completamente lógico.

Y solo el titular de los derechos exclusivos del programa puede usar el modelo de licencia dual, que implica una licencia comercial "no libre" para software para clientes comerciales y una licencia compatible con GPL para representantes de la comunidad.

Pero dicho esquema no es adecuado para proyectos secundarios (los llamados "tenedores") o proyectos dedicados a crear módulos adicionales que deberían funcionar junto con el código GPL y, por lo tanto, también deben tener una licencia compatible con GPL.

El método de comercialización de mejoras de software libre que se propone a continuación le permite sortear los problemas descritos anteriormente. Es adecuado para:

Licencias virales como la GPL.
Comercialización de mejoras de software cuando el desarrollador no posee derechos exclusivos sobre el producto de software.

¿Cuándo aparece el valor comercial?

Según las explicaciones de la Free Software Foundation (FSF), la GPL permite la distribución paga de los programas www.gnu.org/philosophy/selling.html , www.gnu.org/licenses/gpl-faq.ru.html#DoesTheGPLAllowMoney .

Al mismo tiempo, la GPL no impone al desarrollador la obligación de publicar sus mejoras al público en general: www.gnu.org/licenses/gpl-faq.html#GPLRequireSourcePostedPublic

Esto hace posible teóricamente un modelo de negocio de retorno de la inversión en software de código abierto debido a su distribución paga, cuando se crea valor comercial debido a la propiedad exclusiva del producto de software, más precisamente, al limitar la disponibilidad de su versión actual para una amplia gama de usuarios. De hecho, esto es una repetición del modelo comercial de software propietario basado en la propiedad exclusiva del recurso.

En otras palabras, debe hacer un cambio temporal en el segundo retraso entre el derecho del cliente a una mayor distribución de la transferencia de software al cliente y el advenimiento del software adquirido bajo la licencia GPL.

De hecho, es BP es,Restricción variable de la libertad de distribución, como de lo contrario, simplemente "la economía no funcionará", porque la condición para la presencia de demanda del producto será la falta de disponibilidad de análogos más baratos (o gratuitos) en el mercado.

Crear un temporal en el segundo retraso en función de las condiciones de la licencia

La primera opción es la creación de temporal sobre el segundo de retraso entre la transferencia de software para el cliente y el aspecto de su derecho a una mayor expansión de las mejoras adquiridas, basado en la creación de las condiciones necesarias de acuerdo a la interpretación de la cláusula de la GPL por parte de la Fundación para el Software Libre.

Esto es posible al convertir al comprador del producto de software en un (co) desarrollador: www.gnu.org/licenses/gpl-faq.html#DevelopChangesUnderNDA

Para hacer esto, es suficiente firmar un acuerdo con el comprador (cliente) sobre su trabajo, por ejemplo, como un probador de productividad datos, que deben incluir un acuerdo sobre la no distribución de copias del producto de software durante la vigencia de este contrato.

El esquema de interacción del desarrollador con el usuario:

«» .
(-) , , .
FSF . www.gnu.org/licenses/gpl-faq.html#DevelopChangesUnderNDA
.

GPL

La segunda forma de crear un tiempo en el segundo rezago entre la transmisión del cliente y la aparición del software en su derecho legítimo a su posterior propagación es posible debido al hecho de que los derechos del programa creados por orden de la computadora y, en consecuencia, la posibilidad de su posterior propagación allí en el cliente solo después de completarse cumplimiento de sus obligaciones por las partes del acuerdo sobre la finalización del software

El esquema de interacción con la empresa usuaria:

El desarrollador celebra un acuerdo con la empresa usuaria para finalizar el producto original relacionado con el software libre con una licencia de virus.
, ( 712. ; 1296. , ).
() - . , .. .
, .

?

Estos esquemas de trabajo fueron propuestos a la comunidad en 2014 en varias conferencias, pero antes de eso, los autores contactaron a Richard Stallman para conocer su opinión sobre estos métodos de comercialización de la GPL.

Por supuesto, no estaba entusiasmado, porque en este esquema existe una violación temporal, pero aún así, de las libertades originales: Freedom 2: distribuir copias del programa y Freedom 3: mejorar el programa y publicar estos cambios o todo el código del programa.

Sin embargo, tenía que aceptar que el primer método con un (co) desarrollador no violaría la GPL, a menos que el trabajo del usuario fuera ficticio. En otras palabras, el usuario realmente debe trabajar de acuerdo con las obligaciones contractuales y este trabajo debe ser realmente pagado.

En el segundo método, Richard Stallman cree que el esquema viola la GPLv3, que establece explícitamente que la licencia tiene prioridad sobre las obligaciones contractuales. Sin embargo, los abogados no están de acuerdo con esto, ya que la licencia "comienza a funcionar" solo después de la transferencia de derechos al resultado del trabajo. Por lo tanto, quien resulte ser el resultado de los derechos solo puede mostrar una práctica judicial real.

Finalmente

La creación de cualquier restricción en la distribución de Software Libre siempre es percibida como "hostil" por la comunidad, incluso si estas restricciones cumplen completamente con los términos de la licencia, no contradicen la ley y ayudan al desarrollo de proyectos gratuitos.

Por otro lado, la falta de una forma normal de comercializar código bajo la GPL limita significativamente la atracción de inversiones y su desarrollo, porque Los métodos normales de comercialización están disponibles solo para los propietarios de los derechos exclusivos del código fuente.

Como resultado, los desarrolladores se ven obligados a participar en negocios no centrales o utilizar las técnicas de omisión de licencia GPL para trabajar con un modelo comercial de software propietario basado en la propiedad exclusiva del objeto de derechos de autor.

Espero que este material ayude a alguien a construir un negocio utilizando software libre.

Autores: Alexander Ryabikov, Sergey Sereda, Ph.D.

Basado en materiales de la conferencia:
Open Source Summit
LVEE 2014

Me complacería recibir comentarios sobre su experiencia en la comercialización de software libre con licencias de Copyleft.

Comercialización de mejoras de software libre bajo licencias Copyleft