¿Es normal que los desarrolladores de software deben notificar a su empresa antes de involucrarse en cualquier proyecto de código abierto o gratuito?

Gracias por el A2A. Los acuerdos codiciosos y restrictivos como ese dicen mucho sobre la compañía, pero desafortunadamente son comunes. Hay varias razones para eso.

Primero, todos esos acuerdos son plantillas de abogados copiadas / pegadas separadas de la realidad: contratación de inventores versus trabajadores de cintas transportadoras (más sobre eso a continuación). Son creados por abogados corporativos que piensan en los términos más restrictivos para proteger la propiedad intelectual de sus clientes (obviamente no usted). Muy común entre los formularios entregados a las startups por incubadoras (patrocinadas por abogados) que se desviven para impresionar al cliente, y desde entonces no se modificaron.

Desafortunadamente, el 99.9999% de los desarrolladores de software que trabajan para el hombre nunca harán su pregunta ni leerán esos acuerdos. No han inventado nada en su vida, ni van a hacerlo. Muchos ni siquiera son lo suficientemente inteligentes como para reconocer un proyecto paralelo o de código abierto como un posible conflicto de intereses con su “trabajo diario”, en el buen sentido: para hacer un “trabajo mucho mejor” que su empleador no permite (o paga) ellos para hacer.

Lo más probable es que lo contraten como gruñido para corregir errores, escribir código repetitivo y, de lo contrario, trabajar según el libro. Prácticamente nadie se emplea (cambia de trabajo, etc.) con sus propios inventos. Esas personas son empleadas por Google o compañías que no quieren abandonar. Y si “furtivamente” (al más alto nivel), nadie los insultaría con tales acuerdos. ¿Puedes visualizar a Linus Torvalds firmando esos? Desafortunadamente, tú y yo aún no estamos en ese nivel, por lo que nos tratan como gruñidos y programadores para golpear el teclado. La “deslocalización” y el ganado suministrado por el taller solo empeoraron la mentalidad del empleador. No inventores entre los sirvientes.

He estado en tu situación por un tiempo. Siempre es una sorpresa (para los empleadores), cuando completo la sección de invenciones anteriores del típico contrato de IP restrictivo. Supongo que los inventos no son parte de las responsabilidades laborales cotidianas para “ponerlo a trabajar”. Somos ingenieros Se espera que inventemos, ¿no? El enfoque posesivo “todo en tu cerebro nos pertenece automáticamente porque te pagamos un salario casi promedio” es malo. Debe pensar cuánto quiere trabajar para ese empleador y, definitivamente, mantener abiertas sus opciones.

A menos que sea Google. Personalmente, pensaría mucho si quiero renunciar a mi futuro empresarial incluso para Google. Fueron más lejos. Un amigo mío recientemente contratado allí tuvo que entregar su startup (no mucho, ya que se alejó fácilmente, pero aún así …). Estoy seguro de que su posición en el código abierto es igual de estricta. ¿Debería mencionar también los “viernes de Google” o como se llamen oficialmente allí? Ahora, Google es una cosa, pero cuando un departamento de TI típico de mierda o una fábrica de software “mediana” comienza a hacer “Viernes de Google” y pone sus manos en proyectos privados, es un poco injustificado decirlo suavemente. Para empezar, pagan la mitad de los salarios de Google, sin mencionar el sombrío futuro profesional “subcontratado”. ¿Estás siendo contratado por Google, Facebook o Amazon?

Entiendo que necesitas ganarte la vida. Este es uno de los atroces casos corporativos de “no preguntes, no digas”. Nadie lo despediría por violar esa cláusula a menos que su jefe esté buscando una excusa para deshacerse de usted, en cuyo caso encontrarían fácilmente otra cosa.

Mantener un perfil bajo es clave. Nunca van a descubrir en qué nicho de proyecto de código abierto está involucrado. El problema solo surgirá si su proyecto paralelo lo convierte en millonario. Pero incluso entonces la carga de la prueba recae sobre ellos. Tendrían que demostrar que realmente trabajó en su proyecto exitoso mientras trabajaba para ellos, y aprovechó su conocimiento laboral y capacitación específica, etc., etc.

