¿Qué debe saber todo desarrollador sobre asuntos legales? [cerrado]

Hoy tuve una mala sorpresa al enterarme de algunas implicaciones de la licencia GPL, principalmente que no podía usarla tan libremente como pensaba.

Ahora sé.

¿Qué más debería saber y, más ampliamente, qué debería saber todo desarrollador sobre cuestiones legales como esa?

Puede separar empleados, autónomos, colaboradores de proyectos de código abierto (etc.) o dar una respuesta más amplia.

Doce consideraciones legales para el desarrollo de software

1. El software está protegido por derechos de autor si se pone a disposición del público en general. Ya no es necesario poner un aviso de copyright en la aplicación o en el código fuente. El propietario de los derechos de autor es el autor (es) o la empresa que paga al autor (es).

2. Los derechos de autor del software pueden ser asignados por el propietario de los derechos de autor, o puede ser retenido por el propietario y el software puede ser licenciado al usuario o usuarios por el propietario.

3. Las bibliotecas utilizadas en el desarrollo probablemente tengan restricciones en su uso y distribución. GPL no convierte una biblioteca en dominio público, ni el hecho de que la biblioteca venga con una plataforma de desarrollo. Debe leer y comprender la licencia antes de distribuir su aplicación. Algunas bibliotecas exigen el pago de regalías, aunque esto se ha vuelto menos común en los últimos años.

4. Las demandas por patentes de software son disparates. Por supuesto, no debe violar conscientemente una patente de software. Sin embargo, existe una pequeña pero real posibilidad de que alguna empresa lo demande por violar su patente. Esto puede suceder incluso si desarrolla su software de forma independiente, nunca ha oído hablar de la patente y la patente cubre una técnica que es intuitivamente obvia y que casi no tiene relación con su software. No hay mucho que pueda hacer para evitar esto, dadas las políticas actuales de la USPTO, aparte de comprar un seguro. La buena noticia es que los trolls de patentes generalmente demandan a las grandes empresas con mucho dinero.

5. Si utiliza a un empleado o profesional independiente para desarrollar software, debe dejar claro, por escrito, quién posee los derechos de autor de la aplicación, incluido el código fuente. Algunos autónomos y empresas de desarrollo por contrato consideran que el código fuente es de su propiedad, lo que deja a la empresa dependiente de los desarrolladores originales. Esto es legal si está en el acuerdo de desarrollo.

6. Si tiene un empleado que desarrolla software "fuera de horario", debe dejar claro quién es el propietario de ese software y qué tipo de software el empleado debería poder escribir y distribuir fuera de la empresa.

7. Si es un empleado o un profesional independiente que desarrolla software, debe dejar en claro quién será el propietario de los derechos de autor de su aplicación antes de comenzar el desarrollo. Además, debe saber o aclarar quién es el propietario del software que escribe en su tiempo libre. Algunas empresas tienen cláusulas en los acuerdos laborales que reclaman la propiedad de cualquier software escrito por un desarrollador durante el período de empleo, ya sea en el hogar o en el trabajo. Muchas empresas tienen cláusulas de no competencia en los acuerdos laborales que restringen el software que un empleado puede producir para su distribución fuera de la empresa. A veces, estas restricciones son bastante amplias.

8. Una marca comercial es un nombre o símbolo, no el software en sí. Si distribuye software, debe (a) asegurarse de que el nombre de su aplicación y la "marca" o el diseño del nombre no sea "confusamente similar" a otras aplicaciones, y (b) registrar su marca comercial. La fecha del primer uso es importante para resolver conflictos, por lo que debe documentar cuándo se usa la aplicación por primera vez en el comercio.

9. Cuando asigne un nombre a una aplicación, compruebe si hay marcas comerciales registradas, pero también compruebe Google. Una solicitud con el primer uso del nombre puede tomar su nombre y marca comercial después de que su solicitud sea exitosa, incluso si no han registrado la marca comercial y usted lo ha hecho.

