¿Por qué la ACTI pretende castrar la competitividad de las empresas que desarrolla(ría)n software en Chile?

Esta es una pregunta que personalmente me tiene desconcertado. Supuestamente la ACTI (Asociación Chilena de Empresas de Tecnología de Información A.G.) representa los intereses de la Industria chilena de Empresas de TI. Esto incluye tanto a las empresas dedicadas al software como a servicios y productos relacionados, y dentro de las empresas dedicadas al software podemos diferenciar entre las que desarrollan software en Chile y las que no. Por otra parte está la GECHS-Software y Servicios Chile A.G. (también conocido como Grupo Chileno de Empresas de Software), que ha tenido sus encuentros y desencuentros con la ACTI, y agrupa a las empresas relacionadas directamente con software, y tiene una reputación de agrupar más bien a las empresas que desarrollan software en Chile, un subconjunto de las que puede representar ACTI, y en general de menor tamaño.

¿Castrar la competitividad de las empresas que desarrolla(ría)n software en Chile?

En el título hago una afirmación que es necesario aclarar un poco para dar contexto: por qué digo que la ACTI "pretende castrar la competitividad de las empresas que desarrolla(ría)n software en Chile?". Básicamente me estoy refiriendo al tema de la Ingeniería Reversa. Lo que propone la ACTI es que las excepciones que explícitamente permiten la Ingeniería Reversa para el caso del software se limiten exclusivamente a situaciones en las que:

1. exista algún tipo de protección tecnológica para acceder al código del software
2. el objetivo sea únicamente de interoperabilidad, sin incluir desarrollo ni investigación

Es evidente que esto afecta muy negativamente a la investigación en seguridad y en software en general, pero dado que no es un rol primordial de la ACTI (aunque sería un aporte al país que sí lo tomaran) de incentivar la investigación o al menos no la coharten, no es tan raro. Voy a partir por explicar los hechos que me motivan a señalar que la ACTI está disminuyendo la competitividad de aquellos representados suyos que osan desarrollar software en Chile.

Los hechos

1. La ingeniería reversa está permitida en EEUU y Europa.

Es cierto que la DMCA prohibe la ingeniería reversa (y muchas otras cosas) cuando existen medidas de protección tecnológicas (que llama "efectivas", aunque nunca lo han sido) involucradas para acceder al código, salvo para interoperabilidad y excepciones aprobadas legalmente caso a caso. Esto último ha sido muy criticado por lo demás, y no constituye el mejor ejemplo de implementación. Sin embargo, cuando no hay medidas tecnológicas, no aplica la DMCA y por ende los usos legales de ingeniería reversa son bastante más amplios. Eso la ACTI convenientemente lo ignora en sus argumentos.

La ACTI también ignora convenientemente el artículo 5 de la directiva 91/250/EEC que ellos citan, donde se permite, contrario a lo que ellos postulan, la ingeniería reversa para corregir errores, así como observar, estudiar y probar los programas. No excluyen que posteriormente, con el conocimiento adquirido, se puedan desarrollar programas que compitan con los que fueron sujetos a ingeniería reversa.

2. La ingeniería es necesaria para el desarrollo de aplicaciones

La documentación de software es una de las tareas más tediosas y menos gratificantes del proceso de desarrollo de software. Es por ello que, para razones de interoperabilidad, para poder generar software que se incorpore exitosamente en ciertos sistemas (sistemas operativos en particular) y otros, se debe recurrir a la ingeniería reversa ante la falta de documentación que explique adecuadamente cómo hacerlo. Veamos un ejemplo concreto: la Cryptoapi de Microsoft. Es la única forma de que una aplicación tenga acceso a elementos como los certificados del usuario, y por ende de generar firmas, validar firmas de terceros y una serie de otras acciones. Hay funciones no documentadas que se han hecho públicas justamente gracias a la ingeniería reversa, y es necesario que un desarrollador pueda:

• Validar qué hace la librería, en particular cómo es utilizada por su competencia, que puede tener información privilegiada
• Conocer la mejor forma de acceder a esa librería, para no estar en desventaja con su competencia.