No estoy seguro de dónde vives / trabajas. Los acuerdos de no competencia no son exigibles en mi estado: California, ni creo en ningún lugar de los EE. UU. La Europa debe ser la misma. La propiedad intelectual (ideas, técnicas, patrones, diseños, etc.) es un área gris grande. Las patentes son complicadas, ya que lo ponen en el radar del empleador de inmediato y deben divulgarse. Aunque muy pocas cosas son patentables en el desarrollo de software hoy en día.

La participación en un proyecto de código abierto implica obligaciones legales que pueden ser exigibles contra la empresa. La compañía tiene el derecho de decidir sobre tal participación. Como un ejemplo clásico de hace algunos años, una importante empresa de informática contrató a un joven que había utilizado un software de código abierto como estudiante universitario y tenía una copia en un disquete (esto fue en la década de 1980) que trajo con él a trabajar. El compañero incorporó ese software en una aplicación que estaba desarrollando para su empleador y la aplicación terminó siendo vendida a decenas de miles de clientes. Un tiempo después, el empleador fue demandado por las personas responsables del software de código abierto porque una cláusula en su acuerdo, que el estudiante había firmado sin volver a leerlo como estudiante universitario, declaró que cualquier uso comercial tenía que implicar el pago de una regalía. Era una regalía modesta, pero como había tantos clientes, el total era de varios millones de dólares. La compañía tenía la obligación legal de pagar eso porque, técnicamente, era su obligación asegurarse de que cualquier software utilizado en su producto fuera utilizado de acuerdo con su acuerdo de licencia.

Es razonablemente común y, creo, comprensible desde su perspectiva. Puede utilizar la información recopilada en el trabajo para crear un widget de código abierto que le brinde al competidor una ventaja de algún tipo.

Dicho esto, si no te gusta, retrocede. Lo más probable es que no quieran perderte por un desacuerdo (especialmente si aún no has comenzado) y esto es solo una pequeña parte de tu paquete de responsabilidades y beneficios. Pueden argumentar que no pueden hacer excepciones o que necesitan hablar con abogados, pero el hecho es que es una responsabilidad adicional (que no vale mucho para la empresa, especialmente en comparación con su salario o sus beneficios médicos) eso no era parte del acuerdo (especialmente si eres nuevo) y no estás recibiendo compensación por ello.

Si están dispuestos a despedirlo y reemplazarlo por no firmar, entonces es lo suficientemente importante como para pagarle al menos el cambio.

Es posible que también desee echar un vistazo a lo que hace Software Freedom Conservancy en este sentido con su iniciativa “ContractPatch”. ContractPatch, paso 1: todo es negociable. ContractPatch, Paso 2: Comprender el equilibrio de poder. También tienen una lista de correo (página de información de ContractPatch) para discutirlo.

Esto es bastante común.

El problema es que en los lugares de trabajo que implican un pensamiento e investigación originales significativos, trazar la línea entre la IP del trabajo y su IP es realmente complicado. Si tienes una onda cerebral a medianoche, ¿fue por tu trabajo o por tu propio tiempo?

En general, es una precaución para que luego, si surgen problemas de propiedad intelectual, haya un rastro en papel a seguir y se pueda llegar a un acuerdo razonable.

Si cree que los términos son injustos, hable con su jefe, pero esto no es particularmente inusual.

Muchos empleadores no permiten el código abierto (“todo su código es producto de trabajo”). Notificación previa y aprobación no es una mala política. Sería mejor si tuvieran cortes (“los parches de menos de 100 líneas no necesitan aprobación”) y un cronograma para las aprobaciones (“si no recibe respuesta nuestra en dos días hábiles, puede suponer que la solicitud se ha concedido”

La otra política común es “política no establecida”, lo que significa que piensa que OSS está bien, pero puede descubrir que su gerente o la compañía piensan lo contrario. Eso puede ser estresante.

No, no es inusual. He preguntado a los empleadores cuál es su política al respecto durante la etapa de la entrevista.

Puede que simplemente no les guste el código abierto, simplemente podrían estar preocupados de que los exponga a problemas legales copiando accidentalmente el código con derechos en una dirección u otra (dependiendo de su negocio, eso puede ser una preocupación legítima).

Considera cómo puede afectar tu vida. Decida cuánto confía en su empleador y qué tan buena es su relación con ellos.

Pero estaría preparado para firmar el contrato y cruzar los dedos.