10. Cuando utilice o firme un contrato o acuerdo, asegúrese de que ambas partes lo comprendan. En un contrato de trabajo, mencionar cualquier área potencialmente sensible por adelantado puede evitar muchos problemas más adelante. En un acuerdo de desarrollo, si ambas partes saben quién es el propietario del código fuente, o quién es responsable de las actualizaciones, o quién es responsable del mantenimiento, etc., al entrar en el proyecto de desarrollo, entonces hay muchas menos probabilidades de que se presente una demanda después de la aplicación. se ha completado. En un contrato de distribución, asegúrese de que el distribuidor comprenda las responsabilidades y los términos del contrato.

11. Cada aplicación no trivial tiene errores (o "consideraciones de diseño" :-)). Cualquier acuerdo de usuario o acuerdo de distribución debe dejar en claro que usted no es responsable del software libre de errores y no se puede esperar que usted corrija todos los errores. Deje en claro que los cambios, correcciones y actualizaciones se realizan a opción (o mejor esfuerzo) del desarrollador, y deje en claro quién paga las correcciones y actualizaciones.

12. Incluso después de consultar a un abogado sobre el desarrollo de software y los acuerdos de distribución, debe leer los acuerdos de otras empresas de software y ver qué se les ocurrió a sus abogados.

13. No soy abogado y esto no es un consejo legal.

En caso de duda, comuníquese con un abogado.

No soy abogado, pero con el tiempo he recopilado algunas reglas generales de personas legales que puede usar para ahorrar tiempo:

• La licencia GPL es 'copia a la izquierda' o 'viral'. Significa que cualquier código que escriba que dependa de un componente GPL también debe publicarse bajo GPL. Una buena regla general es que si necesita un componente GPL para compilar su software, su software debe publicarse bajo una licencia GPL.
• No está obligado a hacer que su fuente esté disponible si no distribuye su software. Por ejemplo, si ejecuta el software para fines internos o en un servidor web, no es necesario que libere la fuente. Es por eso que Google no necesita lanzar su software que usa bibliotecas GPL. Fue un punto de discusión clave en GPL v3.
• LGPL (Library or Lesser GPL) solo requiere que GPL su propio código fuente si incorpora la biblioteca LGPL-ed de tal manera que se vuelva insustituible. Su propio software no necesita ser GPL si solo 'usa' la biblioteca. Incluir archivos de encabezado y vincularlos con una .dll/ .sode la biblioteca es una de las formas en que puede 'usar' el código LGPL-ed sin ninguna obligación, a excepción del aviso de derechos de autor correspondiente.
• La licencia BSD (la licencia Apache es muy similar) le permite crear extensiones comerciales que utilizan el componente de código abierto. Es por eso que Apple eligió FreeBSD sobre Linux como núcleo para OSX.
• MPL es muy comercial porque Netscape pensó que podrían ganar algo de dinero con Mozilla en el momento en que se escribió la licencia.

A menudo resulta útil ponerse en contacto con el responsable del mantenimiento del proyecto de código abierto. Ellos están en la mejor posición para asesorarle sobre la intención original de la licencia, así como sus propias opiniones sobre el código abierto. A veces, los encargados de mantenimiento están dispuestos a lanzar software con varias licencias para ayudarlo. A menudo no lo son. Depende de la persona propietaria de los derechos de autor.

El proyecto KDE tiene una práctica matriz

Creo que lo que está buscando es la Guía legal para el desarrollo web y de software de Stephen Fishman Attorney.

revisión

¡Un libro asombroso! Responde casi todas las preguntas legales que pueda imaginar y algunas en las que nunca hubiera pensado. - John Dvorak, Revista de PC

Cubre todos los detalles imaginables importantes para un medio intangible y de rápido crecimiento. - emprendedor

Este libro pasa mi propia prueba personal para guías legales, con calificaciones más altas que cualquier otra guía legal. - Jeff Duntemann, editor de la revista PC Techniques

Descripción del producto

¡Proteja sus derechos y su arduo trabajo!

