Certificados de retribución

Los certificados de retribución son sellos públicos, verificables criptográficamente, que una autora o colectivo productor otorga a una entidad que obtiene beneficio económico de su trabajo.

No sustituyen a las licencias. Operan junto a ellas, en un registro distinto: el plano reputacional y cultural, no el jurídico.

Qué hacen

• Hacen visible lo que la licencia sola no muestra: un certificado convierte una práctica de retribución en un hecho público que cualquier tercero puede verificar.
• Son agnósticos a la licencia: funcionan con GPL, AGPL, MIT, LCL, RCL o cualquier otra licencia.
• Permiten retribución gradual: una empresa puede retribuir a múltiples proyectos o personas a niveles distintos y documentar cada uno por separado.

Cómo funcionan

1. La autora o proyecto destinatario publica una clave pública asociada a su identidad. La entidad beneficiaria hace lo mismo.
2. Al cierre de un período de referencia, la entidad prepara una solicitud de certificado describiendo la práctica de retribución aplicada.
3. La entidad firma la solicitud con su clave privada y la envía a la autora o al proyecto.
4. La autora evalúa si la práctica es adecuada. Si lo considera así, firma el documento con su clave privada. El resultado, firmado por ambas partes pero emitido por decisión de quien recibe, es el certificado de retribución.
5. El certificado se publica en un lugar consultable e inmutable, un repositorio git público cumple ambas condiciones, donde cualquier persona puede verificar las firmas.

La firma del autor o del proyecto destinatario sobre el mismo documento es el acto de reconocimiento. No se requiere modificar el archivo después de la primera firma: ambas firmas detached coexisten sobre el mismo archivo TOML.

Formato del certificado (TOML)

El certificado es un archivo de texto legible. Estos son los campos mínimos recomendados:

[certificate]
id = "cert-2026-acme-audio-lib"
version = "1.0"
period_start = "2026-01-01"
period_end = "2026-03-31"

[parties.beneficiary]
name = "Acme Corp"
email = "legal@acme.corp"
public_key = "RWRg..."

[parties.recipient]
name = "María López"
email = "maria@ejemplo.com"
public_key = "RWQf..."

[work]
name = "Biblioteca de Análisis de Audio"
repository = "https://github.com/maria/audio-lib"

[practice]
description = "Retribución voluntaria por uso comercial en el período"
declared_amount = 5000   # opcional
currency = "EUR"         # opcional
method = "transferencia" # opcional

Los campos financieros son opcionales. Si el beneficiario prefiere discreción, puede omitir el monto y describir la práctica en description. Lo que no es negociable es la doble firma sobre un documento público.

Pasos prácticos

Usamos minisign como herramienta por defecto. Es mínima, moderna y suficiente. Si ya usas GPG, el flujo es análogo.

1. Generar claves

Cada parte lo hace una sola vez:

minisign -G
# Guarda minisign.key (privada) y minisign.pub (pública)

La cadena que empieza con RW... en minisign.pub es la que se anota en el campo public_key del certificado.

2. Crear y firmar el certificado

La entidad beneficiaria rellena el TOML y lo firma:

minisign -Sm cert-2026-acme-q1.toml
# Genera cert-2026-acme-q1.toml.minisig

3. La autora o proyecto revisa y firma

Recibe el archivo TOML y la firma .minisig. Verifica:

minisign -Vm cert-2026-acme-q1.toml -p acme.pub -x cert-2026-acme-q1.toml.minisig

Si está de acuerdo, firma el mismo archivo:

minisign -Sm cert-2026-acme-q1.toml -x cert-2026-acme-q1.toml.author.minisig

Resultado: tres archivos que viajan juntos:

1. cert-2026-acme-q1.toml el certificado.
2. cert-2026-acme-q1.toml.minisig firma del beneficiario.
3. cert-2026-acme-q1.toml.author.minisig firma del receptor.

4. Publicar

Súbelos a un repositorio git público o a una web estática:

git add cert-2026-acme-q1.toml \
        cert-2026-acme-q1.toml.minisig \
        cert-2026-acme-q1.toml.author.minisig
git commit -m "Certificado de retribución Q1 2026"
git push

5. Verificar

Cualquiera puede verificar ambas firmas:

minisign -Vm cert-2026-acme-q1.toml -p acme.pub -x cert-2026-acme-q1.toml.minisig
minisign -Vm cert-2026-acme-q1.toml -p maria.pub -x cert-2026-acme-q1.toml.author.minisig

Si ambos comandos devuelven Signature and comment signature verified, el certificado es auténtico.

Verificación

Cualquier usuario puede verificar un certificado con herramientas estándar. No se requiere confiar en una autoridad central. La fuerza del certificado viene del reconocimiento público, no de una jerarquía externa.

Qué no son

• No son un mecanismo de enforcement: no obligan a nadie a nada; acreditan algo que ya ocurrió.
• No son una certificación de autoridad: no hay tribunal que los expida ni organismo que los avale.
• No garantizan sustento: crean una infraestructura que permite que la retribución, cuando existe, sea visible.

Consideraciones prácticas

Si las partes no se ponen de acuerdo

La autora o proyecto destinatario no está obligada a firmar. Si considera que la práctica es inadecuada, puede negociar, solicitar auditoría, o simplemente no emitir el certificado. La ausencia de firma no es sanción, pero sí es información pública.

Si el certificado se edita después de firmar

Cualquier cambio en el archivo .toml invalida las firmas. Hay que generar un nuevo certificado y firmarlo de nuevo.

Rotación de claves

Si una clave privada se ve comprometida, la parte afectada genera un nuevo par, publica la nueva clave pública y reemite los certificados vigentes con la nueva firma. Los antiguos se mantienen en el histórico.

Horizonte

Esperamos que surjan registros comunitarios donde los certificados puedan depositarse, indexarse y consultarse con facilidad. A largo plazo, gestores de dependencias podrían reportar el estado de retribución de los componentes usados, y los usuarios finales podrían verificar la ética de sus proveedores sin esfuerzo.

Los certificados completan, en el plano reputacional, lo que las licencias hacen en el plano jurídico. Juntos forman una propuesta más densa que cualquiera de las dos piezas por separado.