Resumen

  • Balsam obtuvo una sentencia en rebeldía de 1,125 millones de dólares tras alegar la recepción de 1.125 correos comerciales ilícitos, pero no logró cobrarla.
  • El Noveno Circuito sostuvo que el apartado 3.7.7.3 debía incorporarse a otro contrato, mientras que el 5.10 negaba derechos a terceros bajo el propio RAA.
  • El fallo rechazó la teoría de beneficiario tercero; no resolvió si la cláusula aguas abajo se cumplió, si divulgar era conveniente o si ICANN podía ejecutar su acuerdo.

Ganar el caso no reveló a quién cobrar

El expediente no comenzó con una víctima que aún buscaba una sentencia. Daniel Balsam ya la tenía. La opinión oficial del Noveno Circuito recoge que afirmó haber recibido 1.125 mensajes no solicitados entre octubre de 2005 y mayo de 2006. En marzo de 2008, un tribunal federal dictó contra Angeles Technology una sentencia en rebeldía por 1,125 millones de dólares.

El fallo no proporcionó un deudor localizable. La base pública había mostrado a Tucows como registrador y a Angeles como titular de adultactioncam.com. Según la opinión, Angeles aparentemente activó después Contact Privacy. La descripción del arreglo procedía de las alegaciones de Balsam; el tribunal de apelación no celebró un juicio sobre la arquitectura completa del servicio.

Balsam encontró una frase prometedora en el Registrar Accreditation Agreement entre ICANN y Tucows. El apartado 3.7.7.3 trataba al titular que cedía el uso de un nombre. En términos generales, debía asumir responsabilidad por el uso ilícito salvo que identificara con prontitud al licenciatario ante quien aportara pruebas razonables de un daño accionable.

Su demanda conectó tres elementos: una sentencia, una identidad custodiada por el servicio de privacidad y una consecuencia contractual para la falta de identificación. Pidió a Tucows que revelara al operador o pagara el importe del fallo.

La conexión económica era directa. La conexión jurídica no lo era.

La frase pertenecía a otro contrato

El apartado 3.7.7 exigía al registrador celebrar con cada titular un acuerdo de registro separado que contuviera determinadas cláusulas. El 3.7.7.3 era una de ellas. Por tanto, el RAA imponía al registrador una obligación de incorporar lenguaje a un contrato posterior; no formulaba una promesa independiente a favor de cada perjudicado.

El apartado 5.10 cerraba la vía contraria. El RAA no creaba obligaciones de ICANN ni del registrador frente a ningún tercero, incluido un titular. El archivo de ICANN identifica el formulario de 17 de mayo de 2001, y una copia escaneada aparece en el expediente de ICANN en el litigio Pool.com.

Balsam argumentó que la cláusula específica debía prevalecer sobre la exclusión general de beneficiarios. El tribunal no encontró intención contractual que apoyara esa lectura. Ordenar que un registrador incluyera una condición en otro acuerdo no convertía a la persona mencionada por esa condición en beneficiaria del RAA.

El límite procesal fue decisivo. Balsam había admitido que sus cuatro pretensiones —contrato, negligencia, conspiración civil y declaración judicial— dependían de su condición de beneficiario tercero. Al caer esa premisa, no quedó una base autónoma que enmendar. El rechazo con efecto definitivo fue confirmado.

Lo que la sentencia dejó abierto

No es correcto resumir el caso como si hubiera eliminado toda obligación de identificar. El Noveno Circuito decidió que Balsam no podía ejecutar el RAA con la teoría presentada. No decidió que el titular pudiera ignorar las condiciones de su propio acuerdo de registro.

La opinión señaló que Balsam ni siquiera había alegado que Tucows omitiera celebrar el acuerdo separado exigido por el apartado 3.7.7. Por ello no interpretó el texto completo de ese contrato, sus posibles beneficiarios ni su cumplimiento. Cualquier reclamación fundada en él necesitaría su propia prueba de partes, intención, ley aplicable y legitimación.

Tampoco se negó a ICANN la capacidad contractual. ICANN era parte del RAA; Balsam no. Rechazar la legitimación de un extraño no extingue los derechos del contratante. La apelación no evaluó si ICANN debía actuar, qué expediente de cumplimiento tenía ni qué remedio contractual podía utilizar.

El borrador de aviso de ICANN de mayo de 2010 ayuda a delimitar el problema. Reconocía que el RAA no definía qué era una prueba razonable de daño accionable ni qué significaba identificar “con prontitud”. Contemplaba que un juez o árbitro valorara esas cuestiones.

El documento era expresamente un borrador. Su referencia orientativa a cinco días hábiles no fue una norma vinculante ni una regla adoptada por el tribunal. Sí demuestra que, incluso en el análisis institucional de ICANN, hacía falta una capa de decisión entre recibir pruebas y asignar responsabilidad.

El coste y el poder quedaron separados

Balsam cargaba con los mensajes, el pleito y la falta de cobro. Tucows controlaba el servicio registral y, según las alegaciones, el dato de identidad. ICANN tenía los derechos de ejecución del contrato de acreditación. Los tribunales controlaban la legitimación y el proceso obligatorio.

La cláusula hablaba de la persona perjudicada porque describía las pruebas que esta podía entregar. Pero el RAA no la nombraba ejecutora. Una norma puede reconocer el papel operativo de alguien y mantenerlo fuera del mecanismo jurídico que la hace efectiva.

Esa separación no era puramente defensiva. Los clientes legítimos necesitan protección contra solicitudes de divulgación improvisadas. Una acusación privada no debe sustituir el umbral probatorio, la notificación y la revisión. La exclusión de terceros también evita interpretaciones contradictorias del sistema de acreditación en miles de pleitos.

La concentración de autoridad, no obstante, desplaza el riesgo. ICANN y el registrador no soportan el fallo incobrable. Si el actor autorizado no ofrece un canal razonado, la obligación pública existe sin producir una decisión para quien aportó el daño y la evidencia.

Un procedimiento limitado

La alternativa no es revelar automáticamente. Un procedimiento acotado pediría evidencia definida, preservaría registros, autenticaría al solicitante y avisaría al cliente salvo que existiera un riesgo documentado para la conservación.

En un plazo breve, el proveedor podría divulgar de forma protegida a un destinatario autorizado, rechazar con razones, mantener datos o estado temporalmente, o escalar a ICANN, a un regulador o a un tribunal. El cliente tendría una oportunidad de responder y el solicitante conocería al dueño de la siguiente decisión.

Ese mecanismo no convertiría al solicitante en beneficiario del RAA. Haría verificable la forma en que la institución autorizada utiliza el poder que decidió conservar.

Fuentes