Las leyes que cubren el desarrollo de sitios web y software son complejas y confusas, pero si no las desenreda, podría costarle miles de dólares en honorarios de abogados y demandas.

Afortunadamente, Legal Guide to Web & Software Development decodifica esta compleja área del derecho, a fondo y en un inglés fácil de leer. También proporciona contratos, acuerdos y formularios legales en CD-ROM, con instrucciones paso a paso para completarlos, para que pueda proteger su software y sitio web sin pagar el rescate de un abogado.

Utilice la Guía legal para el desarrollo web y de software para aprender:

• qué tipo de protección legal necesitas
• las fortalezas y limitaciones de cada tipo de protección
• cómo evitar una infracción
• qué disposiciones necesita al redactar un acuerdo
• cómo obtener permiso para usar materiales de otras personas

Encontrará instrucciones completas paso a paso para redactar:

• convenios laborales
• acuerdos de contratista y consultor
• acuerdos de desarrollo
• acuerdos de licencia

La quinta edición de la Guía legal para el desarrollo web y de software está completamente actualizada para proporcionar la jurisprudencia y las revisiones estatutarias más recientes.

Algunas otras sugerencias:

• Trabajando para usted mismo: leyes e impuestos para contratistas independientes, autónomos y consultores (mismo autor).
• Acuerdos entre consultores y contratistas independientes (mismo autor).
• Manual de licencias de software de Jeffrey I. Gordon.
• Guía práctica de licencias de software para licenciatarios y licenciantes por H. Ward Classen.
• The Tech Contracts Pocket Guide: Acuerdos de software y servicios para vendedores, gerentes de contratos, desarrolladores comerciales y abogados por David Tollen.

Si es un autónomo o un contratista: asegúrese de tener un buen seguro de responsabilidad civil y sepa qué cubre.

Por ejemplo, el mío no cubre la responsabilidad por errores cometidos en el código que podrían exponer los números de tarjetas de crédito. ¡Así que ya no toco esas cosas!

Para los empleados: deberíamos poder dar una primera ronda de consejos a sus clientes, como ¿pueden ellos / nosotros usar el componente que queremos, en su aplicación?

Para los autónomos: debemos ser capaces de dar buenos consejos a sus clientes; y elegir qué componentes podemos utilizar para las aplicaciones que desarrollamos para ellos.

Por supuesto, su palabra no es tan buena como los consejos que le puede dar un abogado; pero ya puedes ayudar en una primera ronda; por ejemplo, para decir "definitivamente no podemos usar esto porque significaría ..."
Al final, el abogado sabrá mucho sobre casos de esquina, pero si puede ayudar un poco ...

Para los contribuyentes de OSS: conocer algunas diferencias entre las licencias gratuitas puede ser importante si le importa lo que la gente pueda hacer con su código (¿redistribuir ?, ¿modificar ?, ¿usarlo en una aplicación comercial ?, ¿usarlo en una aplicación propietaria?)

Una respuesta ha afirmado que la ley no es como un código. Estoy en desacuerdo.

En los primeros días, IBM pagaba a los programadores por instrucciones. (Alguien que conocí dijo que trabajó con un programador que se hizo rico de esta manera. Aparentemente, el tipo no sabía cómo usar el registro de índice de la máquina; escribió una rutina de memoria cero que almacena manualmente cero en cada dirección de memoria).

También hubo un tiempo (hace mucho tiempo) en que a los abogados se les pagaba por palabra. Esto ayudó a popularizar prácticas tales como dirigirse a las personas como "el tal y tal más estimado" y otras verbosidades.

Acabo de leer una respuesta en SO que decía que VB.NET 2008 todavía permite números de línea . Aún puede ejecutar DOS puro en una PC moderna. Y hay mucha verdad en la broma de que todos los programas COBOL descienden de un antepasado común mediante cambios incrementales. La compatibilidad con versiones anteriores y las "razones históricas" abundan en nuestro campo.

