Existen muchas plantillas legales útiles, pero para una compañía de software, el acuerdo para desarrollar software es el corazón absoluto de su negocio y es el área donde sugeriría nunca usar una plantilla. Debe hablar con un abogado, y uno que sepa sobre la industria del software, porque hay muchas preguntas clave que determinarán qué implica el contrato, que dependen de cómo usted (y su cliente) quieran hacer negocios.
Y hay algunas trampas específicas para el software, especialmente sobre los derechos de propiedad intelectual (DPI). Por ejemplo, en el Reino Unido, si contrata a un empleado para escribir software, será propietario del IPR (el código fuente), pero si contrata a un contratista, no lo hará a menos que se acuerde específicamente, así que asegúrese de que sea explícito acordado (preferiblemente en los contratos de sus empleados también).
Puede reducir el costo de su asesoramiento legal si está bien preparado y comprende los problemas de antemano, de modo que tenga claras las respuestas a las preguntas del abogado. (Por lo tanto, leer los contratos de plantilla puede ser útil).
- Como desarrollador junior, ¿qué oportunidades profesionales existen para combinar mi formación científica y mi conjunto de habilidades de software?
- Si alguna vez creó un banco en línea, ¿qué necesita hacer diferente en comparación con un sitio web comercial simple?
- Cómo definir una 'característica' de un software de forma precisa y efectiva
- Cuando trabajo en un nuevo proyecto de software que utiliza tecnologías desconocidas, es extremadamente difícil comenzar, ¿qué debo hacer?
- ¿Cuáles son las tareas difíciles realizadas o los problemas resueltos en la (s) línea (s) de código más simple y más corta?
En general, los contratos de desarrollo de software dirán:
- ¿Quiénes son exactamente las personas jurídicas que lo firman y por qué?
- definiciones, como qué son las horas estándar, qué significa “día” (día de la semana o calendario), “por escrito” incluye correo electrónico, etc.
- cuánto durará el contrato y qué eventos harán que se rescinda (por ejemplo, 3 meses de aviso, cláusulas de penalización, insolvencia, etc.)
- qué dinero cambiará de manos y cuándo (no permita que el cliente use el software indefinidamente sin el “cierre de sesión” final que desencadenará su pago final)
- qué bienes y qué se suministrarán (una especificación del software)
- qué servicios se proporcionarán, por ejemplo, alojamiento y soporte: nunca acepte un soporte abierto, ¡debe haber límites!
- cómo se manejarán los cambios en el camino
- qué sucede si el cliente no paga, porque esto sucede todo el tiempo
- quién posee el IPR, idealmente usted, no solo el código fuente, sino también cualquier gráfico, marca registrada, nombre de dominio, etc.
- si es el propietario de los DPI, a veces una cláusula de no competencia para decir que no competirá con su cliente vendiendo lo mismo a competidores en su industria
- Además, si usted es el propietario de los derechos de propiedad intelectual, el cliente podría pedirle razonablemente que coloque el código en custodia para que pueda tenerlo en caso de quiebra
- cláusulas legales estándar, como un acuerdo de confidencialidad mutua, exención de responsabilidad, si puede subcontratar, qué garantías habrá, cesión, exención, no agencia, etc.
También puede diseñar su contrato para que sea fácilmente reutilizable. Una forma de hacerlo es que todos los detalles del proyecto específico (aplicación, etc.) estén en los cronogramas del contrato, uno que describa la aplicación que se desarrollará en detalle, otra para plazos y entregables, y otra para costos y etapas de pago . (Y uno para soporte continuo, si lo hay). El contrato se referirá a los cronogramas a lo largo, lo que significa que el contrato puede no necesitar ningún cambio de un proyecto a otro. También significa que si el cliente desea agregar una función, puede modificar los cronogramas en lugar del contrato, lo cual puede ser lo suficientemente seguro como para prescindir de un abogado.