Software no Registrado: La Odisea de Probar una Infracción
El Espejismo de la Creación: ¿De Quién es el Código?
La ley argentina, en un alarde de modernidad y confianza, establece que el software está protegido por el derecho de autor desde el momento mismo de su creación. La Ley 11.723, en su infinita sabiduría, lo equipara a una obra literaria, científica o artística. Esto significa que no se necesita ningún papel, ningún sello oficial, para que el autor sea, en teoría, el dueño de su creación. Una idea magnífica que reconforta el alma de todo desarrollador que pasa noches en vela frente a una pantalla.
Ahora, la incómoda verdad. Esa protección que nace con la obra es, sin el registro correspondiente ante la Dirección Nacional del Derecho de Autor (DNDA), poco más que una declaración de buenas intenciones frente a un juez. El Decreto 165/94, que regula la inscripción de los programas de computación, es la pieza clave. El registro no es constitutivo del derecho –el derecho ya existe–, pero sí es la llave que abre la puerta a una defensa judicial medianamente civilizada. ¿Por qué? Porque el certificado de registro otorga una presunción de titularidad. Quien figura en ese papel es, hasta que se demuestre lo contrario con pruebas contundentes, el autor y titular de los derechos.
Sin ese certificado, la situación se invierte de forma dramática. El supuesto autor ya no tiene una presunción a su favor; tiene una carga. La carga de probar que él, y no otro, es el creador de la obra en disputa. De repente, debe convertirse en un arqueólogo de su propio trabajo. Tiene que desempolvar correos electrónicos, contratos de desarrollo, facturas, mensajes de Slack, registros de versiones en Git o SVN, y cualquier otro documento que pueda acreditar la fecha y autoría de su creación. Es como tener un auto espectacular, pero sin la cédula verde ni el título de propiedad. Se puede usar, claro, pero el primer control policial se convierte en un problema existencial.
Este es el primer y más grande obstáculo. Antes de siquiera entrar a discutir si hubo o no una copia, el autor sin registro debe construir, pieza por pieza, su legitimidad como demandante. Es un desgaste previo, una batalla preliminar que muchos subestiman y que puede hacer naufragar el caso antes de zarpar.
La Danza de los Peritos: El Código como Campo de Batalla
Superada la cuestión de la titularidad –o mientras se intenta superar–, nos adentramos en el corazón técnico del conflicto: demostrar la copia. Y aquí, las cosas se ponen aún más interesantes. Rara vez un infractor es tan torpe como para realizar una copia literal, un simple «copiar y pegar» del código fuente. Eso sería demasiado fácil. La verdadera batalla se libra en el terreno de la copia no literal, también conocida como la infracción de la «estructura, secuencia y organización» del software.
Esto significa que dos programas pueden tener un código fuente que, a simple vista, parece diferente, pero que por debajo comparten la misma lógica, la misma arquitectura, los mismos flujos de datos y las mismas soluciones a problemas específicos. Es como dos autos de marcas distintas que usan exactamente el mismo motor y chasis, pero con una carrocería diferente. Para un usuario común, son distintos. Para un mecánico, son gemelos. En nuestro caso, el mecánico es el perito informático.
El perito es la figura central. Su misión es realizar un análisis comparativo profundo entre el software presuntamente original y el presuntamente infractor. No busca palabras idénticas, sino patrones. Busca esas «huellas digitales» que todo programador deja, a menudo sin darse cuenta: nombres de variables peculiares, comentarios en el código, errores recurrentes, funciones escritas de una manera ineficiente pero idéntica en ambos programas, o el uso de algoritmos complejos que resuelven un problema de una forma muy específica y poco convencional. Estos son los «tics de programador» que delatan la copia. El informe pericial que resulte de este análisis será la columna vertebral de la acusación o de la defensa. Sin un peritaje sólido, claro y convincente, el reclamo se desvanece en un mar de jerga técnica que ningún juez tiene por qué entender.
Consejos para el Acusador: Preparando la Artillería
Si usted es el creador y siente que su obra ha sido plagiada, la impulsividad es su peor enemiga. Proceda con la frialdad de un cirujano. Primero, documente todo. Su mejor defensa es un ataque bien preparado. Reúna cada prueba de su autoría: repositorios de código con fechas, correos, contratos, especificaciones funcionales. Si no registró la obra en su momento, considere hacer un «depósito en custodia» ante un escribano público. Esto no reemplaza al registro, pero crea una prueba con fecha cierta de que en ese día, usted tenía ese código en su poder. Es una foto que congela el tiempo a su favor.
Segundo, contrate a un excelente perito informático. No escatime. Este profesional debe realizar un análisis preliminar antes de que usted mueva un solo dedo legalmente. Necesita saber si su sospecha tiene fundamento técnico real o si es solo una paranoia. El perito debe comparar ambos programas y emitir un dictamen claro sobre si existe o no una similitud sustancial que sugiera una copia. Este informe inicial es su termómetro; le dirá si tiene un caso sólido o si está por embarcarse en una aventura legal muy cara y con pocas chances de éxito.
Tercero, sea estratégico. Una vez que tenga el informe pericial preliminar en mano y este sea favorable, puede proceder. El primer paso suele ser una intimación extrajudicial, la clásica carta documento. Pero no una genérica. Debe ser precisa, detallando la obra presuntamente infringida y la naturaleza de la infracción, quizás incluso anticipando que posee pruebas técnicas que lo respaldan. A veces, una demostración de fuerza bien documentada es suficiente para que la otra parte se siente a negociar y evite un litigio largo y costoso para todos.
Consejos para el Acusado: Navegando la Tormenta
Ahora, pongámonos del otro lado del mostrador. Recibir una carta documento acusándolo de plagio de software puede generar pánico. Mantenga la calma. Lo primero es no ignorarla. El silencio puede ser interpretado como una admisión de culpa. Lo segundo es recordar una verdad fundamental: la carga de la prueba recae sobre quien acusa. No es usted quien debe probar su inocencia; es el demandante quien debe probar, de manera fehaciente, su culpabilidad.
Su defensa debe centrarse en dos pilares. El primero es atacar la supuesta prueba de la copia. Su propio perito informático debe analizar el informe de la otra parte y buscar sus debilidades. ¿Las similitudes encontradas son realmente significativas o se deben a que ambos programas resuelven un problema común de la manera más lógica y eficiente? ¿Se basan en algoritmos que son de dominio público? ¿O quizás utilizan librerías de código abierto (open source) que ambos tienen derecho a usar? Demostrar que las similitudes son funcionales, estándar o basadas en fuentes públicas desarma gran parte del ataque.
El segundo pilar, y quizás el más fuerte, es la defensa del «desarrollo independiente» o «cuarto limpio» (clean room). Si puede demostrar que su equipo desarrolló el software desde cero, sin haber tenido jamás acceso al código fuente del demandante, la acusación de copia se cae por su propio peso. ¿Cómo se prueba esto? De nuevo, con documentación. Registros de desarrollo, control de versiones que muestre una evolución orgánica del código, especificaciones de diseño creadas internamente, actas de reuniones de equipo, testimonios de los programadores. Debe construir una narrativa sólida y creíble de su propio proceso creativo. Esta es su coartada técnica, y si está bien documentada, es casi irrefutable.
Finalmente, exija precisión. Obligue al acusador a especificar qué partes exactas de su código consideran una copia. Una acusación vaga de «se parece a mi programa» es inadmisible. Deben señalar líneas, módulos, estructuras. Cuanto más se los obligue a ser específicos, más oportunidades tendrá su defensa para demostrar que esas similitudes son triviales, funcionales o meramente casuales. En esta guerra de percepciones, la precisión es su mejor escudo.