Esto es comparable al ámbito de la ley. Hay leyes que hacen cambios pequeños (o grandes) a otras leyes. Tienes una especie de dependencia-infierno. Hay algunas leyes históricas ridículas (en Hobart, Tasmania, es ilegal que un hombre use un vestido de mujer después de la puesta del sol, porque una vez los convictos se vestían de mujeres y asaltaban a la gente) que nadie soñaría con hacer cumplir, al igual que hay algunas características históricas en el software que ya nadie usa.

Las leyes a menudo tienen consecuencias no deseadas (¡errores!), Se usan de manera creativa (¡trucos!), Contienen lagunas (¡vulnerabilidades de seguridad!), Algunas de las cuales son intencionales (¡puertas traseras!), Se modifican (¡parches!) O se anulan (¡desinstalación!) .

Sí, las leyes (a diferencia del código) están sujetas a interpretación. Pero creo que esto es como un mantenimiento de código. Ayuda a ajustar las leyes a las nuevas normas sociales.

Para responder a la pregunta directamente: todo desarrollador debe saber que la ley es como un proyecto de software ridículamente enorme que ha estado en desarrollo durante cientos de años. (En realidad, cada país tiene su propio proyecto y resuelven problemas de diferentes maneras). En teoría, después de leer una licencia, sabrá lo que puede y no puede hacer con su código. Pero si un programador competente no puede detectar todos los errores en su código con solo leerlo, entonces, ¿qué posibilidades tiene un no abogado de analizar los casos de esquina y las áreas grises de un documento legal?

Al igual que con el código fuente del software, generalmente puede obtener la esencia de un documento legal leyéndolo, pero si necesita saber algo específico, pregúntele a un profesional .

NOLO (no trabajo para ellos) publica un buen conjunto de libros legales sobre cómo hacer para el profano.

http://www.nolo.com/products/a-legal-guide-to-web-&-software-development-SFT.html

Yo respondería a esto de la misma manera que respondería "¿qué debería saber todo abogado sobre programación?" Es decir, sepa que no hay forma de que pueda conocer el campo en profundidad lo suficientemente bien como para hacer más que las cosas más simples. Consiga un experto.

Debe conocer los derechos y obligaciones básicos de la licencia que va a utilizar. No es tan difícil, e incluso si hay muchos, debe leer cuidadosamente solo aquellos que va a usar o tocar. Solo léelos, en la mayoría de los casos son bastante claros.

Cualquier otra cosa que puedas necesitar, bueno, eso depende. ¿Patentar? Marcas comerciales Si necesita estas cosas, es probable que esté en una empresa y tenga un departamento legal que lo haga por usted.

Siempre supongo que los desarrolladores de un proyecto quieren que cualquier software que utilice su trabajo se publique bajo la misma licencia. Lea sus preguntas frecuentes y las páginas legales para obtener más información y no dude en ponerse en contacto con los desarrolladores / mantenedores si aún no está seguro.

Si necesita ayuda para comprender los detalles de un contrato de licencia, hable con un abogado.

1. No trabaje en un país que tiene más abogados que desarrolladores.
2. Un porcentaje extremadamente grande de todas las patentes de software (de EE. UU.) Son falsas, pero no puede pagar ni esperar a que se invaliden.
3. Si desea utilizar / desarrollar software de código abierto, utilice una licencia existente y no la modifique. No se acerque a los límites de lo que se supone que significa la licencia.

El nombre de un buen abogado de propiedad intelectual.

6. Si tiene un empleado que desarrolla software "fuera de horario", debe dejar en claro quién es el propietario de ese software y qué tipo de software el empleado debe poder escribir y distribuir fuera de la empresa.

El derecho a la libertad de expresión como se establece en la mayoría de las constituciones (especialmente si los desarrolladores hacen s / w gratis fuera del horario) puede hacer que tales términos fracasen miserablemente en los tribunales.

La ley no es como un código. No es un conjunto de pasos y reglas bien estructurados que pueda entenderse sin ambigüedades.