Algunos ejemplos de casos donde la ingeniería reversa es crucial para el desarrollo de software:

• Para dispositivos que puedan operar en sistemas no considerados por el fabricante. Normalmente, el fabricante entrega drivers para ciertos sistemas soportados, pero para utilizar el dispositivo en otros sistemas es necesario que terceros puedan desarrollar estos drivers. Esto se da comúnmente en el caso de tarjetas de video, cámaras web y muchos otros dispositivos.
• Para programas que interactúen con servidores o aplicaciones de terceros, tales como aplicaciones de mensajería instantánea o chat. Independiente que la razón de la no disponibilidad de documentación sea la falta de interés del fabricante, su incompetencia o alguna intención de aprovechar o mantener un monopolio, la ingeniería reversa es la forma de solucionar la disponibilidad de software.
• Para incorporar un software en una plataforma específica que no provee la documentación necesaria. Esto incluye sistemas operativos para computadores de escritorio, teléfonos celulares y otro tipo de PIMs. Hay ejemplos donde, gracias a la ingeniería reversa, se ha logrado proveer un firmware mejor al existente para reproductores MP3 por ejemplo, dando inicio a una oferta en un mercado nuevo. Ya mencioné arriba el ejemplo de la Cryptoapi como otro ejemplo.

3. La ACTI basa toda su argumentación en que solamente se debe permitir la ingeniería reversa para acceder a código protegido explícitamente por medidas de protección tecnológicas.

Bueno, basta leer los comentarios, hay un link en un artículo anterior sobre el tema.

4. La mayoría del software no incluye medidas de protección tecnológica hoy en día

Hay que notar que utilizar restricciones para instalar o activar el software son medidas contra el uso del software, no contra un acceso al código del software, por lo tanto no cuentan como medida de protección en este contexto. Irónicamente, un software que no cuente con medidas de protección tecnológicas tendría restricciones legales mucho más fuertes que un software que las incluya.

Discusión

La propuesta de la ACTI de entregar la facultad legal de acceder al código solamente si el desarrollador del código original lo desea (al agregar una medida tecnológica de protección), es dejar al gato a cargo de la carnicería. Habrá empresas que no quieran agregar medidas tecnológicas de protección, y con eso nadie podrá conocer legalmente su funcionamiento interno para validar si hace lo que promete, para desarrollar software que pueda interactuar con él ni muchas otras actividades abosolutamente razonables.

Dado que la ingeniería reversa está permitida en muchos países, los desarrolladores chilenos quedan en desventaja. Si quisiéramos hacer ingeniería reversa, debiéramos ir a Mendoza, Lima o Córdova, donde seguiría siendo legal. Si el objetivo es desincentivar el desarrollo de software en Chile, es un buen camino. Parece que la ACTI está muy mal asesorada en este tema.

Casos en los cuales la industria de software nacional estaría en desventaja

En caso de aprobarse los cambios solicitados por la ACTI, hay una serie de consecuencias negativas para los desarrolladores de software, por ejemplo:

• Cómo podría un desarrollador de software defenderse frente a una competencia desleal o lisa y llanamente estafadora, que vende software que supuestamente hace lo mismo, pero en la práctica no lo hace? Hoy en día puede demostrar que el software de la competencia no hace lo que dice, pero a futuro eso estaría prohibido.
• ¿Cómo podría un desarrollador hacer que su aplicación funcione en un sistema con poca o nula información disponible? Actualmente puede utilizar la ingeniería reversa para averiguar lo que le falta. A futuro, tendría que comenzar por largas demandas ante tribunales de libre competencia, para después de muchos años y recursos invertidos les entreguen un documento con información, probablemente cumpliendo con ser "too little, too late".
• ¿Cómo podría un desarrollador generar un software que sea compatible con otro que se usa en muchos computadores, donde el proveedor de ese otro software aprovecha su monopolio en otros campos para evitar la competencia? Si tiene prohibición de hacer ingeniería reversa, deberá contratar a especialistas en otras partes del mundo.