Skip to content

chore(license): relicense to Apache-2.0 + Safeguards (trademark) policy - #30

Closed
ggalancs wants to merge 1 commit into
mainfrom
chore/relicense-apache-dual
Closed

chore(license): relicense to Apache-2.0 + Safeguards (trademark) policy#30
ggalancs wants to merge 1 commit into
mainfrom
chore/relicense-apache-dual

Conversation

@ggalancs

Copy link
Copy Markdown
Owner

⚖️ NO ES ASESORÍA LEGAL. Es un cambio de licencia, irreversible una vez publicado. Revísalo con un abogado antes de mergear (sobre todo SAFEGUARDS.md y la postura de marca). No lo he auto-mergeado a propósito.

Esquema dual solicitado: core bajo Apache-2.0 + salvaguardas protegidas.

Qué hace

  • Código → Apache License 2.0. LICENSE reemplazado por el texto canónico de Apache-2.0; 355 cabeceras SPDX volteadas HRUL-1.0 → Apache-2.0; classifier OSI añadido. hfl pasa a ser open-source real (adopción, packaging, GitHub lo reconoce, confianza).
  • Salvaguardas → política de marca (SAFEGUARDS.md + NOTICE). Las 5 (verificación de licencia, procedencia, descargo de IA, privacidad, gating) se protegen vía trademark, no por copyright: el código Apache es libre, pero una distribución presentada como "hfl" debe mantenerlas activas. Un fork renombrado puede quitarlas (es su derecho bajo Apache) — pero no puede usar el nombre hfl.

Por qué marca y no copyleft por-fichero

Las salvaguardas son transversales (p. ej. el descargo de IA vive en el server.py del core), así que una dual-copyright fichero-a-fichero no es limpia sin refactorizarlas antes a módulos aislados. La vía de marca protege la marca + los usuarios hoy y mantiene el código 100% Apache. (Si en el futuro aíslas las salvaguardas en módulos, se puede pasar a dual-copyright por-fichero.)

Qué ganas / qué pierdes

  • Ganas: licencia OSI → adopción, contribuciones, ecosistema, SEO de "open source", reconocimiento de GitHub; protección de marca explícita (Apache §6) + descargo de responsabilidad.
  • Pierdes: la capacidad de impedir por copyright que un fork renombrado quite las salvaguardas (Apache lo permite). La protección pasa a ser de marca/reputación.

Detalles

  • HRUL conservado como LICENSE-HRUL-1.0.txt. LICENSE-FAQ.md (específico de HRUL) eliminado, sustituido por SAFEGUARDS.md. CHANGELOG con sección [Unreleased].
  • Pendiente menor: 2 HTML de arquitectura en docs/ aún mencionan HRUL/LICENSE-FAQ (docs generados; follow-up).

Verificación

python -m build + twine check PASSED; METADATA con classifier Apache OSI; suite completa 3525 passed, cobertura 89.5%. (El flip SPDX es solo comentarios → cero cambio de comportamiento.)

🤖 Generated with Claude Code

Move from the custom source-available HRUL v1.0 to a dual scheme:

- Code: Apache License 2.0 (LICENSE replaced; SPDX headers across 355 files
  flipped HRUL-1.0 -> Apache-2.0; OSI classifier added). This makes hfl a
  real open-source project — adoption, packaging, GitHub recognition, trust.
- Safeguards: the five responsible-use features (license verification,
  provenance, AI disclaimer, privacy, gating) are protected via the project's
  TRADEMARK policy (SAFEGUARDS.md + NOTICE) instead of copyright conditions.
  The Apache code is unrestricted; a distribution presented *as* "hfl" must
  keep the Safeguards active. A renamed fork may strip them under Apache.

Why trademark rather than per-file copyleft: the safeguards are cross-cutting
(e.g. the AI disclaimer lives in the core server), so a clean per-file
dual-copyright split isn't feasible without first refactoring them into
isolated modules. The trademark route protects the brand + users today and
keeps the code fully Apache.

HRUL text preserved at LICENSE-HRUL-1.0.txt; LICENSE-FAQ.md (HRUL-specific)
removed, superseded by SAFEGUARDS.md. CHANGELOG updated.

NOT LEGAL ADVICE — please have counsel review SAFEGUARDS.md / the trademark
posture before relying on it. Build + twine check pass; full suite green (3525).

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
@ggalancs ggalancs closed this Jul 20, 2026
@ggalancs
ggalancs deleted the chore/relicense-apache-dual branch July 20, 2026 08:35
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant