open source - source - ¿Qué debería saber cada desarrollador sobre asuntos legales?

software licenses (15)

6. Si tiene un empleado que desarrolla software "fuera del reloj", debe aclarar quién posee ese software y qué tipo de software el empleado debería poder escribir y distribuir fuera de la empresa.

la libertad de expresión, tal como se establece en la mayoría de las constituciones (especialmente si los desarrolladores hacen s / w de forma gratuita) puede hacer que dichos términos fracasen miserablemente en los tribunales.

Hoy tuve una gran sorpresa al conocer algunas implicaciones de la licencia GPL, principalmente porque no podía usarla tan libremente como pensaba.

Ahora sé.

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

Puede separar empleados, profesionales independientes, contribuyentes de proyectos de código abierto (etc.) o dar una respuesta más amplia.

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

Creo que la Guía Legal para el Desarrollo de Software y Web por Stephen Fishman Attorney es lo que estás buscando.

revisión
Un libro increíble! Contesta casi todas las preguntas legales que puedas imaginar y algunas que nunca hubieras pensado. - John Dvorak, PC Magazine
Cubre todos los detalles imaginables importantes para un medio tan intangible y de rápido crecimiento. - Emprendedor
Este libro pasa mi prueba personal para guías legales, con calificaciones más altas que cualquier otra guía legal. - Jeff Duntemann, Editor, PC Techniques Magazine
Descripción del producto
¡Protege tus derechos y tu 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 y demandas legales.
Afortunadamente, la Guía legal de desarrollo de software y web decodifica esta área compleja de la ley, minuciosamente 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 un rescate de un abogado.
Use la guía legal para desarrollo de aplicaciones y web 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é provisiones necesitas al redactar un acuerdo
cómo obtener permiso para usar los materiales de otras personas
Encontrarás instrucciones completas y paso a paso para redactar:
acuerdos de empleo
contratos de contratistas y consultores
acuerdos de desarrollo
acuerdos de licencia
La quinta edición de la Guía legal de desarrollo de software y web se actualiza por completo para proporcionar la última jurisprudencia y revisiones reglamentarias.

Algunas otras sugerencias:

Trabajando para usted: Ley e impuestos para contratistas independientes, profesionales independientes y consultores (Mismo autor).
Consultores de consultores e independientes (Mismo autor).
Manual de licencia de software por Jeffrey I. Gordon.
Guía práctica de licencias de software para licenciatarios y otorgantes de licencias por H. Ward Classen.
La Guía de bolsillo de contratos tecnológicos: Acuerdos de software y servicios para vendedores, gerentes de contratos, desarrolladores de negocios y abogados por David Tollen.

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 de ellos, debe leer cuidadosamente solo los que va a usar o tocar. Solo léalos, en la mayoría de los casos están bastante claros.

Cualquier otra cosa que puedas necesitar, bueno, eso depende. Patentar Marcas registradas Si necesita estas cosas, es probable que esté en una empresa y tenga un departamento legal para hacer esto por usted.

Doce consideraciones legales para el desarrollo de software

El software tiene 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 del copyright es el autor o la empresa que paga al autor.
Los derechos de autor del software pueden ser asignados por el propietario del copyright, o puede ser retenido por el propietario y el propietario puede autorizar el software al usuario o usuarios.
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 tampoco el hecho de que la biblioteca incluya una plataforma de desarrollo. Debe leer y comprender la licencia antes de distribuir su aplicación. Algunas bibliotecas requieren pagos de regalías, aunque esto se ha vuelto menos común en los últimos años.
Las demandas de patentes de software son brotes de mierda. No debe, por supuesto, violar a sabiendas una patente de software. Sin embargo, existe una posibilidad pequeña pero real de que alguna compañía lo demande por violar su patente. Esto puede suceder incluso si desarrolla su software de forma independiente, nunca oyó hablar de la patente, y la patente cubre una técnica que es intuitivamente obvia y que 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 trols de patentes generalmente demandan a grandes compañías con mucho dinero.
Si usa un empleado o profesional independiente para desarrollar software, debe dejar en claro, por escrito, quién es el propietario de los derechos de autor de la aplicación, incluido el código fuente. Algunos profesionales independientes y empresas de desarrollo de contratos consideran que el código fuente es de su propiedad, lo que deja a la empresa dependiendo de los desarrolladores originales. Esto es legal si está en el acuerdo de desarrollo.
Si tiene un empleado que desarrolla software "fuera del reloj", debe aclarar quién posee ese software y qué tipo de software el empleado debería poder escribir y distribuir fuera de la empresa.
Si usted es un empleado o desarrollador independiente de 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 a quién pertenece el software que escribe en su propio tiempo. Algunas empresas tienen cláusulas en los contratos de empleo que afirman ser propietarias 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 de empleo que restringen el software que un empleado puede producir para su distribución fuera de la empresa. Algunas veces estas restricciones son bastante amplias.
Una marca registrada es un nombre o símbolo, no el software en sí. Si distribuye software, debe (a) asegurarse de que el nombre de la aplicación y la "marca" o el diseño del nombre no sean "confusamente similares" con 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 la aplicación se utiliza por primera vez en el comercio.
Cuando nombre una aplicación, busque marcas comerciales registradas, pero también verifique Google. Una aplicación con el primer uso del nombre puede tomar su nombre y marca comercial después de que su aplicación sea exitosa, incluso si no han registrado la marca registrada y usted lo ha hecho.
Cuando use o firme un contrato o acuerdo, asegúrese de que ambas partes lo entiendan. En un acuerdo de empleo, mencionar cualquier área potencialmente sensible por adelantado puede evitar muchos problemas más adelante. En un acuerdo de desarrollo, si ambas partes saben a quién pertenece el código fuente, o quién es responsable de las actualizaciones, o quién es responsable del mantenimiento, etc., entrando en el proyecto de desarrollo, entonces hay mucha menos probabilidad de una demanda después de la aplicación se ha completado. En un acuerdo de distribución, asegúrese de que el distribuidor comprenda las responsabilidades y el plazo del acuerdo.
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 solucione todos los errores. Deje en claro que los cambios, las correcciones y las actualizaciones se realizan a la opción (o mejores esfuerzos) del desarrollador, y dejar en claro quién paga las correcciones y actualizaciones.
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 compañías de software y ver qué se propusieron sus abogados.
No soy abogado, y esto no es un consejo legal.

