Protección del código de sus propios desarrolladores

Question

Tal vez la forma más obvia de proteger la propiedad intelectual de una empresa de sus propios desarrolladores parece ser un acuerdo de no divulgación de la NDA. La efectividad de este enfoque puede variar, dependiendo de muchos factores, y algunas veces o en algún lugar puede no funcionar como se espera.

¿Qué otros enfoques, aparte de este puramente legal, existen para proteger el código de software de las personas que lo desarrollan? ¿Existen en absoluto? ¿Tiene sentido en la práctica?

Quizás, por ejemplo, Team Edition de Visual Studio ya contenga algunas características relacionadas con este problema (por ejemplo, niveles de acceso a partes de código, dependiendo del rol dentro de un equipo de desarrollo o algo así).

de referencia sobre el tema:

Como dice estadísticas, en promedio, los programadores tienden a cambiar de trabajo cada tres - y cuatro años.

Answer 1

Intenta formar un equipo en el que puedas confiar.

Answer 2

Sé que dijiste aparte de la puramente legal, pero me gustaría agregar que además del legal que mencionaste, también está el Non-Compete. Básicamente dice que una vez que deje su trabajo, no podrá competir de ninguna manera contra su ex empleador. El código de robo no es tan atractivo si no podrá usarlo durante un año o dos.

Answer 3

Si es realmente necesario, puede dividir la aplicación en subaplicaciones. Cada equipo trabaja en una sola aplicación y ve a todos los demás como "cajas negras". Quizás SOA ayude aquí.

Answer 4

Es muy poco probable que su código sea propiedad intelectual real, es decir, el conocimiento y el proceso comercial de su empresa.

Answer 5

Cree un equipo de desarrolladores en los que pueda confiar o bloquee completamente el sistema para que no puedan acceder a los puertos USB, la unidad de CD o los clientes de correo web. Lo único que podrían hacer es trabajar en el código y posiblemente navegar por la web. También solo déles acceso al código que están a cargo.

Pero con todas estas medidas de seguridad es probable que sus desarrolladores se odian trabajar con usted y salir de su trabajo

Answer 6

No hay manera fácil de hacer esto si su código está dentro del mismo proyecto (es decir, que desea permitir el acceso a algunas partes del código y otras no). Sin embargo, si tiene proyectos separados que requieren diferentes niveles de seguridad, es posible permitir que los desarrolladores solo tengan acceso de código a ciertos proyectos y luego extraer compilaciones de un servidor de compilación común.

Tenga en cuenta que la descompilación de marcos que funcionan contra IL como .NET es relativamente sencilla, por lo que evitar el acceso a los archivos de código no es necesariamente una bala para proteger el IP.

Answer 7

El primer enfoque es forzar a los programadores a que solo conozcan interfaces de otros componentes, de modo que cada uno pueda robar una pequeña parte de todo el software. Este enfoque puede tomarse prestado de la producción de calzado. Una corporación transnacional, para evitar el robo por parte de los empleados, arregló sus fábricas para que cada fábrica produjera solo zapatos izquierdos o solo adecuados. Usted podría hacer lo mismo con su código: algunos programadores solo escriben líneas con números impares, y los otros, aquellos con números pares; ¡con la condición de que no puedan ver el trabajo del otro! A veces se lo denomina "pair programming".

Algunas organizaciones obligan a los empleados a firmar un acuerdo de no competencia. Ese es el tipo de acuerdo que impide que los programadores trabajen para la competencia. Esta técnica se combina mejor con ofertas de trabajo como "Buscando programador senior con 5 años de experiencia en el campo similar".

Para evitar el robo de sus programadores, puede dañarlos tan pronto como finalicen el software. El método demostró ser el más eficiente y se ha utilizado durante siglos. Por ejemplo, el zar ruso Ivan The Terrible quema los ojos del arquitecto que diseñó una hermosa iglesia en la Plaza Roja, por lo que el diseño sigue siendo el más bello de todos. Puede hacer algo como esto a su arquitecto. Escuché, el último Visual Studio contiene algunas características ...

