Patentes de Software vs. Copyright: El Conflicto de los Algoritmos
El campo de batalla: Copyright, no patentes
Llega el caso al estudio y la historia es siempre la misma. Una empresa de tecnología, generalmente joven, pujante, acusa a otra, generalmente más grande y con más espalda, de haberle robado una idea. Un algoritmo mágico, una funcionalidad revolucionaria. Y lo primero que uno escucha es la palabra maldita: ‘patente’. ‘Le violaron la patente del software’. Y ahí, antes de siquiera pedir el primer café, hay que empezar a desarmar el nudo. Porque en nuestra querida jurisdicción, esa idea de la ‘patente de software’ es, para ser elegante, una importación conceptual que no termina de encajar. Una fantasía. La realidad, la cruda realidad que mastican los tribunales, es mucho más terrenal y se llama derecho de autor.
Seamos claros. El software, para nuestra ley madre en la materia, la 11.723, es considerado una obra. Pero no una obra de ingeniería ni un invento. Es una obra literaria, o científica, si se quiere. Así de simple y así de complicado. Esto significa que lo que se protege no es la idea genial, no es la función que cumple el algoritmo de recomendación, no es el ‘qué hace’. Lo que se protege es el ‘cómo lo hace’, la expresión concreta de esa idea en un lenguaje de programación. El código fuente. Línea por línea, como si fuera el manuscrito de una novela. Una novela bastante aburrida para la mayoría, pero una novela al fin.
Esta distinción no es un capricho académico, es la columna vertebral de cualquier estrategia legal. Porque si el cliente viene a decirme ‘me copiaron la idea de recomendar productos basados en el clima’, mi respuesta es, lamentablemente, ‘mala suerte’. Las ideas son libres como el aire. Ahora, si me dice ‘me copiaron estas tres mil líneas de código que implementan esa idea’, ahí sí tenemos una conversación. Ahí sí podemos empezar a hablar de infracción. El derecho de autor no protege el monopolio sobre una funcionalidad, protege la expresión original de un autor, en este caso, un programador o un equipo de ellos.
Entonces, el primer paso en esta guerra siempre es el mismo: reeducar. Explicarle al cliente que su pelea no es por la patente de un invento, sino por los derechos de autor sobre una creación intelectual. Que su algoritmo, esa secuencia de pasos lógicos, en abstracto, no tiene dueño. Pero que su implementación, su código, sí lo tiene. Y que toda la batalla se va a librar en ese terreno: en demostrar que el código del demandado es una copia, una reproducción no autorizada o una transformación ilícita del suyo. Es un cambio de paradigma que duele, porque baja las expectativas de ‘soy el dueño de la recomendación de productos’ a ‘soy el dueño de esta forma particular de escribir cómo se recomiendan productos’. Pero es el único punto de partida realista para no estrellarse contra la primera pared del juzgado.
Las armas que tenemos (y sus limitaciones)
Una vez que todos entendemos que estamos en una pelea de derecho de autor, hay que revisar el arsenal. El arma principal, como dije, es la Ley 11.723. Una ley del año 1933, señores. Obviamente, con sus parches y modificaciones, como la que incluyó explícitamente a los programas de computación. Pero su espíritu sigue siendo el de proteger a un autor de carne y hueso, no a una corporación con un ejército de programadores. Esto genera una tensión constante. Los jueces, a menudo formados en una tradición jurídica muy humanista, tienden a buscar al ‘creador’ y a veces se pierden en la complejidad de la creación colectiva y anónima que caracteriza al desarrollo de software moderno.
Luego está la jurisprudencia. Y acá la cosa se pone… interesante. Nuestros tribunales tienen lo que a mí me gusta llamar una ‘sensibilidad social’ particular. Han dictado fallos donde, a falta de una prueba directa y contundente, se han inclinado por proteger al desarrollador local frente a la multinacional, o a la parte que consideran más débil. Se valen de presunciones, de indicios. A veces, la simple transferencia de un empleado clave de una empresa a otra ha sido suficiente para encender las alarmas de un juez y dar vuelta una decisión. No es que ignoren la ley, pero la interpretan con una plasticidad que a veces sorprende. Esto es un arma de doble filo: puede ayudarte si sos David, pero te puede liquidar si sos Goliat.
Otra herramienta, más administrativa que otra cosa, es el registro en la Dirección Nacional del Derecho de Autor. Registrar el software. Un trámite que muchos desarrolladores ignoran. Se presenta una parte del código en un sobre lacrado y se obtiene un certificado. ¿Esto prueba que vos sos el autor? No, el registro es declarativo, no constitutivo de derechos. Es decir, no te ‘da’ la autoría, solo declara que en tal fecha vos dijiste ser el autor. Pero en un juicio, ese papelito tiene un peso enorme. Es una presunción de autoría y titularidad que obliga al otro a tener que probar lo contrario. Es como empezar el partido ganando uno a cero. Un trámite tedioso, burocrático, pero que en la trinchera legal vale oro.
Sin embargo, todas estas armas tienen pólvora mojada si no resolvemos el problema central. El problema que define el 99% de estos casos. La prueba.
La prueba: el Santo Grial del litigio de software
Aquí es donde la teoría legal choca de frente con la realidad técnica. Probar que un software es una copia de otro es endemoniadamente difícil. Rara vez, muy rara vez, uno se encuentra con una copia literal, un ‘copy-paste’ descarado. Lo habitual es más sutil: código refactorizado, nombres de variables cambiados, lógica reordenada pero estructuralmente idéntica. Es como acusar a alguien de plagiar una novela porque usó la misma trama, los mismos arquetipos de personajes y hasta frases similares, pero cambiándole el nombre a los protagonistas y el escenario.
Acá entra en escena el verdadero protagonista de este drama: el perito informático. El abogado propone, pero el perito dispone. Es él quien se va a sumergir en miles de líneas de código y va a emitir un dictamen que, para el juez, que con suerte sabe mandar un correo electrónico, será prácticamente palabra santa. La elección de un buen perito es más importante que la del mejor de los abogados. Necesitás a alguien que no solo sepa de código, sino que sepa ‘traducir’ sus hallazgos a un lenguaje que un juez pueda entender. Alguien que pueda explicar por qué dos fragmentos de código, aunque no se vean idénticos, hacen exactamente lo mismo de una manera tan peculiarmente similar que la única explicación razonable es la copia.
¿Y qué busca el perito? Busca ‘huellas dactilares’. Comentarios en el código que el ‘copiador’ se olvidó de borrar. Nombres de funciones o variables internas que son idénticos. Errores o ‘bugs’ que se replican misteriosamente en ambos programas. La presencia de ‘código muerto’ o no funcional que fue arrastrado en la copia. O, la prueba reina, la comparación estructural. Existen herramientas que analizan la arquitectura, los flujos de datos y la lógica de control para determinar el grado de similitud más allá de lo cosmético. Es un trabajo de arqueología digital.
Para llegar a ese punto, a menudo se necesita una medida preliminar, el famoso ‘auto judicial’ para asegurar la prueba. Es decir, caerle con una orden del juez a la empresa demandada y secuestrar servidores, discos rígidos o pedir acceso a sus repositorios de código. Es una medida drástica, casi un allanamiento. Y hay que justificarla muy bien, porque ningún juez la va a conceder a la ligera. Hay que presentar indicios serios de que la copia existe y de que hay riesgo de que la evidencia se destruya. Es una jugada de alto riesgo: si la pedís y no encontrás nada, tu caso queda herido de muerte y te exponés a una contrademanda por los daños y perjuicios. Pero si no la pedís, quizás nunca consigas el código para que tu perito lo analice. Un verdadero dilema estratégico.
Consejos desde la trinchera: cómo sobrevivir a esto
Después de años viendo estas batallas, uno aprende a dar consejos que no están en los libros. Son consejos fríos, calculados, que apuntan a la supervivencia, no a la justicia poética. Y valen para ambos lados del mostrador.
Para el demandante (el que se siente robado):
Primero, la prevención es tu mejor arma. Documentá tu proceso de desarrollo. Usá sistemas de control de versiones como Git, que dejan un rastro auditable de quién escribió qué y cuándo. Y, por favor, registrá tu software. Hacelo con cada versión importante. Es un seguro barato. Guardá una copia del sobre lacrado y el certificado como si fuera el título de propiedad de tu casa.
Segundo, antes de mandar una carta documento o iniciar una demanda, hacé tu propia investigación. ¿Tenés sospechas fundadas? ¿Se fue un programador clave a la competencia justo antes de que lanzaran ese producto ‘sospechosamente’ similar? ¿Pudiste analizar el comportamiento de su software y encontraste similitudes funcionales inexplicables? Necesitás más que una corazonada. Necesitás indicios fuertes para convencer a un juez y para no quedar en ridículo.
Tercero, sé realista con tus objetivos. Ganar un juicio por millones en daños y perjuicios es una quimera. Lleva años, los cálculos de daños son complejos y difíciles de probar. Muchas veces, el objetivo más inteligente es conseguir una medida cautelar para que dejen de usar tu código. Frenar la sangría. Forzar una negociación desde una posición de fuerza. A veces, la mejor victoria es un buen acuerdo extrajudicial.
Para el demandado (el acusado de copiar):
Primero, no subestimes la acusación. Nunca. Apenas recibas la intimación, la primera llamada tiene que ser a tu abogado y la segunda a tu director de tecnología. Hay que hacer una auditoría interna inmediata y brutalmente honesta. ¿Es posible que alguien haya metido la pata? ¿Contrataron a alguien de la empresa demandante? ¿Qué políticas de ‘código limpio’ tienen? Es fundamental saber si tenés un problema real en casa antes de salir a contestar.
Segundo, tu mejor defensa es la prueba de la creación independiente. Lo que se conoce como ‘clean room development’. Si podés demostrar con registros, documentos, y testimonios que tu equipo desarrolló el software desde cero, sin acceso al código del demandante, tenés el caso casi ganado. La similitud, si la hubiera, se podría explicar como una consecuencia de que dos expertos, enfrentados al mismo problema técnico, llegaron a soluciones parecidas, algo que en programación es perfectamente posible.
Tercero, la estrategia del desgaste. Es la triste realidad. Estos juicios son largos y caros. Muy caros. Especialmente por los costos de los peritos. A veces, la estrategia no es demostrar inocencia, sino hacer que el proceso sea tan costoso y lento para el demandante que termine abandonando o aceptando un acuerdo por un monto irrisorio. No es noble, no es justo, pero es una táctica empresarial tan válida como cualquier otra en el campo de batalla legal.
Al final del día, estas disputas sobre algoritmos y código son un reflejo de nuestra época. Son conflictos donde la tecnología avanza mucho más rápido que la ley, y donde los abogados y los jueces hacemos lo que podemos para encajar estas nuevas realidades en viejas estructuras. Y en el medio, quedan las empresas, peleando no tanto por un principio de justicia, sino por una porción del mercado. Una pelea de perros grandes donde lo que menos importa, a veces, es quién tiene la razón.