El nombre de un buen abogado de propiedad intelectual.

En caso de duda, contacte a un abogado.

La ley no es como el código. No es un conjunto de pasos bien moldeados y reglas que pueden entenderse sin ambigüedad.

NOLO (yo no trabajo para ellos) publica un buen conjunto de libros de cómo legal para el profano.

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

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

La licencia GPL es ''copia 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 ser lanzado bajo una licencia GPL.
No está obligado a poner a disposición su fuente si no está distribuyendo su software. Por ejemplo, si ejecuta el software para fines internos o en un servidor web, no necesita liberar la fuente. Es por eso que Google no necesita lanzar su software que usa bibliotecas GPL. Fue un punto de contención clave en GPL v3.
LGPL (Library o Less GPL) solo requiere que usted tenga su propio código fuente en GPL si incorpora la biblioteca LGPL-ed de tal manera que se convierta en irremplazable. Su propio software no necesita ser GPL si solo ''usa'' la biblioteca. Incluir los archivos de encabezado y vincularlos con .dll / .so de la biblioteca es una de las formas en que puede "usar" el código LGPL-ed sin ninguna obligación, excepto por el aviso de copyright adecuado.
Licencia BSD (la licencia de Apache es muy similar) le permite crear extensiones comerciales de las que usan el componente de código abierto. Es por eso que Apple eligió FreeBSD sobre Linux como kernel para OSX.
MPL es muy amigable comercialmente porque Netscape pensó que podrían ganar algo de dinero de Mozilla en el momento en que se escribió la licencia.

A menudo ayuda ponerse en contacto con el responsable del proyecto Open Source. Están en la mejor posición para aconsejarte acerca de la intención original de la licencia, así como sus propios puntos de vista sobre el código abierto. A veces los mantenedores están dispuestos a lanzar software bajo múltiples licencias para ayudarlo. A menudo no lo son. Depende de la persona que posee los derechos de autor.

El proyecto de KDE tiene una matriz útil

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

Para autónomos: debemos ser capaces de dar consejos sólidos a sus clientes; y elija qué componentes podemos usar para las aplicaciones que desarrollamos para ellos.

Por supuesto, tu palabra no es tan buena como los consejos que un abogado puede darte; pero ya puedes ayudar para una primera ronda; por ejemplo, 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 contribuidores de OSS: conocer algunas diferencias entre licencias libres puede importar si le importa lo que las personas pueden hacer con su código (¿redistribuir? Modificar? Usarlo en una aplicación comercial? ¿Usarlo en una aplicación propietaria?)

Respondería esto de la misma manera que respondería "¿qué deberían saber todos los abogados sobre programación?" Es decir, saber que no hay manera de que puedas conocer el campo a fondo lo suficientemente bien como para hacer más que las cosas más simples. Obtener un experto

Si es un profesional independiente o un contratista: asegúrese de tener un buen seguro de responsabilidad civil y saber qué está cubierto por él.

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

Siempre asumo que los desarrolladores de un proyecto quieren que cualquier software que use su trabajo sea lanzado bajo la misma licencia. Lea sus preguntas frecuentes y páginas legales para obtener más información y no dude en ponerse en contacto con los desarrolladores / mantenedores si todavía no está seguro.

Si desea ayuda para comprender los detalles de un acuerdo de licencia, hable con un abogado.

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

En los primeros días, IBM pagaba a los programadores por las instrucciones. (Alguien que conocía dijo que trabajaba 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 almacenaba manualmente cero en cada dirección de memoria).

Hubo un tiempo (hace mucho tiempo) en que los abogados recibían el pago por la palabra. Esto ayudó a popularizar prácticas tales como dirigirse a las personas como "el más estimado de tal y tal" y otras verbosidades.

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

Esto es comparable al reino de la ley. Hay leyes que hacen pequeños (o grandes) cambios a otras leyes. Tienes una especie de dependencia, demonios. Hay algunas leyes históricas ridículas (en Hobart, Tasmania, es ilegal que un hombre use el vestido de una mujer después del atardecer, porque alguna vez los convictos se vestían como mujeres y asaltaban a las personas) 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 involuntarias (¡errores!), Se utilizan de forma creativa (¡pirateos!), Contienen lagunas (¡vulnerabilidades de seguridad!), Algunas de las cuales son intencionales (¡puertas traseras!), Modificadas (¡parches!) O anuladas (¡desinstalación!) .

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

Para responder la pregunta directamente: cada desarrollador debe saber que la ley es más bien 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 los problemas de diferentes maneras). En teoría, después de leer una licencia sabrá qué puede y qué no puede hacer con su código. Pero si un programador competente no puede detectar todos los errores en su código simplemente leyéndolo, 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, consulte a un profesional .