Sistema de soporte sobre código abierto con freelance — ¿de quién son los derechos?

Ojo con el tema de la AGPL. Si escribe código directamente dentro del núcleo AGPL, ese código también puede quedar bajo AGPL. Si mandas a diseñar los módulos adicionales como un servicio independiente que se comunique con el núcleo solo a través de una API aislada, vas a tener la posición mucho más cómoda ante cualquier disputa de propiedad.

Hace dos años mandamos a hacer un sistema de soporte por 6.000 dólares en un proyecto similar. Como no dejamos clara la propiedad del código en el contrato, el dev nos pidió 2.000 dólares extra por una simple actualización de API. Si no dejas la cesión de derechos atada desde el principio, ese sistema te termina saliendo más caro en unos años que el software comercial.

Abre ya mismo un repo privado en Git a nombre de tu empresa y dale solo permisos de escritura al programador. Que el código vaya cayendo a tu servidor todos los días. Ni se te ocurra permitir que diga "lo tengo en mi compu cuando termine subo todo junto".

¿El desarrollador está programando un panel de cero o está integrando librerías que ya tenía de otros clientes? Si usa herramientas genéricas que hizo antes, es normal que dé una licencia sobre eso; pero los derechos de lo que se programe de cero con los 7.500 dólares que estás pagando vos tienen que ser 100% tuyos.

Según la doctrina de "Work Made for Hire" aplicable en el sistema legal estadounidense, la propiedad intelectual creada por contratistas independientes no pasa automáticamente al empleador sin un contrato escrito de cesión explícito. Incluir una cláusula de transferencia de propiedad explícita en el contrato es una necesidad legal para evitar la pérdida de derechos.

no le dejes los derechos del código a medida al chabón si lo estás pagando vos. bueno mañana le vende el mismo módulo a tu competencia y encima te quedás enganchado teniendo que llamarlo a él cada vez q quieras meter una línea de código.

La regla de oro al trabajar con desarrolladores de software es esta: el día que termina el trabajo, aunque ese programador desaparezca por completo, tenés que haber recibido la documentación y accesos necesarios para que otro ingeniero pueda hacerse cargo del sistema en 24 horas. No firmes ningún contrato que no te dé esa garantía.

edit: he corregido unas erratas.

Le agradecería que compartiera el resultado.

Aquí hay una trampa no puedo dejar de mencionarla. Si intentas cambiarlo todo a la vez, nada termina de asentarse.

Si escribís el resultado aquí también servirá de ayuda a otros.

Gracias, esa era la respuesta que buscaba. Si decidimos sin medir, siempre acabamos en el mismo punto.

Lo dejo como nota, por si sirve.

Han surgido tres opiniones distintas, todas se complementan. El error cometido por titularidad de código abierto suele ser reversible, pero caro.

¿Buscas un socio o un cofundador? Son cosas distintas. Eso es todo, disculpa si me he extendido demasiado.

Estoy de acuerdo a medias, en parte no. Una sociedad no es una decisión que se tome sin trabajar juntos antes.

Eso es todo, disculpa si me he extendido demasiado.

Han surgido tres opiniones distintas todas se complementan. o sea antes de hablar de acciones hagan un pequeño proyecto trimestral así se ven mutuamente.

Ánimo.

Yo también estaba pensando en lo mismo. Lo único que separa la amistad de la sociedad es un contrato escrito.

Muchas gracias lo probaré hoy.

A nosotros también nos pasa. Tomar notas durante dos semanas da mejores resultados que estimar seis meses.

Por supuesto, cambia si tu situación es diferente.

estoy de acuerdo.

Gracias por escribir esto, es lo correcto. Lo único que separa la amistad de la sociedad es un contrato escrito.

Lo dejo como nota, por si sirve.