Hoy en día, sin embargo, es más humanista contratar personas ya ciegas y ya mudas que perdieron sus manos, por lo que no pueden mirar su código para memorizarlo, no puede contarle a nadie sobre su código y no puede volver a escribirlo. La ventaja es que esto lo ayudará a tratar con la agencia laboral en su país, que busca el equilibrio para que sus empleados no sean discriminados.

Y sí, esta publicación es una broma sarcástica, que critica la idea de cualquier medida de prevención de robo de código. Lo siento, no pude evitar publicarlo.

Answer 8

¿Cómo se protege una central eléctrica del sabotaje de un empleado? ¿Cómo previene que un boxeador lance la pelea? ¿Cómo se evita que un burdel distribuya la palmada?

Su preocupación, si bien es válida, es aquella a la que solo se puede dirigir de forma adecuada mediante la responsabilidad personal y la responsabilidad dentro de su equipo. Cualquier opción que emplee para proteger el código contra el robo es más dañino que beneficioso. Si crees que un miembro del equipo no es confiable, deshazte de ellos.

Answer 9

Puede hacer que desarrollen un módulo que sería independiente del resto de la aplicación. Si tuviera un sistema de plugin/tipo de módulo funcionando, esto sería adecuado. Podría lanzar API para que los desarrolladores se desarrollen contra y hacer que se integren con sus archivos DLL y no con el código fuente.

La gente parece ser muy crítica con esto, pero hay razones legítimas para hacerlo, es decir, asociarse con un competidor potencial si les daba toda su fuente, se dispararía en el pie.

Answer 10

SVN tiene la capacidad de limitar diferentes usuarios a diferentes carpetas, por lo que podría dividir el código en bibliotecas separadas y permitir solo el acceso de lectura/escritura a ciertas personas.

El archivo para esto está bajo conf \ authz Aquí es una muestra

[aliases] 
# joe = /C=XZ/ST=Dessert/L=Snake City/O=Snake Oil, Ltd./OU=Research Institute/CN=Joe Average 

[groups] 
# harry_and_sally = harry,sally 
# harry_sally_and_joe = harry,sally,&joe 

[/ 
# [/foo/bar] 
# harry = rw 
# &joe = r 
# * = 

# [repository:/baz/fuz] 
# @harry_and_sally = rw 
# * = r 

Parte de la documentación se puede encontrar 'por directorio de control de acceso' here

Bajo

Answer 11

Se podría valer la pena gastar algo de actividad cerebral en el modelo comercial que desea seguir. Si el valor central está incorporado en el código, el valor central puede ser robado robando el código. Sin embargo, si el valor central de su empresa está integrado en un grupo de empleados, algunos de ellos ingenieros, otros vendedores, y otros, personas de soporte al cliente, y cuando el software es solo la red que mantiene funcionando a estas personas, entonces hay no es una forma fácil de robar el valor de su negocio. Y si se roba el software , los ladrones no podrán usarlo mucho.

Por lo tanto, además de lo que dijo cherouvim, forme un equipo en el que no pueda simplemente confiar, sino un equipo que sea el valor central de su negocio.

Answer 12

Desarrolle su software en módulos.

Tiene un módulo común que contiene objetos que pasan de ida y vuelta, y clases de utilidad que actúan sobre esos objetos.

Haga que cada grupo construya módulos además de eso, sin mucha necesidad de conocer otros módulos.

Haga que un equipo de desarrolladores de confianza haga la planificación de lo que se incluye en cada módulo, y haga que ese equipo también realice la integración de todos los módulos en el conjunto.

También confíe mucho en quien ejecuta su servidor de control de versiones. Si bien es estable, ningún desarrollador puede hacer tanto daño; no pueden borrar todo, por ejemplo, y sabrá exactamente lo que hicieron y cuándo, si eso llega a ser un problema.