A gente tomou uma decisão aqui na agência que mudou a velocidade dos projetos: parar de construir tudo do zero. Quando aparece uma necessidade nova, a primeira pergunta deixou de ser "como eu faço isso" e virou "alguém já fez isso melhor do que eu faria". Quase sempre a resposta está no GitHub. Só que no caminho eu esbarrei num detalhe que eu nem sabia que existia.
Tem ferramenta open source pra quase tudo. Coisa madura, testada por milhares de pessoas, com anos de bug corrigido. Pegar uma dessas e adaptar é muito mais inteligente do que escrever a minha versão meia-boca, que vai quebrar no primeiro cliente. Isso virou regra aqui dentro. Usar o que já foi validado antes de inventar o meu.
Aí veio a ficha que eu quero dividir com você hoje.
Tá no GitHub não quer dizer que pode usar
Eu sempre achei que "está no GitHub" era a mesma coisa que "pode usar". Público, aberto, de graça. Está errado.
Código no GitHub sem um arquivo de licença é, por padrão, "todos os direitos reservados". Ou seja: você pode olhar, pode estudar, mas legalmente não pode usar no seu projeto, nem copiar, nem mexer. Está visível, mas não está liberado. São coisas diferentes.
Quem libera o uso de verdade é a licença. É um arquivinho na raiz do projeto, quase sempre chamado de LICENSE, que diz em miúdos: olha, você pode usar isso, e essas são as regras. Sem ele, o padrão é o mais fechado possível.
O mapa que eu queria ter tido antes
Depois de quebrar a cabeça, organizei tudo na minha cabeça em dois grandes times. Esse é o resumo que uso hoje pra decidir rápido.
O primeiro time é o das permissivas, as que deixam você usar quase à vontade:
- MIT. A mais comum e a mais tranquila. Pode usar, modificar, vender e até fechar o seu código. A única regra séria é manter o aviso de copyright original. É a que eu mais gosto pra agência.
- Apache 2.0. Parecida com a MIT, com um bônus importante: tem uma cláusula de patente que te protege juridicamente. Pede pra você sinalizar o que mudou.
- BSD. Mesma vibe liberal da MIT, bem de boa.
O segundo time é o do copyleft, as que têm contrapartida. Aqui vale ligar o alerta:
- GPL. A famosa "viral". Se você usa código GPL e distribui o seu produto, é obrigado a abrir o seu código também, sob a mesma licença. Pra quem faz produto fechado, é um sinal amarelo.
- AGPL. A GPL turbinada. Ela pega até quando você só roda o software como serviço na web. Se você oferece aquilo pela internet, tem que disponibilizar o código. É a mais pegajosa de todas.
- LGPL e MPL. Versões mais brandas do copyleft, pensadas pra bibliotecas. Dá pra usar sem ser obrigado a abrir tudo, dependendo de como você encaixa no projeto.
O hábito de 30 segundos que eu criei
Hoje, antes de adotar qualquer ferramenta do GitHub, eu faço uma checagem rápida que virou automático:
- Tem arquivo LICENSE? Se não tem, eu nem considero, ou pergunto pro autor.
- Qual licença é? Se for MIT, Apache ou BSD, sigo tranquilo.
- É GPL ou AGPL? Aí eu paro e penso. Esse projeto vai ser fechado e comercial? Se for, procuro outra opção ou trato com muito cuidado.
Parece burocracia, mas é o contrário. É isso que me deixa construir rápido e dormir tranquilo. Eu uso o que já existe, em vez de reinventar, sabendo exatamente o que posso e o que não posso.
A real
A lição que fica nem é sobre código. É sobre uma forma de trabalhar: não reinventar o que já foi validado. Tem gente que passou anos resolvendo um problema e te entregou a solução de graça. Pegar isso é inteligência, não preguiça.
Só que "de graça" tem letra miúda. E a letra miúda chama licença. Aprender a ler ela foi uma das coisas mais úteis que eu fiz esse ano, e olha que parecia o assunto mais chato do mundo. Fica a dica pra você: dá uma olhada no arquivo LICENSE do próximo projeto que for usar. Você vai começar a enxergar o GitHub com outros olhos.
Chegou até aqui? Clica pra eu saber que você curtiu.
Quer usar mais ferramenta pronta no seu negócio sem cair em cilada?
Eu monto muita coisa em cima de open source e gosto de conversar sobre o que funciona de verdade, sem complicar. Se quiser trocar ideia, me chama.
Falar contigo →