Cómo proteger las violaciones de la propiedad intelectual del propio equipo [duplicado]

Question

Esta pregunta ya tiene respuestas aquí :

¿Cómo administrar un proyecto de alto riesgo de origen cerrado? (8 respuestas)

cerrado hace 7 años .

Tengo una idea de aplicación de Android, quiero hacer la aplicación junto con algunos compañeros de lote en mi collage.

(1) ¿Cómo me aseguro de que estos muchachos no comprometan las propiedades intelectuales involucradas? En el sentido de que no fugan información confidencial, nuevas teorías, nuevas ideas, descripciones de nuevas características, ya sea libremente en ningún medio o de alguna otra compañía que desarrolla software similar. Además, es probable que estas personas tengan acceso a todo el código fuente (con comentarios) del proyecto, ¿cómo me aseguro de que en el futuro cooperarán conmigo,

(2) no liberará ninguna parte del código,

(3) no liberarán libremente las versiones alfa que contengan características significadas solo para usuarios premium. También,

(4) ¿Hay manera de trabajar de manera efectiva sin otorgarles acceso a todo el código fuente?

Estoy abierto a todo tipo de respuestas: Fideicomiso, Técnico, Gerencial - Liderazgo, Buena Amistad - Relación con Collegues.

Actualización: todos vivimos en la India.

Answer 1

OK, tienes una idea, buena. Estoy seguro de que tus amigos también tienen la suya. Si quieres que trabajen en el tuyo, veo pocas opciones:

1. pagarles por su trabajo.

2. Hablar con ellos, agrupar las mejores ideas, idear una nueva que pertenece a todos.

3. Comience usted mismo, cuando ya está rodando, llámalos.

En el primer caso, puede estar seguro de que deje claro quién posee lo que y habla muy específicamente sobre lo que espera que no hará.

En el segundo caso, comparte los intereses y los riesgos. La redacción de un compromiso para no apuñalarse entre sí en la parte posterior sigue siendo una buena idea.

En el tercer caso, podría ser más fácil convencerlos de que trabajen en su idea, y es un poco obvio que lo inició todo; Pero todavía tiene que escribir en algún lugar lo que pertenece a quién, desde el principio. Eso también implica reconocer su trabajo, y asegurarse de que regresen lo que sienten es justo.

En cualquier caso, todavía tiene que confiar en ellos, no hay una cárcel mágica donde pueda ponerle a nadie que los haga leales a usted.

Answer 2

Sé poco sobre el sistema legal de la India, pero consideran las leyes de propiedad intelectual . Por ejemplo, si su idea es patentable, considere la patente. Sí, esto es caro (y no popular entre algunas personas), pero esto es para las patentes. Asegúrese de que cada archivo de código fuente incluya un aviso de copyright. La ley de IP no detendrá a las personas que roban su código e ideas, pero es posible que pueda evitar que los usen.

Si su idea se basa o se integra con otro producto u organización. Considere hablar con esa organización y ver si puede resolver una preferida o único acuerdo de licencia . Hipotéticamente, si su aplicación va a comercializar refrescos, acercarse a las compañías de refrescos y incluir su idea. Si les gusta, pueden financiarlo, le brinden ayuda técnica y niegue esa asistencia a otros.

Para los controles técnicos, considere componenando el sistema y usando segregación de deberes . Específicamente:

1. dividir el equipo de desarrollo en equipos separados. Sepárelas físicamente para que los desarrolladores en un equipo no puedan hablar con otros.
2. dividir el producto en componentes con interfaces bien definidas y asignar a cada equipo un componente diferente.
3. Coloque el código fuente de cada componente en un sistema de control de fuente separado y denegue el acceso a otros equipos a ese componente.

Al componente, considere rebanadas verticales del sistema (por ejemplo, ui, lógica empresarial y almacenamiento) en lugar de capas horizontales (E.g. 1 Equipo de UI, 1 equipo de lógica empresarial, etc.). De lo contrario, cada equipo puede ver demasiado del sistema.

De esta manera, cada equipo conocerá su componente, pero si alguien habla o toma el código en otra parte, lo peor que pueden hacer es hablar de su componente. A menudo ves este enfoque en sistemas muy sensibles a la seguridad.

Para componentes de acceso a la red, use autenticación , auditoría y usando diferentes credenciales de desarrollo y producción . Específicamente:

1. Haga que cada interfaz requiera autenticación, por ejemplo. un nombre de usuario y contraseña.
2. credenciales de pruebas de desarrollo de suministro, pero usan diferentes credenciales en la producción
3. Mantener un registro de auditoría de los accesos y revise regularmente.

Esto asegura que estos componentes se usen solo para fines previstos. Esta puede ser una razón para mover una funcionalidad fuera de la aplicación y en los servicios de la nube, por ejemplo.

Dicho esto, es probable que cualquier cosa que aflige el intercambio de información dentro del equipo tenga un impacto de la moral y el rendimiento del equipo. Efectivamente, está diciendo que no confía en su equipo de desarrollo . En ese caso, ¿cómo puedes esperar que confíen en ti? Si confía en sus desarrolladores y comparte su éxito con ellos, trabajarán más duro porque también lo es su producto.

Además, tenga en cuenta que la tecla para la mayoría de los proyectos nuevos es su ejecución, no la idea inicial . Su idea podría ser grande, pero, es probable que lo cambien, va a cambiar mucho a medida que desarrolle su producto y la exponga a los clientes.

Answer 3

Estoy convencido de que no tendrá éxito al fundar su esfuerzo comercial en la desconfianza abierta hacia sus colegas, recuerde, en realidad necesita que construyan el sistema, de lo contrario, no se preocupará por el tema de su pregunta a las direcciones.

También estoy convencido de que se centre en la propiedad intelectual del aspecto incorrecto WRT: Si bien es correcto que el código fuente encarna su producto, el borde de su compañía de fledgling será el cerebro de los miembros en la etapa de fundación. Cuanto más sugiera un comportamiento deshonroso o una violación absoluta de la ley entre sus codificadores, menos probable es que atraiga al personal dotado (o si lo hace, más fácil, los alienará). Pero cuanto más supere su equipo, en particular, en particular, ya que su producto probablemente evolucionará (posible lejos del concepto de incoate) para satisfacer la demanda del cliente, por lo que una instantánea de código fuente podría ser menos valiosa de lo que parece a primera vista.

un comentario constructivo por fin: El código fuente, incluso en idiomas de alto nivel, puede ser difícil de entender. Más aún, si los comentarios y la documentación son escasos e incompletos. Tu mejor protección podría ser

• un equipo dotado
• desarrollo sabio componente
• un estilo de codificación de 'no comentarios'.

Viola los principios básicos de la ingeniería SW, pero lo protegerá incluso si un miembro de su equipo lo abandona: como se habrá especializado naturalmente en solo algunos de los componentes de su aplicación, el impacto de la divulgación se mitiga un poco. < / p>

Descargo de responsabilidad: No soy fundador y no he trabajado en la India, así que tome las ideas con algún grano de sal.