Toolbox — Sesión 07: GitHub como herramienta (repos, forks, licencias)

Objetivo de la sesión

Al terminar esta sesión serás capaz de:

1. Evaluar repositorios GitHub con criterios profesionales (no solo estrellas)
2. Entender las licencias open-source y sus implicaciones legales para tu proyecto
3. Hacer forks productivos y mantenerlos sincronizados
4. Usar GitHub Issues, Discussions y Projects como herramientas de gestión
5. Contribuir a proyectos open-source de forma profesional

Vídeo: Evaluando un repo en 2 minutos

1. Licencias: lo que DEBES saber antes de usar código ajeno

Por que importa (de verdad)

Cada repo en GitHub tiene una licencia que define que puedes y que NO puedes hacer con ese código. Ignorar la licencia puede tener consecuencias legales reales, especialmente si tu proyecto es comercial.

Las 4 licencias que vas a encontrar el 90% de las veces

GPL: la trampa para proyectos comerciales

GPL dice: si usas código GPL en tu proyecto, TODO tu proyecto debe ser GPL (código abierto). Esto se llama "copyleft" o efecto viral.

Excepción: Si solo usas la herramienta GPL como servicio externo (ej: ejecutas n8n como servicio separado, no integras su código en tu app), generalmente no aplica el copyleft. Pero es zona gris legal.

Regla práctica para SaaS:

    MIT / Apache 2.0 / BSD → Usar sin preocupacion
    AGPL → Cuidado, efecto viral mas fuerte (incluye uso en servidor)
    GPL → Solo como herramienta externa, nunca integrar codigo
    Sin licencia → NO USAR. Sin licencia = todos los derechos reservados
    

Como verificar la licencia

1. Abre el repo en GitHub
2. Busca el archivo LICENSE en la raíz
3. GitHub muestra un badge con el nombre de la licencia en la parte superior del repo
4. Si no hay archivo LICENSE: el código NO es open-source. No lo uses.

Atribución: como hacerla correctamente

Para MIT y Apache 2.0, basta con incluir en tu proyecto:

    // En un archivo THIRD_PARTY_LICENSES.md o en tu LICENSE
    
    This project uses the following open-source software:
    
    - [nombre-repo] (MIT License) — Copyright (c) [anio] [autor]
      https://github.com/[owner]/[repo]
    

2. Evaluar repos: más allá de las estrellas

Los 7 criterios (repaso profundo de AB-01)

Senales avanzadas de calidad

Senales de alarma

3. Forks: cuando y como

Cuando hacer fork

Como mantener un fork sincronizado

    # 1. Anade el repo original como "upstream"
    git remote add upstream https://github.com/original/repo.git
    
    # 2. Trae los cambios del original
    git fetch upstream
    
    # 3. Mergea en tu rama
    git checkout main
    git merge upstream/main
    
    # 4. Pushea a tu fork
    git push origin main
    

Regla: Si tu fork diverge mucho del original, mantenerlo sincronizado se vuelve difícil. Antes de forkear, preguntate: puedo conseguir lo que necesito con un PR al repo original?

4. GitHub Issues, Discussions y Projects

Issues: no solo para bugs

Antes de abrir un Issue

    1. Busca en Issues cerrados: alguien tuvo el mismo problema?
    2. Busca en Discussions: ya se discutio?
    3. Lee la doc: la respuesta puede estar ahi
    4. Si nada: abre Issue con toda la informacion necesaria
    

GitHub Projects para tu equipo

GitHub Projects es un tablero Kanban gratuito integrado con Issues y PRs.

Estructura recomendada:

    Columnas: Backlog | In Progress | Review | Done
    Cada tarjeta = 1 Issue
    Asignar a personas
    Linkear PRs
    

Para equipos pequenos (1-5 personas), GitHub Projects reemplaza a Jira/Linear sin coste.

5. Contribuir a open-source

Por que contribuir

1. Aprendes: Leer código de otros es la forma más rápida de mejorar
2. Portfolio: Contribuciones a repos conocidos valen más que proyectos propios en un CV
3. Networking: Los mantenedores son la gente más conectada del ecosistema
4. Reciprocidad: Si usas OSS gratis, contribuir es justo

Tu primera contribución (el camino fácil)

    1. Busca repos con label "good first issue" o "help wanted"
       → github.com/search?q=label%3A%22good+first+issue%22+language%3Apython
    2. Elige un issue sencillo (fix typo, mejorar doc, anadir test)
    3. Fork el repo
    4. Crea una rama: git checkout -b fix/typo-readme
    5. Haz el cambio
    6. Abre un PR con descripcion clara de que cambiaste y por que
    7. Responde al feedback del reviewer
    

Etiqueta de contribución

• Lee CONTRIBUTING.md antes de hacer nada
• Sigue el estilo de código del proyecto (no impongas el tuyo)
• PRs pequenos y focalizados (1 cambio por PR)
• Describe el POR QUE del cambio, no solo el QUE
• Se paciente: los mantenedores son voluntarios

6. Lab práctico: Evalua y forkea

Instrucciones

Evalua 5 repos para un proyecto real y haz un fork productivo. 25 minutos.

Paso 1: Evalua 5 repos (15 min)

Busca 5 repos relevantes para tu proyecto. Evalua cada uno:

Paso 2: Fork un repo (5 min)

1. Elige el repo con mejor score
2. Haz fork
3. Clona tu fork localmente
4. Añade upstream
5. Verifica que compila/funciona

Paso 3: Primera contribución (5 min)

Encuentra algo que mejorar (typo en doc, test que falta, ejemplo incompleto):

    Repo: _________________________________
    Cambio: _________________________________
    Rama: fix/_________________________________
    PR abierto: [ ] Si  [ ] No (pendiente)
    

Entregable de la sesión

Tu evaluación de 5 repos + fork productivo + primera contribución (o plan).

    EVALUACION DE REPOS
    ====================
    
    Proyecto: _________________________________
    Repos evaluados: 5
    Mejor repo: _____________ (score ___/7, licencia _____)
    Fork creado: [ ] Si — URL: _________________________________
    Contribucion: _____________ (PR / pendiente)
    
    LICENCIAS DE MI PROYECTO:
      Todas MIT/Apache? [ ] Si  [ ] Verificar: _____________
      THIRD_PARTY_LICENSES.md creado? [ ] Si  [ ] Pendiente
    

Recursos descargables

1. Guía de licencias OSS (PDF) — Comparativa visual de MIT, Apache, BSD, GPL, AGPL con decisión tree
2. Checklist evaluación repos (PDF) — Los 7 criterios en formato imprimible
3. Template CONTRIBUTING.md (Notion) — Para tus propios repos

Siguientes pasos

En la siguiente sesión (AB-08: Seguridad en proyectos IA) vas a aprender a proteger tu proyecto de los ataques más comunes: prompt injection, secretos expuestos, y el OWASP LLM Top 10.

Antes de pasar a AB-08:

• Has evaluado al menos 5 repos con los 7 criterios
• Has verificado las licencias de todas las dependencias de tu proyecto
• Has creado THIRD_PARTY_LICENSES.md si usas código OSS

Toolbox — Sesión 07 de 09

IAcademy — iacedemy.com